RE: Dealing with mutable resources (PROV-O in Callimachus) - ISSUE-569

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.

Received on Wednesday, 10 October 2012 13:56:45 UTC