account
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Thu, 15 Sep 2011 22:59:27 +0100
changeset 291 2807ccf4ae37
parent 290 35c543bd8d7e
child 292 0b04b3138f2c
account
model/ProvenanceModel.html
--- a/model/ProvenanceModel.html	Thu Sep 15 22:15:30 2011 +0100
+++ b/model/ProvenanceModel.html	Thu Sep 15 22:59:27 2011 +0100
@@ -37,6 +37,12 @@
           "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html\"><cite>Provenance Formal Model</cite></a>. "+
           "2011, Work in progress. "+
           "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html\">http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceFormalModel.html</a>",
+
+        "PROV-PAQ":
+          "Graham Klyne and Paul Groth "+
+          "<a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html\"><cite>Provenance Access and Query</cite></a>. "+
+          "2011, Work in progress. "+
+          "URL: <a href=\"http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html\">http://dvcs.w3.org/hg/prov/tip/paq/provenance-access.html</a>",
       };
       var respecConfig = {
           // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
@@ -1612,7 +1618,7 @@
 <h4>Annotation Association</h4>
 
 
-<p>An <dfn id="dfn-annotationAssociation">annotation association expression</dfn> establishes a link between a PROV-DM expression with an identifier and an annotation expression referred to by its identifier.  Multiple annotations can be associated with a given PROV-DM expression; symmetrically, multiple PROV-DM expressions can be associated with a given annotation. Since annotation expressions have identifiers,  we can also annotate annotation expressions. The annotation mechansim (with annotation expression and the annotation association expression) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p> 
+<p>An <dfn id="dfn-annotationAssociation">annotation association expression</dfn> establishes a link between a PROV-DM expression with an identifier and an annotation expression referred to by its identifier.  Multiple annotation expressions can be associated with a given PROV-DM expression; symmetrically, multiple PROV-DM expressions can be associated with a given annotation expression.  Since annotation expressions have identifiers,  they can also be annotated. The annotation mechanism (with annotation expression and the annotation association expression) forms a key aspect of the extensibility mechanism of PROV-DM (see <a href="#extensibility-section">extensibility section</a>).</p> 
 
 <p>In PROV-ASN, an annotation expression's text matches the <span class="nonterminal">annotationExpression</span> production of the grammar defined in this specification document.
 </p>
@@ -1636,7 +1642,7 @@
 hasAnnotation(e1,ann1)
 hasAnnotation(e2,ann1)
 </pre>
-assert the existence of two  documents in the world  (attribute-value pair: <span class="name">type="document"</span>) represented by entity expressions identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these expressions with an annotation, indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>.
+assert the existence of two  documents in the world  (attribute-value pair: <span class="name">type="document"</span>) represented by entity expressions identified by <span class="name">e1</span> and <span class="name">e2</span>, and annotate these expressions with an annotation indicating that the icon (an application specific way of rendering provenance) is <span class="name">doc.png</span>.
 </p>
 
 </section>
@@ -1645,7 +1651,7 @@
 <section  id="bundle">
 <h3>Bundle</h3>
 
-In this section, we introduce two constructs allowing us to group
+In this section, two constructs are introduced to group
 PROV-DM expressions.  The first
 one, <span class="nonterminal">accountExpression</span> is itself an
 expression, whereas the second
@@ -1688,21 +1694,10 @@
 <div class='note'>
 Currently, the non-terminal <span class="nonterminal">asserter</span> is defined as URI. We may want the asserter to be an agent instead, and therefore use PROV-DM to express the provenance of PROV-DM.  We seek inputs on how to resolve this issue. </div>
 
-<p>Account expressions constitue a scope for identifiers. An identifier within the scope of an account is intended to denote a single expression. However, nothing prevents an asserter from asserting an account containing, for example,  multiple entity expressions with a same identifier but different attribute-values. In that case, this should be understood the entity expression with this identifier, with the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identifier-in-account</a>.</p>
-
-<div class='constraint' id='identified-entity-in-account'>
-Given an identifiers <span class="name">e</span>,  two set of attribute-values <span class="name">av1</span> and <span class="name">av2</span>, 
- two entity expressions  <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account  are equivalent to the entity expression <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set given by the union of <span class="name">av1</span> and <span class="name">av2</span>.
-</div>
-
-<div class='note'>Luc: explain this may lead to inconsistency when attribute have different values. Also, extend to any expression with identity (agent,annotation) </div>
-
-<p>Account expressions can be nested since  an account expression can occur among the expressions being wrapped by another account. </p>
-
 <p>
 The following account expression
 <pre class="example">
-account(acc1,
+account(acc0,
         http://x.com/asserter, 
           entity(e0, [ type= "File", location= "/shared/crime.txt", creator= "Alice" ])
           ...
@@ -1714,16 +1709,40 @@
           ...
           wasControlledBy(pe4,a5, [role=communicator])  )
 </pre>
-contains the set of provenance expressions of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://x.com/asserter</span>, and is identified by identifier <span class="name">acc1</span>.
+contains the set of provenance expressions of section <a href="#example-prov-asn-encoding">example-prov-asn-encoding</a>, is asserted by agent <span class="name">http://x.com/asserter</span>, and is identified by identifier <span class="name">acc0</span>.
 </p>
 
+<p>Account expressions constitue a scope for identifiers. An identifier within the scope of an account is intended to denote a single expression. However, nothing prevents an asserter from asserting an account containing, for example,  multiple entity expressions with a same identifier but different attribute-values. In that case, they should be understood as a single entity expression with this identifier, with the union of all attributes values, as formalized in <a href="#identified-entity-in-account">identified-entity-in-account</a>.</p>
+
+<div class='constraint' id='identified-entity-in-account'>
+Given an identifier <span class="name">e</span>,  two sets of attribute-values <span class="name">av1</span> and <span class="name">av2</span>, 
+ two entity expressions  <span class="name">entity(e,av1)</span> and <span class="name">entity(e,av2)</span> occurring in an account  are equivalent to the entity expression <span class="name">entity(e,av)</span> where <span class="name">av</span> is the set formed by the union of <span class="name">av1</span> and <span class="name">av2</span>.
+</div>
+
+<p>Whilst constraint <a href="#identified-entity-in-account">identified-entity-in-account</a> specifies how to understand multiple entity expressions with a same identifier within a given account, it does not guarantee that the entity expression formed with the union of all attributes is consistent. Indeed, a given attribute may be assigned multiple values, resulting in an inconsistent entity expression, as illustrated by the following example.</p>
+
+<p>
+In the following account expression, we find two entity expressions with a same identifier <span class="name">e</span>.
+<pre class="example">
+account(acc1,
+        http://x.com/id,
+          entity(e,[type="person",age=20])
+          entity(e,[type="person",age=30])
+          ...)
+</pre>
+Application of <a href="#identified-entity-in-account">identified-entity-in-account</a> results in an entity expression containing the attributes <span class="name">age=20</span> and <span class="name">age=30</span>. This results in an inconsistent characterization of a person. We note that deciding whether a set of attribute-values is consistent or not is application specific.
+</p>
+
+<p>Account expressions can be nested since  an account expression can occur among the expressions being wrapped by another account. </p>
+
+
 <p>
 An account is said to be well-formed if
 it satisfied the constraints  <a href="#generation-unicity">generation-unicity</a> and <a href="#derivation-use">derivation-use</a>.</p>
 
 <p> The union of two accounts is another account, 
 containing the unions of their respective expressions, where
- expressions with a same identifier should be understood according to constraint <a href="#identified-entity-in-account">. Well-formed
+ expressions with a same identifier should be understood according to constraint <a href="#identified-entity-in-account">identified-entity-in-account</a>. Well-formed
 accounts are not
 closed under union because the
 constraint <a href="#generation-unicity">generation-unicity</a> may no
@@ -1742,7 +1761,7 @@
           wasGeneratedBy(e0,pe1,outFile)     
           ... )
 </pre>
-with identifier <span class="name">acc2</span>, containing assertions by asserter by <span class="name">http://x.com/asserter2</span> stating that entity expression identified by <span class="name">e0</span> was generated by process execution expression identified by <span class="name">pe1</span> instead of <span class="name">pe0</span> in the previous account <span class="name">acc1</span>.  If both account are merged together, the resulting set of expressions violates <a href="#generation-unicity">generation-unicity</a>.</p>
+with identifier <span class="name">acc2</span>, containing assertions by asserter by <span class="name">http://x.com/asserter2</span> stating that thing represented by entity expression identified by <span class="name">e0</span> was generated by an activity represented by process execution expression identified by <span class="name">pe1</span> instead of <span class="name">pe0</span> in the previous account <span class="name">acc0</span>.  If accounts <span class="name">acc0</span> and <span class="name">acc2</span> are merged together, the resulting set of expressions violates <a href="#generation-unicity">generation-unicity</a>.</p>
 
 <p>Account expressions constitue a scope for identifiers. Since accounts can be nested, their scope can also be nested; thus, the scope of identifiers should be understood in the context of such nested scopes.  When an identifiable expression occurs directly within an account, then its identifier denotes this identifiable expression in the scope of this account, except in sub-accounts where expressions with the same identifier occur. </p>
 
@@ -1761,7 +1780,7 @@
                  wasGeneratedBy(e1,pe0,outFile)
                  isComplement(e1,e0)))
 </pre>
-Alternatively, a process expression identified by <span class="name">pe0</span> occurs in each of the two accounts. Therefore, they constitue process execution expression in separate scope, which may represent different characterized things in the world.
+Alternatively, a process execution expression identified by <span class="name">pe0</span> occurs in each of the two accounts. Therefore,  each process execution expression is asserted in a separate scope, and therefore may represent different activities in the world.
 </p>
 
 <p>The account expression is the hook by which further meta information can be expressed about provenance, such as asserter, time of creation, signatures. How general meta-information is expressed is beyond the scope of this specification, except for asserters.</p>
@@ -1772,7 +1791,7 @@
 <section id="ProvenanceContainer">
 <h4>Provenance Container</h4>
 
-<p>A <dfn id="dfn-ProvenanceContainer">provenance container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM expressions. A provenance container is not an expression, but can be exploited to return all the provenance assertions in response to a request for the provenance of something (here, refer to PAQ document). </p> 
+<p>A <dfn id="dfn-ProvenanceContainer">provenance container</dfn> is a house-keeping construct of PROV-DM, also capable of bundling PROV-DM expressions. A provenance container is not an expression, but can be exploited to return all the provenance assertions in response to a request for the provenance of something ([[PROV-PAQ]]). </p> 
 
 <p>In PROV-ASN, a provenance container's text matches the <span class="nonterminal">provenanceContainer</span> production of the grammar defined in this specification document.</p>
 
@@ -1791,7 +1810,7 @@
 
 <p>An instance of a provenance container, noted <span class="name">provenanceContainer(decls, ids, exprs)</span> in PROV-ASN:
 <ul>
-<li> contains a set of namespace declarations  <span class="name">decls</span>, declaring namespaces and associated prefixes, which can be used in attributes (conformant to production <span class="nonterminal">attribute</span>) and names (conformant to production <span class="nonterminal">name</span>) in  <span class="name">exprs</span>;</li>
+<li> contains a set of namespace declarations  <span class="name">decls</span>, declaring namespaces and associated prefixes, which can be used in attributes (conformant to production <span class="nonterminal">attribute</span>) and in names (conformant to production <span class="nonterminal">name</span>) in  <span class="name">exprs</span>;</li>
 <li> contains a set of identifiers <span class="name">ids</span> naming all accounts occurring (at any nesting level) in  <span class="name">exprs</span>;</li>
 <li> contains one or more  expressions <span class="name">exprs</span>.</li>
 </ul>
@@ -1800,7 +1819,7 @@
 <p>
 The following container 
 <pre class="example">
-container([x http://x.com#],[acc1,acc2]
+container([x http://x.com],[acc1,acc2]
           account(acc1,http://x.com/asserter1,...)
           account(acc2,http://x.com/asserter1,...))
 </pre>
@@ -1810,24 +1829,8 @@
 
 <div class='pending'>Asserter needs to be defined. This is <a href="http://www.w3.org/2011/prov/track/issues/51">ISSUE-51</a>.</div>
 
-<div class='note'>The scope of identifiers needs to be discussed. We should recycle the following text which appeared in a previous version.
-
-<p>The data model includes a notion of "provenance container" that is
- a logical grouping for a set of assertions. It serves multiple
- purposes.  First, it provides a way to attach various metadata to the
- set of assertions.  Second, it provides a scope in which some constraints may apply.
- Third, it provides a default scope for
- identifiers used in assertions.  This means that identifiers are
- expected to be resolvable only within the scope of a container,
- rather than globally. Optionally, identifiers can be exported so that
- they can be used outside their default scope.  Finally, the data
- model does not prescribe the mechanisms by which identifiers are
- generated.</p>
-
-
-</div>
-
-<div class='issue'>Scope and Identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/81">ISSUE-81</a>.</div>
+
+<div class='pending'>Scope and Identifiers. This is <a href="http://www.w3.org/2011/prov/track/issues/81">ISSUE-81</a>.</div>
 
 
 </section>