- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 25 Apr 2012 10:08:04 +0100
- To: Provenance Working Group WG <public-prov-wg@w3.org>
I have closed this issue, as PROV-CONSTRAINTS now says: "PROV-DM does not provide an interpretation for descriptions that consist of two (or more) insertion, removal, membership relations that result in the same collection." On Wed, Feb 22, 2012 at 15:49, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote: > This issue is still open, as DM is currently almost contradicting > itself on functionality. I've marked this as an issue in [1]: > > >> One can have multiple assertions regarding the state of a collection following a set of insertions, for example: > CollectionAfterInsertion(c2,c1, k1, v1) > CollectionAfterInsertion(c2,c1, k2, v2) > ... > This is interpreted as " c2 is the state that results from inserting > (k1, v1), (k2, v2) etc. into c1 > > >> Both relations are functional, in the sense that they represent a state change following a unique insertion/removal operation (or a unique set of them). Thus, from the pair of assertions: > CollectionAfterInsertion(c, c1, k1, v1) > CollectionAfterInsertion(c, c2, k2, v2) > one can infer: c1==c2, k1==k2, v1==v2, because one cannot have two > different derivations for the same final collection state. > > > We have to decide on one of these. My feeling is that it should be > functional on all parameters, because otherwise the open-world > assumption means there could also be an unknown additional > insertions/deletions between c1 and c. (This touches on ISSUE-137 > [2]). > > > However, this then leaves ISSUE-138 open for how to represent multiple > insertions/removal. See separate email about this. > > > > > [1] http://dvcs.w3.org/hg/prov/raw-file/tip/model/ProvenanceModel.html#record-Collection > [2] http://www.w3.org/2011/prov/track/issues/137 > [3] http://www.w3.org/2011/prov/track/issues/138 > > > > On Sun, Oct 30, 2011 at 00:18, Provenance Working Group Issue Tracker > <sysbot+tracker@w3.org> wrote: >> >> PROV-ISSUE-136 (collection-functional): Collection not stated as functional [Data Model] >> >> http://www.w3.org/2011/prov/track/issues/136 >> >> Raised by: Stian Soiland-Reyes >> On product: Data Model >> >> http://www.w3.org/TR/prov-dm/#expression-Collection introduces relations for expressing collection addition by using three statements >> >> wasAddedTo_Coll(c2,c1) >> wasAddedTo_Key(c2,k1) >> wasAddedTo_Entity(c2,e1) >> >> Saying that c2 is the content of c1 - but with e1 added under the key k1. >> >> It is not stated that the relations are functional - thus it would be valid to also say *for the same collection c2*: >> >> wasAddedTo_Key(c2,k2) >> wasAddedTo_Entity(c2,e2) >> >> >> But now assuming order of assertions in PROV-ASN don't matter - we don't know if it is (k2,e2) and (k1,e1) that was added, alternatively (k1,e2) and (k2,e1). >> >> >> My rough interpretation is that these assertions are meant to be functional - so that you can only add one key->entity at a time. If this is true, it should be stated in PROV-DM. >> >> If it is not - then a different way to associate the key to the value is needed, like a new "CollectionEntry" entity with attributes "key:, "value" and possibly "collection". >> >> >> > > > > -- > Stian Soiland-Reyes, myGrid team > School of Computer Science > The University of Manchester -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Wednesday, 25 April 2012 09:08:58 UTC