Re: Collections in PROV-O

Jun

> 1/ the containment relationship between two entities, i.e A contained by B.

I take your suggestion as the need to have an additional explicit containment relationship. In fact this existed in earlier drafts, 
if I remember correctly.

But Stian's rendering is not valid exactly because he is ab-using the insertion mechanism by omitting the key. To me this is 
"scruffy". I could do the same in ASN:
CollectionAfterInsertion(c1, c, "k1", v1)
where I mint "k1" for the purpose.

Either we introduce an extra relation for containment (and think through how it plays out with the current state update framework), 
or we use the current framework "properly".  The framework states that the only way you can /achieve/ containment of A into B is by 
asserting that A was added to B. Containment is a consequence of this.

BTW 1: I don't see why having literal keys is a problem. I may be missing it. Nesting is accommodated by having values which are 
Entities (of type prov:Collection).

BTW 2: when did prov:Container start to be used for collections?

--Paolo



On 2/23/12 3:29 PM, Jun Zhao wrote:
> 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).
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
-----------  ~oo~  --------------
Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org
School of Computing Science, Newcastle University,  UK
http://www.cs.ncl.ac.uk/people/Paolo.Missier