Re: Collections in PROV-O

Hi guys,

What if people don't have key-value pair for their collection structure? 
Instead, they just want to simply express that one entity is contained 
by another, like what we have in the Provenance Vocabulary:

A prv:containedBy B .

Can we express that in prov-o?

I don't need to express what element was deleted or inserted. I just 
want to express a containment and derivation relationship.

Can I do that?

Cheers,

-- Jun

On 23/02/2012 10:44, Khalid Belhajjame wrote:
> On 23/02/2012 08:25, Stian Soiland-Reyes wrote:
>
> No, this is very good reasoning, I like it.
>
> Great :-)
>
>
> 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?)
>
> Yes, that's what I had in mind. c2 will be derived from c1, whereas the key and value pair they will be qualified attributes of that derivation.
>
> Thanks, khalid
>
> 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<mailto: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
>
> 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 14:47:28 UTC