--- a/model/comments/issue-332-Khalid.txt	Wed Apr 11 15:31:27 2012 +0100
+++ b/model/comments/issue-332-Khalid.txt	Wed Apr 11 16:30:10 2012 +0100
@@ -8,10 +8,13 @@
 2- Design Rationale for PROV-N
 * The number of examples that are given to illustrate the notation can be reduced. For example, 2 examples are used to illustrate PROV-N optional arguments. I think that at this stage, the reader does not know yet PROV-N expression, and therefore, it would be better to use one kind of expression, e.g., derivation, and use small number of examples.
 
+
 * The term expression, and expression identifier is used in this section, but it is actually introduced in the section that follows.
 
 * "While not all PROV-DM relations are not binary, they involve two primary elements". I find the use of the term primary element a bit vague, specially when presenting a notation. Instead, I would use something in the following lines. "While most of PROV-DM relations are binary, such relations can be characterized (or qualified) using attributes."
 
+PM. edited.
+
 4 PROV-N Productions per Component
 * For several expressions, e.g. generation and start by activity, it is specified that certain allowed expressions are not valid. Take the example of generation, the text specify that when the expression contain information only about the entity generated, i.e., without mentioning the activity or the generation time, then the expression is not valid. Instead of doing so, and given that this document is only on annotation, I think we can reformulate the definition of expression to exclude invalid cases. To illustrate this, consider the case of generation. The definition of generation in the PROV-N document is as follows:
 

--- a/model/prov-n.html	Wed Apr 11 15:31:27 2012 +0100
+++ b/model/prov-n.html	Wed Apr 11 16:30:10 2012 +0100
@@ -245,26 +245,34 @@
 provenance, allowing provenance descriptions to be expressed  [[PROV-DM]]  and a set of constraints that provenance descriptions are expected to satisfy   [[PROV-DM-CONSTRAINTS]].
 </p>
 
+<section id="purpose"> 
+<h2>Purpose of this Document and target audience</h2>
 
-<p>In this context,  PROV-N is introduced as a notation to write instances of the PROV data model primarily aimed at human consumption. PROV-N allows
-serializations of PROV-DM instances to be written in a technology independent manner.
-So far, PROV-N has been used in the following ways:</p>
+This document describes PROV-N, a formal notation designed to express instances of the PROV data model in a way that is technology independent, and with human readabilty in mind. At the same time, PROV-N is a formal language, for which parsers can be implemented.
+
+PROV-N has several uses:
 <ul>
-<li> PROV-N is used to provide technology independent illustrations of provenance in [[PROV-DM]] and in the definition of PROV-DM constraints [[PROV-DM-CONSTRAINTS]];</li>
-<li> PROV-N is instrumental in defining the mapping of PROV-DM to concrete syntaxes. Mappings translate each PROV-N expression to RDF [[PROV-RDF]] and to XML [[PROV-XML]];</li>
-<li> PROV-N is the basis for a
-formal semantics, in which each PROV-N expression is provided with an interpretation [[PROV-SEM]].
+<li> It is the notation used in the examples found in  [[PROV-DM]], as well as in the definition of PROV-DM constraints [[PROV-DM-CONSTRAINTS]]; </li>
+<li>  It is a source language for the encoding of PROV-DM instances into a variety of target languages, including amongst others  RDF [[PROV-RDF]] and XML [[PROV-XML]]; </li>
+<li> It provides the basis for a formal semantics of PROV-DM  [[PROV-SEM]], in which an interpretation is given to each element of the PROV-N language.
 </ul>
 
-<p>PROV-N was designed to be as close as possible to PROV-DM without the syntactic bias and modelling constraints that concrete technologies bring with them, e.g., XML's choice between attribute and element, RDF's reliance on triples, or JSON's usage of dictionaries. </p>
+This document introduces the PROV-N grammar along with examples of its usage, and a justification for the language design choices.<br/>
+Its target audience includes primarily implementors of new PROV-DM encodings, and thus in particular of PROV-N parsers. It also includes those readers of the  [[PROV-DM]] and of  [[PROV-DM-CONSTRAINTS]] documents, who are interested in the details of the formal language underpinning the notation used in the examples and in the definition of the constraints.
 
-<p>The purpose of this document is solely to define the syntax of PROV-N.
-For each construct of PROV-DM, a corresponding PROV-N expression is introduced, by way of a production in the PROV-N grammar presented in this document. </p> 
+<!--
+<p>PROV-N was designed to be as close as possible to PROV-DM without the syntactic bias and modelling constraints that concrete technologies bring with them, e.g., XML's choice between attribute and element, RDF's reliance on triples, or JSON's usage of dictionaries. </p>
+-->
 
+</section>
 
     <section id="structure-of-this-document"> 
 <h3>Structure of this Document</h3>
 
+This document defines a grammar using the Extended  Backus-Naur Form (EBNF) notation. Its productions correspond to constructs of PROV-DM.
+<br/>
+It is structured as follows.
+
 <p><a href="#prov-n-rationale">Section 2</a> provides the design rationale for the PROV Notation.</p>
 
 <p><a href="#grammar-notation">Section 3</a> defines the notation for the Extended  Backus-Naur Form (EBNF) grammar used in this specification.</p>
@@ -389,12 +397,17 @@
 
 
 <li id="subject-object-order">
-While  not all PROV-DM relations are binary, they all involve two primary elements.  The subject of the relation precedes its object.
+All PROV-DM relations involve two primary elements, the <em>subject</em> and the <em>object</em>, in this order. Furthermore, some relations also admit additional elements that further characterize it.
 <div class="anexample">
-The following expression states that <span class="name">e2</span> was generated by <span class="name">e1</span>; <span class="name">e2</span> is the subject, whereas <span class="name">e1</span> is the object.
+The following expression should be read as "<span class="name">e2</span> was generated by <span class="name">e1</span>". Here <span class="name">e2</span> is the subject, and  <span class="name">e1</span> is the object.
 <pre class="codeexample" >
 wasDerivedFrom(e2, e1)
 </pre>
+In the following expression, the optional activity <span class="name">a</span> has been added to further qualify the derivation:
+<pre class="codeexample" >
+wasDerivedFrom(e2, e1, a)
+</pre>
+ 
 </div>
 </li>
 </ul>