Re: Collections in PROV-O

Stian,

On 23/02/2012 15:26, Stian Soiland-Reyes wrote:
> 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 .

Thanks! That's all I need to know and to confirm. Nice to have the 
extras, but I didn't have requirements for them!
>
> 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).

SO, the DM people, why not? Do we want to lax it?

-- Jun


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

Received on Thursday, 23 February 2012 15:29:42 UTC