Re: Collections in PROV-O

If you want to express that B was *added* to A, yes, you can do that
in PROV-O (but not as easily in DM):

We don't care if :B is a Container or not - as long as it is a
prov:Entity it can be added.

:B a prov:Container .
:Abefore a prov:Container .
:AwithB a prov:Container ;
    prov:wasObtainedAfterInsertion :Bbefore ;
    prov:qualified [
        a prov:entity :Abefore ;
        prov:value :B .
        # prov:key _:unknown
] .


However you can't currently express that :A :contained :B .

In Prov-DM ASN this is harder because the syntax forces you to name
the key. In the suggested DM4 (Paolo?) the key is said to be a literal
rather than entity, making it even trickier, and making it impossible
to represent sets in my view (currently you can just use key==value).


On Thu, Feb 23, 2012 at 14:47, Jun Zhao <jun.zhao@zoo.ox.ac.uk> wrote:
> 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).
>>
>>
>>
>>
>
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Thursday, 23 February 2012 15:27:53 UTC