- From: Paul Groth <p.t.groth@vu.nl>
- Date: Mon, 22 Oct 2012 17:29:27 +0200
- To: "Miles, Simon" <simon.miles@kcl.ac.uk>
- Cc: Luc Moreau <l.moreau@ecs.soton.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
Hi Simon, It wasn't sent to him. Can you do that and cc public prov comments? I just think it's better if you send it because I'd like you to be in the conversation. cheers Paul On Mon, Oct 22, 2012 at 5:24 PM, Miles, Simon <simon.miles@kcl.ac.uk> wrote: > 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 -- -- 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:30:01 UTC