--- a/model/satya-comments-issue-100.txt	Thu Oct 06 23:31:48 2011 +0100
+++ b/model/satya-comments-issue-100.txt	Fri Oct 07 10:19:09 2011 +0200
@@ -12,6 +12,22 @@
 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.
+
+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. "
+
+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:
+É
+
+
+
   > 
   > 2. An instance of an entity expression, noted entity(id, [ attr1=val1,
   > ...]) in PROV-ASN contains an identifier id identifying a
@@ -27,6 +43,9 @@
 
 We refer to it with its identifier.
 
+PM identifier. not an issue
+
+
   > 
   > 3. The assertion of an instance of an entity expression, entity(id, [
   > attr1=val1, ...]), states, from a given asserter's viewpoint, the
@@ -44,7 +63,10 @@
 
 Does it really need to be defined explicitly?
 
-  > 
+PM there is a hidden issue here though: how do we get agreement on event ordering? isn't this a way to sweep agreement on time under the rug?
+I am not competent enough to see this through I'm afraid but I see this will creep back up on us
+
+
   > 4. If an asserter wishes to characterize a thing with the same
   > attribute-value pairs over several intervals, then they are required
   > to assert multiple entity expressions, each with its own identifier
@@ -65,6 +87,8 @@
 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.
 
+PM agreed
+
   > 
   > I believe this consideration is not required and adds a layer of complexity.
   > 
@@ -79,3 +103,6 @@
 
 That's why the whole model is event based.
 
+PM see my earlier comment. Satya has a point when he says events are "surrogates for time". 
+Have no solution, but need more discussion goinf forward. This issue will continue
+