Re: Collections in PROV-O

Hi Stian,
... and how would you represent this set without literal keys then?
I don't understand what the issue is.
Luc

On 02/24/2012 03:03 PM, Paolo Missier wrote:
> Stian
>
> agreed on making this an issue and discussing it further. Thank you 
> for elucidating the "impossible" cases, that's what I meant with "and 
> think through how it plays out with the current state update 
> framework"  :-).
>
> On this point:
>
>>> 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).
>> How would you represent this set of set of empty sets (ugh!) using 
>> literal keys?
>>
>> A = {
>>    { {}, {} }
>>    { {} }
>>    { }
>> }
> I think you have just taken the notion of "corner cases" to a whole 
> new level :-)
>
> --Paolo
>
>
>
> On 2/24/12 9:56 AM, Stian Soiland-Reyes wrote:
>> On Thu, Feb 23, 2012 at 15:59, Paolo 
>> Missier<Paolo.Missier@ncl.ac.uk>  wrote:
>>> 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
>> Yes, this is very scruffy. It is like saying X was generated by an
>> activity which used Y, but without identifying the activity. That's a
>> 'power' of RDF if you like, which would not be easily be mapped to
>> PROV-DM (unless we introduce an anonymous _ prefix, like in Turtle)
>>
>>
>>> 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.
>> But Jun might not know when A was added to B, she just observed that B
>> (that perhaps came out of a workflow activity) contained A - and
>> perhaps later she used A - and so we want to have a trace to say where
>> A came from. You can just say that A was derived from B (through a
>> get-from-collection kind of activity) - but that's not very
>> transparent.
>>
>> I can see two problems with allowing asserting of collection members:
>>
>> a) Users could say "impossible" things such as:
>>    A contained { (a,1), (b,2) }
>>    B was made by adding (c,3) to A
>>    B contained { (b,2), (d,4) }.
>>
>> b) In an open world assumption it might be hard to assert that the
>> members of A was x,y,z and nothing else. Other times one might
>> actually want to say it contained x,y,z AND possibly something else
>> (unknown). See RDF collections and the problem of 'closing' a list.
>> [2]
>>
>>
>> We should make collection member containment an issue/request.
>>
>> Jun - could you write it as an issue in the tracker and give a simple
>> usecase for when one would want to state containment?
>>
>>
>>
>>> 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).
>> How would you represent this set of set of empty sets (ugh!) using 
>> literal keys?
>>
>> A = {
>>    { {}, {} }
>>    { {} }
>>    { }
>> }
>>
>> You have to make up some keys. (I did the inner set members be empty
>> sets instead of literals {a,b,c} so you can't be tempted to say "We'll
>> call the first key "a_b_c" etc :) )
>>
>> Two asserters of provenance about modifications to this set could
>> generate totally different keys.
>>
>> If you use entities as keys, it's easy, as you just use the value as
>> the key. For bags (unordered, allows duplicates) you still have a
>> problem, and would probably have to resort to fresh random-id-assigned
>> entity for every key. RDF containers [1] uses rdf:_n for this purpose,
>> for instance
>>    :bag rdf:_5 :fifth .
>> (even if the bag is unordered)
>>
>>
>>> BTW 2: when did prov:Container start to be used for collections?
>> Sorry, I obviously meant prov:Collection :)
>>
>> [1] http://www.w3.org/TR/rdf-primer/#containers
>> [2] http://www.w3.org/TR/rdf-primer/#collections
>>
>>
>
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Friday, 24 February 2012 15:11:36 UTC