issue-437
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Mon, 09 Jul 2012 21:30:30 +0100
changeset 3817 1c354e5b7d4e
parent 3816 4a3a1070bf89
child 3818 ba61d65b887b
issue-437
model/comments/issue-437-graham.txt
model/prov-dm.html
--- a/model/comments/issue-437-graham.txt	Mon Jul 09 16:00:29 2012 -0400
+++ b/model/comments/issue-437-graham.txt	Mon Jul 09 21:30:30 2012 +0100
@@ -15,6 +15,9 @@
    > expressions used imply that ex:report1 and ex:report2 are bundles when
    > the defintion of mentionOf is taken into account.  I don't think this
    > is intended.
+
+Yes, James pointed this out too. 
+
    > 
    > (This comment is completely independent of my opposition to the
    > mentionOf construct as currently proposed.  I intend to construct my
@@ -35,6 +38,8 @@
    >   wasStartedBy(a1, a2) (activity a1 was started by activity a2)
    >   wasAssociatedWith(a2, ag) (agent ag was associated with activity a2)
    >   or wasInfluencedBy(a2, e) (entity e influenced activity a2)
+
+
    > 
    > So I'm thinking that wasStartedBy could be simplified by dropping the
    > entity parameter.  But that doesn't completely address my uncertainty.
@@ -42,6 +47,12 @@
    > Part of my problem here is that it's all a bit unclear, and I can see
    > different ways of expressing the idea that an agent started an
    > activity:
+
+Just to be clear, wasStartedBy is not about agents/responsibility.
+It links an activity to the bit of information/entity that made
+the activity start.
+
+
    > 
    > 1: wasStartedBy, as currently definbed 2: indirectly via another
    > activity, as suggested above 3: by direct involvement, as in
@@ -54,6 +65,10 @@
    > easier for people to generate provenance consistently if the options
    > on wasStartedBy could be simplified.
    > 
+
+
+There was a long debate and a WG resolution on this topic.
+
    > ...
    > 
    > Section 1.2
@@ -68,6 +83,9 @@
    > locate the namespace URIs, so having them buried under notational
    > conventions is not most helpful.
    > 
+
+Done.
+
    > ...
    > 
    > Section 2.2, para 1
@@ -76,6 +94,8 @@
    > provenance"
    > 
    > ...
+
+OK
    > 
    > Section 2.2.3
    > 
@@ -84,7 +104,11 @@
    > perspective, the essence of example given could be expressed without
    > knowing about the member/collection relationship.
    > 
-   > ...
+   > 
+
+Do you mean why collections are relevant to provenance descriptions?
+
+...
    > 
    > Section 3
    > 
@@ -94,6 +118,19 @@
    > functional notation and optional parameters.
    > 
    > ...
+
+
+What we can say here is limited to their syntax. The fact they are mappable to IRIs
+the notion of namespace etc, is introduced in sections 5.7.1 and
+5.7.5, it's not specific to prov-n.
+
+
+So, I have added the following sentence:
+
+<li>The PROV data model defines <em>identifiers</em> as qualified names; in PROV-N, they are expressed as a local name optionally preceded of a prefix and a colon. </li>
+
+
+
    > 
    > Section 5.1.8, example 28
    > 
@@ -101,6 +138,11 @@
    > *entity*.  I'd suggest dropping this example, as it seems rather
    > contrived to me.
    > 
+
+
+It's a good example. Similar to a winning lottery ticket, claimed or not claimed.
+
+
    > ...
    > 
    > Section 5.6.2, memberOf parameter "complete"
@@ -114,6 +156,10 @@
    > meaningful way.
    > 
    > ...
+
+
+Updated as you suggested, closed or open.
+
    > 
    > Section 5.7.4
    > 
@@ -122,6 +168,10 @@
    > useful purpose here.
    > 
    > ...
+
+No change here.
+
+
    > 
    > End of comments.
    > 
--- a/model/prov-dm.html	Mon Jul 09 16:00:29 2012 -0400
+++ b/model/prov-dm.html	Mon Jul 09 21:30:30 2012 +0100
@@ -598,6 +598,16 @@
       "OPTIONAL" in this document are to be interpreted as described in
       [[!RFC2119]].</p>
 
+<p> 
+  Examples throughout this document use the PROV-N Provenance
+  Notation, briefly introduced in <a href="#prov-notation">Section 3</a> and specified fully in a separate document [[PROV-N]].</p>
+
+
+
+</section> 
+
+<section id="namespaces"> 
+<h3>Namespaces</h3>
 
 <p>
 The following namespaces prefixes are used throughout this document.
@@ -613,10 +623,6 @@
 </table>
 </div>
 
-<p> 
-  Examples throughout this document use the PROV-N Provenance
-  Notation, briefly introduced in <a href="#prov-notation">Section 3</a> and specified fully in a separate document [[PROV-N]].</p>
-
 
 </section> 
 
@@ -628,7 +634,7 @@
 <h1>PROV Overview</h1>
 
 <p>This section introduces provenance concepts with informal explanations and illustrative
-examples. PROV distinguishes  <em>core structures</em>, forming the essence of  provenance, from <em>extended structures</em> catering for more advanced uses of provenance.  Core and extended structures are respectively presented in <a href="#core-structures">Section 2.1</a> and <a href="#section-extended-structures">Section 2.2</a>. Furthermore, the PROV data model is organized according to components, which form thematic groupings of concepts (see <a href="#section-overview-components">Section 2.3</a>). A <em>provenance description</em> is an instance of  a core and extended provenance structure described below.
+examples. PROV distinguishes  <em>core structures</em>, forming the essence of  provenance, from <em>extended structures</em> catering for more specific uses of provenance.  Core and extended structures are respectively presented in <a href="#core-structures">Section 2.1</a> and <a href="#section-extended-structures">Section 2.2</a>. Furthermore, the PROV data model is organized according to components, which form thematic groupings of concepts (see <a href="#section-overview-components">Section 2.3</a>). A <em>provenance description</em> is an instance of  a core and extended provenance structure described below.
 </p>
 
 
@@ -1139,7 +1145,7 @@
 </section>
 
 
-<section id="prov-notation"> 
+<section id="prov-notation">  
 <h2>The Provenance Notation</h2>
 
 
@@ -1152,6 +1158,10 @@
 
 <li>The interpretation of PROV-N arguments is defined according to their <em>position</em> in the list of arguments. This convention allows for a compact notation. </li>
 
+<li>The PROV data model defines <em>identifiers</em> as qualified names; in PROV-N, they are expressed as a local name optionally preceded of a prefix and a colon. </li>
+
+
+
 <li>
 PROV-N <em>optional arguments</em> need not be specified:
 the general rule for optional arguments is that, if none of them are used in the expression, then they are simply omitted, resulting in a simpler expression. However, it may be the case that only some of the optional arguments need to be specified. Because the position of the arguments in the expression matters, in this case, an additional marker must be used to indicate that a particular term is not available. The syntactic marker  '<span class="name">-</span>' is used for this purpose.
@@ -3185,9 +3195,9 @@
 <li><span class='attribute' id="membership.complete">complete</span>: an OPTIONAL boolean 
 <a title="value">Value</a> (<span class="name">cplt</span>). It is interpreted as follows:
 <ul>
-<li>if it is present and set to true, then c is believed to include all and only the members specified in the entity-set;
-<li>if it is present and set to false, then c is believed to include more members in addition to those specified in the entity-set;
-<li>if it is not present, then c is believed to include all the members specified in the entity-set, and it MAY include more.
+<li>if it is present and set to true, then 
+<span class="name">c</span> is believed to include all and only the members specified in the entity-set;
+<li>if it is present and set to false or if it is not present, then <span class="name">c</span> is believed to include more members in addition to those specified in the entity-set.
 </ul>
 
 <li><span class='attribute' id="membership.attributes">attributes</span>: an OPTIONAL set (<span class="name">attrs</span>) of attribute-value pairs representing additional information about this relation.</li>