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

Re: Collections in PROV-O

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Thu, 23 Feb 2012 08:25:52 +0000
Message-ID: <CAPRnXtmxoY4-y7ST5TkkXTNdxi56gsahDUv94JLhab1PmJt0Yw@mail.gmail.com>
To: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>
Cc: public-prov-wg@w3.org
No, this is very good reasoning, I like it. One issue is that PROV does not
specify a way to assert the existing members.

I preferred the Involvement solution, but as the other alternative is just
3 functional properties they also work directly on the collection entity.

Practical example (Let's see how easy it is to write Turtle on the phone):

Khalid shortened:

:c2 prov:wasObtainedAfterInsertion :c1 ;
    prov:qualified [
         a prov:InsertionInCollection;
         prov:entity :c1;
         prov:key :k1;
         prov:value :v1
] .

(I assume wasObtained.. is subproperty of wasDerivedFrom, but perhaps the
involvement is not subclass of prov:Derivation?)

current provrdf shortened without involvement:

:c2 prov:wasExpandedFrom :c1;
    prov:wasExpandedWithKey :k1;
    prov:wasExpandedWithValue :v1.

(all subprops of wasDerivedFrom)
On Feb 22, 2012 4:36 PM, "Khalid Belhajjame" <Khalid.Belhajjame@cs.man.ac.uk>

> Hi Stian,
> Thanks for giving this a try.
> CollectionAfterInsertion(c2,**c1,k1,v1)
> CollectionAfterRemoval(c2,c1,**k)
> Basically, in the design you suggested you introduced relationships
> between c2 and c1, but also between c2 and k1, between c2 and v1, (and
> between c1 and k in the case of removal).
> Here, I am wondering if an alternative design that capitalizes on the
> notion of involvement that we introduced in the OWL ontology would be
> better.
> The idea is to have two binary object properties:
> wasObtainedAfterInsertion and wasObtainedAfterRemoval (there may be other
> better names) between the collections c1 and c2, and to specify information
> about the key k1 and value v1 (or the key k in the case of removal), using
> involvement.
> For example, we can have two classes RemovalInCollection, and
> InsertionInCollection, which can be defined as subclasses of
> CollectionInvolvement, which in turn is a subclass of Involvement. And this
> involvement classes will have object properties that point to the key and
> values.
> So now the question is why I think this design is better. If I am not
> wrong, a binary property between two collections c1 and c2, can capture all
> the information we need about insertion or removal. To illustrate this,
> consider that we have:
> wasObtainedAfterRemoval(c2,c1)**.
> Given c1 and c2, we can deduce the entries of c1 that were removed to
> obtain c2.
> Similarly, if we have:
> wasObtainedAfterInsertion(c2,**c1)
> Then we can deduce information about the pair of <key,value> that were
> inserted in c1 to obtain c2.
> In other words, binary properties would be enough to express all what we
> want for insertion/removal in collections. And if we want to specify
> explicitly the information that, we can infer otherwise, then we can use
> involvement.
> Please take the above proposal with a pinch of salt, as I may have got it
> completely wrong :-)
> khalid
> On 22/02/2012 15:04, Stian Soiland-Reyes wrote:
>> Hi,
>> I've tried to do a first take on collections:
>> http://www.w3.org/2011/prov/**wiki/ProvRDF#Collections<http://www.w3.org/2011/prov/wiki/ProvRDF#Collections>
>> I'm not very decided on this, and open for directions and ideas. I've
>> not added it to the OWL, but the ProvRDF page should hint at what
>> subproperties/subclasses are intended.
>> Note that the DM section on Collections still need a fair bit of work
>> which I should raise as new issues. (I'll close the old ones that are
>> now fixed, such as EmptyCollection).
Received on Thursday, 23 February 2012 08:26:23 UTC

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