Re: PROV-O in Callimachus

Hi James,

This looks really good. I was wondering why you used prov:generated - is
this so you can more easily query ?

Thanks
Paul


On Thu, Nov 8, 2012 at 2:50 PM, James Leigh <james@3roundstones.com> wrote:

> Hi Simon,
>
> Yes I have, thanks for the response. It has taken me a while to digest
> everything and reconsider the best way forward.
>
> I have incorporated the use of prov:specializationOf into Callimachus. I
> expect to have 0.18-beta-10 out soon that demonstrates this. In the mean
> time I updated my blog post[1] to reflect the new model. In short the
> structure looks like the following after two insert operations and one
> update operation. It's a bit more verbose, but it is also more accurate.
>
> [1]
> http://jamesrdf.blogspot.ca/2012/10/provenance-and-traceability-in.html
>
> Thank you again and please let me know if I there is anything else I can
> improve here.
>
> Regards,
> James
>
> GRAPH <b1> {
>     <b1> prov:wasGeneratedBy <a1> .
>
>     <a1> prov:generated <e1> .
>
>     <e1> prov:specializationOf <e> ;
>          audit:with <s1>.
> }
> GRAPH <b2> {
>     <b2> prov:wasGeneratedBy <a2> .
>
>     <a2> prov:generated <e2> .
>
>     <e2> prov:specializationOf <e> ;
>          prov:wasRevisionOf <e1> ;
>          audit:with <s2>.
> }
> GRAPH <b3> {
>     <b3> prov:wasInfluencedBy <b1>, <b2> ;
>          prov:wasGeneratedBy <a3> .
>
>     <a3> prov:generated <e3> .
>
>     <e3> prov:specializationOf <e> ;
>          prov:wasRevisionOf <e2> ;
>          audit:without <s1>, <s2> .
>
>     <s1> rdf:subject <e> ;
>          rdf:predicate foo:bar ;
>          rdf:object <x> .
>
>     <s2> rdf:subject <e> ;
>          rdf:predicate foo:bar ;
>          rdf:object <y> .
>
>     <e> foo:bar <z> ; prov:wasGeneratedBy <a3> .
> }
>
>
>
> On Mon, 2012-11-05 at 16:00 +0000, Miles, Simon wrote:
> > Hi James,
> >
> > Have you had a chance to look at the response below? As part of the W3C
> process we need an acknowledgement from you to record that your comments
> have been satisfactorily responded to. The provenance working group will be
> meeting on Friday, and it would be very helpful to know whether what we
> said answered your query before then, if possible.
> >
> > thanks,
> > Simon
> >
> > Dr Simon Miles
> > Senior Lecturer, Department of Informatics
> > Kings College London, WC2R 2LS, UK
> > +44 (0)20 7848 1166
> >
> > Evolutionary Testing of Autonomous Software Agents:
> > http://eprints.dcs.kcl.ac.uk/1370/
> > ________________________________________
> > From: Miles, Simon
> > Sent: 25 October 2012 17:55
> > To: James Leigh
> > Cc: public-prov-comments
> > Subject: RE: PROV-O in Callimachus
> >
> > Hi James,
> >
> > The PROV working group discussed the questions regarding mutable
> resources in Callimachus (and in general) that you raised. We've uploaded
> the response to the group Wiki [1], but I'll copy the text here for
> convenience.
> >
> > PROV supports the case you describe using the prov:specializationOf
> relation to connect a 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
> >
> > Can you say whether you think this addresses your questions?
> >
> > thanks,
> > Simon
> >
> > [1]
> http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-569_.28Mutable_resources.29
> >
> >
> > 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: 10 October 2012 14:28
> > To: James Leigh
> > Cc: public-prov-comments
> > Subject: Re: PROV-O in Callimachus
> >
> > Hi James,
> >
> > Following-up, I think the issue (now ISSUE-569) you raised on how to
> > deal with mutable resources is important. We are going to discuss this
> > in the working group. As to not bombard you with emails, we will take
> > this onto our own working group email list and get back to you with a
> > response. If you want to follow the discussion, you can find all the
> > email traffic and discussion at
> > https://www.w3.org/2011/prov/track/issues/569.
> >
> > Thanks again for your input and we are excited that Callimachus is using
> prov.
> >
> > regards
> > Paul
>
>
>
>