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

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

From: Paul Groth <p.t.groth@vu.nl>
Date: Mon, 22 Oct 2012 17:29:27 +0200
Message-ID: <CAJCyKRo9RBtRBRxWt_dfWVzK5VOwj+AHdraXcfRagQbNrCntPA@mail.gmail.com>
To: "Miles, Simon" <simon.miles@kcl.ac.uk>
Cc: Luc Moreau <l.moreau@ecs.soton.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
Hi Simon,

It wasn't sent to him. Can you do that and cc public prov comments?

I just think it's better if you send it because I'd like you to be in
the conversation.

cheers
Paul

On Mon, Oct 22, 2012 at 5:24 PM, Miles, Simon <simon.miles@kcl.ac.uk> wrote:
> Luc, Paul,
>
> Sorry I could not get to this before. I see that the response is now filled out with my suggestion. Let me know if there's more that needs to be done.
>
> thanks,
> Simon
>
> Dr Simon Miles
> Senior Lecturer, Department of Informatics
> Kings College London, WC2R 2LS, UK
> +44 (0)20 7848 1166
>
> Automatically Adapting Source Code to Document Provenance:
> http://eprints.dcs.kcl.ac.uk/1397/
> ________________________________________
> From: pgroth@gmail.com [pgroth@gmail.com] On Behalf Of Paul Groth [p.t.groth@vu.nl]
> Sent: 22 October 2012 09:24
> To: Luc Moreau
> Cc: Miles, Simon; Provenance Working Group WG
> Subject: Re: Dealing with mutable resources (PROV-O in Callimachus) - ISSUE-569
>
> 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



-- 
--
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 15:30:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:20 UTC