--- a/model/ACTIONS-04082011.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,34 +0,0 @@
-ACTIONS (from skype 4/8/11)
-
-
-sec. 4
-
-ISSUE-62:
-
-* [LUC] we are defnining a data model.
- We offer an ASN to express assertions that conform to the data model, but a language will be needed to express instances of the model (ABox, KBase, DB.... term to be determined) but this language is likely to be out of scope of this spec.
-
-* we should shave a discussion on whether a formal notion of "validity" is appropriate and whether one can have a practical test for validity (without which, the notion becomes useless)
-
-sec. 5:
-
-5.2: outcome is that PEs and entities are disjoint "classes".
- ACTION (NOT ASSIGNED): explain why they are conceptually different.
-
-5.3: parked "role" issue: no linear reading is possible and the def. of role may need to be revised, but we don't have a good way of doing it just now.
-
-5.6
-- ACTION[PAOLO] raise an issue on the persistence of agent
-- ACTION[PAOLO] raise an issue on whether we should have agent-of as relation, this emerges naturally from Fig. 1
-
-
-sec 5.8
-sec 5.15 ACTION[LUC] complete
-
-
-sec 6 ACTION[PAUL] take a stab at it
-
-
-
-
-
\ No newline at end of file
--- a/model/README.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,38 +0,0 @@
-Changes in version 2011-09-19:
-
-The document underwent substantial reorganization. Section 2,
-preliminaries, now includes key material setting the context for the
-definition of the data model:
-- conceptualization of the world
-- ASN
-- discussion on representation/assertion/inference
-
-The following issues have been addressed in this version of the document
-and have been closed pending review:
-
-- ISSUE-87: section 2.2 now explains the role of PROV-ASN. Its role
- is now more central in this document (as reflected in the new title).
-
-- ISSUE-86: a high-level overview of the data model is now available
- in section 3.
-
-- ISSUE-71: multiple comments about the example have now been tackled.
-
-- ISSUE-65: extensibility points are now explicitly discussed in section 6.
-
-- ISSUE-85: the email discussions have indicated where the origin of
- the confusion arises from. Multiple changes have been introduced to tackle
- this issue:
- - preliminaries section: to introduce conceptual model
- - section 6, PROV DM: refers to 'entity expression'
-
-- ISSUE-50: definition of process ordering now incorporated
-
-- ISSUE-48: definition of revision also included
-
-- ISSUE-49: definition of participation also included
-
-- ISSUE-51: asserter now defined
-
-- ISSUE-81: container and account now defined
- scope of identifier discussed in account section
--- a/model/README.txt~ Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,8 +0,0 @@
-Changes in version 2011-09-19:
-
-The following issues have been addressed in this version of the document
-and have been closed pending review:
-
-- ISSUE-87: section 2.2 now explains the role of PROV-ASN. Its role
- is now more central in this document (as reflected in the new title).
-
--- a/model/authors.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,14 +0,0 @@
-Khalid
-Paul Groth
-Simon Miles
-Graham Klyne
-James Myers
-
-
-
-
-Borderline
-Stian
-Tim Lebo
-Jim Mccusker
-Stephen Cresswell
--- a/model/container-example.pasn Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,89 +0,0 @@
-
-provenanceContainer(id1, ;;; <- container identifier
-
-
-
- hasProvenance:
- provenanceContainer(id2, ;;; <- no provenance for container id2
- statements: {
- entity(id1) ;;; <- container seen as a entity
- isGeneratedBy(id1,p,out)
-
- processExecution(p,assert,"07-28-2011:10.38am") ;;; <- time of assertion
-
- entity(a6, [ type: "Person", name: "Luc" ]) ;;; <- luc is an agent
- agent(a6)
- isControlledBy(p,a6,"asserter") ;;; <- luc is the asserter
- }
-
-
- statements: {
-
- entity(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
- entity(e1, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "" ])
- entity(e2, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London last month."])
- entity(e3, [ type: "File", location: "/shared/crime.txt", creator: "Alice", content: "There was a lot of crime in London and New York last month."])
- entity(e4)
- entity(e5)
- entity(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)
-
- processExecution(pe0,create-file,t)
- processExecution(pe1,add-crime-in-london,t+1)
- processExecution(pe2,email,t+2)
- processExecution(pe3,edit-London-New-York,t+3)
- processExecution(pe4,email,t+4)
- processExecution(pe5,spellcheck)
-
-
- isGeneratedBy(e0,pe0,outFile)
- isGeneratedBy(e1,pe0,outContent)
- isGeneratedBy(e2,pe1,out)
- isGeneratedBy(e3,pe3,out)
- isGeneratedBy(e4,pe2,attachment)
- isGeneratedBy(e5,pe4,attachment)
- isGeneratedBy(e6,pe5,out)
-
- uses(pe1,e1,in)
- uses(pe3,e2,in)
- uses(pe2,e2,in)
- uses(pe4,e3,in)
- uses(pe5,e3,fileIn)
-
- isComplementOf(e1,e0)
- isComplementOf(e2,e0)
- isComplementOf(e3,e0)
- isComplementOf(e6,e3)
-
- entity(a1, [ type: "Person", name: "Alice" ])
- agent(a1)
-
- entity(a2, [ type: "Person", name: "Bob" ])
- agent(a2)
-
- entity(a3, [ type: "Person", name: "Charles" ])
- agent(a3)
-
- entity(a4, [ type: "Person", name: "David" ])
- agent(a4)
-
- entity(a5, [ type: "Person", name: "Edith" ])
- agent(a5)
-
- isControlledBy(pe0,a1, creator)
- isControlledBy(pe1,a2, author)
- isControlledBy(pe2,a3, communicator)
- isControlledBy(pe3,a4, author)
- isControlledBy(pe4,a5, communicator)
-
-
- }
-
-)
-
-
--- a/model/container1.prov Thu Feb 23 22:45:49 2012 +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://www.w3.org/ns/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/container2.prov Thu Feb 23 22:45:49 2012 +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://www.w3.org/ns/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/container3.prov Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,91 +0,0 @@
-
-; An example of container,
-; - declaring three namespaces with prefix x, viz, prov
-; - two nested accounts
-; - some identifiers (urn:demo:0, urn:demo:100) declared in the toplevel account (acc1)
-; and reusable in the innermost account (acc2)
-; - toplevel container lists al lthe accounts.
-;
-; 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://www.w3.org/ns/prov/,
- viz: http://viz.com/,
- ],
- [http://x.com/acc1, http://x.com/acc2]
- ,
- account(http://x.com/acc1,
- http://x.com/asserter1,
- entity(urn:demo:0, [ prov:type="File", prov:location="/shared/crime.txt", x:creator="Alice" ])
- processExecution(urn:demo:100,http://myapp/create-file,t,,[])
- wasGeneratedBy(urn:demo:0, urn:demo:100, qualifier())
-
- account(http://x.com/acc2,
- http://x.com/asserter1,
-
- 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: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: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/derivation.html Thu Feb 23 22:45:49 2012 +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>
--- a/model/diff.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,16 +0,0 @@
-diff -r 79920156d85d model/ProvenanceModel.html
---- a/model/ProvenanceModel.html Fri Sep 16 13:11:44 2011 +0100
-+++ b/model/ProvenanceModel.html Fri Sep 16 13:14:00 2011 +0100
-@@ -313,10 +313,10 @@
-
- The model includes two additional entity types: <strong>qualifiers</strong> and <strong>annotations</strong>. These are both structured as sets of attribute-value pairs.
- <ul><li> Qualifiers can be associated to relations, namely <strong>use</strong> and <strong>wasGeneratedBy</strong>, in order to further characterise their nature. <strong>Role</strong> is a standard qualifier.
--<li> Annotations are used to provide additional, "free-form" information regarding <strong>any</strong> construct of the model, with no prescribed meaning. The difference between attributes and annotations is further clarified <a href="#expression-annotation">here</a>.
-+<li> Annotations are used to provide additional, "free-form" information regarding <strong>any</strong> identifiable construct of the model, with no prescribed meaning. The difference between attributes and annotations is further clarified <a href="#expression-annotation">here</a>.
- </ul>
-
--Attributes and extensions are the main <strong>extensibility points</strong> in the model: individual interest groups are expected to extend PROV-DM by introducing new sets of attributes and annotations as needed to address applications-specific provenance modelling requirements.
-+Attributes, qualifiers, and annotation are the main <strong>extensibility points</strong> in the model: individual interest groups are expected to extend PROV-DM by introducing new sets of attributes, qualifiers, and annotations as needed to address applications-specific provenance modelling requirements.
-
-
- </section>
--- a/model/entity.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,79 +0,0 @@
-
-
-In section 4:
-
-
-Data modelling has always relied on three elements, and it seems strange that one would have to recall this:
-- the "real world": stuff you want to model
-- a representation of the real-world: the model itself
-- a language for expressing the model
-
-
-
-In PIDM, we have the need to accommodate multiple relative views of
-the world, and thus multiple and often overlapping models (which may
-also change in time). This leads to the three elements being
-formulated as:
-
-- stuff in the real world: identifiable characterized things and activities
-- their representation: Entities (further specialized as needed), and relations amongst entities
-- assertions, which state the existence of entities and of their relationships
-
-
-
-----------------------------------------------------------------------
-
-In section 5:
-
-
-
-In PIDM, an entity construct is a representation of an identifiable characterized thing.
-
-An instance of an entity construct, expressed as entity(id, [ attr:
-val, ...]) in the Provenance Abstract Syntax Notation:
-- contains an identifier id, denoting a characterized thing
-- contains a set of attribute-value pairs [ attr: val, ...], representing
- this characterized thing's situation in the world.
-
-The assertion of an instance of an entity construct , entity(id, [ attr: val, ...]), states, from a given asserter's viewpoint, the existence of an identifiable characterized thing, whose situation in the world is represented by the attribute-value pairs, which remain unchanged during a characterization interval, i.e. a continuous interval between two events in the world (which may collapse into a single instant).
-
-Example:
-... states the existence of a thing of type File and location /shared/crime.txt, and creator alice, denoted by identifier e0, during some characterization interval.
-
-
-Further properties:
-- If an asserter wishes to characterize a thing with same attribute-value pairs over several intervals, then they are required to assert multiple entity assertions, each with its own identifier.
-
-- There is no assumption that the set of attributes is complete and that the attributes are independent/orthogonal of each other.
-
-
-
-General assumption (to appear in section 4):
- in the real world:
- - identifiable characterized things, their situation in the world
- - activities
- - events
-
-
-
-
-----------------------------------------------------------------------
-
-
-An entity is an assertion about a characterized thing. Using the Provenance Abstract Syntax Notation, an entity is represented as:
-
- entity(e,[a1:v1, a2:v2, ...])
-
-where "e" is a name that denotes the characterized thing about which provenance is expressed, and the "ai:vi" are assertions about attributes of that thing. The entity is true exactly when all of the attribute assertions are true of the named thing.
-
-For example, the entity represented by:
-
- entity(e0, [ type: "File", location: "/shared/crime.txt", creator: "Alice" ])
-
-might be interpreted as asserting that the thing denoted by "e0" is a file whose file system location is "/shared/crime.txt", and which was created by "Alice".
-
-----------------------------------------------------------------------
-
- Defn 2. entity(id, [ attr: val, ...]) *is* an assertion that an
-entity, identified by id, existed and was characterized by the
-attributes [ attr: val, ...].
--- a/model/extensibility.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,201 +0,0 @@
-
-
-Extensibility points:
-
-- for entities: a standard attribute (type), note compatible with definition of attribute since remaining constant during caracterization interval
-
-
-- for process execution: recipe link, built in the definitin of process exectuion
-
- where you subtype process execution is with recipe link,
- it up to the application to define how to encode type
-
- Note, if requirement comes up, we may expose it as a first-class property.
-
-
-
-
-
-
-- Should everything be annotable
-
-
-
-recipe link: need a production
- is recipe link a uri or identifier
-
-identifier what is it
-
-
-
-
-
-
-- Declaration of namespace in container
-
-- General annotation mechanism for unconstrained name value pairs
- such as rendering metadata for provenance graphs (eg. label, colour)
-
- - WHAT can we annotate?
- - annotations are first class citizens, they are an element of the model
- - can be associated to anything that has an identifier (using standard notation, has annotation)
- and that includes relations (e.g. wasGeneratedBy) since they have implicitly an identifier
- (id x id x role)
- - annotations must have an identifier
-
-
-e is entity
- hasAnnotation [ is Annotation
- hasName "ex:foo"
- hasValue "bar"
- hasAnnotation ...
- hasAccount ... ]
-
-e is entity
- ex:foo "bar"
-
-annotation(ann1,[ attr: val, ...])
-hasAnnotation(e1, ann1)
-hasAnnotation(e2, ann1)
-
-what's the difference between attributes and annotations
-
-- Colour as annotation is not same as color as attribute
-
-- attributes are intrisic part of characterization
- annotations, are application dependent, and do not help characterize entities
- colour as attribyte characterizes a car
- colour as annotation is application dependent, and may be used for instance to render the graph.
-
--> types: attributes of entities,
-
- for processexecutoin, st, et, type, rl, are standard attributes (in the same sense as for entities)
-
- needs to adopt same syntax as entities.
-
-
-
-In 8.2.1. say that type is a reserved name for attributes
-Need a section for standard attributes
-
-
-processExecution := processExecution ( identifier [, recipe] [, time] [, time] )
-
-processExecution := processExecution ( identifier , [ attribute-values ] )
-
-
-
-
-
-
-----------------------------------------------------------------------
-
-Should role be [attribute-values]
-
-use() ...=use(..., useQualifiers)
-
-useQualifiers= attribute-values
-
-
-A given qualifier must be "unique" for a process execution:
- Failing to do so, would prevent us from annotating use,generation, derivation
- or expressing pe-linked-derivation
-
-If you want to annoate an edge or express pe-linked-derivation, qualifiers must be unique.
-
-example of streamTO WRITE
- x:port 1, x:pos=1,
- x:port 1, x:pos=2,
-
-
-prov:role
-
-
-procedrue: proc:parameterName, proc:parameterType
-
-
-pe-linked-derivation:= wasDerivedFrom ( identifier , identifier [, processExecution , generateQualifier , useQualifier] )
-
-multiple occurrences of type attributes
-
-----------------------------------------------------------------------
-
-- Action Luc: keep on renaming xxx -> xxxExpression
-- Action Luc: replace roles by xxxQualifier (use/generatedBy)
- and expand the grammer of those xxxQualifiers
-
--
-interoperability: must exchange prov:concept
-
-----------------------------------------------------------------------
-
-
-31: prov-dm, prov-asn
-
-42: ?? no action
-
-43: ?? no action
-
-44: needs aligning to new terminology/grammars
-
-64: solved with qualifers + if ..., then MUST
-
-69: give example of two process executions one paused, the other
-relocated, attribute changing is location, part of the characterization of the PE.
-
-71: closeable
-
-81:
- given a scope,
- nultiple entity expressions with a same id,
- they should be understood as taking the union of all attributes (as conformant to grammar)
- authro=john
- authro=bar -> [authro=bar, authro=john]
-
- id
-
-accounts:
- - hierarchical nature is useful
- - give example e1 isComplementOf e0 should be in
- e0 in toplevel account, e1 in lowerlevel account, scope of e0 includes lowevel account
-
-- container is wrapper, namespace declarations, and mul
- house keekping concept
- containing multiple accounts, potentially
- an index of all accounts
- all expressions belong to a default account, placed inside a container
-
- is it named?
-
-
-
-
-82: event was introduced in the conceptualisation, but there is no first class expression in the model to represents, annotate them, or associate relationships with them.
- We should see whether this is enough, or whether we have more requirements
-
-
-
-85: to be closed pending review
-
-86: paolo to do an ER diagram
-
-87: now addressed by the new structure
-
-48: to close
-
-29: ask stephen, can this be closed , see complementOf
-
-50: add some text around wasScheduledAfter, close issue 50 (pending)
- raise another issue, to ask about wasScheduledAfter
-
-91: locations are optional attributes for entities and process if they characterize them
- for the duration,
- alternative they can be expressed an annotation,
-
- standard name: location
- multiple locations are possible
-
-94: yes
-
-
-if role becomes qualifier, should time be encoded in qualifier??
--- a/model/grammar.html Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,17 +0,0 @@
-<construct> :== <name> '(' <argument+> ')'
-<argument+> ::= <argument> | <argument> ',' <argument+>
-<argument> ::= <identifier>
- | <role>
- | <time>
- | <properties>
-
-<properties> ::= '[' <attribute-value*> ']'
-<attribute-value*> ::= <attribute-value> | <attribute-value> ',' <attribute-value*>
-<attribute-value> ::= <attribute> ':' <value>
-
-<value> ::= <string> | <number> | <time>
-
-
-<role> ::= token
-<identifier> ::= token
-<attribute> ::= token
--- a/model/grammar.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,17 +0,0 @@
-<construct> :== <name> '(' <argument+> ')'
-<argument+> ::= <argument> | <argument> ',' <argument+>
-<argument> ::= <identifier>
- | <role>
- | <time>
- | <properties>
-
-<properties> ::= '[' <attribute-value*> ']'
-<attribute-value*> ::= | <attribute-value> ',' <attribute-value*>
-<attribute-value> ::= <attribute> ':' <value>
-
-<value> ::= <string> | <number> | <time>
-
-
-<role> ::= token
-<identifier> ::= token
-<attribute> ::= token
--- a/model/intro.html Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,41 +0,0 @@
-<html>
-<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>
-The idea that a single way of representing and collecting provenance could be adopted internally by all systems does not seem to be realistic today. Instead, a pragmatic approach is to consider a core data model for provenance that allows domain and application specific representations of provenance to be translated into such a data model and exchanged between systems.
-Heterogeneous systems can then export their provenance into such a core data model, and applications that need to make sense of provenance in heterogeneous systems can then import it, process it, and reason over it.</p>
-
-<p>A set of specifications define the various aspects
-that are necessary to achieve this vision in an inter-operable
-way:</p>
-<ul>
-<li> This document defines the PROV-DM data model for provenance, accompanied with a notation to express instances of that data model for human consumption; </li>
-<li> A normative serialization of PROV-DM in RDF [[PROV-OWL2]], specified by means of a mapping to the OWL2 Web Ontology Language [[!OWL2-SYNTAX]];</li>
-<li> The mechanisms for accessing and querying provenance [[PROV-PAQ]].</li>
-</ul>
-
-
-<p>
-The PROV-DM data model for provenance consists of a set of core
-concepts, and a few common extensions, based on these core concepts. PROV-DM provides extensibility points allowing further domain-specific and application specific extensions to be defined.</p>
-
-<p>This specification also introduces
-PROV-ASN, an abstract syntax that is primarily aimed at human consumption. PROV-ASN allows
-serializations of PROV-DM instances to be created in a technology independent manner,
-it facilitates its mapping to concrete syntax, and it is used as the basis for a
-formal semantics.
-</p>
-
-
-</html>
--- a/model/intro.txt Thu Feb 23 22:45:49 2012 +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/note.txt Thu Feb 23 22:45:49 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,19 +0,0 @@
-21 July 2011:
-
-- Name required for the language/data model
-
-- BOB: we kept it as a placeholder. Name required to make the document readable.
-
-- Process execution: could be renamed Activity?
-
-- There is a notion of event underpinning the data model. It should be made explicit in Section 4.
-
-- We need to define the partial orders "precedes/follows"
-
-- Roles: we neeed roles both as parameter-names and as parameter-types
-
-- The WG may defined default role names, eg. in, out, initiator, terminator
-
-- The WG may defined default role types, eg. responsibleFor, etc
-
-