W3C home > Mailing lists > Public > public-prov-wg@w3.org > October 2012

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

From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Mon, 22 Oct 2012 09:20:44 +0100
Message-ID: <EMEW3|79edb661a688ba0d116f6d62d9653f2fo9L9Km08l.moreau|ecs.soton.ac.uk|508501DC.4010307@ecs.soton.ac.uk>
To: Paul Groth <p.t.groth@vu.nl>, "Miles, Simon" <simon.miles@kcl.ac.uk>
CC: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Paul and Simon,

What is the situation on this issue? Simon, have you followed up as Paul 
I drafted an entry in the response page, is someone going to fill it up?


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 
> <mailto: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 <tel:%2B44%20%280%2920%207848%201166>
>     Transparent Provenance Derivation for User Decisions:
>     http://eprints.dcs.kcl.ac.uk/1400/
>     ________________________________________
>     From: pgroth@gmail.com <mailto:pgroth@gmail.com> [pgroth@gmail.com
>     <mailto:pgroth@gmail.com>] On Behalf Of Paul Groth
>     [p.t.groth@vu.nl <mailto: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 <mailto:p.t.groth@vu.nl>)
> http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
> 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 08:21:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:24 UTC