- From: Paul Groth <p.t.groth@vu.nl>
- Date: Wed, 10 Oct 2012 15:23:14 +0200
- To: Provenance Working Group WG <public-prov-wg@w3.org>
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.
Received on Wednesday, 10 October 2012 13:24:42 UTC