--- a/model/ProvenanceModel.html	Mon Nov 07 11:18:24 2011 +0000
+++ b/model/ProvenanceModel.html	Mon Nov 07 12:06:35 2011 +0000
@@ -309,8 +309,16 @@
     <section> 
 <h3>PROV-ASN: The Provenance Abstract Syntax Notation</h3>
 
-<p>This specification defines PROV-DM, a data model for provenance, and relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
-<em>instances</em> of that data model. </p>
+<p>This specification defines PROV-DM, a data model for provenance, consisting of provenance records describing how people, entities, and activities, were involved in producing,
+influencing, or delivering a piece of data or a thing in the world.</p>
+
+<p>This specification also relies on a language, PROV-ASN, the Provenance Abstract Syntax Notation, to express
+<em>instances</em> of that data model. 
+For each construct of PROV-DM, a corresponding ASN expression is introduced, by way of a production in the ASN grammar. </p>
+
+
+
+
 
 <p>PROV-ASN is an abstract syntax, whose goals are:
 <ul>

--- a/model/satya-comments-issue-100.txt	Mon Nov 07 11:18:24 2011 +0000
+++ b/model/satya-comments-issue-100.txt	Mon Nov 07 12:06:35 2011 +0000
@@ -8,24 +8,20 @@
   > component is Entity, I am confused why we are defining "Entity
   > Expression" and not "Entity"?
 
-An instance of an entity expression is syntactally written as 'entity',
-but we use the term 'entity expression' to make it clear that we
-refer to a PROV-DM construct (see intro of section 5.1)
-
-PM have the feeling that Satya's point will be echoed by others -- you expect an element of the model and you find an element of the language. 
-
-can we make an effort to keep the distinction model/language.
+An instance of an entity expression is syntactally written as
+'entity', but we use the term 'entity record' (was 'entity
+expression') to make it clear that we refer to a PROV-DM construct and
+not a thing in the world (see intro of section 5.1)
 
-PM how about introducing the entire sec. 2 with:
-
-"In this section, for each element of the model a corresponding ASN expression is introduced, by way of a production in the ASN grammar. "
+We also tried to make the distinction between the model and language clearer.
+So, we use 'records' to talk about prov-dm. 
 
-Then in 5.2.1:
-"In PROV-DM, an entity expression is a representation of an identifiable characterized thing."  
-becomes
-"In PROV-DM, an entity is a representation of an identifiable characterized thing." Entities are asserted using entity expressions, according to the following grammar production:
-É
+In section 2.2, we now write:
 
+  This specification also relies on a language, PROV-ASN, the
+  Provenance Abstract Syntax Notation, to express instances of that
+  data model. For each construct of PROV-DM, a corresponding ASN
+  expression is introduced, by way of a production in the ASN grammar.
 
 
   > 
@@ -43,8 +39,6 @@
 
 We refer to it with its identifier.
 
-PM identifier. not an issue
-
 
   > 
   > 3. The assertion of an instance of an entity expression, entity(id, [
@@ -81,7 +75,7 @@
   End could be the destructive consumption of an entity: egg broken to make a cake
 
 Luc: events are not observable, but time is. Not global time, but local time, found
-on local clocks, more or leass synchronized.
+on local clocks, more or less synchronized.
 
 
 
@@ -101,7 +95,7 @@
   > reconcile them later?
 
 The example of "luc in boston" in January and June has been discussed extensively.
-That theroretically, we can find distinguishing attributes, yes (luc with winter clothes
+Theroretically, we can find distinguishing attributes, yes (luc with winter clothes
 and summer clothes). But we have no requirements that these attributes are expressed.
 So, if we have just "luc in boston" as a characterization, the constraint makes sense.