- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Mon, 22 Oct 2012 16:35:53 +0100
- To: Paul Groth <p.t.groth@vu.nl>
- CC: "Miles, Simon" <simon.miles@kcl.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
Paul shouldn't we get it endorsed by the WG first? Luc On 22/10/2012 16:29, Paul Groth wrote: > 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 >> > > > -- 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
Received on Monday, 22 October 2012 15:36:29 UTC