Re: Dictionary/Collection: where are we?

Luc,

this is a good summary and as I have stated in the past, I see no problems with 1-10.
My understanding of the OWA/CWA issue is that it only comes into play when one tries to incorporate _new_ knowledge into an existing 
set of provenance statements, which affects collections because they are the only costruct that carries state (so your new 
statements mau change your knowledge of what you knew about was the state). But because of (7) and (8) below, this reduces to 
whether one can have multiple insertions/removal assertions about the same collection, but this is already forbidden: 
http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#collection-unique-derivation

So I would just go with option 1 below

-Paolo




On 6/7/12 8:59 AM, Luc Moreau wrote:
> Dear all,
>
> We have had multiple threads discussing collections lately.
> I would like to summarise what collections currently are in prov-dm, and check whether it's still what people want.
>
> 1. A notion of EmptyDictionary:  it's complete knowledge, no future knowledge can change its empty nature
>
> 2. A relation insertion that completely list pairs to be added to a  dictionary, with an update semantics.
>
> 3 A relation removal that completely lists keys of pairs to be removed from the dictionary
>
> 4. The property that the state of a dictionary is computable: given a complete knowledge of a dictionary, any sequence of 
> insertion/removal leads to a dictionary whose state can exactly be computed.
>
> 5. Incomplete knowledge of a dictionary state can be modelled  by not specifying the initial state of a dictionary (see d1,d2 in 
> example http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#example_53) or by introducing derivations (see c2 in 
> example http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#collections-and-derivation)
>
> 6 so far, no mention of membership relation!
>   So, if there are issues regarding CWA, they need to be discussed for the above.
>
> 7. Membership defined, in this context, as a convenience notation for an insertion operation into an unspecified dictionary.
> See  constraint 38 in prov-constraints 
> (http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#membership-as-insertion).
>
> 8. Complete membership defined, in this context, as a convenience notation for an insertion operation into an empty dictionary.
>
> 9. There was a request to disallow complete membership. Given that this is just a convenience notation, it's unclear why we do 
> this? 1, 2, 3, 4 are all about complete knowledge of a dictionary state.
>
> 10. Prov-dm define a type prov:collection but NO relation that applies to it.
>
> 11 a further point was discussed: can we specify a membership relation for collections. given point 4 above, the axiomatisation of 
> dictionary requires comparison of its members. It's ok for dictionaries, since we compare keys. It's unclear how we can make this 
> compatible with a membership for a collection of entities.
>
> Where does it leave us?
>
> 1. Do we want to allow dictionaries for which we have complete knowledge of the contents?
> 1.1 if yes, what's the point of removing the complete flag
> 1.2 if no, .... Go back to drawing board for dictionaries ....
>      ... Realistically, that looks like the final nail ...
>
> 2. If we have specified dictionaries and their relations, then do we need to specify some relations for collections?
>


-- 
-----------  ~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

Received on Thursday, 7 June 2012 09:06:31 UTC