- From: Paul Groth <p.t.groth@vu.nl>
- Date: Mon, 22 Oct 2012 10:24:01 +0200
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: "Miles, Simon" <simon.miles@kcl.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
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 08:24:29 UTC