- From: Miles, Simon <simon.miles@kcl.ac.uk>
- Date: Mon, 22 Oct 2012 16:24:54 +0100
- To: Paul Groth <p.t.groth@vu.nl>, Luc Moreau <l.moreau@ecs.soton.ac.uk>
- CC: Provenance Working Group WG <public-prov-wg@w3.org>
Luc, Paul, Sorry I could not get to this before. I see that the response is now filled out with my suggestion. Let me know if there's more that needs to be done. thanks, Simon Dr Simon Miles Senior Lecturer, Department of Informatics Kings College London, WC2R 2LS, UK +44 (0)20 7848 1166 Automatically Adapting Source Code to Document Provenance: http://eprints.dcs.kcl.ac.uk/1397/ ________________________________________ From: pgroth@gmail.com [pgroth@gmail.com] On Behalf Of Paul Groth [p.t.groth@vu.nl] Sent: 22 October 2012 09:24 To: Luc Moreau Cc: Miles, Simon; Provenance Working Group WG Subject: Re: Dealing with mutable resources (PROV-O in Callimachus) - ISSUE-569 Hi Luc, I think we can fill in the issue based on Simon's response. We also should ask him to provide a formal acknowledgement then. Thanks Paul On Mon, Oct 22, 2012 at 10:20 AM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote: > Hi Paul and Simon, > > What is the situation on this issue? Simon, have you followed up as Paul > suggested? > I drafted an entry in the response page, is someone going to fill it up? > > Thanks, > Luc > > > On 10/17/2012 08:02 PM, Paul Groth wrote: > > Hi Simon, > > I'm fine with the reply, could you send it directly to him and see what he > thinks? > > thanks! > Paul > > On Wed, Oct 10, 2012 at 3:56 PM, Miles, Simon <simon.miles@kcl.ac.uk> wrote: >> >> Hello Paul, >> >> I read their questions differently. I think they want to use a single >> entity URI for a mutable resource, because that is what Callimachus does, >> but say that it was successively altered by different agents or changed over >> time. So, for example, there is an an entity ex:document, which ex:simon >> contributed to in September and ex:paul contributed to in October, or a >> single entity ex:flour changed (but "not in a significant way") by a baking >> activity. They ask how they would express this information. >> >> I would answer something like: >> >> PROV supports the case you describe using the prov:specializationOf >> relation to connect your mutable resource URI to entities representing each >> revision over time. The latter don't have to exist already in Callimachus, >> but may be created with unique IDs specifically to model the provenance. >> >> If a change in a resource's state is something to be documented in the >> provenance, then that requires multiple entities. PROV entities are allowed >> to be mutable, but the purpose of this is to hide information that is >> unimportant, i.e. that you do not want to model in the provenance. As soon >> as the timeline of the resource is divided into relevantly different periods >> (e.g. before and after each contributor edited), then the mechanism to >> document this in PROV is to use multiple entities. If you have a single >> identifier (entity) for the mutable resource as it exists over time, through >> multiple revisions, this can be connected to the set of revision entities >> using the prov:specializationOf relation. >> >> The flour and baking example is similar. If a change is to be documented >> in PROV, then multiple entities are used, e.g. the flour before and after >> baking. If it is not documented, then only one entity is required. There is >> no notion of a change which is "documented but not significant", because it >> is unclear what significance would be in general except for the decision to >> model/document it. As before, a general, mutable "flour" entity can exist >> that is connected to the flour before and after baking using >> prov:specializationOf. For example: >> >> ex:baked prov:used ex:flour1 >> ex:flour2 prov:wasGeneratedBy ex:baked >> ex:flour2 prov:wasDerivedFrom ex:flour1 >> ex:flour1 prov:specializationOf ex:flour >> ex:flour2 prov:specializationOf ex:flour >> >> thanks, >> Simon >> >> Dr Simon Miles >> Senior Lecturer, Department of Informatics >> Kings College London, WC2R 2LS, UK >> +44 (0)20 7848 1166 >> >> Transparent Provenance Derivation for User Decisions: >> http://eprints.dcs.kcl.ac.uk/1400/ >> ________________________________________ >> From: pgroth@gmail.com [pgroth@gmail.com] On Behalf Of Paul Groth >> [p.t.groth@vu.nl] >> Sent: 10 October 2012 14:23 >> To: Provenance Working Group WG >> Subject: Dealing with mutable resources (PROV-O in Callimachus) - >> ISSUE-569 >> >> Hi All, >> >> I'm trying to put together a response for James. See >> http://lists.w3.org/Archives/Public/public-prov-comments/2012Oct/0001.html >> >> Below are my thoughts on answering the question. The central question >> is how do we deal with mutable resources. >> >> Response/Questions >> >> >Can PROV-O be used to capture contributors to a resource over time, if >> > each of the resource revisions is not represented with a unique entity? >> >> I would say the answer is yes. It's fine to write e1 wasDerivedFrom >> e2, e1 wasDerivedFrom e3. >> >> >> > What is the recommended way to capture these consumable resources? Must >> > different entity URIs be used to represent the bag of flour before and after >> > it was used? Is there any way to say an activity changed the state of a >> > resource, but not in any significant way? >> >> I think this was why we wanted to introduce entity, no? The current >> definition of wasGeneratedBy clearly states that it is a new entity. >> The question is if this is too constraining. This seems to imply that >> it is. Or I'm a misreading things? >> >> >> > The way PROV-O uses qualified relationships is very interesting and >> > useful. It allows simple relationships to be created (like prov:used) and if >> > needed it can be clarified with a qualifiedUsage, very clever idea. >> >> Nice one prov-o team! >> >> >> >Callimachus assumes that a resource may change over time and permits the >> > state of a resource to be modified by a user without changing the resource's >> > identifier. This means that, over time, multiple activities may contribute >> > to the current state of a resource. However, distinct URIs to reference each >> > of the states may not be available. >> >> I think we wanted to cater for this with scruffy provenance, no? >> >> >> > The property prov:wasRevisionOf is documented[2] as a way to link entity >> > revisions and combined with prov:wasGeneratedBy a way to link all the >> > activities that contributed to an entity. However, since Callimachus does >> > not require different URIs for each revision, this relationship could not be >> > relied upon. >> >> This is the issue of wasGeneratedBy not being allowed to be on the >> same resource. >> >> > Callimachus also uses prov:wasInformedBy to link a activity, that >> > reverses a resource state, to the activity that created the resource state. >> > Is this usage permitted by the semantics of PROV-O? >> >> I think this is fine. > > > > > -- > -- > Dr. Paul Groth (p.t.groth@vu.nl) > http://www.few.vu.nl/~pgroth/ > Assistant Professor > - Knowledge Representation & Reasoning Group | > Artificial Intelligence Section | Department of Computer Science > - The Network Institute > VU University Amsterdam > > > -- > Professor Luc Moreau > Electronics and Computer Science tel: +44 23 8059 4487 > University of Southampton fax: +44 23 8059 2865 > Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk > United Kingdom http://www.ecs.soton.ac.uk/~lavm > -- -- Dr. Paul Groth (p.t.groth@vu.nl) http://www.few.vu.nl/~pgroth/ Assistant Professor - Knowledge Representation & Reasoning Group | Artificial Intelligence Section | Department of Computer Science - The Network Institute VU University Amsterdam
Received on Monday, 22 October 2012 15:28:50 UTC