--- a/model/working-copy/prov-dm-constraints.html Mon Feb 13 21:50:56 2012 +0000
+++ b/model/working-copy/prov-dm-constraints.html Mon Feb 13 22:15:47 2012 +0000
@@ -511,63 +511,12 @@
<h4>Entity Record</h4>
-<p>In PROV-DM, an <dfn id="dfn-entity">entity record</dfn> is a representation of an entity.</p>
-
-
-<p>Examples of entities include a car on a road, a linked data set, a sparse-matrix matrix of floating-point numbers, a document in a directory, the same document published on the Web, and
-meta-data embedded in a document.</p>
-
-<p>An entity record, noted <span class="name">entity(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an entity; </li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this entity's situation in the world.</li>
-</ul>
-
<p>
The assertion of an entity record states, from a given asserter's viewpoint, the existence of an entity, whose situation in the world is represented by the attribute-value pairs, which
remain unchanged during a characterization interval, i.e. a continuous interval between two <a title="event">instantaneous events</a> in the world.
</p>
-<p>
-In PROV-ASN, an entity record's text matches the <span class="nonterminal">entityRecord</span> production of the grammar defined in this specification document.
-</p>
-
-<div class='grammar'>
-<span class="nonterminal">entityRecord</span> ::=
-<span class="name">entity</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/><br/>
-<!-- -->
-<span class="nonterminal">optional-attribute-values</span> ::=
-<span class="optional"><span class="name">,</span>
-<span class="name">[</span>
-<span class="nonterminal">attribute-values</span>
-<span class="name">]</span>
-</span><br/>
-<span class="nonterminal">attribute-values</span> ::=
-<span class="nonterminal">attribute-value</span>
-| <span class="nonterminal">attribute-value</span> <span class="name">,</span> <span class="nonterminal">attribute-values</span>
-<br/>
-<span class="nonterminal">attribute-value</span> ::=
-<span class="nonterminal">attribute</span>
-<span class="name">=</span>
-<span class="nonterminal">Literal</span>
-<br/>
-</div>
-
-<div class="anexample">
-<p>
-The following entity record,</p>
-<pre class="codeexample">
-entity(e0, [ prov:type="File", ex:path="/shared/crime.txt", ex:creator="Alice" ])
-</pre>
-states the existence of an entity, denoted by identifier <span class="name">e0</span>, with type <span class="name">File</span> and path <span class="name">/shared/crime.txt</span> in the
-file system, and creator alice The attributes <span class="name">path</span> and <span class="name">creator</span> are application specific, whereas the attribute <span
-class="name">type</span> is reserved in the PROV-DM namespace.
-</div>
Further considerations:
<ul>
@@ -602,17 +551,6 @@
as <a>attribute occurrence validity</a>.</li>
-<li>Activities are not represented by entity records, but instead by activity records, as explained below.</li>
-</ul>
-
-<p>Furthermore, section <a href="#record-ActivityAssociation">Activity Association Record</a>, introduces the idea of <em>plans</em> being associated with activities:</p>
-<ul>
-<li><span class="name">Plan</span>: entities of type <a >plan</a> that represent a set of
-actions or steps intended by one or more agents to achieve some goals.</li>
-</ul>
-
-
-
<div class='issue'>The characterization interval of an entity record is currently implicit. Making it explicit would allow us to define alternateOf and specializationOf more precisely.
@@ -628,7 +566,7 @@
<section id="record-Activity">
<h3>Activity Record</h3>
-<p>In PROV-DM, an <dfn id="dfn-activity">activity record</dfn> is a representation of an identifiable activity, which performs a piece of work.</p>
+
<p>An activity, represented by an activity record, is delimited by its <a title="activity start event">start</a> and its <a title="activity end event">end</a> events; hence, it occurs over
@@ -638,49 +576,6 @@
interpretation of attribute for entity record: an activity record's attribute remains constant for the duration of the activity it represents. Further characteristics of the activity in the
world can be represented by other attribute-value pairs, which MUST also remain unchanged during the activity duration.</p>
-<p>
-Examples of activities include driving a car from Boston to Cambridge, assembling a data set based on a set of measurements, performing a statistical analysis over a data set, sorting news
-items according to some criteria, running a sparql query over a triple store, editing a file, and publishing a web page. </p>
-
-<p> An activity record, written <span class="name">activity(id, st, et, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an activity;</li>
-<!--<li><em>recipeLink</em>: an OPTIONAL <a href="#record-RecipeLink">recipe link</a> <span class="name">rl</span>, which consists of a domain specific specification of the activity;</li>-->
-<li><em>startTime</em>: an OPTIONAL time <span class="name">st</span> indicating the start of the activity;</li>
-<li><em>endTime</em>: an OPTIONAL time <span class="name">et</span> indicating the end of the activity;</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing other attributes of this activity that hold for its whole
-duration.</li>
-</ul>
-
-<p>In PROV-ASN, an activity record's text matches the <span class='nonterminal'>activityRecord</span> production of the grammar defined in this specification document.</p>
-
-
-
-<div class='grammar'>
-<span class="nonterminal">activityRecord</span> ::=
-<span class="name">activity</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">time</span></span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">time</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="anexample">
-<p>
-The following activity record</p>
-<pre class="codeexample">
-activity(a1,2011-11-16T16:05:00,2011-11-16T16:06:00,
- [ex:host="server.example.org",prov:type="ex:edit" %% xsd:QName])
-</pre>
-<p>states the existence of an activity identified by <span class="name">a1</span>, start time <span class="name">2011-11-16T16:05:00</span>, and end time <span
-class="name">2011-11-16T16:06:00</span>, running on host <span class="name">server.example.org</span>, and of type <span class="name">edit</span> (declared in some namespace with prefix
-<span class="name">ex</span>). The attribute <span class="name">host</span> is application specific, but MUST hold for the duration of activity. The attribute <span
-class="name">type</span> is a reserved attribute of PROV-DM, allowing for subtyping to be expressed.</p>
-</div>
<div class="interpretation-forward">
For the interpretation of an activity record, see <a href="#start-precedes-end">start-precedes-end</a>.
@@ -719,60 +614,8 @@
-<p>An <dfn id="dfn-Agent">agent record</dfn> is a representation of an agent, which is an entity that can be assigned some degree of responsibility for an activity taking place.</p>
-
-<p>Many agents can have an association with a given activity. An agent may do the ordering of the activity, another agent may do its design, another agent may push the button to start it,
-another agent may run it, etc.
-As many agents as one wishes to mention can occur in the provenance record, if it is important to indicate that they were associated with the activity. </p>
-
-<p>
-From an inter-operability perspective, it is useful to define some basic categories of agents since
-it will improve the use of provenance records by applications.
-There should be very few of these basic categories to keep the model simple and accessible.
-There are three types of agents in the model since they are common across most anticipated domain of use:
-<ul>
-<li><span class="name">Person</span>: agents of type Person are people. (This type is equivalent to a "foaf:person" [[FOAF]])</li>
-<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc. (This type is equivalent to a "foaf:organization"
-[[FOAF]])</li>
-<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
-</ul>
-<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
-
-
-<p>An agent record, noted <span class="name">agent(id, [ attr1=val1, ...])</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an identifier <span class="name">id</span> identifying an agent;</li>
-<li><em>attributes</em>: contains a set of attribute-value pairs <span class="name">[ attr1=val1, ...]</span>, representing this agent's situation in the world.</li>
-</ul>
-
-<p>In PROV-ASN, an agent record's text matches the <span class="nonterminal">agentRecord</span> production of the grammar defined in this specification document.
-</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">agentRecord</span> ::=
-<span class="name">agent</span>
-<span class="name">(</span>
-<span class="nonterminal">identifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-
-
-<div class="anexample">
-<p>With the following assertions,</p>
-<pre class="codeexample">
-agent(e1, [ex:employee="1234", ex:name="Alice", prov:type="prov:Person" %% xsd:QName])
-
-entity(e2) and wasStartedBy(a1,e2,[prov:role="author"])
-
-entity(e3) and wasAssociatedWith(a1,e3,[prov:role="sponsor"])
-</pre>
-<p>the agent record represents an explicit agent identified by <span class="name">e1</span> that holds irrespective of activities it may be associated with. On the other hand, from the
-entity records identified by <span class="name">e2</span> and <span class="name">e3</span>, one can infer agent records, as per the following inference.</p>
-</div>
+
+
<p>One can assert an agent record or alternatively, one can infer an agent record
by its association with an activity. </p>
@@ -816,28 +659,7 @@
<section id="record-relation">
<h3>PROV-DM Relations</h3>
-<p>This section describes all the PROV-DM records representing relations between the elements introduced in <a href="#record-element">Section Element</a>. While these relations are not
-binary, they all involve two primary elements. They can be summarized as follows. </p>
-
-
-<div style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption>PROV-DM Core Relation Summary</caption>
-<tr><td></td><td>Entity</td><td>Activity</td><td>Agent</td><td>Note</td></tr>
-<tr><td>Entity</td><td><a title="derivation record">wasDerivedFrom</a><br><a title="alternate record">alternateOf</a><br><a title="specialization record">specializationOf</a></td><td><a
-title="generation record">wasGeneratedBy</a></td><td>—</td><td><a title="annotation record">hasAnnotation</a></td></tr>
-<tr><td>Activity</td><td><a title="usage record">used</a></td><td>—</td><td><a title="start record">wasStartedBy</a><br><a title="end record">wasEndedBy</a><br><a title="activity
-association record">wasAssociatedWith</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
-<tr><td>Agent</td><td>—</td><td>—</td><td><a title="responsibility record">actedOnBehalfOf</a></td><td><a title="annotation record">hasAnnotation</a></td></tr>
-<tr><td>Note</td><td>—</td><td>—</td><td>—</td><td><a title="annotation record">hasAnnotation</a></td></tr>
-</table>
-</div>
-
-
-<p>In PROV-ASN, all these relation records are conformant to the <span class='nonterminal'>relationRecord</span> production of the grammar.</p>
-
-<section id="activity-entity-relation">
-<h3>Activity-Entity Relation</h3>
+
<section id="record-Generation">
<h4>Generation Record</h4>
@@ -848,38 +670,6 @@
event</a>. This entity did not exist before creation (though another with a different characterization may have existed before).
The representation of this <a title="event">instantaneous event</a> encompasses a description of the modalities of generation of this entity by this activity.</p>
-<p>A <a title="entity generation event">generation event</a> may be, for example, the completed creation of a file by a program, the completed creation of a linked data set, the completed
-publication of a new version of a document, and the complete sending of a value on a communication channel. The point at which creation is actually complete is application specific:
-generation of a file may complete when a lock is released by its creator, whereas actual publication of a document may be after the embargo period that was defined for it.</p>
-
-<p>A generation record, written <span class="name">wasGeneratedBy(id,e,a,t,attrs)</span> in PROV-ASN, has the following components:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the generation record;</li>
-<li><em>entity</em>: an identifier <span class="name">e</span> identifying an entity record that represents the entity that is created; </li>
-<li><em>activity</em>: an OPTIONAL identifier <span class="name">a</span> identifying an activity record that represents the activity that creates the entity;</li>
-
-<li><em>time</em>: an OPTIONAL "generation time" <span class="name">t</span>, the time at which the entity was created;</li>
-
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describes the modalities of generation of this entity by this activity.</li>
-
-</ul>
-
-<p>In PROV-ASN, a generation record's text matches the <span class='nonterminal'>generationRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">generationRecord</span> ::=
-<span class="name">wasGeneratedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>
-<span class="name">,</span> </span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">aIdentifier</span></span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">time</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-</div>
<p>
@@ -888,30 +678,6 @@
</p>
-<div class='anexample'>
-<p>
-The following generation assertions</p>
-<pre class="codeexample">
- wasGeneratedBy(e1,a1, 2001-10-26T21:32:52, [ex:port="p1", ex:order=1])
- wasGeneratedBy(e2,a1, 2001-10-26T10:00:00, [ex:port="p1", ex:order=2])
-</pre>
-<p>state the existence of two <a title="event">events</a> in the world (with respective times <span class="name">2001-10-26T21:32:52</span> and <span
-class="name">2001-10-26T10:00:00</span>), at which new entities, represented by entity records identified by <span class="name">e1</span> and <span class="name">e2</span>, are created by an
-activity, itself represented by an activity record identified by <span class="name">a1</span>.
-The first one is available as the first value on port p1, whereas the other is the second value on port p1. The semantics of <span class="name">port</span> and <span
-class="name">order</span> in these records are application specific.
-</p>
-</div>
-
-
-<div class='anexample'>
-<p>
-In some cases, we may want to record the time at which an entity was generated without having to specify the activity that generated it. To support this requirement, the activity component in generation records is optional. Hence, the following record indicates the time at which an entity is generated, without giving the activity that did it.</p>
-<pre class="codeexample">
- wasGeneratedBy(e,,2001-10-26T21:32:52)
-</pre>
-</div>
-
<p></p>
<div class="interpretation-forward">
For the interpretation of a generation record, see <a href="#generation-within-activity">generation-within-activity</a>.
@@ -919,40 +685,12 @@
-<!--
-<p>The assertion of a generation record implies ordering of <a title="event">events</a> in the world.</p>
-
-
-<div class='interpretation' id='generation-within-activity'><span class='conditional'>If</span> an assertion <span class="name">wasGeneratedBy(x,a,attrs)</span> or <span
-class="name">wasGeneratedBy(x,a,attrs,t)</span> holds, <span class='conditional'>then</span> the following temporal constraint also holds: the <a title="entity generation
-event">generation</a> of the entity denoted by <span class="name">x</span> <a>precedes</a> the <a title="activity end event">end</a>
-of <span class="name">a</span> and <a>follows</a> the <a title="activity start event">start</a> of <span class="name">a</span>.
-</div>
--->
-
<p></p>
<div class="structural-forward">
See <a href="#generation-uniqueness">generation-uniqueness</a> for a structural constraint on generation records.
</div>
-<!--
-<p>A given entity record can be referred to in a single generation record in the scope of a given <a href="#record-Account">account</a>.
-The rationale for this constraint is as follows.
-If two activities sequentially set different values to some attribute by means of two different <a title="entity generation event">generation events</a>, then they generate distinct
-entities. Alternatively, for two activities to generate an entity simultaneously, they would require some synchronization by which they agree the entity is released for use; the end of this
-synchronization would constitute the actual generation of the entity, but is performed by a single activity. This uniqueness constraint is formalized as follows.
-
-<div class='constraint' id='generation-uniqueness'>Given an entity record denoted by <span class="name">e</span>, two activity records denoted by <span class="name">a1</span> and <span
-class="name">a2</span>, and two sets of attribute-value pairs <span class="name">attrs1</span> and <span class="name">attrs2</span>,
-<span class='conditional'>if</span> the records <span class="name">wasGeneratedBy(e,a1,attrs1)</span> and <span class="name">wasGeneratedBy(e,a2,attrs2)</span> exist in the scope of a given
-account,
-<span class='conditional'>then</span> <span class="name">a1</span>=<span class="name">a2</span> and <span class="name">attrs1</span>=<span class="name">attrs2</span>.
-</div>
-
-<div class='note'>TODO: Introduce the well-formed-ness constraint in a entirely separate section.</div>
--->
-
<div class='pending'> We may want to assert the time at which an entity is created. The placeholder for such time information is a generation record. But a generation mandates the presence of an activity identifier. But it may not be known.
It would be nice if the activity identifier was made optional in the generation record.
@@ -970,61 +708,6 @@
Before this event, the activity had not begun to consume or use to this entity.
The representation includes a description of the modalities of usage of this entity by this activity.</p>
-<p>
-A <a title="entity usage event">usage event</a> may be a procedure beginning to consume a parameter, a service starting to read a value on a port, a program beginning to read a configuration
-file, or the point at which an ingredient, such as eggs, is being added in a baking activity. Usage may entirely consume an entity (e.g. eggs are not longer available after being added to
-the mix), or leave it as such, ready for further uses (e.g. a file on a file system can be read indefinitely).</p>
-
-
-<p>A usage record, written <span class="name">used(id,a,e,t,attrs)</span> in PROV-ASN, has the following constituent:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the usage record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record, which represents the consuming activity;</li>
-<li><em>entity</em>: an identifier <span class="name">e</span> for an entity record, which represents the entity that is consumed;</li>
-<li><em>time</em>: an OPTIONAL "usage time" <span class="name">t</span>, the time at which the entity was used;</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of usage of this entity by this activity;</li>
-</ul>
-
-<p>In PROV-ASN, a usage record's text matches the <span class='nonterminal'>usageRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">usageRecord</span> ::=
-<span class="name">used</span>
-<span class="name">(</span>
-<span class="optional">
-<span class="nonterminal">identifier</span>
-<span class="name">,</span>
-</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="optional">
-<span class="name">,</span>
- <span class="nonterminal">time</span>
-</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-</div>
-
-
-<p>
-A usage record's id is OPTIONAL, but comes handy when annotating usage records (see Section <a href="#record-annotation">Annotation Record</a>) or when defining derivations.
-</p>
-
-
-<div class='anexample'>
-<p>The following usage records</p>
-<pre class="codeexample">
- used(a1,e1,2011-11-16T16:00:00,[ex:parameter="p1"])
- used(a1,e2,2011-11-16T16:00:01,[ex:parameter="p2"])
-</pre>
-<p>state that the activity, represented by the activity record identified by <span class="name">a1</span>, consumed two entities, represented by entity records identified by <span
-class="name">e1</span> and <span class="name">e2</span>, at times <span class="name">2011-11-16T16:00:00</span> and <span class="name">2011-11-16T16:00:01</span>, respectively; the first
-one was found as the value of parameter <span class="name">p1</span>, whereas the second was found as value of parameter <span class="name">p2</span>. The semantics of <span
-class="name">parameter</span> in these records is application specific.</p>
-</div>
-
-
@@ -1045,110 +728,16 @@
</section>
-</section>
-
-
-
-
-
-<section id="activity-agent-relation">
-<h3>Activity-Agent Relation</h3>
+
+
+
+
+
<section id="record-ActivityAssociation">
<h4>Activity Association Record</h4>
-<p>The key purpose of agents in PROV-DM is to assign responsibility
-for activities. It is important to reflect that there is a degree in
-the responsibility of agents, and that is a major reason for
-distinguishing among all the agents that have some association with an
-activity and determine which ones are really the originators of the
-entity. For example, a programmer and a researcher could both be
-associated with running a workflow, but it may not matter what
-programmer clicked the button to start the workflow while it would
-matter a lot what researcher told the programmer to do so. Another
-example: a student publishing a web page describing an academic
-department could result in both the student and the department being
-agents associated with the activity, and it may not matter what
-student published a web page but it matters a lot that the department
-told the student to put up the web page. So there is some notion of
-responsibility that needs to be captured. </p>
-
-<p>Examples of activity association include designing, participation, initiation and termination, timetabling or sponsoring. </p>
-
-
-<p>Provenance reflects activities that have occurred. In some
-cases, those activities reflect the execution of a plan that was
-designed in advance to guide the execution. PROV-DM allows attaching
-a plan to an activity record, which represents what was intended to
-happen. The plan can be useful for various tasks, for example to
-validate the execution as represented in the provenance record, to
-manage expectation failures, or to provide explanations.</p>
-
-
-
-
-<p>In the context of PROV-DM, a <dfn>plan</dfn> should be understood as the description of a set of
-actions or steps intended by one or more agents to achieve some goal. PROV-DM is not
-prescriptive about the nature of plans, their representation, the
-actions and steps they consist of, and their intended goals. Hence,
-for the purpose of this specification, a plan can be a workflow for a
-scientific experiment, a recipe for a cooking activity, or a list of
-instructions for a micro-processor execution. While PROV-DM does not
-specify the representations of plans, it allows for activities to be
-associated with plans. Furthermore, since plans may evolve over time,
-it may become necessary to track their provenance, and hence, plans are
-entities. An activity MAY be associated with multiple plans. This
-allows for descriptions of activities initially associated with a
-plan, which was changed, on the fly, as the activity progresses. Plans
-can be successfully executed or they can fail. We expect applications
-to exploit PROV-DM <a href="#extensibility-section">extensibility
-mechanisms</a> to capture the rich nature of plans and associations
-between activities and plans.</p>
-
-
-<p>Thus, PROV-DM offers two kinds of records. The first, introduced in this section, represents an association between an agent, a plan, and an activity; the second, introduced in <a
-href="#record-responsibility">Section Responsibility record</a>, represents the fact that an agent was acting on behalf of another, in the context of an activity. </p>
-
-
-<p>An <dfn id="dfn-activity-association">activity association record</dfn>, written <span class="name">wasAssociatedWith(id,a,ag2,pl,attrs)</span> in PROV-ASN, has the following
-constituents:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the activity association record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> for an activity record;</li>
-<li><em>agent</em>: an identifier <span class="name">ag2</span> for an agent record, which represents the agent associated with the activity;</li>
-<li><em>plan</em>: an OPTIONAL identifier <span class="name">pl</span> for an entity record, which represents a plan adopted by the agent in the context of this activity;
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of association of this activity with this agent.</li>
-</ul>
-
-<p>In PROV-ASN, an activity association record's text matches the <span class="nonterminal">activityAssociationRecord</span> productions of the grammar defined in this specification
-document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">activityAssociationRecord</span> ::=
-<span class="name">wasAssociatedWith</span>
-<span class="name">(</span>
-<span class="optional"><span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="optional">,<span class="nonterminal">eIdentifier</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="anexample">
-In the following example, a designer and an operator agents are asserted to be associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>.
-<pre class="codeexample">
-activity(ex:a,[prov:type="workflow execution"])
-agent(ex:ag1,[prov:type="operator"])
-agent(ex:ag2,[prov:type="designer"])
-wasAssociatedWith(ex:a,ex:ag1,[prov:role="loggedInUser", ex:how="webapp"])
-wasAssociatedWith(ex:a,ex:ag2,ex:wf,[prov:role="designer", ex:context="project1"])
-entity(ex:wf,[prov:type="prov:Plan"%% xsd:QName, ex:label="Workflow 1",
- ex:url="http://example.org/workflow1.bpel" %% xsd:anyURI])
-</pre>
-Since the workflow <span class="name">ex:wf</span> is itself an entity, its provenance can also be expressed in PROV-DM: it can be generated by some activity and derived from other entities,
-for instance.
-</div>
+
<div class='issue'> The activity association record does not allow for a plan to be asserted without an agent.
This seems over-restrictive. Discussed in the context of <a href="http://www.w3.org/2011/prov/track/issues/203">ISSUE-203</a>.</div>
@@ -1163,64 +752,6 @@
<section id="record-Start-End">
<h4>Start and End Records</h4>
-<p> A <dfn id="dfn-Start">start record</dfn> is a representation of an agent starting an activity.
- An <dfn id="dfn-End">end record</dfn> is a representation of an agent ending an activity. Both relations are specialized forms of <span class="name">wasAssociatedWith</span>. They contain
-attributes describing the modalities of acting/ending activities.</p>
-
-
-
-<p>A start record, written <span class="name">wasStartedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the start record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the started activity;
-<li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the starting agent;
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent started the activity.
-</ul>
-
-<p>An end record, written <span class="name">wasEndedBy(id,a,ag,attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the end record;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> denoting an activity record, representing the ended activity;
-<li><em>agent</em>: an identifier <span class="name">ag</span> for an agent record, representing the ending agent;
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span>, describing modalities according to which the agent ended the activity.
-</ul>
-
-<p>In PROV-ASN, start and end record's texts match the <span class="nonterminal">startRecord</span> and <span class="nonterminal">endRecord</span> productions of the grammar defined in this
-specification document.
-</p>
-
-
-<div class='grammar'>
-<span class="nonterminal">startRecord</span> ::=
-<span class="name">wasStartedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-<span class="nonterminal">endRecord</span> ::=
-<span class="name">wasEndedBy</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">aIdentifier</span>,
-<span class="nonterminal">agIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-
-<div class="anexample">
-<p>
-The following assertions</p>
-<pre class="codeexample">
-wasStartedBy(a,ag,[ex:mode="manual"])
-wasEndedby(a,ag,[ex:mode="manual"])
-</pre>
-<p>state that the activity, represented by the activity record denoted by <span class="name">a</span>
-was started and ended by an agent, represented by record denoted by <span class="name">ag</span>, in "manual" mode, an application specific characterization of these relations.
-</p>
-</div>
<div class='issue'>
Should we define start/end records as representation of activity start/end events.
@@ -1233,259 +764,21 @@
-</section>
-
-<section id="entity-entity-agent-agent-relation">
-<h4>Entity-Entity or Agent-Agent Relation</h4>
+
+
<section id="record-responsibility">
<h4>Responsibility Record</h4>
-<p>To promote take-up, PROV-DM offers a mild version of responsibility
-in the form of a relation to represent when an agent acted on another
-agent's behalf. So in the example of someone running a mail program,
-the program is an agent of that activity and the person is also an
-agent of the activity, but we would also add that the mail software
-agent is running on the person's behalf. In the other example, the
-student acted on behalf of his supervisor, who acted on behalf of the
-department chair, who acts on behalf of the university, and all those
-agents are responsible in some way for the activity to take place but
-we don't say explicitly who bears responsibility and to what
-degree. </p>
-
-<p>We could also say that an agent can act on behalf of several other
-agents (a group of agents). This would also make possible to
-indirectly reflect chains of responsibility. This also indirectly
-reflects control without requiring that control is explicitly
-indicated. In some contexts there will be a need to represent
-responsibility explicitly, for example to indicate legal
-responsibility, and that could be added as an extension to this core
-model. Similarly with control, since in particular contexts there
-might be a need to define specific aspects of control that various
-agents exert over a given activity.</p>
-
-<p>Given an activity association record <span class="name">wasAssociatedWith(a,ag2,attrs)</span>,
-a <dfn id="dfn-responsibility">responsibility record</dfn>, written <span class="name">actedOnBehalfOf(id,ag2,ag1,a,attrs)</span> in PROV-ASN, has the following constituents:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the responsibility record;</li>
-<li><em>subordinate</em>: an identifier <span class="name">ag2</span> for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible
-agent;</li>
-<li><em>responsible</em>: an identifier <span class="name">ag1</span> for an agent record, which represents the agent on behalf of which the subordinate agent <span class="name">ag2</span>
-acts;</li>
-<li><em>activity</em>: an OPTIONAL identifier <span class="name">a</span> of an activity record for which the responsibility record holds;</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this relation.</li>
-</ul>
-
-
-<div class='grammar'>
-<span class="nonterminal">responsibilityRecord</span> ::=
-<span class="name">actedOnBehalfOf</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">agIdentifier</span>
-<span class="name">,</span>
-<span class="optional"><span class="nonterminal">aIdentifier</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<div class="anexample">
-In the following example, a programmer, a researcher and a funder agents are asserted. The programmer and researcher are associated with a workflow activity. The programmer acts on behalf
-of the researcher (delegation) encoding the commands specified by the researcher; the researcher acts on behalf of the funder, who has an contractual agreement with the researcher. The terms
-'delegation' and 'contact' used in this example are domain specific.
-<pre class="codeexample">
-activity(a,[prov:type="workflow"])
-agent(ag1,[prov:type="programmer"])
-agent(ag2,[prov:type="researcher"])
-agent(ag3,[prov:type="funder"])
-wasAssociatedWith(a,ag1,[prov:role="loggedInUser"])
-wasAssociatedWith(a,ag2)
-actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"])
-actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])
-</pre>
-</div>
-
+
+Nothing here.
</section>
<section id="Derivation-Relation">
<h4>Derivation Record</h4>
-<p>In PROV-DM, a <dfn id="dfn-Derivation">derivation record</dfn> is a representation that some entity is transformed from, created from, or affected by another entity in the world. </p>
-
-
-<p>Examples of derivation include the transformation of a canvas into a painting, the transportation of a person from London to New York, the transformation of a relational table into a
-linked data set, and the melting of ice into water.</p>
-
-
-<p>According to <a href="#conceptualization">Section Conceptualization</a>, for an entity to be transformed from, created from, or affected by another in some way, there must be some
-underpinning activities performing the necessary actions resulting in such a derivation.
-However, asserters may not assert or have knowledge of these activities and associated details: they may not assert or know their number, they may not assert or know their identity, they may
-not assert or know the attributes characterizing how the relevant entities are used or generated. To accommodate the varying circumstances of the various asserters, PROV-DM allows more or
-less precise records of derivation to be asserted. Hence, PROV-DM uses the terms <em>precise</em> and <em>imprecise</em> to characterize the different kinds of derivation record. We note
-that the derivation itself is exact (i.e., deterministic, non-probabilistic), but it is its description, expressed in a derivation record, that may be imprecise. </p>
-
-<p>The lack of precision may come from two sources:</p>
-<ul>
-<li> the number of activities that underpin a derivation is not asserted or known, or</li>
-<li> any of the other details that are involved in the derivation is not asserted or known; these include activity identities, generation and usage records, and their attributes.</li>
-</ul>
-
-
-<!--
-Furthermore, assuming that an asserter has full knowledge of an activity underpinning a derivation, the same activity can generally be modelled in terms of sub-activities, composed in a such
-a way as to deliver the same behavior. Hence, since activities can be modelled at arbitrary levels of granularity, there is a distinguished case in which a derivation between two entities
-<span class="name">e2</span> and <span class="name">e1</span> corresponds <em>exactly</em> to <em>one</em> activity that used <span class="name">e1</span> and generated <span
-class="name">e2</span>. This is to be contrasted to the case where one derivation corresponds to n activities, where n can be any number greater than 1.
-Hence, PROV-DM uses the terms <em>one-activity</em> and <em>n-activities</em> to distinguish these two cases.</p>
--->
-
-
-<p>Hence, we can consider two axis. An activity number axis that has values <em>single</em>, <em>multiple</em>, and <em>unknown</em>, respectively representing the case where one activity
-is known to have occurred, more than one activities are known to have occurred, or an unknown number of activities have occurred. Likewise, we can consider another axis to cover other
-details (identities, generation and usage records, attributes), with values <em>asserted</em> and <em>not asserted</em>. We can then form a matrix of possible derivations. Out of the six
-possibilities,
-PROV-DM offers three forms of derivation derivation records to cater for five othem, while the remaining one is not meaningful. The following table summarises names for the three kinds of
-derivation, which we then explain.</p>
-
-<div style="text-align: center;">
-<table border="1" style="margin-left: auto; margin-right: auto;">
-<caption>PROV-DM Derivation Type Summary</caption>
-<tr><td colspan=2 rowspan=2></td><td colspan=2><em>other details</em> axis</td></tr>
-<tr><td>asserted</td><td>not asserted</td></tr>
-<tr><td rowspan=3><em>activity number</em><br>axis</td><td>single</td><td><a>precise-1 derivation record</a></td><td><a>imprecise-1 derivation record</a></td></tr>
-<tr><td>multiple</td><td><a>imprecise-n derivation record</a></td><td rowspan=2><a>imprecise-n derivation record</a></td></tr>
-<tr><td>unknown</td><td>—</td></tr>
-</table>
-</div>
-
-<ul>
-<li> The asserter asserts that derivation is due to exactly one activity, and all the details are asserted. We call this a precise-1 derivation record.</li>
-<li> The asserter asserts that derivation is due to exactly one activity, but other details, whether known or unknown, are not asserted. We call this an imprecise-1 derivation record.</li>
-<li> The following cases are captured by an imprecise-n derivation record.
-<ul>
-<li> The asserter knows that multiple activities are involved or ignores the number of activities involved in the derivation, and other details are not asserted. </li>
-<li> The asserter knows that multiple activities are involved in the derivation, and all their details are asserted. In this case, these activities are connected by means of generated and
-used intermediary entities. Despite all activities and details being known, there is no guarantee that any of these activities plays an active role in the derivation; hence, this case is
-also regarded as imprecise. Instead, precise derivations need to be expressed between these intermediary entities. </li>
-</ul>
-</ul>
-
-<p> We note that the last theoretical cases cannot occur, since
- asserting the details of an unknown number of activities is a contradiction.
-</p>
-
-<p>In order to represent the number of activities in a derivation, we introduce a PROV-DM attribute <span class="name">steps</span>, which can take two possible values: <span
-class="name">single</span> and <span class="name">any</span>.
-When <span class="name">prov:steps="single"</span>, derivation is due to one activity; when <span class="name">prov:steps="any"</span>, the number of activities is multiple or not known.</p>
-
-
-<p>The three kinds of derivation records are successively introduced. Making use of the attribute <span class="name">steps</span>, we can distinguish the various derivation types.</p>
-
-<p>A <dfn>precise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, a, g2, u1, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
-<li><em>activity</em>: an identifier <span class="name">a</span> of an activity record, which is a representation of the activity using and generating the above entities;</li>
-<li><em>generation</em>: an identifier <span class="name">g2</span> of the generation record pertaining to <span class="name">e2</span> and <span class="name">a</span>;</li>
-<li><em>usage</em>: an identifier <span class="name">u1</span> of the usage record pertaining to <span class="name">e1</span> and <span class="name">a</span>.</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation, optionally including the attribute-value
-pair <span class="name">prov:steps="single"</span>.</li>
-</ul>
-<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in a precise-1 derivation since the record already refers to the one and only one activity underpinning the
-derivation.</p>
-
-
-<p>An <dfn>imprecise-1 derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2,e1, t, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
-<li><em>time</em>: an OPTIONAL "generation time" <span class="name">t</span>, the time at which the entity denoted by <span class="name">e2</span> was created;</li>
-<li><em>attributes</em>: a set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it MUST include the attribute-value pair <span class="name">prov:steps="single"</span>.</li>
-</ul>
-<p>An imprecise-1 derivation MUST include the attribute <span class="name">prov:steps</span>, since it is the only means to distinguish this record from an imprecise-n derivation
-record.</p>
-
-
-<p>An <dfn>imprecise-n derivation record</dfn>, written <span class="name">wasDerivedFrom(id, e2, e1, t, attrs)</span> in PROV-ASN, contains:</p>
-<ul>
-<li><em>id</em>: an OPTIONAL identifier <span class="name">id</span> identifying the derivation record;</li>
-<li><em>generatedEntity</em>: the identifier <span class="name">e2</span> of an entity record, which is a representation of the generated entity;</li>
-<li><em>usedEntity</em>: the identifier <span class="name">e1</span> of an entity record, which is a representation of the used entity;</li>
-<li><em>time</em>: an OPTIONAL "generation time" <span class="name">t</span>, the time at which the entity denoted by <span class="name">e2</span> was created;</li>
-<li><em>attributes</em>: an OPTIONAL set of attribute-value pairs <span class="name">attrs</span> that describe the modalities of this derivation; it optionally includes the attribute-value pair <span class="name">prov:steps="any"</span>.</li>
-</ul>
-<p>It is OPTIONAL to include the attribute <span class="name">prov:steps</span> in an imprecise-n derivation record. It defaults to <span class="name">prov:steps="any"</span>.</p>
-
-
-<p>None of the three kinds of derivation is defined to be transitive. Domain-specific specializations of these derivations may be defined in such a way that the transitivity property
-holds.</p>
-
-
-<p>In PROV-ASN, a derivation record's text matches the <span class='nonterminal'>derivationRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
-<span class="nonterminal">derivationRecord</span> ::=
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">aIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">gIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">uIdentifier</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span><br/>
-|
-<span class="name">wasDerivedFrom</span>
-<span class="name">(</span>
-<span class="optional"> <span class="nonterminal">identifier</span>,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="optional"><span class="name">,</span>
-<span class="nonterminal">time</span></span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-<p>
-The first clause of the alternative, where the activity, generation and usage record identifiers are present formalizes a derivation record is precise-1. The second clause of the alternative, with optional time formalizes imprecise records. The distinction between imprecise-1 and imprecise-n is made by the
-attribute <span class="name">prov:steps</span>.
-</p>
-
-<div class="anexample">
-<p>The following assertions state the existence of derivations.</p>
-<pre class="codeexample">
-wasDerivedFrom(e5,e3,a4,g2,u2)
-wasDerivedFrom(e5,e3,a4,g2,u2,[prov:steps="single"])
-
-wasDerivedFrom(e3,e2,[prov:steps="single"])
-
-wasDerivedFrom(e2,e1,[])
-wasDerivedFrom(e2,e1,[prov:steps="any"])
-
-wasDerivedFrom(e2,e1,2012-01-18T16:00:00, [prov:steps="any"])
-</pre>
-<p>
-The first two are precise-1 derivation records expressing that the activity represented by the activity <span class="name">a4</span>, by
-using the entity denoted by <span class="name">e3</span> according to usage record <span class="name">u2</span>
- derived the
-entity denoted by <span class="name">e5</span> and generated it according to generation record
- <span class="name">g2</span>.
-
-
-The third record is an imprecise-1 derivation, which is similar for <span class="name">e3</span> and <span class="name">e2</span>, but it leaves the activity record and associated attributes implicit. The fourth and fifth records are imprecise-n derivation records between <span class="name">e2</span> and <span class="name">e1</span>, but no information is provided as to the number and identity of activities underpinning the derivation. The six derivation records extends the fifth with the derivation time of <span class="name">e2</span>.
-</p>
-</div>
<p>An precise-1 derivation record is richer than an imprecise-1 derivation record, itself, being more informative that an imprecise-n derivation record. Hence, the following implications
@@ -1612,36 +905,6 @@
<h4>Alternate and Specialization Records</h4>
-<div class="note">This section is currently under revision and in flux</div>
-
-The purpose of the record types defined in this section is to establish a relationship between two entities, which asserts that they provide a different characterization of the same thing.
-Consider for example three entities:
-<ul>
-
- <li><span class="name">e1</span> denoting "Bob, the holder of facebook account ABC",
-
- <li><span class="name">e2</span> denoting "Bob, the holder of twitter account XYZ",
-
- <li><span class="name">e3</span> denoting "Bob, the person".
-</ul>
-
-One may make several assertions to establish that these entities refer to the same the real-world thing Bob, either in different contexts, or at different levels of abstraction. For example:
-
-<ol>
- <li> Entity denoted by <span class="name">e1</span> provides a <em>more concrete</em> characterization of Bob than <span class="name">e3</span> does;
- <li> Entity denoted by <span class="name">e2</span> provides a <em>more concrete</em> characterization of Bob than <span class="name">e3</span> does;
- <li> The entities denoted by <span class="name">e1</span> and <span class="name">e2</span> provide two different characterizations of the same thing, i.e., Bob.
-</ol>
-
-Two relations are introduced to express these assertions:
-
-<ul>
-
- <li> e2 is a <em>specialization</em> of e1, written <span class="name">specializationOf(e2,e1)</span> captures the intent of assertion (1) and (2);
- <li> e2 is an <em>alternative characterization</em> of e1, written <span class="name">alternateOf(e2,e1)</span> captures the intent of assertion (3).
-
- </ul>
-
In order to further convey the intended meaning, the following properties are associated to these two relations.
<ul>
@@ -1655,95 +918,12 @@
<div class="note">There are proposals to make alternateOf a transitive property. This is still under discussion and the default is for alternateOf <strong>not</strong> to be transitive, and this is what the current text reflects.</div>
-<p>A <dfn id="dfn-Alternate">alternate record</dfn>, written alternateOf(alt1, alt2, attrs) in PROV-ASN, has the following constituents:</p>
-
-<ul>
-<li><em>first alternate</em>: an identifier <span class="name">alt1</span> of the first of the two entities</li>
-<li><em>second alternate</em>: an identifier <span class="name">alt2</span> of the second of the two entities</li>
-<li><em>attrs</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-
-<p>A <dfn id="dfn-Specialization">specialization record</dfn> written specializationOf(sub, super, attrs) in PROV-ASN, has the following constituents:</p>
-
-<ul>
-<li><em>specialised entity</em>: an identifier <span class="name">sub</span> of the specialised entity</li>
-<li><em>general entity</em>: an identifier <span class="name">super</span> of the entity that is being specialised</li>
-<li><em>attrs</em>: an OPTIONAL set <span class="name">attrs</span> of attribute-value pairs to further describe this record.</li>
-</ul>
-
-
-
-<p>
-An entity record identifier can optionally be accompanied by an account identifier. When this is the case, it becomes possible to use the <span class="name">alternateOf</span> relation to
-link two entity record identifiers that are appear in different accounts. (In particular, the entity identifiers in two different account are allowed to be the same.). When account
-identifiers are not available, then the linking of entity records through <span class="name">alternateOf</span> can only take place within the scope of a single account.
-</p>
-
-
-
-<p>In PROV-ASN, an alternate record's text matches the <span class="nonterminal">alternateRecord</span> production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
- <span class="nonterminal">alternateRecord</span> ::=
- <span class="name">alternateOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span> <br/>
-|
- <span class="name">alternateOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
- <span class="nonterminal">accIdentifier</span>
- <span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
- <span class="nonterminal">accIdentifier</span>
-<span class="name">,</span>
- <span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span>
-</div>
-
-<p>In PROV-ASN, a specialization record's text matches the <span class="nonterminal">specializationRecord</span>production of the grammar defined in this specification document.</p>
-
-<div class='grammar'>
- <span class="nonterminal">specializationRecord</span> ::=
- <span class="name">specializationOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
-<span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span> <br/>
-|
- <span class="name">specializationOf</span>
-<span class="name">(</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
- <span class="nonterminal">accIdentifier</span>
- <span class="name">,</span>
-<span class="nonterminal">eIdentifier</span>
-<span class="name">,</span>
- <span class="nonterminal">accIdentifier</span>
-<span class="name">,</span>
- <span class="nonterminal">optional-attribute-values</span>
-<span class="name">)</span> <br/>
-
-</div>
-
<div class='issue'>A discussion on alternative definition of these relations has not reached a satisfactory conclusion yet. This is <a
href="http://www.w3.org/2011/prov/track/issues/29">ISSUE-29</a>. Also <a href="http://www.w3.org/2011/prov/track/issues/96">ISSUE-96</a>.</div>
</section>
-</section>
@@ -2002,66 +1182,6 @@
<a href="http://www.w3.org/2011/prov/track/issues/135">ISSUE-139</a>
</div>
-The intent of the <em>collection</em> record types relations introduced in this section is to account for <strong>part-of</strong> relationships that may exist amongst entities. Specifically, this section:
-
-<ul>
- <li>introduces a new built-in type <span class="name">collection</span>, and </li>
- <li>introduces relations that let asserters describe how the content of entities of type collection changes over time, as a consequence of insertion and deletion operations.</li>
- </ul>
-
-<p>We adopt a very generic form of collection for the purpose, namely an abstract data types consisting of <strong>set of key-value pairs</strong>, often referred to as a <strong>map</strong>. This provides a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" or maps in some programming languages), relational tables, ordered lists, and more (the specification of such specialized structures in terms of key-value pairs is out of the scope of this document).</p>
-
-<p>Keys and values used in collections are literals. This allows expressing nested collections, that is, collections whose values include entities of type collection.</p>
-
-<p>The following relations and corresponding record types are introduced to model (a) insertion of a new key-value pair into a collection and (b) removal of a key-value pair from a collection.</p>
-
-<ul>
- <li>Record: <span class="name">CollectionAfterInsertion(c2,c1, k, v)</span> denotes that collection <span class="name">c2</span> represents the new state of collection <span class="name">c1</span>,
-following the insertion of pair <span class="name">(k,v)</span> into <span class="name">c1</span></li>
-
-<li> Record: <span class="name">CollectionAfterRemoval(c2,c1, k)</span> denotes that collection <span class="name">c2</span> represents the removal of pair <span class="name">(k,v)</span> from <span class="name">c1</span>, where <span class="name">v</span> is the value
-corresponding to key <span class="name">k</span> in <span class="name">c1</span>. </li>
-
-</ul>
-
-<p>
-Because these relations state the derivation of a collection from another, formally they are specializations of the precise-1 <a
-href="#Derivation-Relation"><strong>wasDerivedFrom</strong></a> relation.</p>
-
-The following entity types are introduced:
-
-<ul>
- <li> <span class="name">prov:type="Collection"%%xsd:QName</span> denotes that the entity is a collection, that is, it can participate in <span class="name">CollectionAfterInsertion</span> and <span class="name">CollectionAfterDeletion</span> relations;
-
- <li><span class="name">prov:type="emptyCollection"%%xsd:QName</span> denotes that the entity is a collection, and furthermore that it does not contain any key-value pairs.
-</ul>
-
-<div class="note">Given the specific nature of the derivation, the intervening activity that accounts for imprecise-1 derivation should have an equally specific type, such as"
-collection-insertion" and "collection-rmoval". This is left for a future version.</div>
-
-<p>The intent of these relations and entity types is to capture the <em>history of changes that occurred to a collection</em>. </p>
-
-<p>The following examples illustrate how these assertions are expected to be used in practice.</p>
-
-<div class="anexample">
-<pre class="codeexample">
- entity(c, [prov:type="EmptyCollection"]) // e is an empty collection
- entity(k1)
- entity(v1)
- entity(k2)
- entity(v2)
- entity(c1, [prov:type="Collection"])
- entity(c2, [prov:type="Collection"])
-
- CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
- CollectionAfterInsertion(c2, c1, k2, v2) // c2 = { (k1,v1), (k2 v2) }
- CollectionAfterRemoval(c3, c2, k1) // c3 = { (k2,v2) }
-</pre>
-</div>
-
-<p>This representation of a collection's evolution makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. In fact, the state of a collection (i.e., the set of key-value pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivation assertions involving insertions and removals. Entity type <span class="name">prov:type="emptyCollection"</span> can be used in this context as it marks the start of a sequence of collection operations.</p>
-
-<p>Observations:</p>
<ul>
<li> One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:<br/>
@@ -2140,53 +1260,6 @@
</ul>
-<p> An assertion CollectionAfterInsertion, written <span class="name"> CollectionAfterInsertion(collAfter, collBefore, key, value)</span>, contains:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">collAfter</span> for the collection record representing the collection <em>after</em> the insertion; </li>
-<li><em>source</em>: an identifier <span class="name">collBefore</span> for the collection record representing the collection <em>before</em> the insertion;</li>
-<li><em>source</em>: an identifier <span class="name">key</span> for the key that has been inserted into <span class="name">collBefore</span></li>
-<li><em>source</em>: an identifier <span class="name">value</span> for the value corresponding to the key that has been inserted into <span class="name">collBefore</span></li>
-</ul>
-
-<p> An assertion CollectionAfterDeletion, written <span class="name"> CollectionAfterDeletion(collAfter, collBefore, key)</span>, contains:</p>
-<ul>
-<li><em>entity</em>: an identifier <span class="name">collAfter</span> for the collection record representing the collection <em>after</em> the deletion; </li>
-<li><em>source</em>: an identifier <span class="name">collBefore</span> for the collection record representing the collection <em>before</em> the deletion;</li>
-<li><em>source</em>: an identifier <span class="name">key</span> for the key corresponding to the (key, value) pair that has been deleted from <span class="name">collBefore</span></li>
-</ul>
-
-
-<p>In PROV-ASN, an collection record's text matches the <span class="nonterminal">collectionRecord</span> production of the grammar:</p>
-<div class='grammar'>
- <span class="nonterminal">collectionRecord</span> ::=
-<span class="nonterminal">collectionInsertionRecord</span>
-| <span class="nonterminal">collectionRemovalRecord</span>
-<br/>
-
- <span class="nonterminal">collectionInsertionRecord</span> ::=
-<span class="name">CollectionAfterInsertion</span>
- <span class="name">(</span>
- <span class="nonterminal">cidentifier</span>
- <span class="name">,</span>
-<span class="nonterminal">cidentifier</span>
- <span class="name">,</span>
-<span class="nonterminal">kidentifier</span>
- <span class="name">,</span>
-<span class="nonterminal">videntifier</span>
- <span class="name">)</span>
- <br/>
-
- <span class="nonterminal">collectionRemovalRecord</span> ::=
- <span class="name">CollectionAfterRemoval</span>
- <span class="name">(</span>
- <span class="nonterminal">cidentifier</span>
- <span class="name">,</span>
-<span class="nonterminal">cidentifier</span>
- <span class="name">,</span>
-<span class="nonterminal">kidentifier</span>
- <span class="name">)</span>
-
- </div>
</section>
@@ -2793,8 +1866,86 @@
+
+
+<section>
+<h3>PROV-DM Collection Constraints</h3>
+
+<ul>
+ <li> One can have multiple assertions regarding the state of a collection following a <em>set</em> of insertions, for example:<br/>
+<span class="name">CollectionAfterInsertion(c2,c1, k1, v1)</span><br/>
+<span class="name">CollectionAfterInsertion(c2,c1, k2, v2)</span><br/>
+ <span class="name">...</span><br/>
+This is interpreted as <em>" <span class="name">c2</span> is the state that results from inserting <span class="name">(k1, v1)</span>, <span class="name">(k2, v2)</span> etc. into <span class="name">c1</span>"</em></li></p>
+
+<li> It is possible to have multiple derivations from a single root collection, possibly by different asserters, as shown in the following example.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="EmptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+ entity(v3)
+ entity(c1, [prov:type="Collection"])
+ entity(c2, [prov:type="Collection"])
+ entity(c3, [prov:type="Collection"])
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ CollectionAfterInsertion(c2, c, k2, v2) // c2 = { (k2 v2) }
+ CollectionAfterInsertion(c3, c1, k3,v3) // c3 = { (k1,v1), (k3,v3) }
+</pre>
+</div>
+
+<div class='note'>Asserter not defined</div>
+</li></p>
+
+
+<li>Given the pair of assertions:
+
+<span class="name">CollectionAfterInsertion(c, c1, k1, v1)</span><br/>
+<span class="name">CollectionAfterInsertion(c, c2, k2, v2)</span><br/>
+
+it follows that <span class="name">c1==c2, k1==k2, v1==v2</span>, because one cannot have two different derivations for the same final collection state.</li></p>
+
+
+<li>Given the following set of insertions:<br/>
+
+<span class="name">CollectionAfterInsertion(c1, c, k, v1)</span><br/>
+<span class="name">CollectionAfterInsertion(c1, c, k, v2)</span><br/>
+
+it follows that <span class="name">v1==v2</span>.</li></p>
+
+
+<li> The state of a collection is only known to the extent that a chain of derivations starting from an empty collection can be found. Since a set of assertions regarding a collection's evolution may be incomplete, so is the reconstructed state obtained by querying those assertions. In general, all assertions reflect the asserter's partial knowledge of a sequence of data transformation events. In the particular case of collection evolution, in which the asserter <em>knows</em> that some of the state changes may have been missed, then the more generic <a href="#Derivation-Relation">derivation</a> relation should be used to signal that some updates may have occurred, which cannot be precisely asserted as insertions or removals. The following two examples illustrate this.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="collection"]) // e is a collection, possibly not empty
+ entity(v1)
+ entity(v2, [prov:type="collection"]) // v2 is a collection
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 <em>includes</em> { (k1,v1) } but may contain additional unknown pairs
+ CollectionAfterInsertion(c2, c1, k2, v2) // c2 includes { (k1,v1), (k2 v2) } where v2 is a collection with unknown state
+</pre>
+</div>
+ In the example, the state of <span class="name">c2</span> is only partially known because the collection is constructed from partially known other collections.
+
+<div class="anexample">
+<pre class="codeexample">
+ entity(c, [prov:type="emptyCollection"]) // e is an empty collection
+ entity(v1)
+ entity(v2)
+
+ CollectionAfterInsertion(c1, c, k1, v1) // c1 = { (k1,v1) }
+ wasDerivedFrom(c2, c1) // the asserted knows that c2 is somehow derived from c1, but cannot assert the precise sequence of updates
+ CollectionAfterInsertion(c3, c2, k2, v2)
+</pre>
+</div>
+Here <span class="name">c3</span> includes <span class="name">{ (k2 v2) }</span> but the earlier "gap" leaves uncertainty regarding <span class="name">(k1,v1)</span> (it may have been removed) or any other pair that may have been added as part of the derivation activities.</li></p>
+</ul>
</section>
+</section>
<section id="resource-section">