- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 07 Jun 2012 10:15:22 +0100
- To: public-prov-wg@w3.org
Thanks for adding this point, Paolo. Luc On 06/07/2012 10:06 AM, Paolo Missier wrote: > 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? >> > > -- 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 Thursday, 7 June 2012 09:15:58 UTC