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 10:24:01 +0200
Message-ID: <CAJCyKRqZqyBqHoUi_o5yRrg67OfTf_32t1sUqTkeDWfapC53Gg@mail.gmail.com>
To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Cc: "Miles, Simon" <simon.miles@kcl.ac.uk>, Provenance Working Group WG <public-prov-wg@w3.org>
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
Received on Monday, 22 October 2012 08:24:29 UTC

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