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

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