Binary file .DS_Store has changed
--- a/model/#authors.txt# Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,16 +0,0 @@
-Khalid
-Paul Groth
-Simon Miles
-Graham Klyne
-James Myers
-Satya Sahoo
-
-
-
-Borderline
-Stian Soiland-Reyes
-Tim Lebo
-Jim Mccusker
-Stephen Cresswell
-James Cheney
-Ryan Golden
\ No newline at end of file
--- a/model/#derivation.html# Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,276 +0,0 @@
-<!DOCTYPE html>
-<html><head>
- <title>Provenance Model</title>
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
- <!--
- === NOTA BENE ===
- For the three scripts below, if your spec resides on dev.w3 you can check them
- out in the same tree and use relative links so that they'll work offline,
- -->
-<!-- PM -->
- <style type="text/css">
- .note { font-size:small; margin-left:50px }
- </style>
-
- <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
-
- <script class="remove">
- var respecConfig = {
- // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
- specStatus: "ED",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "PIL-Model",
-
- // if your specification has a subtitle that goes below the main
- // formal title, define it here
- subtitle : "Initial draft for internal discussion",
-
- // if you wish the publication date to be other than today, set this
- // publishDate: "2009-08-06",
-
- // if the specification's copyright date is a range of years, specify
- // the start date here:
- // copyrightStart: "2005"
-
- // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
- // and its maturity status
- // previousPublishDate: "1977-03-15",
- // previousMaturity: "WD",
-
- // if there a publicly available Editor's Draft, this is the link
- edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html",
-
- // if this is a LCWD, uncomment and set the end of its review period
- // lcEnd: "2009-08-05",
-
- // if you want to have extra CSS, append them to this list
- // it is recommended that the respec.css stylesheet be kept
- extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css", "./extra.css"],
-
- // editors, add as many as you like
- // only "name" is required
- editors: [
- { name: "Luc Moreau", url: "http://www.ecs.soton.ac.uk/~lavm",
- company: "University of Southampton, UK" },
- { name: "Paolo Missier", url: "http://www.cs.ncl.ac.uk/people/Paolo.Missier",
- company: "Newcastle University, UK" },
- ],
-
- // authors, add as many as you like.
- // This is optional, uncomment if you have authors as well as editors.
- // only "name" is required. Same format as editors.
-
- authors: [
- { name: "TBD"},
- ],
-
- // name of the WG
- wg: "Provenance Working Group",
-
- // URI of the public WG page
- wgURI: "http://www.w3.org/2011/prov/wiki/Main_Page",
-
- // name (with the @w3c.org) of the public mailing to which comments are due
- wgPublicList: "public-prov-wg",
-
- // URI of the patent status for this WG, for Rec-track documents
- // !!!! IMPORTANT !!!!
- // This is important for Rec-track documents, do not copy a patent URI from a random
- // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
- // Team Contact.
- wgPatentURI: "",
- };
- </script>
- </head>
- <body>
-
-<section id="abstract">
-<p>This document defines a data model for Provenance.</p>
-</section>
-
-<section id="concept-Derivation">
-<h3>Derivation</h3>
-
-
-<div class='note'>This section remains very much work in progress. Many issues have been raised and discussed, and for several of them, consensus still remains difficult to reach. The presentation of derivation has been altered, and new names adopted, in the hope of clarifying this notion. Key outstanding issues include:
-<ul>
-<li> what is the exact relationship between entities attributes and derivation;
-<li> transitive nature of derivation.
-</ul></div>
-
-<p><dfn id="dfn-Derivation">Derivation</dfn> expresses that some characterized thing is transformed from, created from, or affected by another characterized thing. </p>
-
-<p>PIL offers two different kinds of assertions by which asserters can formulate derivations. The first one is tightly connected to the notion of process execution, whereas the second one is not. The first kind of assertion is particularly suitable for asserters who have an intimate knowledge of process executions, and offers a more precise description of derivation, whereas the second does not put such a requirement on the asserter, and allows a less precise description of derivation to be asserted. From these assertions, further derivations can be inferred by transitive closure. </p>
-
-<section>
-<h4>Process Execution Linked Derivation</h4>
-
-<p>A process execution linked derivation, which, by definition of derivation, expresses that some characterized thing is transformed from, created from, or affected by another characterized thing, entails a process execution that transforms, creates or affects this characterized thing.</pe>
-
-<p>In its full form, a process-execution linked derivation assertion, noted <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>:
-<ul>
-<li> refers to an entity <b>e2</b>, denoting the used characterized thing;
-<li> refers to an entity <b>e1</b>, denoting the generated characterized thing;
-<li> refers to process execution <b>pe</b>;
-<li> contains a role <b>r2</b>.
-<li> contains a role <b>r1</b>.
-</ul>
-This assertion expresses that the process execution <b>pe</b>, by
-using the thing denoted by <b>e1</b> with role <b>r1</b> derived the
-thing denoted by entity <b>e2</b> and generated it with
-role <b>r2</b>.
-</p>
-
-<p>
-The following inference rule allows generation and use assertions to be inferred.
-</p>
-
-<div class="inference">
-If <b>isDerivedFrom(e2,e1,pe,r2,r1)</b> holds, then <b>isGeneratedBy(e2,pe,r2)</b> and <b>uses(pe,e1,r1)</b> also hold.
-</div>
-
-
-<p>For convenience, PIL allows for a compact, process-execution linked derivation assertion, written <b>isDerivedFrom(e2,e1)</b>, which:
-<ul>
-<li> refers to an entity <b>e2</b>, denoting the generated characterized thing;
-<li> refers to an entity <b>e1</b>, denoting the used characterized thing.
-</ul>
-</p>
-
-
-<p>The compact version has the same meaning as the fully formed process-execution linked derivation, except that a process execution is known to exist, though it does not need to be asserted.
-This is formalized by the following inference rule, referred to as <em>process execution introduction</em>:<br/>
-<div class='inference'>
-If <b>isDerivedFrom(e2,e1)</b> holds, then there exists a process execution <b>pe</b>, and roles <b>r1</b>,<b>r2</b>,
-such that:
- <b>isGeneratedBy(e2,pe,r2)</b> and <b>uses(pe,e1,r1)</b>.
-</div></p>
-
-
-
-
-<p>If <b>e2</b> is derived from <b>e1</b>, then
-this means that the thing represented by <b>e1</b> has an influence on the thing represented by <b>e2</b>, which is captured by a dependency between their attribute values; it also implies temporal ordering. These are specified as follows:</p>
-
-<p>Given a process execution <b>pe</b>, entities <b>e1</b> and <b>e2</b>, roles <b>r1</b> and <b>r2</b>, if the assertion <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
-or <b>isDerivedFrom(e2,e1)</b> holds, if and only if:
- the values of some attributes
-of <b>e2</b> are partly or fully determined by the values of some
-attributes of <b>e1</b>.</li>
-
-<div class='note'>Should this dependency of attributes be made explicit as argument of the derivation? By making it explicit, we would allow someone to verify the validity of the derivation.</div>
-</p>
-
-
-<p>Given a process execution <b>pe</b>, entities <b>e1</b> and <b>e2</b>, roles <b>r1</b> and <b>r2</b>, if the assertion <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
-or <b>isDerivedFrom(e2,e1)</b> holds, then
-the use
-of characterized thing denoted by <b>e1</b> precedes the generation of
-the characterized thing denoted by <b>e2</b>.
-</p>
-
-
-
-<p>
-Note that inferring derivation from use and generation does not hold
-in general. Indeed, when a generation <b>isGeneratedBy(e2,pe,r2)</b>
-precedes <b>uses(pe,e1,r1)</b>, for
-some <b>e1</b>, <b>e2</b>, <b>r1</b>, <b>r2</b>, and <b>pe</b>, one
-cannot infer derivation <b>isDerivedFrom(e2,e1,pe,r2,r1)</b>
-or <b>isDerivedFrom(e2,e1)</b> since the values of attributes
-of <b>e2</b> cannot possibly be determined by the values of attributes
-of <b>e1</b>, given the creation of <b>e2</b> precedes the use
-of <b>e1</b>.
-</p>
-
-<p>
-<pre class="example">
-isDerivedFrom(e5,e3)
-</pre>
-</p>
-
-<p>A further inference is permitted from the compact version of derivation:
-<div class='inference'>
-Given a process execution <b>pe</b>, entities <b>e1</b> and <b>e2</b>, and role <b>r2</b>,
-if <b>isDerivedFrom(e2,e1)</b> and <b>isGeneratedBy(e2,pe,r2)</b> hold, then there exists a role <b>r1</b>,
-such that <b>uses(pe,e1,r1)</b> also holds.
-</div>
-This inference is justified by the fact that <b>e2</b> is generated by at most one process execution. Hence, this process execution is also the one that uses <b>e1</b>.
-</p>
-
-<div class='note'>There is a suggestion by Simon that this notion of derivation is only meaningful in the context of an account. <a href="http://lists.w3.org/Archives/Public/public-prov-wg/2011Aug/0101.html">See email</a>. It is not clear it is the case anymore. However, the inference above is only meaning full if unicity of generation hold.</div>
-
-
-<p>We note that the "symmetric" inference, does not hold.
-From <b>isDerivedFrom(e2,e1)</b> and <b>uses(pe,e1)</b>, one cannot
-derive <b>isGeneratedBy(e2,pe,r2)</b> because <b>e1</b> may be used by
-many process execution, not all of them generating <b>e2</b>.</p>
-
-
-
-</section>
-
-<section>
-<h4>Process Execution Independent Derivation</h4>
-
-
-
-
-<p>A process execution independent derivation states the existence of a derivation, by any means whether direct or not, and regardless of any process executions. </p>
-
-<p>A process execution independent derivation, written <b>isEventuallyDerivedFrom (e2, e1)</b>,
-<ul>
-<li> refers to an entity <b>e2</b>, denoting the used characterized thing;
-<li> refers to an entity <b>e1</b>, denoting the generated characterized thing;
-</ul>
-
-
-<p>If <b>e2</b> is derived (isEventuallyDerivedFrom) from <b>e1</b>, then
-this means that the thing represented by <b>e1</b> has an influence on the thing represented by <b>e2</b>,
- which at the minimum implies temporal ordering, specified as follows:</p>
-
-<p>Given two entities <b>e1</b> and <b>e2</b>, if the assertion <b>isEventuallyDerivedFrom(e2,e1)</b>
- holds, then:
-generation of the characterized thing denoted by <b>e1</b> precedes the generation of
-the characterized thing denoted by <b>e2</b>.
-</p>
-
-<p>Note that temporal ordering is between generations of <b>e1</b>
-and <b>e2</b>, as opposed to process execution linked derivation,
-which implied temporal ordering between the use of <b>e1</b> and
-generation of <b>e2</b>. Indeed, in the case of
-isEventuallyDerivedFrom, nothing is known about the use of <b>e1</b>,
-since there is no associated process execution.</p>
-
-<div class='note'>Should we link isEventuallyDerivedFrom to attributes as we did for isDerivedFrom? If so, this type of inference should be presented upfront, for both.</div>
-
-
-
-
-
-</section>
-
-<section>
-<h4>Transitivity</h4>
-
-
-<p>
-If <b>isDerivedFrom(e2,e1)</b> holds because attribute <b>a2.1</b> of <b>e2</b> is determined by attribute <b>a1.1</b> of <b>e1</b>,
-and if <b>isDerivedFrom(e3,e2)</b> holds because attribute <b>a3.1</b>of <b>e3</b> is determined by attribute <b>a2.2</b> of <b>e1</b>, it is not necessary the case that an attribute of <b>e3</b> is determined by an attribute of <b>e1</b>, so, an asserter may not be able to assert <b>isDerivedFrom(e3,e1)</b>. Hence, constraints on attributes invalidate transitivit in the general case.
-</p>
-
-<p>However, there is sense that <b>e3</b> still depends on <b>e1</b>, since <b>e3</b> could not be generated without <b>e1</b> existing. Hence, we introduce a weaker notion of derivation, which is transitive.</p>
-
-<p>The relationship <dfn id="dfn-dependsOn">dependsOn</dfn> is defined as follows:
-<ul>
-<li>If <b>isDerivedFrom(e2,e1)</b> or <b>isDerivedFrom(e2,e1,pe,r2,r1)</b> holds, then <b>dependsOn(e2,e1)</b>.</li>
-<li>If <b>isEventuallyDerivedFrom(e2,e1)</b> holds, then <b>dependsOn(e2,e1)</b>.</li>
-<li>If <b>dependsOn(e3,e2)</b> and <b>dependsOn(e2,e1)</b> hold, then <b>dependsOn(e3,e1)</b>.</li>
-</ul>
-</section>
-</section>
-
-
-
- </body></html>
Binary file model/.DS_Store has changed
--- a/model/comments-from-graham.txt~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,220 +0,0 @@
-With reference to:
-http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html
-Retrieved at about 17:30 on 28-Jul-2011
-
-As promised, I've taken a tilt at reviewing the model draft. I must
-say, I've found it to be really hard going - many of the notions
-described are not making sense to me, and the language used sometimes
-seems to be unnecessarily obscure.
-
-After a mammoth session going though this, I really don't have the
-time or energy to split my comments out into separate issues. I think
-many of them are purely editorial in nature, and as such could be
-cleaned up relatively easily. There are some substantive comments that
-I may separate out as formal issues later, but I'm rather hoping that
-won't be needed.
-
-My comments follow:
-
-
-3.1 Notation used is obscure. What does [...[ mean? Should be explained.
-
-For a general audience, examples based on Unix command shell commands are probably not very helpful.
-
-What is "characterized entity represented by the file". As this is an example, just say "crime statistics" - would that be a correct interpretation?
-
-
-3.2 where did 'e0' come from? - it's not mentioned in 3.1. What is it intended to denote?
-
-The "agent" statements are completely impenetrable to me.
-
-How is the notation to be interpreted. It looks a b it like some kind of deviant Prolog, but either I've forgotten some of the basic constructs, or it's not entirely clear how the deviant bits are meant to be interpreted.
-
-
-3.3 graphical representation: could be very useful, and would be much easier to follow if the illustration included a key
-
-What does it mean for an agent to be linked to a BOB as opposed to a process execution (cf. Alice and e0).
-
-
-4. About the Provenance Language
-
-Introduction of "characterized entities" - if this is something that really needs to be said, I think it needs to be clarified. I spent some time thinking about these two sentences, trying to work out if they could ever be completely correct, or just not understanding what they are intended to convey:
-[[
-Furthermore, this specification is concerned with characterized entities, that is, entities and their situation in the world, as perceived by their asserters.
-
-In the rest of the document, we are concerned with the representation of such entities; their situation in the world will be represented using sets of attributes.
-]]
-
-Why "characterized entities" as opposed to perceived entities"? What's the important distinction here?
-
-The only interpretation I've found that makes sense to me is that the document is concerning itself with entities that are characterized by the values of some bounded set of attributes. But that interpretation, if correct, is not obvious to me from the wording here.
-
-
-"PIL is a language by which representations of the world can be expressed using terms that are drawn from a controlled vocabulary. "
-I'm not sure how to interpret this. Does this "controlled vocabulary include, for example, numbers? Is this controlled vocabulary expected to be the complete set of terms used in PIL expressions?
-
-
-"These representations are relative to an asserter, and in that sense constitute assertions about the world."
-What is this trying to say? I think you might mean something like:
-"These representations are relative to the context of an asserter, and in that sense constitute perceptions about the world."
-which ties back to the earlier statement about "as perceived by their asserters".
-
-"All assertions in PIL SHOULD be interpreted as a record of what has happened, as opposed to what may or will happen."
-I feel we should find a way to strengthen this SHOULD to a MUST, but comments from earlier discussions make this tricky to get right. Maybe:
-"All assertions in PIL MUST be interpreted as a record of what has happened or been observed in some context, as opposed to what might happen or potential observations." In this, I am using the reference to a context to provide just enough wiggle-room for description in future or imagined contexts.
-
-"This specification does not prescribe the means by which assertions are made, for example on the basis of observations, inferences, or any other means."
-The phrasing "... assertions are made" here is jarring, if not confusing - I would think that assertions are made in PIL for the purposes of this spec. Suggest "... how assertions are arrived at, ..."
-
-"The language introduces a notion of "provenance container", which provides a default scope for assertions."
-The term "container" here is suggested of a physical or logical encapsulation, which I don't think is meant. How about "provenance context"?
-
-[[
-... The model may define additional scoping rules for assertions. Identifiers can safely be used within that scope. Optionally, identifiers can be exported so that they can be used outside their default scope. The language does not prescribe the mechanisms by which identifiers are generated.
-]]
-This spec is describing a data model, *not* a language. It says so at the top. As such I think it's entirely inappropriate to start defining linguistic constructs such as identifiers and scoping. Assuming the actual language used will be RDF, I'm not seeing how what you describe will be possible.
-
-"In this specification, when an assertion is defined to refer to another assertion about something, it does so by means of that thing's identifier."
-I don't understand what this is trying to say.
-
-
-5.1 BOB
-
-"A BOB represents an identifiable characterized entity."
-
-What does it mean to be "characterized" here? What does this tell us? What does it mean to not be "characterized"? If this refers to the attribute-based assertions mentioned earlier, does this mean that if there are no such assertions, an entity cannot be a "BOB"?
-
-[[
-A BOB assertion is about a characterized entity, whose situation in the world is variant. A BOB assertion is made at a particular point and is invariant, in the sense that all the attributes are assigned a value as part of that assertion.
-]]
-
-This section is, according to its heading, about "BOB". But this is defining a different concept, so shouldn't this be in a separate section?
-
-It seems to me that what we're talking about here is a "provenance assertion". I think it would be clearer to just describe that, e.g.
-[[
-A provenance assertion is about an entity, whose situation in the world is generally assumed to be variable.
-]]
-
-I either don't understand or don't agree with the second part of that description. The notion of assigning values as party of an assertion seems wrong to me (I think the notion of constraining attributes is the job of the IVP-of relation). I would expect something like:
-[[
-A provenance assertion is made at a particular point and is invariant, in the sense that the attributes it mentions do not change for the entity concerned.
-]]
-
-[[
-A BOB assertion must describe a characterized entity over a continuous time interval in the world (which may collapse into a single instant). Characterizing an entity over multiple time intervals requires multiple BOB assertions, each with its own identifier. Some attributes may retain their values across multiple assertions.
-]]
-This constraint seems rather unnecessary, and maybe counter-productive.
-
-Suppose we want to describe the collective observations of a particular telescope when pointed at a particular region of the sky. This might actually consist of a (possibly unknown) number of disjoint time-segments caused by the rotation of the earth and other factors. I can't see any clear benefit in being forced to treat these observation-sets as distinct entities.
-
-[[
-There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.
-]]
-I don't see this adding any useful information here. Remove?
-
-
-5.2 Process Execution
-
-Thinking about today's teleconference (28 July) and reading this, I'm seeing the key distinction between Entity and Process execution being like the philosophical distinction between continuants (endurant) and occurrents (perdurant) (http://en.wikipedia.org/wiki/Formal_ontology#Common_terms_in_formal_ontologies)
-
-
-5.3 Generation
-
-"characterized entitity" is clumsy - suggest just "entity" (or whatever term is selected for "BOB").
-
-If I had not previously read about OPM, I'd be completely confused by the introduction of "role" here. Following the hyperlink here does not help at all.
-
-[[
-Given an assertion isGeneratedBy(x,pe,r) or isGeneratedBy(x,pe,r,t), the activity denoted by pe and the entities used by pe dermine values of some of x's attributes.
-]]
-I've no idea what this is trying to say.
-
-
-5.4 Use
-
-Same problem with 'role' as above.
-
-[[
-A reference to a given BOB may appear in multiple use assertions that refer to a given process execution, but each of those use assertions must have a distinct role.
-]]
-In light of the above, this seems nonsensical to me.
-
-[[
-Given an assertion uses(pe,x,r) or uses(pe,x,r,t), at least one value of x's attributes is a pre-condition for the activity denoted by pe to terminate.
-]]
-As written this doesn't make sense - a value of an attribute being a precondition seems like a type error to me. I think you mean something like availability of an attribute value. But even that is hard to follow. Suggest simplifying this to just:
-[[
-Given an assertion uses(pe,x,r) or uses(pe,x,r,t), existence of x is a pre-condition for the activity denoted by pe to terminate.
-]]
-
-
-5.5 Derivation
-
-[[
-Given an assertion isDerivedFrom(B,A), one can infer that the use of characterized entity denoted by A precedes the generation of the characterized entity denoted by B.
-]]
-Where does this notion of "use" come from in the absence of some referenced activity?
-
-Concerning transitivity of derivation:
-
-Suppose:
-A has attributes a0, a1
-B having attributes b0, b1 is derived from A, with b0 being dependent on a0
-C having attributes c0, c1, is derived from B with c1 being dependent on b1
-
-So none of the attributes of C can be said to be directly or indirectly dependent on attributes of A, which by the given definition is a requirement for derivation of C from A. Thus, as defined, derivation cannot be transitive.
-
-I don't really know if derivation should or should not be transitive, but the above seems to me like a problem of spurious over-specification. My suggestion for now would be to focus on what really matters and see what logical properties fall out later.
-
-
-5.8 IVP of
-
-The revised (w.r.t. http://www.w3.org/2011/prov/wiki/F2F1ConceptDefinitions#IVP_of) treatment of IVP-of, and relabeling as "complement-of" completely overturns my understanding of what this was intended to capture. I understood the whole point of A IVP-of B was intended to capture the notion that A denotes a contextually constrained form of the entity denoted by B. I don't see what useful purpose this relation serves.
-
-From a practical perspective, given the asymmetric nature of IVP-of (as was) it is easy to express the effect of complement-of in RDF by introducing a new entity node. But I see no way of constructing the strict constraining role of IVP using complement-of.
-
-
-5.9 Time
-
-[[
-Time is defined according to [ISO8601].
-]]
-
-I don't think it is appropriate of an open standard to be normatively dependent on a standard that is available only on payment of a charge for access. In this case, we could make reference to the XML scheme datatypes, which would also require us to think about my next point...
-
-As far as I'm aware, ISO 8601 covers both points in time and time intervals. As such a bare reference to ISO 86012 is not really an adequate definition: which do we want? I suspect http://www.w3.org/TR/xmlschema-2/#dateTime.
-
-
-5.10 Recipe Link
-
-I don't see what useful purpose this serves.
-
-
-5.11 Role
-
-I can't completely follow the description given.
-
-
-5.13 Ordering of Processes
-
-This section confusingly changes the style of presentation from sections dedicated to specific concepts to a vague discussion of possible relationships between things.
-
-
-5.14 Revision
-
-This seems to be just a different form of Derivation that happens to mention an agent. I'm not sure why I'd choose one over the other.
-
-I think this may be unnecessary - would not a similar effect be achieved by having a process execution of "revision" that uses b1, generates b2 and is controlled by ag (possibly with role "revise"?).
-
-
-5.16 Provenance Container
-
-It's not clear what this is intended to be (maybe unsurprising, since
-the definition is absent). But it looks as if it's intended to a
-syntactical kind of thing, which I feel is out of place in a data
-model description (especially if we're expecting to use RDF to
-represent the data). The next version of RDF will probably formally
-define named graphs - I'm not seeing what additional definition would
-be needed here.
-
-
--- a/model/container1.prov~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,4 +0,0 @@
-
-container([x http://x.com],[acc1,acc2]
- account(acc1,http://x.com/asserter1,...)
- account(acc2,http://x.com/asserter1,...))
--- a/model/container2.prov~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,82 +0,0 @@
-
-; An example of container,
-; - declaring three namespaces with prefix x, viz, prov
-; - no account
-; - a set of prov assertions (hence, all considered to be part of a deafult account)
-
-; The example shows illustrations of prov attributes and application
-; specific attributes, and application specific annotations.
-
-; identifiers in this example follow the URN syntax with "demo" namespace
-
-container([x http://x.com/,
- prov: http://w3.org/prov/,
- viz: http://viz.com/,
- ],
- ,
-
- entity(urn:demo:0, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice" ])
- entity(urn:demo:1, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="" ])
- entity(urn:demo:2, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London last month."])
- entity(urn:demo:3, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month."])
- entity(urn:demo:4, [ ])
- entity(urn:demo:5, [ ])
- entity(urn:demo:6, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month.", x:spellchecked="yes"])
-
- processExecution(urn:demo:100,http://myapp/create-file,t,,[])
- processExecution(urn:demo:101,http://myapp/add-crime-in-london,t+1,,[])
- processExecution(urn:demo:102,http://myapp/email,t+2,,[])
- processExecution(urn:demo:103,http://myapp/edit-London-New-York,t+3,,[])
- processExecution(urn:demo:104,http://myapp/email,t+4,,[])
- processExecution(urn:demo:105,http://myapp/spellcheck,,,[])
-
- wasGeneratedBy(urn:demo:0, urn:demo:100, qualifier())
- wasGeneratedBy(urn:demo:1, urn:demo:100, qualifier(x:fct="create"))
- wasGeneratedBy(urn:demo:2, urn:demo:101, qualifier(x:fct="save"))
- wasGeneratedBy(urn:demo:3, urn:demo:103, qualifier(x:fct="save"))
- wasGeneratedBy(urn:demo:4, urn:demo:102, qualifier(x:port="smtp", x:section="attachment"))
- wasGeneratedBy(urn:demo:5, urn:demo:104, qualifier(x:port="smtp", x:section="attachment"))
- wasGeneratedBy(urn:demo:6, urn:demo:105, qualifier(x:file="stdout"))
-
- used(urn:demo:101,urn:demo:1,qualifier(x:fct="load"))
- used(urn:demo:103,urn:demo:2,qualifier(x:fct="load"))
- used(urn:demo:102,urn:demo:2,qualifier(x:fct="attach"))
- used(urn:demo:104,urn:demo:3,qualifier(x:fct="attach"))
- used(urn:demo:105,urn:demo:3,qualifier(x:file="stdin"))
-
- wasDerivedFrom(urn:demo:2,urn:demo:1)
- wasDerivedFrom(urn:demo:3,urn:demo:2)
- wasDerivedFrom(urn:demo:4,urn:demo:2,urn:demo:102,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
- wasDerivedFrom(urn:demo:5,urn:demo:3,urn:demo:104,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
-
- wasComplementOf(urn:demo:1,urn:demo:0)
- wasComplementOf(urn:demo:2,urn:demo:0)
- wasComplementOf(urn:demo:3,urn:demo:0)
- wasComplementOf(urn:demo:6,urn:demo:3)
-
-
- entity(urn:demo:201, [ prov:type="Person", x:name="Alice" ])
- agent(urn:demo:201)
-
- entity(urn:demo:202, [ prov:type="Person", x:name="Bob" ])
- agent(urn:demo:202)
-
- entity(urn:demo:203, [ prov:type="Person", x:name="Charles" ])
- agent(urn:demo:203)
-
- entity(urn:demo:204, [ prov:type="Person", x:name="David" ])
- agent(urn:demo:204)
-
- entity(urn:demo:205, [ prov:type="Person", x:name="Edith" ])
- agent(urn:demo:205)
-
- annotation(urn:demo:301,[viz:icon="person.png"])
- hasAnnotation(urn:demo:201,urn:demo:301)
- hasAnnotation(urn:demo:202,urn:demo:301)
- hasAnnotation(urn:demo:203,urn:demo:301)
- hasAnnotation(urn:demo:204,urn:demo:301)
- hasAnnotation(urn:demo:205,urn:demo:301)
-
- )
-
-
--- a/model/container3.prov~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,84 +0,0 @@
-
-; An example of container,
-; - declaring three namespaces with prefix x, viz, prov
-; - one account
-; - a set of prov assertions (all in the single account)
-
-; The example shows illustrations of prov attributes and application
-; specific attributes, and application specific annotations.
-
-; identifiers in this example follow the URN syntax with "demo" namespace
-
-container([x http://x.com/,
- prov: http://w3.org/prov/,
- viz: http://viz.com/,
- ],
- [http://x.com/acc1]
- ,
- account(http://x.com/acc1,
- http://x.com/asserter1,
- entity(urn:demo:0, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice" ])
- entity(urn:demo:1, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="" ])
- entity(urn:demo:2, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London last month."])
- entity(urn:demo:3, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month."])
- entity(urn:demo:4, [ ])
- entity(urn:demo:5, [ ])
- entity(urn:demo:6, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice", x:content="There was a lot of crime in London and New York last month.", x:spellchecked="yes"])
-
- processExecution(urn:demo:100,http://myapp/create-file,t,,[])
- processExecution(urn:demo:101,http://myapp/add-crime-in-london,t+1,,[])
- processExecution(urn:demo:102,http://myapp/email,t+2,,[])
- processExecution(urn:demo:103,http://myapp/edit-London-New-York,t+3,,[])
- processExecution(urn:demo:104,http://myapp/email,t+4,,[])
- processExecution(urn:demo:105,http://myapp/spellcheck,,,[])
-
- wasGeneratedBy(urn:demo:0, urn:demo:100, qualifier())
- wasGeneratedBy(urn:demo:1, urn:demo:100, qualifier(x:fct="create"))
- wasGeneratedBy(urn:demo:2, urn:demo:101, qualifier(x:fct="save"))
- wasGeneratedBy(urn:demo:3, urn:demo:103, qualifier(x:fct="save"))
- wasGeneratedBy(urn:demo:4, urn:demo:102, qualifier(x:port="smtp", x:section="attachment"))
- wasGeneratedBy(urn:demo:5, urn:demo:104, qualifier(x:port="smtp", x:section="attachment"))
- wasGeneratedBy(urn:demo:6, urn:demo:105, qualifier(x:file="stdout"))
-
- used(urn:demo:101,urn:demo:1,qualifier(x:fct="load"))
- used(urn:demo:103,urn:demo:2,qualifier(x:fct="load"))
- used(urn:demo:102,urn:demo:2,qualifier(x:fct="attach"))
- used(urn:demo:104,urn:demo:3,qualifier(x:fct="attach"))
- used(urn:demo:105,urn:demo:3,qualifier(x:file="stdin"))
-
- wasDerivedFrom(urn:demo:2,urn:demo:1)
- wasDerivedFrom(urn:demo:3,urn:demo:2)
- wasDerivedFrom(urn:demo:4,urn:demo:2,urn:demo:102,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
- wasDerivedFrom(urn:demo:5,urn:demo:3,urn:demo:104,qualifier(x:port=smtp, x:section="attachment"),qualifier(x:fct="attach"))
-
- wasComplementOf(urn:demo:1,urn:demo:0)
- wasComplementOf(urn:demo:2,urn:demo:0)
- wasComplementOf(urn:demo:3,urn:demo:0)
- wasComplementOf(urn:demo:6,urn:demo:3)
-
-
- entity(urn:demo:201, [ prov:type="Person", x:name="Alice" ])
- agent(urn:demo:201)
-
- entity(urn:demo:202, [ prov:type="Person", x:name="Bob" ])
- agent(urn:demo:202)
-
- entity(urn:demo:203, [ prov:type="Person", x:name="Charles" ])
- agent(urn:demo:203)
-
- entity(urn:demo:204, [ prov:type="Person", x:name="David" ])
- agent(urn:demo:204)
-
- entity(urn:demo:205, [ prov:type="Person", x:name="Edith" ])
- agent(urn:demo:205)
-
- annotation(urn:demo:301,[viz:icon="person.png"])
- hasAnnotation(urn:demo:201,urn:demo:301)
- hasAnnotation(urn:demo:202,urn:demo:301)
- hasAnnotation(urn:demo:203,urn:demo:301)
- hasAnnotation(urn:demo:204,urn:demo:301)
- hasAnnotation(urn:demo:205,urn:demo:301)
-
- ))
-
-
--- a/model/entity.txt~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,3 +0,0 @@
-
-
-In PIDM, an entity construct is a representation of an identifiable thing.
--- a/model/example.txt~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,41 +0,0 @@
-
-provenanceContainer {
-
-bob(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
-bob(e1, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "" ])
-bob(e2, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London last month."])
-bob(e3, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London and New York last month."])
-bob(e4)
-bob(e5)
-bob(e6, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London and New York last month.", disclaimer: "some text"])
-
-
-isDerivedFrom(e2,e1)
-isDerivedFrom(e3,e2)
-isDerivedFrom(e4,e2)
-isDerivedFrom(e5,e3)
-
-isGeneratedBy(e0,pe0,out)
-isGeneratedBy(e1,pe0,out)
-isGeneratedBy(e2,pe1,out)
-isGeneratedBy(e3,pe3,out)
-isGeneratedBy(e4,pe2,out)
-isGeneratedBy(e5,pe4,out)
-
-uses(pe1,e1,in)
-uses(pe3,e2,in)
-uses(pe2,e2,in)
-uses(pe4,e3,in)
-
-processExecution(pe0,create-file,t)
-processExecution(pe1,add-crime-in-london,t+1)
-processExecution(pe2,copy,t+2)
-processExecution(pe3,edit-London-New-York,t+3)
-processExecution(pe4,copy,t+4)
-
-ivpOf(e1,e0)
-ivpOf(e2,e0)
-ivpOf(e3,e0)
-ivpOf(e6,e3)
-
-}
--- a/model/intro.html~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,15 +0,0 @@
-
-<p>
-The term 'provenance' refers to the sources of information, such
-as people, entities, and processes, involved in producing,
-influencing, or delivering a piece of data or a thing in the world.
-In particular, the provenance of information is crucial in deciding
-whether information is to be trusted, how it should be integrated with
-other diverse information sources, and how to give credit to its
-originators when reusing it. In an open and inclusive environment
-such as the Web, users find information that is often contradictory or
-questionable: provenance can help those users to make trust judgments.
-</p>
-
-
-<p>
--- a/model/intro.txt~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,2 +0,0 @@
-
-<p>
--- a/model/simon-comments.txt~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,223 +0,0 @@
-Luc, Paolo,
-
-Here's my comments on the current data model document, annotated with
-(T) for typo/text clarity or (C) for content comment/question. I think
-most/all comments are small enough that an issue need not be raised.
-
-Throughout:
-(T) Sections are referred to in the text by "Section Entity", "Section
-Process Execution" etc. Shouldn't these be the section numbers?
-(T) There seems to be inconsistency in symbols following the change
-from roles to qualifiers. Sometimes "q" is used in constraint
-definitions, examples etc. and sometimes "r" is used. I suggest it
-would be clearer to always use "q".
-(T) There are a few "characterised" in amongst the majority
-"characterized" spelling.
-(C) At least one standard qualifier name, "role", is used in the
-document, but it is not clear what namespace this name is in. Does it
-mean no other "role"s from domain-specific ontologies may be used in
-Prov data?
-
-Sec 2.1:
-(T) paragraph 1: "Words such thing or activity" should be "Words such
-as 'thing' or 'activity'"
-(C) paragraph 2: The first mention of "provenance" in the document
-proper is in the second paragraph of this section, and is a bit out of
-the blue ("unambiguously report provenance"). Can we add some
-intuition about what provenance is (for this data model)?
-(T) Example paragraph 1: "perspectives about a resource" should be
-"perspectives on a resource"
-(C) Example paragraph 1: "the report independent of where it is hosted
-over time" - I suggest also saying "and of its content over time", to
-distinguish this entity from the report version entity above it
-(C) paragraph 6: "punctual events"? "punctual" as most commonly used
-implies prior planning of when something should occur. I'm not sure
-what you are intending in this context.
-(C) paragraph 6: "a partial order exists between events". I assume you
-mean a temporal order? What kind of ordering do you mean?
-(C) paragraph 6: "global notion of time and Lamport's style clocks" -
-this seems like a weirdly specific level of detail for this overview
-section, especially considering that many other aspects of the model
-are not mentioned at all in the overview.
-
-Sec 2.3:
-(C) Regarding the note (not attempting to ensure consistency of an
-asserter) - this seems practical. I'm not sure how we could enforce
-consistency in any circumstance, only define what it means or say it
-is application specific.
-
-Sec 4.1:
-(T) "We denote this e1." and the same for e2 etc. It is not entirely
-clear whether "this" refers to the event or the entity.
-
-Sec 4.2:
-(C) The fact that Alice is the creator of e1 seems to be expressed
-twice, first as an attribute "creator=Alice", and secondly as the
-"creator" role of an agent in the creation process. I don't think it
-is a good idea for either clarity of use of the model or for ensuring
-interoperability for there to be multiple ways to express the same
-thing, if it can be at all avoided. Even if we cannot stop someone
-using either method, can't we say which they *should* use to aid
-interoperability?
-(T) "Generation expressions... represent the event at which a file is
-created". The surrounding text is generic rather than specific to the
-example, implying this should be "entity" rather than "file",
-Otherwise, readers may assume that all entities are files or that
-generation only applies to files.
-(T) Paragraph on wasComplementOf: in "attribute content" and
-"attribute spellchecked", fixed width font (or another font) should be
-used for the attribute names to show they are names, else the sentence
-can be read in strange ways.
-
-Sec 4.3:
-(T) Fig 1: The arrow from pe2 to a3 is a different direction to the
-other "agent" links. It is also not clear if an "agent" link is the
-same as a "wasControlledBy" link. If so, the pe2-a3 arrow direction
-makes most sense, as the others seem to be saying the agent was
-controlled by the process execution.
-
-Sec 5.1:
-(T) The last sentence, regarding a "house-keeping construct" is rather
-opaque. I'm not sure what the reader is supposed to understand from
-this.
-
-Sec 5.2.1:
-(C) First sentence: "entity expression" is given exactly the same
-definition that "entity" was in Section 4. I think having two terms
-for the same thing will cause confusion. I like addition of
-"expressions" to the model in general, though, as I think this greatly
-clarifies what is intended.
-(C) "the meaning of attribute in the context of a process execution
-expression is similar to the meaning of attribute for entity
-expression" - I think the meaning should be exactly the same, not just
-similar, else there will be confusion.
-(C) Following from the above point: "A process execution expression's
-attribute remains constant for the duration of the activity" - OK, but
-does it also characterise the process execution, e.g. is the start
-time part of what distinguishes one execution from others?
-(T) "noted processExecution" - I think you mean "denoted" (or
-"written" or "expressed")
-
-Sec 5.2.3:
-(T) "representation a characterized thing" - missing "of"
-(T) Last sentence, "On the contrary" should be "On the other hand",
-and "inferred" should be "infer"
-
-Sec 5.2.4:
-(T) Last sentence: "expectede"
-
-Sec 5.3.3.1:
-(C) I suggest that, as accounts are not introduced until later in the
-document, the generation-unicity constraint will not make sense here.
-Moreover, I think the constraint is more about accounts and what it
-means for them to be consistent than it is about generation events or
-process executions. Therefore, I suggest moving this constraint to the
-section on accounts.
-(C) Given that constraint derivation-events applies, don't we just
-have two ways of saying the same thing? Why use the long form of
-wasDerivedFrom when the same can be expressed using wasGeneratedBy and
-used? Which variety *should* be used?
-
-Sec 5.3.3.2:
-(T?) Constraint "derivation-linked-independent" seems to be a
-tautology. I guess this is a typo?
-
-Sec 5.3.3.3:
-(T) Paragraph 4: "In other word" should be "In other words"
-
-Sec 5.3.4:
-(C) This section seems to be confusingly expressed, implying that
-non-agent entities can control executions, whereas the control-agent
-constraint (in the section on agents) contradicts this. It is probably
-just a matter of clarifying the text, e.g. if you mean that a
-non-agent entity can be asserted to be controlling an execution but
-from this inferred to be an agent.
-(T) The text may be read to imply that a control link has only one
-qualifier, role, whereas I guess you mean that, like use/generate, it
-can have multiple "modalities" as part of the qualifier?
-
-Sec 5.3.5:
-(C) I can see this section causing some difficulty... While that may
-just be the nature of the topic, there seems an important thing
-missing: what has complementarity got to do with provenance? In other
-words, what value (with regards to provenance) is there in asserting
-complementarity?
-(C) The text suddenly starts talking about "properties" from the
-second paragraph. What are these, and do they have any relation to
-attributes?
-(C) Should the justification of why the complementarity relation is
-not transitive be in this document? I would expect this document to
-just state that it is not transitive and, for brevity and simplicity,
-leave justifications to another document.
-
-Sec 5.3.6:
-(C) Similarly to above, I'm not sure the justification of why
-wasInformedBy is not transitive should be in this document.
-
-Sec 5.3.8:
-(C) Constraint participation: This seems odd to me. In what
-circumstances would you not know or want to assert which of the three
-possibilities (used/controlled/complement) applied for a given entity
-and execution? Is hadParticipant as defined really useful?
-
-Sec 5.3.9:
-(C) Grammar definition: I don't understand what the
-"relationIdentification" stuff is about or what all the identifiers
-identify.
-
-Sec 5.4.1:
-(C) This appears to be yet another way to say the same thing,
-following the comment on Sec 4.2 above. If A is an "asserter" of
-expression E, then we can either (i) express E to be an entity and use
-an attribute "asserter=E"; (ii) express E to be an entity and A to be
-an agent playing "role=asserter"; or (iii) put A in the "asserter"
-slot of an "account" expression containing E. Why do we need all three
-ways? Isn't method (ii) most consistent with the rest of the model?
-
-Sec 5.4.2:
-(T) Second sentence: "return all the provenance assertions" - all the
-assertions? or just "all the assertions in the container"?
-(C) Under the definition given, you cannot have expressions in a
-container but not in an account. Does this imply that every Prov
-expression is made accessible as part of an account? I think this
-would be a good thing for clarity, but it is not explicit in the
-document (and also differs from OPM).
-
-Section 5.5.1:
-(C) I agree with the first note. If it is mandatory to say something
-but that what we say can be nothing, that means that it is not
-mandatory at all. The "mandatory" thing seems to be just saying
-something about the ASN, and so is irrelevant as the ASN is just there
-to make the model concrete and readable.
-
-Sec 5.5.4:
-(C) Second note: Wouldn't this mean that either account IDs or entity
-IDs can never be URIs, as a sequence of URIs would itself not be a
-URI? If so, that seems to make RDF serialisation difficult to achieve.
-
-Sec 5.5.6:
-(C) I don't see the connection between the section's introductory text
-and the content of the subsections.
-
-Sec 5.7.1:
-(C) I think this section needs something introductory to say why it is
-relevant to the data model, i.e. what has it to do with provenance,
-why is it useful in the context of provenance, why is it standardised
-rather than application-specific?
-(C) If my record of what occurred does not start with an empty
-container, but one with contents, how do I say that the elements are
-part of the container? Do I have to model this as a series of
-wasAddedTo links, even if I know nothing about how the elements were
-added? Or is it out of scope of the standard?
-
-Sec 5.7.2:
-(C) I don't see how wasQuoteOf is a sub-relation of wasRevisionOf, or
-wasAttributedTo a sub-relation of wasEventuallyDerivedFrom, when the
-super-relations do not contain reference to any agents but the
-sub-relations do. What does it mean?
-(T) Last sentence of 5.7.2.2: "wasQuoteOf" should be "wasAttributedTo"
-
-Thanks,
-Simon
-
--- Dr Simon Miles Lecturer, Department of Informatics Kings College London, WC2R 2LS, UK +44 (0)20 7848 1166
--- a/model/todiscuss.txt~ Tue Nov 29 09:38:10 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,20 +0,0 @@
-Hi Paolo,
-
-There are a few things to discuss between us, and I think we should
-update the document accordingly, if we are in agreement. They follow
-issues that were raised earlier.
-
-About time.
-----------
-
-Generation time is instantaneous. If it was not, it should be
-possible to identify an attribute of the generated BOB that changes,
-... and hence, we would be dealing with several BOBs.
-
-
-By symmetry, I would suggest that use time is also instantaneous.
-It is a design decision, to ensure that "symmetry" in the various
-relations.
-
-Start and end time of process executions are also instaneous, and
-activities represented by process executions have a duration.