section 5
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Mon, 13 Feb 2012 21:19:57 +0000
changeset 1538 4eb4f099bcca
parent 1537 daaa83707238
child 1539 0dc9105def79
section 5
model/working-copy/towards-wd4.html
--- a/model/working-copy/towards-wd4.html	Mon Feb 13 13:08:18 2012 +0000
+++ b/model/working-copy/towards-wd4.html	Mon Feb 13 21:19:57 2012 +0000
@@ -685,7 +685,7 @@
 <div style="text-align: center;">
   <figure>
   <img src="http://www.w3.org/2011/prov/wiki/images/c/cd/W3c-publication3.png" alt="Provenance of a Tech Report (b)" style="max-width: 98%; "/>
-<figcaption>Provenance of a Tech Report (b)</figcaption>
+<figcaption id="prov-tech-report">Provenance of a Tech Report (b)</figcaption>
   </figure>
 </div>
 </section>
@@ -1170,7 +1170,7 @@
 
 <p>A <dfn title="dfn-responsibility-chain">responsibility chain</dfn><span class="withAsn">, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN,</span> has the following constituents:</p>
 <ul>
-<li><em>id</em>:  an OPTIONAL identifier  <span class="name">id</span> identifying the responsibility chain;</li> 
+<li><em>id</em>:  an OPTIONAL identifier identifying the responsibility chain;</li> 
 <li><em>subordinate</em>: an identifier for the agent associated with an activity, acting on behalf of the responsible
 agent;</li>
 <li><em>responsible</em>: an identifier for the agent,  on behalf of which the subordinate agent acted;</li>
@@ -1382,7 +1382,7 @@
 <li><em>id</em>:  an OPTIONAL identifier for the association between the two alternates;</li>
 <li><em>firstAlternate</em>: an identifier of the first of the two entities;</li>
 <li><em>secondAlternate</em>: an identifier of the second of the two entities;</li>
-<li><em>attrs</em>: an OPTIONAL set of attribute-value pairs to further describe this relation.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this relation.</li>
 </ul>
 
 
@@ -1392,7 +1392,7 @@
 <li><em>id</em>:  an OPTIONAL identifier for the association between the two entities;</li>
 <li><em>specializedEntity</em>: an identifier of the specialised entity;</li>
 <li><em>generalEntity</em>: an identifier of the entity that is being specialised;</li>
-<li><em>attrs</em>: an OPTIONAL set of attribute-value pairs to further describe this relation.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this relation.</li>
 </ul>
 
 
@@ -1418,8 +1418,9 @@
 annotated. The annotation mechanism (with note and annotation) forms a key aspect of the extensibility mechanism of PROV-DM (see <a
 href="#extensibility-section">extensibility section</a>).</p> 
 
-<p>An <dfn title="dfn-annotation">annotation</dfn><span class="withAsn">, written <span class="name">hasAnnotation(r,n,attrs)</span> in PROV-ASN,</span> has the following constituents:</p>
+<p>An <dfn title="dfn-annotation">annotation</dfn><span class="withAsn">, written <span class="name">hasAnnotation(id,r,n,attrs)</span> in PROV-ASN,</span> has the following constituents:</p>
 <ul>
+<li><em>id</em>:  an OPTIONAL identifier for this relation;</li>
 <li><em>something</em>: the identifier of someting being annnotated;</li>
 <li><em>note</em>: an identifier of a note;</li>
 <li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe this annotation.</li>
@@ -1467,34 +1468,35 @@
 <section id="term-NamespaceDeclaration">
 <h3>Namespace Declaration</h3>
 
-<p>A PROV-DM <dfn title="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals of with datatype <span
-class="name">xsd:QName</span> can be placed in a namespace using the mechanisms described in this specification. </p>
-
-
-<p>A <dfn title="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
+<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI reference [[!IRI]]. In PROV-DM, attributes, identifiers, and literals with <a title="qualified name">qualified names</a> as data type can be placed in a namespace using the mechanisms described in this specification. </p>
+
+
+<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
 declaration refers to this namespace. 
-A <dfn title="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration
+A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every unprefixed qualified name in the scope of this default namespace declaration
 refers to this namespace.</p>
+
+<p>The PROV-DM namespace is <span class="name">http://www.w3.org/ns/prov-dm/</span> (TBC).</p>
+
 </section>
 
 <section id="term-identifier">
 <h4>Identifier</h4>
 
 <p>
-An <dfn title="dfn-identifier">identifier</dfn> is a <a>qualified
+An <dfn id="dfn-identifier">identifier</dfn> is a <a>qualified
  name</a>. 
 </p>
 
 <p>
-A <dfn title="dfn-qualifiedname">qualified name</dfn> is a name subject to <a>namespace</a> interpretation. It consists of <a>namespace</a>, denoted by an optional prefix, and a local name.</p>
+A <dfn id="dfn-qualifiedName">qualified name</dfn> is a name subject to <a>namespace</a> interpretation. It consists of a <a>namespace</a>, denoted by an optional prefix, and a local name.</p>
 
 
 <p>PROV-DM stipulates that a qualified name can be mapped into an IRI
  by concatenating the IRI associated with the prefix and the local part.</p>
 
 <p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
- qualified name, it refers to a <a>namespace</a> declared in the
- record container.  In the absence of prefix, the qualified name
+ qualified name, it refers to a <a>namespace</a> declared in a namespace declaration.  In the absence of prefix, the qualified name 
  refers to the <a title="default namespace declaration">default namespace</a>.</p>
 
 </section>
@@ -1513,7 +1515,7 @@
 
 <p>The attribute <dfn title="dfn-role"><span class="name">prov:role</span></dfn>  denotes the function of an entity with respect to an activity, in the context of a usage, generation,
 activity association, activity start, and activity end. The attribute <span class="name">prov:role</span> is allowed to occur multiple times in a list of attribute-value pairs. The value associated with a <span
-class="name">prov:role</span> attribute MUST be conformant with  <span class="nonterminal">Literal</span>.</p>
+class="name">prov:role</span> attribute MUST be a PROV-DM <a title="literal">Literal</a>.</p>
 
 <div class="anexample">
 <p>The following activity start describes the role of the agent identified by <span class="name">ag</span> in this start relation with activity <span class="name">a</span>. </p>
@@ -1528,7 +1530,7 @@
 
 <p>The attribute <dfn title="dfn-type"><span class="name">prov:type</span></dfn>  provides further typing information for an element or relation. PROV-DM liberally
 defines a type as a category of things having common characteristics. PROV-DM is agnostic about the representation of types, and only states that
-the value associated with a <span class="name">prov:type</span> attribute MUST be conformant with  <span class="nonterminal">Literal</span>. The attribute <span class="name">prov:type</span>
+the value associated with a <span class="name">prov:type</span> attribute MUST be a PROV-DM Literal. The attribute <span class="name">prov:type</span>
 is allowed to occur multiple times.</p>
 
 <div class="anexample">
@@ -1559,7 +1561,7 @@
 <section id="term-attribute-label">
 <h4>prov:label</h4>
 
-<p> The attribute <dfn title="dfn-label"><span class="name">prov:label</span></dfn> provides a human-readable representation of a PROV-DM element or relation.</p>
+<p> The attribute <dfn title="dfn-label"><span class="name">prov:label</span></dfn> provides a human-readable representation of a PROV-DM element or relation.  The value associated with the attribute <span class="name">prov:label</span> MUST be a string.</p>
 
 <div class='issue'>
  This is <a href="http://www.w3.org/2011/prov/track/issues/219">ISSUE-219</a>. </div>
@@ -1575,8 +1577,7 @@
 
 
 <p>
-The attribute <dfn title="dfn-location"><span class="name">prov:location</span></dfn> is an OPTIONAL attribute of entity and activity.  The value associated with the  attribute <span class="name">prov:location</span> MUST be a <span
-class="nonterminal">Literal</span>, expected to denote a location.
+The attribute <dfn title="dfn-location"><span class="name">prov:location</span></dfn> is an OPTIONAL attribute of entity and activity.  The value associated with the  attribute <span class="name">prov:location</span> MUST be a PROV-DM Literal, expected to denote a location.
 </p>
 
 
@@ -1593,6 +1594,10 @@
 <section id="term-literal">
 <h4>Literal</h4>
 
+<div class='note'>
+Usually, in programming languages, Literal are a notation for values. So, Literals should probably be moved to the serialization. Here, instead, we should define the types of values.  Thoughts?
+</div>
+
 <p>
 A PROV-DM Literal represents a data value such as a particular string
 or number.  A PROV-DM Literal represents a value whose interpretation is outside the scope of PROV-DM.
@@ -1607,10 +1612,9 @@
   1
   "http://example.org/foo" %% xsd:anyURI
 </pre>
-The following example shows a literal of type <span class="name">xsd:QName</span> (see
+<p>The following example shows a literal of type <span class="name">xsd:QName</span> (see
 <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName">QName</a> [[!XMLSCHEMA-2]]).
-The prefix <span class="name">ex</span>  MUST be bound to a <a>namespace</a> declared in the
- container.
+The prefix <span class="name">ex</span>  MUST be bound to a <a>namespace</a> declared in a <a>namespace declaration</a>.</p>
 <pre class="codeexample">
   "ex:value" %% xsd:QName
 </pre>
@@ -1675,7 +1679,22 @@
 <li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe properties of the relation.</li>
 </ul>
 
-
+<div class="anexample">
+<p>We refer to the example of <a href="#section-example-a">Section 3.1</a>, and specifically to <a href="#prov-tech-report">Figure prov-tech-report</a>. We can see that there is a path from 
+<span class="name">tr:WD-prov-dm-20111215</span> to 
+<span class="name">w3:Consortium</span> or to
+<span class="name">pr:rec-advance</span>. This is expressed as follows.
+<pre class="codeexample">
+ tracedTo(tr:WD-prov-dm-20111215,w3:Consortium)
+ tracedTo(tr:WD-prov-dm-20111215,pr:rec-advance)
+</pre>
+</div>
+
+
+
+
+<div class='note'>
+  I propose to delete the following, given that this document does not mention inferences.
 <p>Further considerations:</p>
 <ul>
   <li>Traceability is more general than <a href="#Derivation-Relation">Derivation</a>. This means that an assertion of the form: <span class="name">tracedTo(...,e2,e1,...)</span> can be inferred from an assertion of the form:
@@ -1683,10 +1702,8 @@
  <li>Traceability is related to responsibility by way of inference rules that involve <a href="#term-responsibility">responsibility chain</a> and <a href="#term-Generation">generation</a> relations.
   These rules are specified in [REF]
 </ul>
-
- <div class="anexample">
-<div class="note"> need an example. Text uses 'assertion'. Should we drop the above further considerations. </div>
 </div>
+
 </section>
 
 
@@ -1708,8 +1725,10 @@
 <li><em>id</em>:  an OPTIONAL identifier  identifying the relation;</li> 
 <li><em>informed</em>: the identifier of the informed activity;
 <li><em>informant</em>: the identifier of the informant activity;
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe properties of the relation.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe properties of the relation.</li>
 </ul>
+<p> Relation <span class="name">wasInformedBy</span> is not transitive.</p>
+
 
 <div class="anexample">
 <p>
@@ -1725,21 +1744,20 @@
 
 <p>
 A control ordering relation<span class="withAsn">, written as 
-<span class="name">wasStartedBy(a2,a1, attrs)</span> in PROV-ASN,</span> contains: </p>
+<span class="name">wasStartedBy(id, a2, a1, attrs)</span> in PROV-ASN,</span> contains: </p>
 <ul>
 <li><em>id</em>:  an OPTIONAL identifier of the relation;</li> 
 <li><em>started</em>: the identifier of  the started activity;
 <li><em>starter</em>: the identifier of the activity that started the other;</li>
-<li><em>attributes</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe the properties of the relation.</li>
+<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
 </ul>
 
 
-<p> Relation <span class="name">wasInformedBy</span> is not transitive.</p>
 
 
 <div class="anexample">
 <p>
-Suppose activities <span class="name">a1</span> and <span class="name">a2</span> are computer processes that are executed on different hosts, and that <span class="name">a1</span> started <span class="name">a1</span>. This can be expressed as follows:</p>
+Suppose activities <span class="name">a1</span> and <span class="name">a2</span> are computer processes that are executed on different hosts, and that <span class="name">a1</span> started <span class="name">a2</span>. This can be expressed as in the following fragment:</p>
 <pre class="codeexample">
 activity(a1,t1,t2,[ex:host="server1.example.org",prov:type="workflow"])
 activity(a2,t3,t4,[ex:host="server2.example.org",prov:type="subworkflow"])
@@ -1755,7 +1773,7 @@
 
 <p> A <dfn title="dfn-Revision">revision relation</dfn> is a particular case of  <a href="#Derivation-Relation">derivation</a> that states that an entity is a revised version of another. The agent who is responsible for making the revision may optionally be specified.</p>
 
-<p> A revision relation<span class="withAsn">, written <span class="name">wasRevisionOf(e2,e1,ag,attrs)</span> in PROV-ASN,</span> contains:</p>
+<p> A revision relation<span class="withAsn">, written <span class="name">wasRevisionOf(id,e2,e1,ag,attrs)</span> in PROV-ASN,</span> contains:</p>
 <ul>
 <li><em>id</em>: an OPTIONAL identifier for the relation;</li> 
 <li><em>newer</em>: the identifier of the revised  entity;
@@ -1792,9 +1810,9 @@
 <section id="term-attribution">
 <h3>Attribution</h3> 
 
-<p>An <dfn>attribution relation</dfn> states that an entity is attributed to an agent. More precisely, when an entity  <span class="name">e</span> is attributed to agent  <span class="name">ag</span>, entity <span class="name">e</span> was generated by some activity <span class="name">a</span>, which in turn was associated to agent  <span class="name">ag</span>. Thus, this relation is useful when the activity is not known, or irrelevant.
-
-<p> An attribution relation<span class="withAsn">, written <span class="name"> wasAttributedTo(e,ag,attr)</span> in PROV-ASN,</span> contains the following elements:</p>
+<p><dfn id="dfn-attribution">Attribution</dfn> is the ascribing of an entity to an agent. More precisely, when an entity  <span class="name">e</span> is attributed to agent  <span class="name">ag</span>, entity <span class="name">e</span> was generated by some activity <span class="name">a</span>, which in turn was associated to agent  <span class="name">ag</span>. Thus, this relation is useful when the activity is not known, or irrelevant.
+
+<p> An attribution relation<span class="withAsn">, written <span class="name"> wasAttributedTo(id,e,ag,attr)</span> in PROV-ASN,</span> contains the following elements:</p>
 <ul>
 <li><em>id</em>: an OPTIONAL identifier for the relation;</li> 
 <li><em>entity</em>: an entity identifier;</li>
@@ -1856,8 +1874,9 @@
 
 <p> An <dfn>original source relation</dfn> is a particular case of <a href="#Derivation-Relation">derivation</a> that states that an entity <span class="name">e2</span> (derived) was originally part of some other entity <span class="name">e1</span> (the original source).</p>
 
-<p> An original source relation<span class="withAsn">, written <span class="name"> hadOriginalSource(e2,e1,attrs)</span>,</span> contains:</p>
+<p> An original source relation<span class="withAsn">, written <span class="name"> hadOriginalSource(id,e2,e1,attrs)</span>,</span> contains:</p>
 <ul>
+<li><em>id</em>:  an OPTIONAL identifier identifying the relation;</li> 
 <li><em>derived</em>: an identifier for the derived entity; </li>
 <li><em>source</em>: an identifier  for the original source entity;</li>
 <li><em>attributes</em>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
@@ -1870,7 +1889,7 @@
 <section id="term-Collection">
 <h3>Collections</h3>
 
-<p><strong>Collection relations</strong> address the need to describe the evolution of entities that have a collection structure, that is, which may contain other entities. Specifically this section introduces a new built-in type for entities, called <span class="name">collection</span>, and two relations to describe the effect of adding elements to, and removing elements from, a collection entity.
+<p><strong>Collection relations</strong> address the need to describe the evolution of entities that have a collection structure, that is, which may contain other entities. Specifically, this section exploits the built-in type for entities, called <a title="concept-collection">collection</a>, and two relations to describe the effect of adding elements to, and removing elements from, a collection entity.
 The intent of these relations and entity types is to capture the <em>history of changes that occurred to a collection</em>. </p>
 
 <p>A collection is an entity that has a logical internal structure consisting of key-value pairs, often referred to as a map.
@@ -1885,7 +1904,7 @@
 The following relations relate a collection <span class="name">c1</span> with a collection <span class="name">c2</span> obtainted after adding or removing a new pair to (resp. from) <span class="name">c1</span>:
 
 <ul>
-  <li>Insertion relation <span class="name">CollectionAfterInsertion(c2,c1, k, v)</span> states that  <span class="name">c2</span> is the state of the collection
+  <li>Insertion relation <span class="name">CollectionAfterInsertion(c2, c1, k, v)</span> states that  <span class="name">c2</span> is the state of the collection
 following the insertion of pair <span class="name">(k,v)</span> into collection  <span class="name">c1</span>;</li>
 
 <li>  Removal relation <span class="name">CollectionAfterRemoval(c2,c1, k)</span> states that  <span class="name">c2</span> is  the  state of the collection following the removal of the pair corresponding to key  <span class="name">k</span> from  <span class="name">c1</span>.</li>
@@ -1922,6 +1941,10 @@
 <li><em>key</em>: the key corresponding to the (key, value) pair that has been deleted from the collection.</li>
 </ul>
 
+<div class='note'>
+I propose to call them afterInsertion instead of CollectionAfterInsertion (likewise, for deletion).
+What about attributes and optional Id?
+</div>
 
 
 <p>Further considerations:</p>
@@ -2026,7 +2049,7 @@
 <p>The PROV data model provides several extensibility points that allow designers to specialize it to specific applications or domains. We summarize these extensibility points here:
 
 <ul>
-<li> Attributes are constructs of the data model that allow representations of aspects of the world's entities and activities to be expressed.  Applications are free to introduce
+<li> Attributes occur in all elements and relations of the data model.  Applications are free to introduce 
 application-specific attributes, according to their perspective on the world.  Attributes for a given application can be distinguished by qualifying them with a prefix denoting a namespace
 declared in a namespace declaration.
 
@@ -2035,7 +2058,7 @@
 
 
 <li> Sets of Attribute-value pairs offer a mechanism to
-describe modalities of use, generation, and control  
+describe modalities of use, generation, activity association, and responsibility chain.  
 Such attributes are also qualified by namespaces.
 
 <p>To this end, the <a href="#prov-dm-namespace">PROV-DM namespace</a> declares a reserved attribute: <span class="name">role</span>.</p></li>
@@ -2053,8 +2076,7 @@
 </ul>
 
 <p>The PROV data model is designed to be application and technology independent, but specializations of PROV-DM are welcome and encouraged.  To ensure inter-operability, specializations of
-the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in this document. For instance, a qualified attribute on a domain
-specific entity MUST represent an aspect of an entity and this aspect MUST remain unchanged during the characterization's interval of this entity.</p>
+the PROV data model that exploit the extensibility points summarized in this section MUST preserve the semantics specified in the PROV-DM documents (part 1 to 3). </p>
 
 
 
@@ -2083,7 +2105,7 @@
 
 
 <li>
-<p> The example of <a href="#prov-dm-example">section 3</a> contains identifiers such as <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, which denotes a specific version of a technical report.  On the other hand, a URI such as <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a> points to the latest version of a document. In such circumstances, one needs to be cautious about provenance descriptions for such a document, to ensure that they remain valid as denoted resources change. </p>
+<p> The example of <a href="#prov-dm-example">section 3</a> contains identifiers such as <span class="name"><a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215">tr:WD-prov-dm-20111215</a></span>, which denotes a specific version of a technical report.  On the other hand, a URI such as <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a> points to the latest version of a document. One needs to be cautious about provenance descriptions for the latter document, to ensure that they remain valid as denoted resources change. </p>
 
 <p>To this end, PROV-DM allows asserters to describe "<em>partial states</em>" of entities by means of attributes and associated values. Some further constraints apply to the use of these attributes, since the values associated with them are expected to remain unchanged for some period of time. The constraints associated to attributes are also specified in the companion specification [[PROV-DM-CONSTRAINTS]].</p>
 
@@ -2091,14 +2113,13 @@
 </li>
 
 
-<li>It is assumed that some mechanism exists by which a set of provenance descriptions can be bundled up and named.  Such a mechanism is considered as not mature for standardization, and is outside the scope of PROV-DM.  Such a mechanism could be implemented in various, for instance, by:
+<li>The existence of some mechanism(s)  by which a set of provenance descriptions can be bundled up and named is assumed.  No such mechanism is considered as mature for standardization, and therefore such mechanisms remain outside the scope of PROV-DM.   Various ways of achieving this functionality exist, for instance, by:
 <ul>
 <li> packaging up a set of descriptions and exposing them as a Web resource;</li>
 <li> relying on specific serializations to name bundles of descriptions;</li>
 <li> using the idea of a service that is capable of associating provenance descriptions to whom they are attributed to.</li>
 </ul>
-<p>Even though a mechanism for packaging up provenance descriptions and naming them is not part of PROV-DM, it is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named blundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed.   The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that  <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.
-With these constraints, further inferences can be made, because records are more precise, and therefore, richer.</p>
+<p>Even though a mechanism for packaging up provenance descriptions and naming them is not part of PROV-DM, the idea of a bundle of descriptions is crucial to the PROV approach. Indeed, it allows multiple provenance perspectives to be provided for a given entity. It is also the mechanism by which provenance of provenance can be expressed. Such a named blundle is being referred to as an <dfn>account</dfn> and is regarded as an <a title="concept-accountEntity">AccountEntity</a> so that its provenance can be expressed.   The notion of account is specified in the companion specification [[PROV-DM-CONSTRAINTS]], as well as constraint that  <dfn>structurally well-formed</dfn> descriptions are expected to satisfy.</p>
 </li>