--- a/dc-note/Overview.html Fri Oct 26 14:47:02 2012 -0400
+++ b/dc-note/Overview.html Fri Oct 26 14:47:29 2012 -0400
@@ -509,7 +509,9 @@
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }
-</style><link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8" /></head>
+</style><link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8" />
+<script src="http://www.w3.org/2007/OWL/toggles.js"></script>
+</head>
<body style="display: inherit; ">
<div class="head"><p><a href="http://www.w3.org/">
<img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C" /></a></p>
@@ -870,7 +872,7 @@
</div>
</div>
</p><p>
-Since the first option is the most conservative with respect to the underlying semantics, it has been chosen as guideline in the context-free mapping.
+Since the first option is the most conservative with respect to the underlying semantics, it has been chosen as guideline in the complex mapping.
Blank nodes are used for the mapping, although any naming mechanism could be provided if necessary,
leaving the conflating of nodes to the clean-up phase.
<!-- I comment this because it repeats what it has already been stated
@@ -900,7 +902,7 @@
</p>
<p>
<a href="#list_of_direct_terms">Table 3</a> and <a href="#list_of_direct_mappings2">Table 4</a> provide the detailed mapping plus the rationale for each term.
- For more information see the
+ The rest of the terms can be found in the
<a href="#list_of_excluded_terms">list of terms left out of the mapping</a>.
</p><p>
<div id="list_of_direct_terms" ALIGN="center">
@@ -1140,15 +1142,17 @@
<div id="complex_mappings" class="section">
<h3><span class="secno">2.5 </span>Complex Mappings</h3>
<p>
+The complex mappings consist on a set of patterns defined to generate qualified PROV statements from Dublin Core statements. This type of qualification may not be
+always needed, and it is the choice of the implementor whether to use them or not depending on the use case. It is also important to note that not all the
+direct mappings have a complex mapping associated, just those which imply a specific activity: creation, publication, etc.
The complex mappings are provided in form of SPARQL CONSTRUCT queries, i.e., queries that describe a
resulting RDF graph based on another RDF graph found in the original data. We divide the queries in different categories:
</p>
<div id="entity_agent_mappings">
<h4><span class="secno">2.5.1 </span>Entity-Agent mappings (Who)</h4>
<p>
-In this category, we have four terms: <code>dct:contributor</code>, <code>dct:creator</code>, <code>dct:publisher</code>, and <code>dct:rightsHolder</code>.
-The former three
- can be mapped with the same pattern, similar to the one presented in <a href="#figure_mapping_example">Figure 1</a>.
+In this category, we have three terms: <code>dct:contributor</code>, <code>dct:creator</code> and <code>dct:publisher</code>.
+The three of them can be mapped with the same pattern, similar to the one presented in <a href="#figure_mapping_example">Figure 1</a>.
The only changes required are the roles and activities involved for each term.
<p>
@@ -1269,15 +1273,30 @@
<div id="entity_date_mappings">
<h4><span class="secno">2.5.2 </span>Entity-Date mappings (When)</h4>
<p>
-The dates often correspond with a who-property, e.g., creator and created or publisher and issued.
- Therefore, they lead to similar statements, only providing a date instead of an agent associated with the activity.
+Dates often correspond with a who-property, e.g., creator and created or publisher and issued.
+ Therefore, they lead to similar complex patterns (providing a date instead of an agent associated with the corresponding activity).
+ When using Dublin Core terms, it is usual to see that a resource is annotated with several <code>dct</code> assertions like creator, publisher,
+ issued, date, etc., but in this phase of the mapping each term is treated independently.
+ <form action="#"><p>
+ <input id="hide-dates" type="button" value="Hide date patterns"
+ style="display:none"
+ onclick="
+ set_display_by_class('div','date pattern','none');
+ set_display_by_id('hide-dates','none');
+ set_display_by_id('show-dates','');" />
+ <input id="show-dates" type="button" value="Show date patterns"
+ onclick="
+ set_display_by_class('div','date pattern','');
+ set_display_by_id('hide-dates','');
+ set_display_by_id('show-dates','none');" />
+ </p>
+ </form>
</p>
-<p>
-When using Dublin Core terms, it is usual to see that a resource is annotated with several dc assertions like creator, publisher,
- issued, date, etc. In this phase of the mapping each term is treated independently.
+
+<h5 id="term_created"><span class="secno">2.5.2.1 </span>dct:created</h5>
</p>
-<h5 id="term_created"><span class="secno">2.5.2.1 </span>dct:created</h5>
-</p><p><pre class="code">
+<div class="date pattern" style="display:none">
+<pre class="code">
CONSTRUCT{
?document a prov:Entity .
@@ -1297,8 +1316,12 @@
?document dct:created ?date.
}
</pre>
+ </div>
+
<h5 id="term_issued"><span class="secno">2.5.2.2 </span>dct:issued</h5>
-<p><pre class="code">
+<p>
+<div class="date pattern" style="display:none">
+<pre class="code">
CONSTRUCT{
?document a prov:Entity .
@@ -1325,7 +1348,10 @@
}
</pre>
</p>
+</div>
+
<h5 id="term_modified"><span class="secno">2.5.2.3 </span>dct:modified</h5>
+<div class="date pattern" style="display:none">
<p>
As seen with the previous terms, most entity/date properties will have a similar structure.
</p><p><pre class="code">
@@ -1354,9 +1380,12 @@
?document dct:modified ?date.
}
</pre>
-</p><p>
+</p>
+</div>
+
<h5 id="term_dateAccepted"><span class="secno">2.5.2.4 </span>dct:dateAccepted</h5>
-</p><p><pre class="code">
+<div class="date pattern" style="display:none">
+<p><pre class="code">
CONSTRUCT{
?document a prov:Entity .
@@ -1383,7 +1412,9 @@
}
</pre>
</p>
+</div>
<h5 id="term_dateCopyRighted"><span class="secno">2.5.2.5 </span>dct:dateCopyrighted</h5>
+<div class="date pattern" style="display:none">
<p><pre class="code">
CONSTRUCT{
?document a prov:Entity .
@@ -1410,7 +1441,9 @@
?document dct:dateCopyrighted ?date.
}
</pre></p>
+</div>
<h5 id="term_dateSubmitted"><span class="secno">2.5.2.6 </span>dct:dateSubmitted</h5>
+<div class="date pattern" style="display:none">
<p><pre class="code">
CONSTRUCT{
?document a prov:Entity .
@@ -1439,6 +1472,7 @@
</pre>
</p>
</div>
+</div>
<!--
<div id="entity_entity_mappings">
<h4><span class="secno">2.5.3 </span>Entity-Entity mappings (How)</h4>
@@ -1788,7 +1822,7 @@
<!-- OddPage -->
<h2><span class="secno">A. </span>Acknowledgements</h2>
<p>
- We would like to thank Antoine Isaac, Ivan Herman, Timothy Lebo, Simon Miles and Satya Sahoo for their feedback.
+ We would like to thank Antoine Isaac, Ivan Herman, Timothy Lebo, Simon Miles and Satya Sahoo for their comments and feedback, and Idafen Santana Pérez for his help with the HTML generation.
</p>
</div>
--- a/examples/eg-24-prov-o-html-examples/rdf/create/rdf/class_Bundle.ttl Fri Oct 26 14:47:02 2012 -0400
+++ b/examples/eg-24-prov-o-html-examples/rdf/create/rdf/class_Bundle.ttl Fri Oct 26 14:47:29 2012 -0400
@@ -1,14 +1,17 @@
-@base: <http://www.example.com/example.ttl> .
+@base <http://www.example.com/example.ttl> .
@prefix my: <http://example.com/my#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+@prefix : <http://example.com/#> .
+
## A provenance file located a http://example.com/example.ttl
-< > a prov:Bundle;
+<> a prov:Bundle;
prov:generatedAtTime "2012-05-24T10:30:00"^^xsd:dateTime;
prov:wasAttributedTo :Bob.
my:report1
a my:Report, prov:Entity;
my:version "1";
- prov:generatedAtTime "2012-05-24T10:00:01"^^xsd:dateTime.
\ No newline at end of file
+ prov:generatedAtTime "2012-05-24T10:00:01"^^xsd:dateTime.
--- a/examples/eg-24-prov-o-html-examples/rdf/create/rdf/class_EntityInfluence.ttl Fri Oct 26 14:47:02 2012 -0400
+++ b/examples/eg-24-prov-o-html-examples/rdf/create/rdf/class_EntityInfluence.ttl Fri Oct 26 14:47:29 2012 -0400
@@ -16,5 +16,5 @@
prov:generated :sortedData;
.
-:rawData rdf:type prov:Entity .
-:sortedData rdf:type prov:Entity .
+:rawData a prov:Entity .
+:sortedData a prov:Entity .
--- a/examples/eg-24-prov-o-html-examples/rdf/create/rdf/property_qualifiedInfluence.ttl Fri Oct 26 14:47:02 2012 -0400
+++ b/examples/eg-24-prov-o-html-examples/rdf/create/rdf/property_qualifiedInfluence.ttl Fri Oct 26 14:47:29 2012 -0400
@@ -16,7 +16,7 @@
# This unqualified influence is unknown in PROV,
# this would be a subproperty of wasAssociatedWith.
- ex:wasConductedBy :bob;
+ my:wasConductedBy :bob;
prov:wasInfluencedBy :bob;
prov:qualifiedInfluence [
# Even though PROV systems do not understand :wasConductedBy,
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/comments/lc-ack-robert.txt Fri Oct 26 14:47:29 2012 -0400
@@ -0,0 +1,294 @@
+ 1.1.2 ISSUE-525 (Specialization/Alternate)
+
+ I think my comment was misunderstood. Fig 8 in
+ http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html
+ shows the entity-entity relationship as the more general
+ "wasInfluencedBy" relationship, which is defined within that
+ figure to have an ID and attributes (gray box). This is also
+ stated in section 5.3.5. Section 5.5 defines SpecializationOf,
+ AlternateOf, and MentionOf, all of which are entity-entity
+ relationships. Therefore, it seems that specialization is a type
+ of influence and should therefore contain the ID/attributes
+ pattern. If this is not the case, the text may require
+ clarification.
+
+New change implemented.
+Acknowledgement expected.
+
+ 1.1.4 ISSUE-504 (collection/bundle)
+
+ In my opinion, a prov description is as much a "thing in the
+ world" as an activity, attribution, or association (all of which
+ can have an ID). Applications that merge, aggregate, and/or infer
+ provenance will need to track the provenance of individual
+ statements; doing so will require an ID for each statement. It
+ should be noted that if descriptions cannot be given IDs directly,
+ they can (individually) be wrapped in a bundle but this is a
+ highly inefficient workaround.
+
+Suggested change implemented.
+Further response added.
+
+Given that this point has been debated at length (there is no support
+to introduce identifiers for individual prov statements), I propose
+to close this issue.
+
+ 1.1.5 ISSUE-503 (adopt plan)
+
+ The use case in question is simply indicating that a given plan
+ was adopted by a given entity (without necessarily specifying an
+ associated activity). It is not an influence, so wasDerivedFrom
+ and wasAttributedTo do not address the issue. The proposed OWL
+ solution (inverse hadPlan) is technology-specific and isn't quite
+ sufficient, as it requires an activity. I think I'm looking for
+ something similar to wasAssociatedWith, which allows one to
+ associate an activity (required) with an agent and/or plan
+ (optional). In this case, I want to link a plan (required) to an
+ agent (required) with an optional activity.
+
+Suggested change implemented.
+Further response added.
+
+Acknowledgement expected.
+
+ 1.1.15 ISSUE-516 (DerivationAsBundle) Section 5.2.1 states, "there
+ must be some underpinning activities performing the necessary
+ actions resulting in such a derivation". Note both "activities"
+ and "actions" are plural. The statement wasDerivedFrom, however,
+ allows only a single activity to be specified. Is derivation
+ intended to support multiple activities (as per the text), and if
+ so, are multiple statements necessary (one for each activity)?
+ The question about derivation as a bundle was based on the
+ impression that multiple activities might be part of "a
+ derivation" (as per the text).
+
+Clarification about activity/activities implemented.
+http://dvcs.w3.org/hg/prov/rev/65532a436d0c
+Acknowledgement expected.
+
+ 1.1.16 ISSUE-514 (Starter/EnderActivity) The new table helps. I
+ might suggest defining the significance of the terms in
+ parentheses within the table. Also, the agent column probably
+ could be deleted.
+
+Added cross-linking to attribute definitions.
+http://dvcs.w3.org/hg/prov/rev/a995233c4419
+Acknowledgement expected.
+
+ 1.1.12 ISSUE-528 (MentionOf) - I don't feel strongly about this.
+ The comment was in response to an editorial notation in the DM
+ inquiring whether this relation was necessary.
+
+I propose to close. Debate continues for issue-475.
+
+ 1.1.13 ISSUE-517 (Revision/Quotation) I agree that "The
+ definitions of Revision and Quotation are reasonably intuitive."
+ However, the line between the two is fuzzy and it should be
+ acknowledged that those creating provenance statements may face an
+ arbitrary choice between the two.
+
+I extended the response with "We acknowledge the reviewer's follow-on
+comment. Ultimately, the Working Group provides a vocabulary, and
+users of that Vocabulary will have to make judgement as to which
+constructs they have to use. This issue is not specific to revision
+and quotation. (e.g. What is entity? what is activity? Is this
+specialization or alternate? etc)"
+
+I propose to close.
+
+ 1.1.22 ISSUE-515 (Invalidation) Re: temporarily unavailable
+ entities. Thanks for the example. This may address the question.
+ Re: invalidation due to state change. The response by the working
+ group makes sense ("As a minimum, an entity must have a fixed
+ identity during its lifetime." and "some aspects, represented as
+ attributes, that do not change over that lifespan"). That
+ question was motivated by the traffic light example in the DM: "An
+ entity's lifetime can end for different reasons: ... an entity
+ attribute is changing: e.g. the traffic light changed from green
+ to red", then further down in the text "the traffic light became
+ red and therefore is regarded as a different entity to the green
+ light". In that example, the identity of the traffic light did
+ not change, and some attributes of the light remain constant;
+ therefore, it is difficult for me to understand why the state
+ change would invalidate the entity. This example seems to
+ contradict the working group's response to the question.
+
+I added the following to our response.
+
+In the follow-on message, the reviewer discusses the traffic light example. As the light changes from red to green, the green traffic light is invalidated and the red traffic light is generated. Both are specializations of the traffic-light, which continues its existence across this change state, since color is not one of its attributes.
+entity(ex:traffic-light)
+entity(ex:green-traffic-light, [ex:color="green"])
+entity(ex:red-traffic-light, [ex:color="red"])
+specializationOf(ex:green-traffic-light, ex:traffic-light)
+specializationOf(ex:red-traffic-light, ex:traffic-light)
+wasGeneratedBy(ex:red-traffic-light,-,2011-11-16T16:00:00)
+wasInvalidatedBy(ex:green-traffic-light,-,2011-11-16T16:00:00)
+
+I proposed to close this issue.
+
+ 1.1.23 ISSUE-530 (attributes) I understand the group's difficulty
+ in reaching consensus on this issue. Since it is possible to
+ support these attributes via the optional user-defined attributes,
+ leaving them out of the spec will not prevent their use.
+ Variability in implementation is likely, however, so it might be
+ worthwhile to centralize these within an extension once
+ implementations have a chance to experiment with the spec.
+
+Added a comment:
+
+ In response to the follow-on message, the Working Group, as it
+ wraps up its activities, will consider follow-on activities, and
+ mechanisms for community to share information. The Semantic Web
+ wiki is a starting point.
+
+I propose to close this issue.
+
+ 1.1.25 ISSUE-522 (Activity Delegation) There were two parts to my
+ comment. First, agents can be either entities or activities.
+ Does delegation apply to only those agents that are entities, or
+ can activity-agents also delegate? Second, the definition of
+ delegation includes only the delegate and responsible agents;
+ activity is optional. Therefore, it is possible to state that one
+ agent is the delegate of another, irrespective of any activity.
+ This delegation likely is not indefinite, however, and is bounded
+ by some context (e.g., time, role within an organization, etc).
+ It should be possible to describe the bounds of the delegation.
+ This might be done using user-defined attributes, but
+ interoperability would suffer without some guidance within the
+ spec.
+
+Added comment to address this point:
+
+ - It is true that, in a delegation, activity is optional. The reviewer suggests "Therefore, it is possible to state that one agent is the delegate of another, irrespective of any activity. This delegation likely is not indefinite, however, and is bounded by some context (e.g., time, role within an organization, etc). It should be possible to describe the bounds of the delegation.". But it is not the intended semantics:
+ o PROV constraints defines the semantics of optional arguments, and
+ specifically, in Table 3, explains that activity in delegation is
+ expandable.
+ o It means that an absent activity can be replaced by an
+ existential variable. Hence, actedOnBehalfOf(ag2,ag1) really means
+ that agent ag2 acted on behalf of agent ag1 in the context of some
+ unspecified activity. Some activity, not all activity.
+ o This (unspecified) activity defines the bounds of the
+ delegation. If these bounds need to be made explicit, than an
+ activity also needs to be made explicit.
+
+Acknowledgment expected.
+
+ 1.1.27 ISSUE-526 (Alternate) The text in the working group's
+ response to this comment (see below) is helpful. It might be
+ beneficial to add this to the DM document.
+
+ "Note that alternateOf is a necessarily very general
+ relationship that, in reasoning, only tells you that the two
+ alternate entities fix different aspects of some common thing
+ (possibly evolving over time), and so there is some relevant
+ connection between the provenance of the alternates. In a
+ specific application context, alternateOf, or a subtype of it,
+ could allow you to infer more."
+
+Change made
+http://dvcs.w3.org/hg/prov/diff/60b6ee097555/model/prov-dm.html
+Acknowledgment expected.
+
+
+ 1.1.28 ISSUE-502 (Derivation) In my opinion, the initial
+ emphasis on transformation may muddle the definition. The
+ working group's response contained a helpful phrase ("The focus
+ of derivation is on connecting a generated entity to a used
+ entity.") that would add clarity to the definition of
+ derivation.
+
+Sentence was added to the text explaining the notion of derivation:
+ http://dvcs.w3.org/hg/prov/diff/780b82818bcf/model/prov-dm.html
+
+Acknowledgment expected.
+
+
+----------------------------------------------------------------------
+
+All issues below are now closed.
+
+----------------------------------------------------------------------
+
+
+ 1.1.1 ISSUE-532 (Role) - prov:type seems to satisfy the requirement
+
+Closed
+
+
+ 1.1.3 ISSUE-507 (Inverse Relations) - I know there has been
+ considerable discussion regarding the normative/informative
+ sections of the documents. This should address the original
+ comment.
+
+Closed
+
+
+ 1.1.8 ISSUE-500 (activity hierarchy)
+
+ I believe hierarchies of activities will be important when
+ maintaining provenance. I understand the working group is not
+ going to support this use case. I will consider extending the
+ prov spec to support activity hierarchies.
+
+Closed
+
+ 1.1.9 ISSUE-505 (prov-n notation) I believe I reviewed a version
+ of the DM that did not consistently apply the semi-colon
+ convention. The core of the comment, however, duplicates
+ issue-533 (still pending).
+
+Closed
+
+ 1.1.10 ISSUE-508 (Table 5) - Thanks for clarifying the text.
+ Issue-533 will address the remainder of the comment.
+
+Closed
+
+ 1.1.11 ISSUE-531 (Multiple location) - Addressed - no further comment
+
+Closed
+
+ 1.1.14 ISSUE-501 (DrivingACarToBoston) - no further comment
+
+Closed
+ 1.1.17 ISSUE-513 (StartSubActivity) As for Issue-500, I believe it
+ will be important to support these features. As they are not part
+ of the core spec, it may be possible to support them through an
+ extension.
+
+Closed
+
+ 1.1.18 ISSUE-511 (UsageSubActivity) As for Issue-500, I believe it
+ will be important to support these features. As they are not part
+ of the core spec, it may be possible to support them through an
+ extension.
+
+Closed
+
+ 1.1.19 ISSUE-510 (GenerationSubActivity) As for Issue-500, I
+ believe it will be important to support these features. As they
+ are not part of the core spec, it may be possible to support them
+ through an extension.
+
+Closed
+
+ 1.1.20 ISSUE-512 (FinePayingExample) - I think this is more clear.
+ No further comment.
+
+Closed
+
+ 1.1.21 ISSUE-497 (Figure 1) - No further comment
+
+Closed
+
+
+ 1.1.24 ISSUE-520 (Person/Organization/SoftwareAgent)
+ Thank you for the detailed response - it helped clarify for me the intended distinction between entity and agent. I tend to think about these concepts in a different way.
+
+
+Closed.
+
+ 1.1.26 ISSUE-509 (AttributesInUML) - no further comment
+
+Closed
+
--- a/model/diff.html Fri Oct 26 14:47:02 2012 -0400
+++ b/model/diff.html Fri Oct 26 14:47:29 2012 -0400
@@ -1026,7 +1026,7 @@
pre.sh_sourceCode .sh_attribute { color: #006400; }
</style><link href="./extra-dm.css" rel="stylesheet" type="text/css" charset="utf-8"><link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8"></head>
- <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">PROV-DM: The PROV Data Model</h1><h2 id="subtitle"><a href="diff.html"><span class="insert">Changes</span></a><span class="insert"> since LC release</span></h2><h2 id="w3c-editor-s-draft-22-october-2012"><acronym title="World Wide Web Consortium">W3C</acronym> <span class="delete">Working</span><span class="insert">Editor's</span> Draft <span class="delete">24 July</span><span class="insert">22 October</span> 2012</h2><dl><dt>This version:</dt><dd><span class="delete">http://www.w3.org/TR/2012/WD-prov-dm-20120724/</span><a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html"><span class="insert">http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html</span></a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html">http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html</a></dd><dt>Previous version:</dt><dd><span class="delete">http://www.w3.org/TR/2012/WD-prov-dm-20120503/</span><span class="delete"> (</span><span class="delete">color-coded diffs</span><span class="delete">)</span><a href="http://www.w3.org/TR/2012/WD-prov-dm-20120724/"><span class="insert">http://www.w3.org/TR/2012/WD-prov-dm-20120724/</span></a></dd><dt>Editors:</dt><dd><a href="http://www.ecs.soton.ac.uk/~lavm/">Luc Moreau</a>, University of Southampton</dd>
+ <body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">PROV-DM: The PROV Data Model</h1><h2 id="subtitle"><a href="diff.html"><span class="insert">Changes</span></a><span class="insert"> since LC release</span></h2><h2 id="w3c-editor-s-draft-26-october-2012"><acronym title="World Wide Web Consortium">W3C</acronym> <span class="delete">Working</span><span class="insert">Editor's</span> Draft <span class="delete">24 July</span><span class="insert">26 October</span> 2012</h2><dl><dt>This version:</dt><dd><span class="delete">http://www.w3.org/TR/2012/WD-prov-dm-20120724/</span><a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html"><span class="insert">http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html</span></a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html">http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html</a></dd><dt>Previous version:</dt><dd><span class="delete">http://www.w3.org/TR/2012/WD-prov-dm-20120503/</span><span class="delete"> (</span><span class="delete">color-coded diffs</span><span class="delete">)</span><a href="http://www.w3.org/TR/2012/WD-prov-dm-20120724/"><span class="insert">http://www.w3.org/TR/2012/WD-prov-dm-20120724/</span></a></dd><dt>Editors:</dt><dd><a href="http://www.ecs.soton.ac.uk/~lavm/">Luc Moreau</a>, University of Southampton</dd>
<dd><a href="http://www.cs.ncl.ac.uk/people/Paolo.Missier">Paolo Missier</a>, Newcastle University</dd>
<dt><span class="delete">Contributors:</span><span class="insert">Authors:</span></dt><dd><a href="http://semanticweb.org/wiki/Khalid_Belhajjame">Khalid Belhajjame</a>, University of Manchester</dd>
<dd><span>Reza B'Far</span>, Oracle Corporation</dd>
@@ -1503,7 +1503,9 @@
</div>
-<p>
+<p><span class="insert">
+The focus of derivation is on connecting a generated entity to a used
+entity.</span>
While the basic idea is simple, the concept of derivation can be quite
subtle: implicit is the notion that the generated entity was affected
in some way by the used entity.
@@ -1659,9 +1661,10 @@
-<p>To illustrate expanded relations, we consider the concept of
-association, described
-in <a class="section-ref" href="#section-agents-attribution-association-delegation"><span>Section 2.1.3</span></a>. Agents may <span class="delete">adopt</span><span class="insert">rely on</span> <em>plans</em>, i.e. sets of actions or steps, to achieve their
+<p>To illustrate expanded relations, we <span class="delete">consider</span><span class="insert">revisit</span> the concept of
+association, <span class="delete">described</span><span class="insert">introduced</span>
+in <a class="section-ref" href="#section-agents-attribution-association-delegation"><span>Section 2.1.3</span></a><span class="delete">.</span><span class="insert"> (full definition of the expanded association can be found
+in </span><a class="section-ref" href="#term-Association"><span><span class="insert">Section 5.3.3</span></span></a><span class="insert">).</span> Agents may <span class="delete">adopt</span><span class="insert">rely on</span> <em>plans</em>, i.e. sets of actions or steps, to achieve their
goals in the context of an activity.
Hence, an expanded form of
association relation allows for a plan to be specified. Plan is defined by subtyping and
@@ -1758,7 +1761,7 @@
<h4><span class="secno">2.2.3 </span>Collections</h4>
<p>
-<span class="glossary-ref"> A <span class="dfn">collection</span> is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be <span class="dfn">member of</span> the collections. </span> Many different types of collections exist, such as <em>sets</em>, <em>dictionaries</em>, or <em>lists</em>.
+<span class="glossary-ref"> A <span class="dfn">collection</span> is an entity that provides a structure to some <span class="delete">constituents, which are</span><span class="insert">constituents that must</span> themselves<span class="insert"> be</span> entities. These constituents are said to be <span class="dfn">member of</span> the collections. </span> Many different types of collections exist, such as <em>sets</em>, <em>dictionaries</em>, or <em>lists</em>.
Using Collections, one can express the provenance of the collection itself in addition to that of the members. </p>
<div class="anexample conceptexample" id="collection-example"><div class="anexampleTitle">Example <span class="delete">14</span><span class="insert">15</span><sup><a class="internalDFN" href="#collection-example"><span class="diamond"> â—Š</span></a></sup></div>
@@ -2151,11 +2154,11 @@
<div id="secondary-elements-relations-at-a-glance-div" style="text-align: center;">
<table class="thinborder" style="margin-left: auto; margin-right: auto;">
<caption id="secondary-elements-relations-at-a-glance"><span><span class="insert">Table 5</span><sup><a class="internalDFN" href="#secondary-elements-relations-at-a-glance"><span class="diamond"><span class="insert"> â—Š:</span></span></a></sup> </span><span class="insert">Secondary optional elements in PROV-DM Relations</span></caption>
-<tbody><tr><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td><td colspan="6"><span class="insert">Secondary Object</span></td></tr>
+<tbody><tr><td style="border-width: 0px; "></td><td style="border-width: 0px;§> "></td><td colspan="6"><span class="insert">Secondary Object</span></td></tr>
<tr><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td><td><span class="insert">Entity</span></td><td><span class="insert">Activity</span></td><td><span class="insert">Agent</span></td></tr>
-<tr><td rowspan="3"><span class="insert">Subject</span></td><td><span class="insert">Entity</span></td><td class="component5-color"><a href="#dfn-mentionof" class="internalDFN"><span class="insert">MentionOf</span></a><span class="insert"> (bundle)</span></td><td class="component2-color"><a href="#dfn-wasderivedfrom" class="internalDFN"><span class="insert">WasDerivedFrom</span></a><span class="insert"> (activity)</span><br><a><span class="insert">Revision (activity)</span></a><br><a><span class="insert">Quotation (activity)</span></a><br><a><span class="insert">PrimarySource (activity)</span></a></td><td colspan="2"><span class="insert">—</span></td></tr>
-<tr><td><span class="insert">Activity</span></td><td class="component3-color"><a href="#dfn-wasassociatedwith" class="internalDFN"><span class="insert">WasAssociatedWith</span></a><span class="insert"> (plan)</span></td><td class="component1-color"><a href="#dfn-wasstartedby" class="internalDFN"><span class="insert">WasStartedBy</span></a><span class="insert"> (starter)</span><br><a href="#dfn-wasendedby" class="internalDFN"><span class="insert">WasEndedBy</span></a><span class="insert"> (ender)</span></td><td colspan="2"><span class="insert">—</span></td></tr>
-<tr><td><span class="insert">Agent</span></td><td><span class="insert">—</span></td><td class="component3-color"><a href="#dfn-actedonbehalfof" class="internalDFN"><span class="insert">ActedOnBehalfOf</span></a><span class="insert"> (activity)</span></td><td><span class="insert">—</span></td></tr>
+<tr><td rowspan="3"><span class="insert">Subject</span></td><td><span class="insert">Entity</span></td><td class="component5-color"><a href="#dfn-mentionof" class="internalDFN"><span class="insert">MentionOf</span></a><span class="insert"> (</span><a href="#mention.bundle"><span class="insert">bundle</span></a><span class="insert">)</span></td><td class="component2-color"><a href="#dfn-wasderivedfrom" class="internalDFN"><span class="insert">WasDerivedFrom</span></a><span class="insert"> (</span><a href="#derivation.activity"><span class="insert">activity</span></a><span class="insert">)</span></td><td colspan="2"><span class="insert">—</span></td></tr>
+<tr><td><span class="insert">Activity</span></td><td class="component3-color"><a href="#dfn-wasassociatedwith" class="internalDFN"><span class="insert">WasAssociatedWith</span></a><span class="insert"> (</span><a href="#association.plan"><span class="insert">plan</span></a><span class="insert">)</span></td><td class="component1-color"><a href="#dfn-wasstartedby" class="internalDFN"><span class="insert">WasStartedBy</span></a><span class="insert"> (</span><a href="#start.starter"><span class="insert">starter</span></a><span class="insert">)</span><br><a href="#dfn-wasendedby" class="internalDFN"><span class="insert">WasEndedBy</span></a><span class="insert"> (</span><a href="#end.ender"><span class="insert">ender</span></a><span class="insert">)</span></td><td colspan="2"><span class="insert">—</span></td></tr>
+<tr><td><span class="insert">Agent</span></td><td><span class="insert">—</span></td><td class="component3-color"><a href="#dfn-actedonbehalfof" class="internalDFN"><span class="insert">ActedOnBehalfOf</span></a><span class="insert"> (</span><a href="#delegation.activity"><span class="insert">activity</span></a><span class="insert">)</span></td><td><span class="insert">—</span></td></tr>
</tbody></table>
</div>
@@ -2691,7 +2694,7 @@
<p>According to <a href="#section-prov-overview">Section 2</a>, for an entity to be transformed from, created from, or resulting from an update to another, there must be some
-underpinning activities performing the necessary actions resulting in such a derivation.
+underpinning <span class="insert">activity or </span>activities performing the necessary <span class="delete">actions</span><span class="insert">action(s)</span> resulting in such a derivation.
A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to represent further information about the derivation. If the derivation is the result of a single known activity, then this activity can also be optionally expressed. To provide a completely accurate description of the derivation, the generation and usage of the generated and used entities, respectively, can be provided, so as to make the derivation path, through usage, activity, and generation, explicit. Optional information such as activity, generation, and usage can be linked to derivations to aid analysis of provenance and to facilitate provenance-based reproducibility. </p>
@@ -2892,6 +2895,9 @@
<div class="glossary-ref"> An <dfn id="concept-agent" class="internalDFN">agent</dfn><sup><a class="internalDFN" href="#concept-agent"><span class="diamond"> â—Š</span></a></sup> is something that bears some form of responsibility for an activity taking place, for the existence of an entity, or for another agent's activity. </div>
+<p><span class="insert">An agent may be a particular type of entity or activity. This means that the model can be
+ used to express provenance of the agents themselves. </span></p>
+
<p></p><div class="attributes" id="attributes-agent">An <dfn title="dfn-agent" id="dfn-agent" class="internalDFN">agent</dfn><sup><a class="internalDFN" href="#dfn-agent"><span class="diamond"> â—Š</span></a></sup><span class="withPn">, written <span class="pnExpression" id="pn-agent">agent(id, [attr1=val1, ...])</span> in PROV-N,</span> has:
<ul>
@@ -3360,6 +3366,12 @@
</div>
+
+
+<p><span class="insert">Specialization is not defined as Influence, and therefore does not have an id and attributes.</span></p>
+
+
+
<div class="anexample" id="anexample-specialization"><div class="anexampleTitle">Example <span class="delete">42</span><span class="insert">43</span><sup><a class="internalDFN" href="#anexample-specialization"><span class="diamond"> â—Š</span></a></sup></div>
<p>
The BBC news home page on 2012-03-23 <span class="name">ex:bbcNews2012-03-23</span>
@@ -3388,6 +3400,10 @@
+
+
+
+
<p></p><div class="attributes" id="attributes-alternate">An <dfn title="alternateOf" id="dfn-alternateof" class="internalDFN">alternate</dfn><sup><a class="internalDFN" href="#dfn-alternateof"><span class="diamond"> â—Š</span></a></sup> relation<span class="withPn">, written <span class="pnExpression">alternateOf(e1, e2)</span> in PROV-N,</span> has:
<ul>
<li><span class="attribute" id="alternate.alternate1">alternate1</span>: an identifier (<span class="name">e1</span>) of the first of the two entities;</li>
@@ -3395,6 +3411,19 @@
</ul>
</div>
+<p><span class="insert">Alternate is not defined as Influence, and therefore does not have an id and attributes.</span></p>
+
+<p><span class="insert">
+Note that </span><a title="alternateOf" href="#dfn-alternateof" class="internalDFN"><span class="insert">alternateOf</span></a><span class="insert"> is a necessarily very general
+relationship that, in reasoning, only states that the two
+alternate entities fix different aspects of some common thing
+(possibly evolving over time), and so there is some relevant
+connection between the provenance of the alternates. In a
+specific application context, </span><a title="alternateOf" href="#dfn-alternateof" class="internalDFN"><span class="insert">alternateOf</span></a><span class="insert">, or a subtype of it,
+could allow more inferences.
+</span></p>
+
+
<div class="anexample" id="anexample-alternate"><div class="anexampleTitle">Example <span class="delete">43</span><span class="insert">44</span><sup><a class="internalDFN" href="#anexample-alternate"><span class="diamond"> â—Š</span></a></sup></div>
<p>
A given news item on the BBC News site
@@ -3464,6 +3493,11 @@
+
+
+
+
+
<p></p><div class="attributes" id="attributes-mention">A <dfn title="mentionOf" id="dfn-mentionof" class="internalDFN">mention</dfn><sup><a class="internalDFN" href="#dfn-mentionof"><span class="diamond"> â—Š</span></a></sup> relation<span class="withPn">, written <span class="pnExpression">mentionOf(infra, supra, b)</span> in PROV-N,</span> has:
<ul>
<li><span class="attribute" id="mention.specificEntity">specificEntity</span>: an identifier (<span class="name">infra</span>)
@@ -3473,6 +3507,8 @@
</ul>
</div>
+<p><span class="insert">Mention is not defined as Influence, and therefore does not have an id and attributes.</span></p>
+
<div class="anexample" id="anexample-mention-rating"><div class="anexampleTitle">Example <span class="delete">45</span><span class="insert">46</span><sup><a class="internalDFN" href="#anexample-mention-rating"><span class="diamond"> â—Š</span></a></sup></div>
<p>This example is concerned with a performance rating tool that reads and processes provenance to determine the performance of agents. To keep the example simple, an agent's performance is determined by the duration of the activities it is associated with. </p>
<p>As an illustration, we consider that two bundles <span class="name">ex:run1</span> and <span class="name">ex:run2</span> refer to an agent <span class="name">ex:Bob</span> that controlled two activities <span class="name">ex:a1</span> and <span class="name">ex:a2</span>. </p>
@@ -3575,7 +3611,7 @@
<div id="term-collection" class="section">
<h4><span class="secno">5.6.1 </span>Collection</h4>
-<span class="glossary-ref"> A <dfn id="concept-collection" class="internalDFN">collection</dfn><sup><a class="internalDFN" href="#concept-collection"><span class="diamond"> â—Š</span></a></sup> is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be <dfn id="dfn-member-of" class="internalDFN">member of</dfn><sup><a class="internalDFN" href="#dfn-member-of"><span class="diamond"> â—Š</span></a></sup> the collections. </span>
+<span class="glossary-ref"> A <dfn id="concept-collection" class="internalDFN">collection</dfn><sup><a class="internalDFN" href="#concept-collection"><span class="diamond"> â—Š</span></a></sup> is an entity that provides a structure to some <span class="delete">constituents, which are</span><span class="insert">constituents that must</span> themselves<span class="insert"> be</span> entities. These constituents are said to be <dfn id="dfn-member-of" class="internalDFN">member of</dfn><sup><a class="internalDFN" href="#dfn-member-of"><span class="diamond"> â—Š</span></a></sup> the collections. </span>
<span class="glossary-ref"> An <dfn id="concept-empty-collection" class="internalDFN">empty collection</dfn><sup><a class="internalDFN" href="#concept-empty-collection"><span class="diamond"> â—Š</span></a></sup> is a collection without members. </span>
@@ -3620,6 +3656,12 @@
+
+
+
+<p><span class="insert">Membership is not defined as Influence, and therefore does not have an id and attributes.</span></p>
+
+
<div class="anexample" id="example_49"><div class="anexampleTitle">Example <span class="delete">48</span><span class="insert">49</span><sup><a class="internalDFN" href="#example_49"><span class="diamond"> â—Š</span></a></sup></div>
<p>In this example, <span class="name">c</span> is a collection known to have <span class="name">e0</span>, <span class="name">e1</span>, and <span class="name">e2</span> as members, and may have other members.</p>
<pre class="codeexample">entity(e0)
@@ -4307,6 +4349,16 @@
</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/499"><span class="insert">ISSUE-499</span></a><span class="insert">: Made explicit that generation/usage/invalidation/start/end are implicit.
</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/449"><span class="insert">ISSUE-449</span></a><span class="insert">: Clarified definition of prov:value attribute and added an example.
</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/495"><span class="insert">ISSUE-495</span></a><span class="insert">: added paragraph about 'relations opening up'. Clarified the role of '-' in example. Fixed dates in biblio. Fixed space issue in prov-n examples
+</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/516"><span class="insert">ISSUE-516</span></a><span class="insert">: Stating that there moust be some underpinning activity or activities for a derivation, instead of just activities.
+</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/525"><span class="insert">ISSUE-525</span></a><span class="insert">: Made it explicit that Membership, Alternate, Specialization are not Influence
+</span></li><li><span class="insert"> Copied the sentence " An agent may be a particular type of entity or activity. This means that the model can be
+ used to express provenance of the agents themselves. " from the informative section into the normative section.
+</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/504"><span class="insert">ISSUE-504</span></a><span class="insert">: Updated definition of collection.
+</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/503"><span class="insert">ISSUE-503</span></a><span class="insert">: Rephrased the introduction of expanded association in section 2.2.1.2 Expanded Relations.
+</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/514"><span class="insert">ISSUE-514</span></a><span class="insert">: added links to the attributes listed in the secondary element table. Also removed PrimarySource, Quotation, Revision.
+</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/502"><span class="insert">ISSUE-502</span></a><span class="insert">: Added sentence in section 2.1.2 explaining that the focus
+ of derivation is on connecting a generated entity to a used entity.
+</span></li><li> <a href="http://www.w3.org/2011/prov/track/issues/526"><span class="insert">ISSUE-526</span></a><span class="insert">: Added sentence clarifying sentence in section 5.5.2.
</span></li></ul>
</div>
--- a/model/glossary.html Fri Oct 26 14:47:02 2012 -0400
+++ b/model/glossary.html Fri Oct 26 14:47:29 2012 -0400
@@ -36,7 +36,7 @@
</span>
<span class="glossary" id="glossary-collection">
-A <dfn id="concept-collection">collection</dfn> is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be <dfn>member of</dfn> the collections.
+A <dfn id="concept-collection">collection</dfn> is an entity that provides a structure to some constituents that must themselves be entities. These constituents are said to be <dfn>member of</dfn> the collections.
</span>
--- a/model/glossary.js Fri Oct 26 14:47:02 2012 -0400
+++ b/model/glossary.js Fri Oct 26 14:47:29 2012 -0400
@@ -3,7 +3,7 @@
// with <script src="glossary.js" class="remove"></script>
//Insert glossary definitions with the following
// <div class="glossary-ref" ref="glossary-generation"></div>
-glossary_hg='http://dvcs.w3.org/hg/prov/file/d005d76ab405/model/glossary.html';
+glossary_hg='http://dvcs.w3.org/hg/prov/file/38b9e40267bb/model/glossary.html';
glossary_string=
' ' +
'<html> ' +
@@ -43,7 +43,7 @@
'</span> ' +
' ' +
'<span class="glossary" id="glossary-collection"> ' +
-'A <dfn id="concept-collection">collection</dfn> is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be <dfn>member of</dfn> the collections. ' +
+'A <dfn id="concept-collection">collection</dfn> is an entity that provides a structure to some constituents that must themselves be entities. These constituents are said to be <dfn>member of</dfn> the collections. ' +
'</span> ' +
' ' +
' ' +
--- a/model/prov-constraints.html Fri Oct 26 14:47:02 2012 -0400
+++ b/model/prov-constraints.html Fri Oct 26 14:47:29 2012 -0400
@@ -425,7 +425,9 @@
<p> This document defines a subset of PROV instances called
<i><a>valid</a></i> PROV instances.
-The intent of validation is ensure that a PROV instance represents a history of objects and their interactions which is consistent, and thus safe to use for the purpose of logical reasoning and other kinds of analysis.
+The intent of validation is ensure that a PROV instance represents a
+consistent history of objects and their interactions that is safe to
+use for the purpose of logical reasoning and other kinds of analysis.
Valid PROV instances satisfy
certain <a>definitions</a>, <a>inferences</a>, and
<a>constraints</a>. These definitions, inferences, and constraints
@@ -468,13 +470,16 @@
<li>The Linked Data and Semantic Web community should focus on PROV-O
defining PROV classes and properties specified in an OWL2
ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify
-the constraints applicable to the data model, and its interpretation.
-<!--PROV-SEM provides a mathematical semantics.
--->
+the constraints applicable to the data model, and its interpretation.
</li>
<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
<li>Readers seeking to implement other PROV serializations
-should focus on PROV-DM and PROV-CONSTRAINTS. PROV-O and PROV-N offer examples of mapping to RDF and text, respectively.</li>
+should focus on PROV-DM and PROV-CONSTRAINTS. PROV-O and PROV-N offer
+examples of mapping to RDF and text, respectively.</li>
+<li>[[PROV-SEM]] provides a mathematical semantics and a collection of
+axioms that provide a (non-normative, but equivalent) declarative specification, aimed
+at readers with a mathematical logic or formal background. This can
+serve as a starting point for alteranative implementations. </li>
</ul>
</section>
@@ -530,8 +535,11 @@
PROV-DM specification [[PROV-DM]] imposes minimal requirements upon
PROV instances. A <a>valid</a> PROV instance corresponds to a
consistent history of objects and interactions to which logical
-reasoning can be safely applied. By default, PROV instances need not
-be <a>valid</a>. </p>
+reasoning can be safely applied. PROV instances need not
+be <a>valid</a>. (The term <a>valid</a> is chosen by analogy with
+notions of validity in other W3C specifications; it is unfortunately
+incompatible with the usual meaning of "validity" in logic.)
+</p>
<p> This document specifies <em>definitions</em> of some
provenance statements in terms of others, <em>inferences</em> over PROV instances
@@ -543,7 +551,8 @@
constraints</em>.
Further discussion
of the semantics of PROV statements, which justifies the definitions, inferences
-and constraints, can be found in the formal semantics [[PROV-SEM]].
+and constraints, and relates the procedural specification approach
+taken here to a declarative specification, can be found in the formal semantics [[PROV-SEM]].
</p>
<p>We define validity and equivalence in terms of a
@@ -554,26 +563,31 @@
<a title="valid">validity</a>. Equivalence of two PROV
instances can be determined by comparing their normal forms. For PROV
documents, validity and equivalence amount to checking the validity or
-pairwise equivalence of their respective documents.
+pairwise equivalence of their respective instances.
</p>
<p>
-This document outlines an algorithm for validity checking based on
+This specification defines
+validity and equivalence procedurally, via an algorithm based on
<a title="normal form">normalization</a>. Applications MAY implement
-validity and equivalence checking using normalization, as suggested
-here, or in
+validity and equivalence checking using normalization, as outlined
+here. Applications MAY also implement validation and equivalence
+checking in
any other way as long as the same instances or documents are considered valid or
equivalent, respectively.
</p>
-<p>Checking validity or equivalence are RECOMMENDED, but not required, for
-applications compliant with PROV. This specification defines how
-validity and equivalence are to be checked, if an application elects
-to support them at all.
+<p> Checking validity or equivalence are RECOMMENDED, but not required, for
+applications compliant with PROV.
Applications producing provenance SHOULD ensure that it is
<a>valid</a>, and similarly applications consuming provenance MAY reject provenance that is not <a>valid</a>. Applications
which are determining whether PROV instances or documents convey the same
information SHOULD check equivalence as specified here, and SHOULD
-treat equivalent instances or documents in the same way.
+treat equivalent instances or documents in the same way. This is a
+guideline only, and the meaning of "in the same way" is
+application-specific. For example, applications that manipulate the syntax of
+PROV instances in particular representations, such as pretty-printing
+or digital signing, have good reasons to treat different equivalent
+documents differently.
</p>
</section>
<section>
@@ -1151,17 +1165,24 @@
substitution for <span class="math">x<sub>1</sub>...x<sub>n</sub></span> making <span class="math">A<sub>1</sub> ∧ ... ∧ A<sub>l</sub></span> true.
</ol>
-<h4>Merging</h4>
-
- <p><em>Merging</em> is an operation that takes two terms and compares them to
- see if they are equal, or can be made equal by substituting an
- existential variable with another term. This operation is a special
- case of <em>unification</em>, a common operation in logical
- reasoning, including logic programming and automated reasoning.
-Merging two terms <span class="math">t,t'</span> results in either substitution <span class="math">S</span>
+<h4>Unification and Merging</h4>
+
+ <p><em>Unification</em> is an operation that takes two terms and compares them to
+ determine whether they can be made equal by substituting an
+ existential variable with another term. If so, the result is such a
+ substitution; otherwise, the result is failure. Unification is an
+ essential concept in logic programming and automated reasoning,
+where terms can involve variables, constants and function symbols. In PROV,
+ by comparison, unification only needs to deal with
+</p>
+<p>
+Unifying two terms <span class="math">t,t'</span> results in either substitution <span class="math">S</span>
such that <span class="math">S(t) = S(t')</span>, or failure indicating that there is no
substitution that can be applied to both <span class="math">t</span> and <span class="math">t'</span> to make
- them equal.
+ them equal. Unification is also used to define an operation on PROV
+ statements called <em>merging</em>. Merging takes two statements
+ that have equal identifiers, unifies their corresponding term
+ arguments, and combines their attribute lists.
</p>
@@ -1205,20 +1226,20 @@
x<sub>1</sub>...x<sub>n</sub>. A<sub>1</sub> ∧ ... ∧ A<sub>p</sub> ⇒ t
= t'</span> can be
applied by searching for an occurrence <span class="math">A<sub>1</sub> ∧ ... ∧ A<sub>p</sub></span> in the instance, and
- if one is found, merging the terms <span class="math">t</span> and
+ if one is found, unifying the terms <span class="math">t</span> and
<span class="math">t'</span>. If successful, the resulting
substitution is applied to the instance; otherwise, the application
of the uniqueness constraint fails. </li>
<li>A key constraint can similarly be applied by searching for
-different occurrences of a statement with the same identifier, merging the
+different occurrences of a statement with the same identifier, unifying the
corresponding parameters of the statements, and concatenating their
-attribute lists. The substitutions obtained by merging are applied to
-the instance.
+attribute lists, to form a single statement. The substitutions obtained by unification are applied to
+the merged statement and the rest of the instance.
</li>
</ul>
<p>As noted above, uniqueness or key constraint
- application can <em>fail</em>, if a required merging step fails. Failure of constraint
+ application can <em>fail</em>, if a required unification or merging step fails. Failure of constraint
application means that there is no way to add information to the
instance to satisfy the constraint, which in turn implies that the
instance is <em>invalid</em>.
@@ -1230,6 +1251,16 @@
called <em>chasing</em> [[DBCONSTRAINTS]] or <em>saturation</em>
[[CHR]]. We call this process <em>normalization</em>.
</p>
+ <p>
+ Although this specification outlines one particular way of
+ performing inferences and checking constraints, based on
+ normalization, implementations can use any other equivalent
+ algorithm. The logical formulas corresponding to the definitions,
+ inferences, and constraints outlined above (and further elaborated
+ in [[PROV-SEM]]) provides an equivalent specification, and any
+ implementation that correctly checks validity and equivalence (whether it performs nornalization or not) complies
+ with this specification.
+ </p>
<h4>Termination</h4>
@@ -1350,7 +1381,8 @@
</li>
</ol>
<p>
- A normalized instance that satisfies all of the checked constraints
+ A normalized instance that passes all of the ordering, typing,
+ and impossibility constraint checks
is called <a>valid</a>. Validity can be, but is not required to be,
checked by normalizing and then checking constraints. Any other
algorithm that provides equivalent behavior (that is, accepts the
@@ -1379,8 +1411,11 @@
notion of equivalence of normal forms is <em>isomorphism</em>. Two
instances <span class="math">I<sub>1</sub></span> and <span class="math">I<sub>2</sub></span> are <em>isomorphic</em> if there is an invertible
substitution <span class="math">S</span> mapping existential variables to existential variables such that <span class="math">S(I<sub>1</sub>) = I<sub>2</sub></span>.
+<!--
This is similar to the notion of equivalence used in [[RDF]], where
- blank nodes play an analogous role to existential variables. </p>
+ blank nodes play an analogous role to existential variables.
+ -->
+ </p>
<p>Equivalence can be checked by normalizing instances, checking that
both instances are valid, then
@@ -1398,15 +1433,21 @@
<h4>From Instances to Bundles and Documents</h4>
<p>PROV documents can contain multiple instances: a <a>toplevel
-instance</a> consisting of the set of statements not appearing within a bundle, and
-zero or more named instances called <a>bundle</a>s. For the purpose
+instance</a>, and
+zero or more additional, named instances called <a>bundle</a>s. For the purpose
of inference and constraint checking, these instances are treated independently. That is,
a PROV document is valid provided that each instance in it is valid
-and the names of its bundles are distinct. Similarly, a PROV document is
+and the names of its bundles are distinct. In other words, there are
+no validity constraints that need to be checked across the different
+instances in a PROV document; the contents of one instance in a
+multi-instance PROV document cannot affect the validity of another instance.
+Similarly, a PROV document is
equivalent to another if their toplevel instances are equivalent, they
have the same number of bundles with the same names, and the instances
-of their corresponding bundles are equivalent. Analogously to blank nodes in
-[[RDF]], the scope of an existential variable in PROV is the instance
+of their corresponding bundles are equivalent.
+<!--Analogously to blank nodes in
+[[RDF]],-->
+The scope of an existential variable in PROV is delimited at the instance
level, so existential variables with the same name occurring in
different instances do not necessarily denote the same term. This
is a consequence of the fact that the instances of two equivalent
@@ -1711,9 +1752,10 @@
application MAY apply the inferences and definitions in <a
href="#inferences" class='sectionRef'></a>.</li>
<li>If determining whether a PROV instance or document is <a>valid</a>, an
- application MUST check that all of the
+ application MUST determine whether all of the
constraints of <a href="#constraints" class="sectionRef"></a> are
- satisfied on the <a>normal form</a> of the instance or document. </li>
+ satisfied on
+ the <a>normal form</a> of the instance or document. </li>
<li> If producing provenance meant for other applications to
use, the application SHOULD produce <a>valid</a> provenance, as specified in <a href="#normalization-validity-equivalence" class="sectionRef"></a>. </li>
<li>If determining whether two PROV instances or documents are
@@ -1721,10 +1763,15 @@
normal forms are equal, as specified in <a href="#normalization-validity-equivalence" class="sectionRef"></a>.
</ol>
- <p>Compliant applications are not required to explicitly compute
- normal forms; however, if checking validity or equivalence, the
- results should be the same as would be obtained by computing normal
- forms as defined in this specification.</p>
+ <p>This specification defines validity and equivalence procedurally
+ via reduction to normal forms. If checking validity or equivalence, the
+ results MUST be the same as would be obtained by computing normal
+ forms as defined in this specification. Applications that explicitly compute
+ normal forms, or to follow the implementation strategy suggested by
+ this specification, are by definition compliant. However,
+ applications can also comply by checking validity and equivalence in any
+ other way that yields the same answers without explicitly applying
+ definitions, inferences, and constraints or constructing normal forms.</p>
<p>
All figures are for illustration purposes
@@ -1808,7 +1855,9 @@
identifiers might later be found to be equal to known identifiers;
they play a similar role in PROV constraints to existential
variables in logic, to "labeled nulls" in database theory
- [[DBCONSTRAINTS]], or to blank nodes in [[!RDF]]. In general, omitted optional parameters to
+ [[DBCONSTRAINTS]].
+ <!--, or to blank nodes in [[!RDF]].-->
+ In general, omitted optional parameters to
[[PROV-N]] statements, or explicit <span class="name">-</span>
markers, are placeholders for existentially quantified variables;
that is, they denote unknown values. There are a few exceptions to
@@ -1822,8 +1871,11 @@
should be viewed as existentially quantified variables, meaning that
through subsequent reasoning steps they may turn out to be equal to
other identifiers that are already known, or to other existentially
- quantified variables. Their treatment is analogous to that of blank
- nodes in RDF. In contrast, distinct URIs or literal values in PROV
+ quantified variables.
+ <!--
+ Their treatment is analogous to that of blank
+ nodes in RDF.-->
+ In contrast, distinct URIs or literal values in PROV
are assumed to be distinct for the purpose of checking validity or
inferences. This issue is discussed in more detail under <a
href="#uniqueness-constraints">Uniqueness Constraints</a>.
@@ -2558,10 +2610,10 @@
<div class="remark">
In the above inference, <span class="name">_pl</span> is an
- existential variable, so it can be
- merged with a constant identifier, another existential variable, or a
+ existential variable, so it can be unified
+with a constant identifier, another existential variable, or a
placeholder <span class="name">-</span>, as explained
- in the definition of <a>merging</a>.
+ in the definition of <a>unification</a>.
</div>
<hr />
<p id='delegation-inference_text'> Delegation relates agents where one agent acts on behalf of
@@ -2594,7 +2646,7 @@
<span class="name">_pl1</span> and <span class="name">_pl2</span>
can be replaced with constant identifiers, existential variables, or
placeholders <span class="name">-</span> independently, as explained
- in the definition of <a>merging</a>.
+ in the definition of <a>unification</a>.
</div>
<hr />
@@ -2830,44 +2882,41 @@
class="name">a</span>) is <span
class="name">activity(a,2011-11-16T16:00:00,2011-11-16T18:00:00,[a=1,b=2])</span>. </p>
- <p> <dfn>Merging</dfn> is an operation that can be applied
- to a pair of terms, or a pair of attribute lists.
- The result of merging is either a substitution (mapping
- existentially quantified variables to terms) or failure, indicating that the merge
- cannot be performed. Merging of pairs of terms, attribute lists,
- or statements is defined as follows.</p>
+ <p> <dfn>Unification</dfn> is an operation that can be applied
+ to a pair of terms.
+ The result of unification is either a <dfn>unifier</dfn>, that is,
+ a substitution <span class="math">S</span> such that <span class="math">S(t)
+ = S(t')</span>, or failure, indicating
+ that there is no <a>unifier</a>. Unification of pairs of terms is defined as follows.</p>
<ul>
<li> If <span class="name">t</span> and <span
class="name">t'</span> are constant identifiers or values
(including the placeholder <span class="name">-</span>), then
- their <a>merge</a> exists only if they are equal, otherwise merging
+ there are two cases. If <span class="name">t = t'</span> then their <a>unifier</a> is the
+ empty substitution, otherwise unification
fails. </li>
<li> If <span class="name">x</span> is an existential variable
and
<span class="name">t'</span> is any term (identifier, constant,
placeholder <span class="name">-</span>, or
existential variable), then their
- <a>merge</a> is <span class="name">t'</span>, and the resulting substitution is
- <span class="name">[x=t']</span>. In the special case where <span class="name">t'=x</span>, the merge is
- <span class="name">x</span> and the resulting substitution is empty.</li>
+ <a>unifier</a> is
+ <span class="name">[x=t']</span>. In the special case where
+ <span class="name">t'=x</span>, the unifier is the empty substitution.</li>
<li> If <span class="name">t</span> is any term (identifier, constant,
placeholder <span class="name">-</span>, or
existential variable) and
<span class="name">x'</span> is an existential variable, then their
- merge is the same as the merge of <span class="name">x</span> and <span class="name">t</span>.</li>
- <li> The <a>merge</a> of two attribute lists <span
- class="name">attrs1</span> and <span class="name">attrs2</span>
- is their union, considered as sets of key-value pairs, written <span
- class="name">attrs1 ∪ attrs2</span>. Duplicate keys with
- different are
- allowed, but equal key-value pairs are merged.</li>
-</ul>
-
-
-<div class="remark">Merging for terms is analogous to unification in
+ unifier is the same as the unifier of <span class="name">x</span>
+ and <span class="name">t</span>.</li>
+ </ul>
+
+
+
+<div class="remark">Unification is analogous to unification in
logic programming and theorem proving, restricted to flat terms with
- no function symbols. No occurs check is needed because there are no
+constants and variables but no function symbols. No occurs check is needed because there are no
function symbols.</div>
<p>
@@ -2881,15 +2930,15 @@
<ol> <li>Suppose PROV instance <span class="math">I</span> contains all of the hypotheses
<span class="name">hyp<sub>1</sub></span> and ... and <span class="name">hyp<sub>n</sub></span>.
</li>
- <li>Attempt to merge all of the equated terms in the conclusion
+ <li>Attempt to unify all of the equated terms in the conclusion
<span class="name">t<sub>1</sub></span> = <span class="name">u<sub>1</sub></span> and ... and <span class="name">t<sub>n</sub></span> = <span class="name">u<sub>n</sub></span>.
</li>
- <li>If merging fails, then the constraint
+ <li>If unification fails, then the constraint
is unsatisfiable, so application of the constraint to <span class="math">I</span>
fails. If this failure occurs during <a>normalization</a> prior to
validation, then <span class="math">I</span> is invalid, as explained in <a href="#normalization-validity-equivalence">Section 6</a>.
</li>
- <li>If merging succeeds with a substitution <span class="math">S</span>, then
+ <li>If unification succeeds with a substitution <span class="math">S</span>, then
<span class="math">S</span> is applied to the instance <span class="math">I</span>, yielding result <span class="math">S(I)</span>.</li>
</ol>
@@ -2906,20 +2955,20 @@
<p> Because of the presence of attributes, key constraints do not
reduce directly to uniqueness constraints. Instead, we enforce key
- constraints as follows. </p>
+ constraints using the following <dfn>merging</dfn> process. </p>
<ol>
<li> Suppose <span
class="name">r(a<sub>0</sub>; a<sub>1</sub>,...a<sub>n</sub>,attrs1)</span> and <span
class="name">r(b<sub>0</sub>; b<sub>1</sub>,...b<sub>n</sub>,attrs2)</span> hold in PROV instance <span class="math">I</span>, where the key fields <span
class="name">a<sub>k</sub> = b<sub>k</sub></span> are equal.</li>
- <li> Attempt to merge all of the corresponding parameters <span
+ <li> Attempt to unify all of the corresponding parameters <span
class="name">a<sub>0</sub> = b<sub>0</sub> </span> and ... and <span
class="name">a<sub>n</sub> = b<sub>n</sub></span>.
</li>
- <li>If merging fails, then the constraint is unsatisfiable, so
+ <li>If unification fails, then the constraint is unsatisfiable, so
application of the key constraint to <span class="math">I</span> fails.
</li>
- <li>If merging succeeds with substitution <span class="math">S</span>, then we remove <span
+ <li>If unification succeeds with substitution <span class="math">S</span>, then we remove <span
class="name">r(a<sub>0</sub>; a<sub>1</sub>,...a<sub>n</sub>,attrs1)</span> and <span
class="name">r(b<sub>0</sub>; b<sub>1</sub>,...b<sub>n</sub>,attrs2)</span> from <span class="math">I</span>, obtaining
instance <span class="math">I'</span>, and return instance <span
@@ -2927,14 +2976,15 @@
attrs2)}</span> ∪ <span class="math">S(I')</span>.
</ol>
+
<p>Thus, if a PROV instance contains an apparent violation of a uniqueness
- constraint or key constraint, merging can be used to determine
+ constraint or key constraint, unification or merging can be used to determine
whether the constraint can be satisfied by instantiating some existential
variables with other terms. For key constraints, this is the same
as merging pairs of statements whose keys are equal and whose
corresponding arguments are compatible, because after
- merging respective arguments and attribute lists, the two statements
+ unifying respective arguments and combining attribute lists, the two statements
become equal and one can be omitted. </p>
@@ -2952,14 +3002,14 @@
</p>
<div class='constraint' id='key-object'>
<p><ol>
- <li>The identifier field <span class="name">e</span> is a <span class="conditional">KEY</span> for
- the <span class="name">entity(e,attrs)</span> statement.
+ <li>The identifier field <span class="name">id</span> is a <span class="conditional">KEY</span> for
+ the <span class="name">entity(id,attrs)</span> statement.
</li>
- <li>The identifier field <span class="name">a</span> is a <span class="conditional">KEY</span> for
- the <span class="name">activity(a,t1,t2,attrs)</span> statement.
+ <li>The identifier field <span class="name">id</span> is a <span class="conditional">KEY</span> for
+ the <span class="name">activity(id,t1,t2,attrs)</span> statement.
</li>
-<li>The identifier field <span class="name">ag</span> is a <span class="conditional">KEY</span> for
- the <span class="name">agent(ag,attrs)</span> statement.
+<li>The identifier field <span class="name">id</span> is a <span class="conditional">KEY</span> for
+ the <span class="name">agent(id,attrs)</span> statement.
</li>
</ol>
</div>
@@ -3208,7 +3258,7 @@
orders: we say <span class="name">e1</span> <dfn>strictly precedes</dfn> <span
class="name">e2</span> to indicate that <span class="name">e1</span>
happened before <span class="name">e2</span>, but not at the same time. This is a
-<a>transitive</a> relation. </p>
+<a>transitive</a>, <a>irreflexive</a> relation. </p>
<p>PROV also allows for time observations to be inserted in
@@ -3926,7 +3976,7 @@
<p>
<hr />
-<p id='actedOnBehalfOf-ordering_text'>For delegation, two agents need to have some overlap in their lifetime.</p>
+<p id='actedOnBehalfOf-ordering_text'>For delegation, the responsible agent has to precede or have some overlap with the subordinate agent.</p>
<div class='constraint' id='actedOnBehalfOf-ordering'>
@@ -4421,7 +4471,8 @@
variables), yielding an instance <span class="math">I<sub>2</sub></span>.
</li>
<li>
- Apply all uniqueness constraints to <span class="math">I<sub>2</sub></span> by merging terms or statements
+ Apply all uniqueness constraints to <span
+ class="math">I<sub>2</sub></span> by unifying terms or merging statements
and applying the resulting substitution to the instance, yielding
an instance <span class="math">I<sub>3</sub></span>. If some uniqueness constraint cannot be
applied, then normalization fails.
@@ -4446,9 +4497,8 @@
<p>
A PROV instance is <dfn id="dfn-valid">valid</dfn>
-if its normal form exists and satisfies all of
- the validity constraints; this implies that the instance satisfies
- all of the definitions, inferences, and constraints.
+if its normal form exists and all of
+ the validity constraints succeed on the normal form.
The following algorithm can be used to test
validity:</p>
@@ -4473,7 +4523,8 @@
</li>
</ol>
-<p>A normal form of a PROV instance does not exist when a uniqueness constraint fails due to merging failure. </p>
+<p>A normal form of a PROV instance does not exist when a uniqueness
+ constraint fails due to unification or merging failure. </p>
<p>Two PROV instances are <dfn>equivalent</dfn> if they have isomorphic normal forms (that is, after applying all possible inference
@@ -4504,17 +4555,16 @@
<li>
Applying inference rules, definitions, and uniqueness constraints preserves equivalence. That is, a <a>PROV
instance</a> is equivalent to the instance obtained by applying any
- inference rule or definition, or by <a>merging</a> two statements to
+ inference rule or definition, or by <a>unifying</a> two terms or <a>merging</a> two statements to
enforce a uniqueness constraint.
</li>
<li>Equivalence is <a>reflexive</a>, <a>symmetric</a>, and <a>transitive</a>.</li>
</ul>
<p> An application that processes PROV data SHOULD handle
-equivalent instances in the same way. (Common exceptions to this rule
-include, for example, pretty-printers that seek to preserve the
-original order of statements in a file and avoid expanding
-inferences.) </p>
+equivalent instances in the same way. (Common exceptions to this guideline
+include, for example, applications that pretty-print or digitally sign
+provenance, where the order of statements matters.) </p>
</section>
--- a/model/prov-dm.html Fri Oct 26 14:47:02 2012 -0400
+++ b/model/prov-dm.html Fri Oct 26 14:47:29 2012 -0400
@@ -948,6 +948,8 @@
<p>
+The focus of derivation is on connecting a generated entity to a used
+entity.
While the basic idea is simple, the concept of derivation can be quite
subtle: implicit is the notion that the generated entity was affected
in some way by the used entity.
@@ -1107,9 +1109,10 @@
-<p>To illustrate expanded relations, we consider the concept of
-association, described
-in <a class="section-ref" href="#section-agents-attribution-association-delegation"><span>TBD</span></a>. Agents may rely on <em>plans</em>, i.e. sets of actions or steps, to achieve their
+<p>To illustrate expanded relations, we revisit the concept of
+association, introduced
+in <a class="section-ref" href="#section-agents-attribution-association-delegation"><span>TBD</span></a> (full definition of the expanded association can be found
+in <a class="section-ref" href="#term-Association"><span>TBD</span></a>). Agents may rely on <em>plans</em>, i.e. sets of actions or steps, to achieve their
goals in the context of an activity.
Hence, an expanded form of
association relation allows for a plan to be specified. Plan is defined by subtyping and
@@ -1615,11 +1618,11 @@
<div id="secondary-elements-relations-at-a-glance-div" style="text-align: center;">
<table class="thinborder" style="margin-left: auto; margin-right: auto;">
<caption id="secondary-elements-relations-at-a-glance">Secondary optional elements in PROV-DM Relations</caption> <!-- Table 4 -->
-<tr><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td><td colspan="6">Secondary Object</td></tr>
+<tr><td style="border-width: 0px; "></td><td style="border-width: 0px;§> "></td><td colspan="6">Secondary Object</td></tr>
<tr><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td><td>Entity</td><td>Activity</td><td >Agent</td></tr>
-<tr><td rowspan="3">Subject</td><td>Entity</td><td class="component5-color"><a>MentionOf</a> (bundle)</td><td class="component2-color"><a >WasDerivedFrom</a> (activity)<br><a>Revision (activity)</a><br><a>Quotation (activity)</a><br><a>PrimarySource (activity)</a></td><td colspan="2">—</td></tr>
-<tr><td>Activity</td><td class="component3-color"><a>WasAssociatedWith</a> (plan)</td><td class="component1-color"><a>WasStartedBy</a> (starter)<br><a>WasEndedBy</a> (ender)</td><td colspan="2">—</td></tr>
-<tr><td>Agent</td><td>—</td><td class="component3-color"><a>ActedOnBehalfOf</a> (activity)</td><td>—</td></tr>
+<tr><td rowspan="3">Subject</td><td>Entity</td><td class="component5-color"><a>MentionOf</a> (<a href="#mention.bundle">bundle</a>)</td><td class="component2-color"><a >WasDerivedFrom</a> (<a href="#derivation.activity">activity</a>)</td><td colspan="2">—</td></tr>
+<tr><td>Activity</td><td class="component3-color"><a>WasAssociatedWith</a> (<a href="#association.plan">plan</a>)</td><td class="component1-color"><a>WasStartedBy</a> (<a href="#start.starter">starter</a>)<br><a>WasEndedBy</a> (<a href="#end.ender">ender</a>)</td><td colspan="2">—</td></tr>
+<tr><td>Agent</td><td>—</td><td class="component3-color"><a>ActedOnBehalfOf</a> (<a href="#delegation.activity">activity</a>)</td><td>—</td></tr>
</table>
</div>
@@ -2171,7 +2174,7 @@
<p>According to <a href="#section-prov-overview">Section 2</a>, for an entity to be transformed from, created from, or resulting from an update to another, there must be some
-underpinning activities performing the necessary actions resulting in such a derivation.
+underpinning activity or activities performing the necessary action(s) resulting in such a derivation.
A derivation can be described at various levels of precision. In its simplest form, derivation relates two entities. Optionally, attributes can be added to represent further information about the derivation. If the derivation is the result of a single known activity, then this activity can also be optionally expressed. To provide a completely accurate description of the derivation, the generation and usage of the generated and used entities, respectively, can be provided, so as to make the derivation path, through usage, activity, and generation, explicit. Optional information such as activity, generation, and usage can be linked to derivations to aid analysis of provenance and to facilitate provenance-based reproducibility. </p>
@@ -2386,6 +2389,9 @@
<div class="glossary-ref" data-ref="glossary-agent"></div>
+<p>An agent may be a particular type of entity or activity. This means that the model can be
+ used to express provenance of the agents themselves. </p>
+
<p><div class="attributes" id="attributes-agent">An <dfn title="dfn-agent" id="dfn-agent">agent</dfn><span class="withPn">, written <span class="pnExpression" id="pn-agent">agent(id, [attr1=val1, ...])</span> in PROV-N,</span> has:
<ul>
@@ -2857,6 +2863,9 @@
</ul>
</div>
+<p>Specialization is not defined as Influence, and therefore does not have an id and attributes.</p>
+
+
<div class="anexample" id="anexample-specialization">
<p>
@@ -2885,7 +2894,6 @@
<span class="glossary-ref" data-ref="glossary-alternate"></span>
-
<p><div class="attributes" id="attributes-alternate">An <dfn title="alternateOf">alternate</dfn> relation<span class="withPn">, written <span class="pnExpression">alternateOf(e1, e2)</span> in PROV-N,</span> has:
<ul>
@@ -2894,6 +2902,19 @@
</ul>
</div>
+<p>Alternate is not defined as Influence, and therefore does not have an id and attributes.</p>
+
+<p>
+Note that <a title="alternateOf">alternateOf</a> is a necessarily very general
+relationship that, in reasoning, only states that the two
+alternate entities fix different aspects of some common thing
+(possibly evolving over time), and so there is some relevant
+connection between the provenance of the alternates. In a
+specific application context, <a title="alternateOf">alternateOf</a>, or a subtype of it,
+could allow more inferences.
+</p>
+
+
<div class="anexample" id="anexample-alternate">
<p>
A given news item on the BBC News site
@@ -2965,6 +2986,7 @@
+
<p><div class="attributes" id="attributes-mention">A <dfn title="mentionOf">mention</dfn> relation<span class="withPn">, written <span class="pnExpression">mentionOf(infra, supra, b)</span> in PROV-N,</span> has:
<ul>
<li><span class='attribute' id="mention.specificEntity">specificEntity</span>: an identifier (<span class="name">infra</span>)
@@ -2974,6 +2996,8 @@
</ul>
</div>
+<p>Mention is not defined as Influence, and therefore does not have an id and attributes.</p>
+
<div class="anexample" id="anexample-mention-rating">
<p>This example is concerned with a performance rating tool that reads and processes provenance to determine the performance of agents. To keep the example simple, an agent's performance is determined by the duration of the activities it is associated with. </p>
<p>As an illustration, we consider that two bundles <span class="name">ex:run1</span> and <span class="name">ex:run2</span> refer to an agent <span class="name">ex:Bob</span> that controlled two activities <span class="name">ex:a1</span> and <span class="name">ex:a2</span>. </p>
@@ -3114,6 +3138,8 @@
</div>
+<p>Membership is not defined as Influence, and therefore does not have an id and attributes.</p>
+
<div class="anexample" >
<p>In this example, <span class="name">c</span> is a collection known to have <span class="name">e0</span>, <span class="name">e1</span>, and <span class="name">e2</span> as members, and may have other members.</p>
@@ -3889,6 +3915,16 @@
<li> <a href="http://www.w3.org/2011/prov/track/issues/499">ISSUE-499</a>: Made explicit that generation/usage/invalidation/start/end are implicit.
<li> <a href="http://www.w3.org/2011/prov/track/issues/449">ISSUE-449</a>: Clarified definition of prov:value attribute and added an example.
<li> <a href="http://www.w3.org/2011/prov/track/issues/495">ISSUE-495</a>: added paragraph about 'relations opening up'. Clarified the role of '-' in example. Fixed dates in biblio. Fixed space issue in prov-n examples
+<li> <a href="http://www.w3.org/2011/prov/track/issues/516">ISSUE-516</a>: Stating that there moust be some underpinning activity or activities for a derivation, instead of just activities.
+<li> <a href="http://www.w3.org/2011/prov/track/issues/525">ISSUE-525</a>: Made it explicit that Membership, Alternate, Specialization are not Influence
+<li> Copied the sentence " An agent may be a particular type of entity or activity. This means that the model can be
+ used to express provenance of the agents themselves. " from the informative section into the normative section.
+<li> <a href="http://www.w3.org/2011/prov/track/issues/504">ISSUE-504</a>: Updated definition of collection.
+<li> <a href="http://www.w3.org/2011/prov/track/issues/503">ISSUE-503</a>: Rephrased the introduction of expanded association in section 2.2.1.2 Expanded Relations.
+<li> <a href="http://www.w3.org/2011/prov/track/issues/514">ISSUE-514</a>: added links to the attributes listed in the secondary element table. Also removed PrimarySource, Quotation, Revision.
+<li> <a href="http://www.w3.org/2011/prov/track/issues/502">ISSUE-502</a>: Added sentence in section 2.1.2 explaining that the focus
+ of derivation is on connecting a generated entity to a used entity.
+<li> <a href="http://www.w3.org/2011/prov/track/issues/526">ISSUE-526</a>: Added sentence clarifying sentence in section 5.5.2.
</ul>
</section>
--- a/xml/prov-xml.html Fri Oct 26 14:47:02 2012 -0400
+++ b/xml/prov-xml.html Fri Oct 26 14:47:29 2012 -0400
@@ -212,8 +212,8 @@
<script>
$(function() {
- $("div.schema-type").before("<p>Type definition in XML:</p>");
- $("div.schema-usage").before("<p>Usage in XML:</p>");
+ $("pre.schema-type").before("<p>Type definition in XML Schema:</p>");
+ $("pre.schema-usage").before("<p>Usage in XML:</p>");
});
</script>
@@ -705,65 +705,433 @@
<section id="term-Entity">
<h4>Entity</h4>
<div class="glossary-ref" data-ref="glossary-entity"></div>
-<div class="schema-type" data-name="prov:Entity" data-include="schema/prov.xsd" data-oninclude="insertSchema_Entity"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_entity"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Entity.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Entity">
+ <xs:sequence>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:location"/>
+ <xs:element ref="prov:value"/>
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="entity" type="prov:Entity"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on Example 16 from http://www.w3.org/TR/prov-dm/#anexample-entity -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#"
+ xmlns:tr="http://example.com/ns/tr#">
+
+ <prov:entity prov:id="tr:WD-prov-dm-20111215">
+ <prov:type>document</prov:type>
+ <ex:version>2</ex:version>
+ </prov:entity>
+
+</prov:document>
+</pre>
</section> <!-- end term-Entity -->
<section id="term-Activity">
<h3>Activity</h3>
<div class="glossary-ref" data-ref="glossary-activity"></div>
-<div class="schema-type" data-name="prov:Activity" data-include="schema/prov.xsd" data-oninclude="insertSchema_Activity"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_activity"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Activity.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Activity">
+ <xs:sequence>
+ <xs:element name="startTime" type="xs:dateTime" minOccurs="0"/>
+ <xs:element name="endTime" type="xs:dateTime" minOccurs="0"/>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:location"/>
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="activity" type="prov:Activity"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on PROV-DM's Example 17 from http://www.w3.org/TR/prov-dm/#anexample-activity
+ see also http://www.w3.org/TR/prov-dm/#type_Activity -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#">
+
+ <prov:activity prov:id="a1">
+ <prov:startTime>2011-11-16T16:05:00</prov:startTime>
+ <prov:endTime>2011-11-16T16:06:00</prov:endTime>
+ <prov:type>ex:edit</prov:type>
+ <ex:host>server.example.org</ex:host>
+ </prov:activity>
+
+</prov:document>
+</pre>
</section> <!-- end term-Activity -->
<section id="term-Generation">
<h4>Generation</h4>
<div class="glossary-ref" data-ref="glossary-generation"></div>
-<div class="schema-type" data-name="prov:Generation" data-include="schema/prov.xsd" data-oninclude="insertSchema_Generation"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasGeneratedBy"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Generation.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Generation">
+ <xs:sequence>
+ <xs:element name="entity" type="prov:EntityRef"/>
+ <xs:element name="activity" type="prov:ActivityRef" minOccurs="0"/>
+ <xs:element name="time" type="xs:dateTime" minOccurs="0"/>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:location"/>
+ <xs:element ref="prov:role"/>
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="wasGeneratedBy" type="prov:Generation"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- Example 18 from http://www.w3.org/TR/prov-dm/#anexample-generation1 -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#">
+
+ <prov:entity prov:id="e1"/>
+
+ <prov:activity prov:id="a1"/>
+
+ <prov:wasGeneratedBy>
+ <prov:entity prov:ref="e1"/>
+ <prov:activity prov:ref="a1"/>
+ <prov:time>2001-10-26T21:32:52</prov:time>
+ <ex:port>p1</ex:port>
+ </prov:wasGeneratedBy>
+
+ <prov:entity prov:id="e2"/>
+
+ <prov:wasGeneratedBy>
+ <prov:entity prov:ref="e2"/>
+ <prov:activity prov:ref="a1"/>
+ <prov:time>2001-10-26T10:00:00</prov:time>
+ <ex:port>p2</ex:port>
+ </prov:wasGeneratedBy>
+
+ <!-- Example 19, http://www.w3.org/TR/prov-dm/#anexample-generation2 -->
+
+ <prov:entity prov:id="e"/>
+
+ <prov:wasGeneratedBy>
+ <prov:entity prov:ref="e"/>
+ <prov:time>2001-10-26T21:32:52</prov:time>
+ </prov:wasGeneratedBy>
+
+</prov:document>
+</pre>
</section> <!-- end term-Generation -->
<section id="term-Usage">
<h3>Usage</h3>
<div class="glossary-ref" data-ref="glossary-usage"></div>
-<div class="schema-type" data-name="prov:Usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_Usage"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_used"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Usage.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Usage">
+ <xs:sequence>
+ <xs:element name="activity" type="prov:ActivityRef"/>
+ <xs:element name="entity" type="prov:EntityRef" minOccurs="0"/>
+ <xs:element name="time" type="xs:dateTime" minOccurs="0"/>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:location"/>
+ <xs:element ref="prov:role"/>
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="used" type="prov:Usage"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on Example 20 from http://www.w3.org/TR/prov-dm/#anexample-usage -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#">
+
+ <prov:activity prov:id="a1"/>
+
+ <prov:entity prov:id="e1"/>
+
+ <prov:entity prov:id="e2"/>
+
+ <prov:used>
+ <prov:activity prov:ref="a1"/>
+ <prov:entity prov:ref="e1"/>
+ <prov:time≶2011-11-16T16:00:00</prov:time>
+ <ex:parameter>p1</ex:parameter>
+ </prov:used>
+
+ <prov:used>
+ <prov:activity prov:ref="a1"/>
+ <prov:entity prov:ref="e2"/>
+ <prov:time>2011-11-16T16:00:01</prov:time>
+ <ex:parameter>p2</ex:parameter>
+ </prov:used>
+
+</prov:document>
+</pre>
</section> <!-- end term-Usage -->
<section id="term-Communication">
<h3>Communication</h3>
<div class="glossary-ref" data-ref="glossary-communication"></div>
-<div class="schema-type" data-name="prov:Communication" data-include="schema/prov.xsd" data-oninclude="insertSchema_Communication"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasInformedBy"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Communication.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Communication">
+ <xs:sequence>
+ <xs:element name="informed" type="prov:ActivityRef"/>
+ <xs:element name="informant" type="prov:ActivityRef"/>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="wasInformedBy" type="prov:Communication"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on Example 21 from http://www.w3.org/TR/prov-dm/#anexample-communication -->
+
+<prov:document xmlns:prov="http://www.w3.org/ns/prov#">
+
+ <prov:activity prov:id="a1">
+ <prov:type>traffic regulations enforcing<prov:type>
+ </prov:activity>
+
+ <prov:activity prov:id="a2">
+ <prov:type>fine paying, check writing, and mailing</prov:type>
+ </prov:activity>
+
+ <prov:wasInformedBy>
+ <prov:informed prov:ref="a2"/>
+ <prov:informant prov:ref="a1"/>
+ </prov:wasInformedBy>
+
+</prov:document>
+</pre>
</section> <!-- end term-Communication -->
<section id="term-Start">
<h4>Start</h4>
<div class="glossary-ref" data-ref="glossary-start"></div>
-<div class="schema-type" data-name="prov:Start" data-include="schema/prov.xsd" data-oninclude="insertSchema_Start"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasStartedBy"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Start.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Start">
+ <xs:sequence>
+ <xs:element name="activity" type="prov:ActivityRef"/>
+ <xs:element name="trigger" type="prov:EntityRef" minOccurs="0"/>
+ <xs:element name="starter" type="prov:ActivityRef" minOccurs="0"/>
+ <xs:element name="time" type="xs:dateTime" minOccurs="0"/>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:location"/>
+ <xs:element ref="prov:role"/>
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="wasStartedBy" type="prov:Start"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on PROV-DM's Example 22 from http://www.w3.org/TR/prov-dm/#anexample-start1
+ see also http://www.w3.org/TR/prov-dm/#type_WasStartedBy -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#">
+
+ <prov:entity prov:id="e1">
+ <prov:type>email message</prov:type>
+ </prov:entity>
+
+ <prov:activity prov:id="a1">
+ <prov:type>Discuss</prov:type>
+ </prov:activity>
+
+ <prov:wasStartedBy>
+ <prov:activity prov:ref="a1"/>
+ <prov:trigger prov:ref="e1"/>
+ <prov:time>2011-11-16T16:05:00</prov:time>
+ </prov:wasStartedBy>
+
+ <prov:used>
+ <prov:activity prov:ref="a1"/>
+ <prov:entity prov:ref="e1"/>
+ </prov:used>
+
+ <prov:activity prov:id="a0">
+ <prov:type>Write</prov:type>
+ </prov:activity>
+
+ <prov:wasGeneratedBy>
+ <prov:entity prov:ref="e1"/>
+ <prov:activity prov:ref="a0"/>
+ </prov:wasGeneratedBy>
+
+ <prov:wasStartedBy>
+ <prov:activity prov:ref="a1"/>
+ <prov:trigger prov:ref="e1"/>
+ <prov:starter prov:ref="a0"/>
+ <prov:time>2011-11-16T16:05:00</prov:time>
+ </prov:wasStartedBy>
+
+ <prov:wasStartedBy>
+ <prov:activity prov:ref="a1"/>
+ <prov:starter prov:ref="a0"/>
+ <prov:time>2011-11-16T16:05:00</prov:time>
+ </prov:wasStartedBy>
+
+</prov:document>
+</pre>
</section> <!-- end term-Start -->
<section id="term-End">
<h4>End</h4>
<div class="glossary-ref" data-ref="glossary-end"></div>
-<div class="schema-type" data-name="prov:End" data-include="schema/prov.xsd" data-oninclude="insertSchema_End"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasEndedBy"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Entity.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="End">
+ <xs:sequence>
+ <xs:element name="activity" type="prov:ActivityRef"/>
+ <xs:element name="trigger" type="prov:EntityRef" minOccurs="0"/>
+ <xs:element name="ender" type="prov:ActivityRef" minOccurs="0"/>
+ <xs:element name="time" type="xs:dateTime" minOccurs="0"/>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:location"/>
+ <xs:element ref="prov:role"/>
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="wasEndedBy" ype="prov:End"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on PROV-DM's Example 25 from http://www.w3.org/TR/prov-dm/#term-End
+ see also http://www.w3.org/TR/prov-dm/#type_WasEndedBy -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#">
+
+ <prov:entity prov:id="e1">
+ <prov:type>approval document</prov:type>
+ </prov:entity>
+
+ <prov:activity prov:id="a1">
+ <prov:type>Editing</prov:type>
+ </prov:activity>
+
+ <prov:wasEndedBy>
+ <prov:activity prov:ref="a1"/>
+ <prov:trigger prov:ref="e1"/>
+ </prov:wasEndedBy>
+
+</prov:document>
+</pre>
</section> <!-- end term-End -->
<section id="term-Invalidation">
<h3>Invalidation</h3>
<div class="glossary-ref" data-ref="glossary-invalidation"></div>
-<div class="schema-type" data-name="prov:Invalidation" data-include="schema/prov.xsd" data-oninclude="insertSchema_Invalidation"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasInvalidatedBy"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Invalidation.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Invalidation">
+ <xs:sequence>
+ <xs:element name="entity" type="prov:EntityRef"/>
+ <xs:element name="activity" type="prov:ActivityRef" minOccurs="0"/>
+ <xs:element name="time" type="xs:dateTime" minOccurs="0"/>
+ <xs:choice minOccurs="0" maxOccurs="unbounded">
+ <xs:element ref="prov:location"/>
+ <xs:element ref="prov:role"/>
+ <xs:element ref="prov:label"/>
+ <xs:element ref="prov:type"/>
+ <xs:any namespace="##other"/>
+ </xs:choice>
+ </xs:sequence>
+ <xs:attribute ref="prov:id"/>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element mlns:xs="http://www.w3.org/2001/XMLSchema" name="wasInvalidatedBy" type="prov:Invalidation"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on PROV-DM's Example 26 from http://www.w3.org/TR/prov-dm/#anexample-invalidation1
+ see also http://www.w3.org/TR/prov-dm/#type_WasInvalidatedBy -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#"
+ xmlns:bbc="http://www.bbc.co.uk/news/">
+
+ <prov:entity prov:id="ex:The-Painter"/>
+
+ <prov:agent prov:id="ex:Picasso"/>
+
+ <prov:wasAttributedTo>
+ <prov:entity prov:ref="ex:The-Painter" />
+ <prov:agent prov:ref="ex:Picasso" />
+ </prov:wasAttributedTo>
+
+ <prov:activity prov:id="ex:crash"/>
+
+ <prov:wasInvalidatedBy>
+ <prov:entity prov:ref="ex:The-Painter"/>
+ <prov:activity prov:ref="ex:crash"/>
+ <prov:time>1998-09-03T01:31:00</prov:time>
+ <ex:circumstances>plane accident</ex:circumstances>
+ </prov:wasInvalidatedBy>
+
+</prov:document>
+</pre>
</section> <!-- end term-Invalidation -->
</section> <!-- end component1 -->
@@ -778,25 +1146,25 @@
<div class="glossary-ref" data-ref="glossary-derivation"></div>
<div class="schema-type" data-name="prov:Derivation" data-include="schema/prov.xsd" data-oninclude="insertSchema_Derivation"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasDerivedFrom"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Derivation1.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Derivation1.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Derivation -->
<section id="term-Revision">
<h3>Revision</h3>
<div class="glossary-ref" data-ref="glossary-revision"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Revision.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Revision.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Revision -->
<section id="term-Quotation">
<h3>Quotation</h3>
<div class="glossary-ref" data-ref="glossary-quotation"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Quotation.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Quotation.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Quotation -->
<section id="term-Primary-Source">
<h3>Primary Source</h3>
<div class="glossary-ref" data-ref="glossary-primary-source"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/PrimarySource.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/PrimarySource.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Primary-Source -->
</section> <!-- end component2 -->
@@ -812,7 +1180,7 @@
<div class="glossary-ref" data-ref="glossary-agent"></div>
<div class="schema-type" data-name="prov:Agent" data-include="schema/prov.xsd" data-oninclude="insertSchema_Agent"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_agent"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Agent.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Agent.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Agent -->
<section id="term-Attribution">
@@ -820,7 +1188,7 @@
<div class="glossary-ref" data-ref="glossary-attribution"></div>
<div class="schema-type" data-name="prov:Attribution" data-include="schema/prov.xsd" data-oninclude="insertSchema_Attribution"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasAttributedTo"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Attribution.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Attribution.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Attribution -->
<section id="term-Association">
@@ -828,7 +1196,7 @@
<div class="glossary-ref" data-ref="glossary-activityAssociation"></div>
<div class="schema-type" data-name="prov:Association" data-include="schema/prov.xsd" data-oninclude="insertSchema_Association"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasAssociatedWith"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Association.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Association.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Association -->
<section id="term-Delegation">
@@ -836,7 +1204,7 @@
<div class="glossary-ref" data-ref="glossary-delegation"></div>
<div class="schema-type" data-name="prov:Delegation" data-include="schema/prov.xsd" data-oninclude="insertSchema_Delegation"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_actedOnBehalfOf"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Delegation.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Delegation.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Delegation -->
<section id="term-Influence">
@@ -844,7 +1212,7 @@
<div class="glossary-ref" data-ref="glossary-influence"></div>
<div class="schema-type" data-name="prov:Influence" data-include="schema/prov.xsd" data-oninclude="insertSchema_Influence"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_wasInfluencedBy"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Influence.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Influence.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-influence -->
</section> <!-- end component3 -->
@@ -862,7 +1230,7 @@
<div class="glossary-ref" data-ref="glossary-specialization"></div>
<div class="schema-type" data-name="prov:Specialization" data-include="schema/prov.xsd" data-oninclude="insertSchema_Specialization"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_specializationOf"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Specialization.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Specialization.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Specialization -->
<section id="term-Alternate">
@@ -870,7 +1238,7 @@
<div class="glossary-ref" data-ref="glossary-alternate"></div>
<div class="schema-type" data-name="prov:Alternate" data-include="schema/prov.xsd" data-oninclude="insertSchema_Alternate"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_alternateOf"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Alternate_43.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Alternate_43.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Alternate -->
<section id="term-Mention">
@@ -878,7 +1246,7 @@
<div class="glossary-ref" data-ref="glossary-mention"></div>
<div class="schema-type" data-name="prov:Mention" data-include="schema/prov.xsd" data-oninclude="insertSchema_Mention"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_mentionOf"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Mention_45.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Mention_45.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end term-Mention -->
</section> <!-- end component5 -->
@@ -892,15 +1260,70 @@
<section id="term-Collection">
<h3>Collection</h3>
<div class="glossary-ref" data-ref="glossary-collection"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Collection.xml" data-oninclude="formatExample"></pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on PROV-DM's Example 47 from http://www.w3.org/TR/prov-dm/#example_47 -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#"
+ xmlns:ex="http://example.com/ns/ex#">
+
+ <!-- c0 is an empty collection -->
+ <prov:entity prov:id="c0">
+ <!-- prov:EmptyCollection denotes an empty collection. -->
+ <prov:type>prov:EmptyCollection</prov:type>
+ </prov:entity>
+
+ <!-- c1 is a collection, with unknown content -->
+ <prov:entity prov:id="c1">
+ <!-- prov:Collection denotes an entity of type Collection, i.e. an entity that can participate in relations amongst collections -->
+ <prov:type>prov:Collection</prov:type>
+ </prov:entity>
+
+</prov:document>
+</pre>
</section> <!-- end term-Collection -->
<section id="term-Membership">
<h3>Membership</h3>
<div class="glossary-ref" data-ref="glossary-membership"></div>
-<div class="schema-type" data-name="prov:Membership" data-include="schema/prov.xsd" data-oninclude="insertSchema_Membership"></div>
-<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_hadMember"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Membership.xml" data-oninclude="formatExample"></pre>
+<pre class="schema-type">
+<xs:complexType name="Membership">
+ <xs:sequence>
+ <xs:element name="collection" type="prov:EntityRef"/>
+ <xs:element name="entity" type="prov:EntityRef" maxOccurs="unbounded"/>
+ </xs:sequence>
+</xs:complexType>
+</pre>
+<pre class="schema-usage">
+<xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="hadMember" type="prov:Membership"/>
+</pre>
+<pre class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!-- based on Example 48 from http://www.w3.org/TR/prov-dm/#example_48 -->
+
+<prov:document
+ xmlns:prov="http://www.w3.org/ns/prov#">
+
+ <prov:entity prov:id="e0"/>
+ <prov:entity prov:id="e1"/>
+ <prov:entity prov:id="e2"/>
+
+ <prov:entity prov:id="c">
+ <prov:type>prov:Collection</prov:type>
+ </prov:entity>
+
+ <prov:hadMember>
+ <prov:collection prov:ref="c"/>
+ <prov:entity prov:ref="e0"/>
+ <prov:entity prov:ref="e1"/>
+ <prov:entity prov:ref="e2"/>
+ </prov:hadMember>
+
+</prov:document>
+</pre>
</section> <!-- end term-Membership -->
</section> <!-- end component6 -->
@@ -918,21 +1341,21 @@
<h4>Label</h4>
<div class="glossary-ref" data-ref="glossary-label"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_label"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Label.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Label.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end element-Label -->
<section id="element-Location">
<h4>Location</h4>
<div class="glossary-ref" data-ref="glossary-location"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_location"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Location.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Location.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end element-Location -->
<section id="element-Role">
<h4>Role</h4>
<div class="glossary-ref" data-ref="glossary-role"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_role"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Role.xml" data-oninclude="formatExample"></pre>
+<!-- <pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Role.xml" data-oninclude="formatExample"></pre> -->
</section> <!-- end element-Role -->
<section id="element-Type">
@@ -946,7 +1369,7 @@
<h4>Value</h4>
<div class="glossary-ref" data-ref="glossary-value-attribute"></div>
<div class="schema-usage" data-include="schema/prov.xsd" data-oninclude="insertSchema_value"></div>
-<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Value.xml" data-oninclude="formatExample"></pre>
+<!--<pre class="example" data-include="../examples/eg-40-xml-examples-by-term/xml/Value.xml" data-oninclude="formatExample"></pre>-->
</section> <!-- end element-Value -->
</section> <!-- end further-elements -->