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

Ok sounds good.

Paul

On Mon, Oct 22, 2012 at 5:38 PM, Miles, Simon <simon.miles@kcl.ac.uk> wrote:

> Hello Luc, Paul,
>
> As Luc gave a deadline of Wednesday for group approval of the response,
> I'll send it on Thursday afternoon unless there are objections.
>
> 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: Luc Moreau [l.moreau@ecs.soton.ac.uk]
> Sent: 22 October 2012 16:35
> To: Paul Groth
> Cc: Miles, Simon; Provenance Working Group WG
> Subject: Re: Dealing with mutable resources (PROV-O in Callimachus) -
> ISSUE-569
>
> Paul
> shouldn't we get it endorsed by the WG first?
> Luc
>
> On 22/10/2012 16:29, Paul Groth wrote:
> > 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
> >>
> >
> >
> >
>
> --
> 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