- From: Tom De Nies <tom.denies@ugent.be>
- Date: Thu, 28 Mar 2013 15:52:05 +0100
- To: James Cheney <jcheney@inf.ed.ac.uk>
- Cc: Paolo Missier <Paolo.Missier@ncl.ac.uk>, public-prov-wg@w3.org
- Message-ID: <CA+=hbbe9YCMge57XhEY7T64CKJWaJXXrepm_36raDitEZ6YUEw@mail.gmail.com>
I've pushed this to the editor's draft: https://dvcs.w3.org/hg/prov/raw-file/default/dictionary/Overview.html#dictionary-constraints-notation Note that I also made this consistent throughout the entire constraints. Issue is now pending review. Tom 2013/3/28 Tom De Nies <tom.denies@ugent.be> > Ok, then I propose to keep the current notation and include the suggested > explanation as a resolution to this issue. > > Perhaps we can vote on this during the telecon? > > Regards, > Tom > > 2013/3/26 James Cheney <jcheney@inf.ed.ac.uk> > >> Hi, >> >> I think the way the constraints are currently presented is fine. The use >> of equality seems appropriate, provided its meaning is made clear. But I >> wasn't on the last call - were there objections to it? The main potential >> complications are: >> >> - do we require keys in sets of key value pairs to be associated with >> unique values? This is stated in D2, so good. >> - do we allow "unknown" sets of key-value pairs, or of the existence of >> them? If so then reasoning about their equality could become complicated. >> However, we do not appear to need this, so equality of key / kv sets will >> always amount to checking literal equality of sets, not solving equations >> involving unknowns. >> - are sets of keys (or key-value pairs) considered equal up to >> reordering? e.g. {k1,k2} = {k2,k1}? Seems to be the case; including the >> suggested explanation somewhere would help cement this. >> >> These might have to be revisited if this were to be pushed further or >> incorporated into future versions of PROV, but as stated I think the >> existing constraints ought to fold into the existing framework neatly. >> >> Minor comment: >> >> D8: Suggest KV1 should be K1 (as it is just a set of keys, being removed) >> >> --James >> >> On Mar 22, 2013, at 12:20 PM, Tom De Nies <tom.denies@ugent.be> wrote: >> >> Hello James, Paolo, >> >> do you have any suggestions for a better notation of these constructs, or >> are you happy with the ones we have now? >> The main issue is that the current notation deviates from what is used in >> PROV-Constraints, and I'm not sure that we want that. >> I'd like to resolve this issue before the telecon of 28th of March, so we >> can release the document for internal review. >> >> Paul suggested during the telecon to use double equal signs '==' instead >> of a single '=', but I am not sure this solves the issue. >> >> Another proposal is to include an explanatory paragraph, stating the >> following: >> >>> In the constraints below, statements are made concerning the equality of >>> sets of key-value pairs and sets of keys. For the sake of clarity, we will >>> explain the used notations here. >>> 1. To state that a set of keys K1 and another set of keys K2 hold >>> exactly the same keys, we use the notation K1 = K2. >>> 2. To state that a set of key-value pairs KV1 and another set of >>> key-value pairs KV2 hold exactly the same keys, with each key in KV1 mapped >>> to exactly the same value as the same key in KV2, we use the notation KV1 = >>> KV2. >>> For example. the sets of keys {"k1", "k2"} and {"k1", "k3", "k4"} are >>> not considered equal, since one of the sets holds keys the other does not. >>> Analogously, the set of key-value pairs {("k1", e1),("k2", e2)} and the set >>> {("k1", e2),("k2", e3)} are not considered equal, since the keys in the >>> latter set map to different values than the same keys in the former set. >>> >> >> If you could share your view on this, that'd be great. >> Thanks in advance! >> >> regards, >> Tom >> >> @Paolo: in response to your example below, i'd say that in the case of >> >> derivedByInsertionFrom(d2, d1, {(3,e1)} ), >> derivedByInsertionFrom(d2, d1, {(4,e2)}) >> >> KV1=KV2 does not hold (since nor the keys, nor the values are equal), and thus, this is not valid. >> >> 2013/3/7 Paolo Missier <Paolo.Missier@ncl.ac.uk> >> >>> Hi, >>> >>> I went back to James' review and I am not sure what an inference that >>> derives KV1 = KV2 means, when KV1 and KV2 are ground. For example, what do >>> we make of >>> >>> derivedByInsertionFrom(d2, d1, {(3,e1)} ), >>> derivedByInsertionFrom(d2, d1, {(4,e2)}) >>> >>> ? >>> I think I need to understand this better >>> >>> --Paolo >>> >>> >>> >>> On 07/03/2013 10:45, Provenance Working Group Issue Tracker wrote: >>> >>> PROV-ISSUE-638 (TomDN): Notation of set of key-value pairs in contraints of PROV Dictionary [PROV-DICTIONARY] >>> http://www.w3.org/2011/prov/track/issues/638 >>> >>> Raised by: Tom De Nies >>> On product: PROV-DICTIONARY >>> >>> Came up in the review by James, but was agreed to be handled after the first WD release. >>> >>> We need to get consensus of the group whether the notation KV1=KV2 is acceptable for constraints D9, D10, D11, D12.4, and D12.5, and whether considering equalities on sets of keys/KV pairs is a potential complication.https://dvcs.w3.org/hg/prov/raw-file/default/dictionary/releases/WD-prov-dictionary-20130312/Overview.html#impossible-removal-insertion-constraint >>> >>> >>> >>> >>> -- >>> ----------- ~oo~ -------------- >>> Paolo Missier - Paolo.Missier@newcastle.ac.uk, pmissier@acm.org >>> School of Computing Science, Newcastle University, UKhttp://www.cs.ncl.ac.uk/people/Paolo.Missier >>> PGP Public key: 0x45596549 - key servers: pool.sks-keyservers.net >>> >>> >> >> >> >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> >
Received on Thursday, 28 March 2013 14:52:41 UTC