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

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 
> <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