Re: Collections in PROV-O

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>
wrote:

> 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).
>>
>>
>>
>