Re: Collections in PROV-O

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