- From: James Cheney <jcheney@inf.ed.ac.uk>
- Date: Mon, 15 Apr 2013 11:45:38 +0100
- To: Tom De Nies <tom.denies@ugent.be>
- Cc: Provenance Working Group <public-prov-wg@w3.org>
- Message-Id: <1FF04FA8-6A4C-4FB9-99E4-3ED238E515AC@inf.ed.ac.uk>
('binary' encoding is not supported, stored as-is)
I don't think it was discussed. I don't have an objection, but haven't had a chance to think about it very hard. Either way, I suggest flagging this as a point to revisit if there is any future activity on this (e.g. formalization). That is, if you remove a constraint that you think should be implied, please mention it in a remark as something that should be checked later. If you leave it in, leave a remark saying that it appears redundant (which would mean that implementations can skip it). --James On Apr 15, 2013, at 10:49 AM, Tom De Nies <tom.denies@ugent.be> wrote: > I would have liked some feedback on this before we implement it. Any thoughts? > Was anything said about this during last week's telecon? > Thanks. > - Tom > > > 2013/4/11 Tom De Nies <tom.denies@ugent.be> > Small correction, we need to have enough to guarantee that insertions and removals do not introduce or remove any key-entity pairs, other than those specified. > > I think the two proposed constraints are sufficient for this, unless I'm missing something. > > 2013/4/11 Provenance Working Group Issue Tracker <sysbot+tracker@w3.org> > PROV-ISSUE-660 (TomDN): Constraints of PROV-Dictionary [PROV-DICTIONARY] > > http://www.w3.org/2011/prov/track/issues/660 > > Raised by: Tom De Nies > On product: PROV-DICTIONARY > > Luc raised some interesting ideas for the constraints. > > Note that we now have this inference: > https://dvcs.w3.org/hg/prov/raw-file/default/dictionary/Overview.html#membership-insertion-membership-inference > Inference D4 (membership-insertion-membership) Here, KV1 is a set of key-entity pairs and K1 is the key-set of KV1. > 1. IF prov:hadDictionaryMember(d1, e, k) and prov:derivedByInsertionFrom(d2, d1, KV1) and k ∉ K1 THEN prov:hadDictionaryMember(d2, e, k) > 2. IF prov:hadDictionaryMember(d2, e, k) and prov:derivedByInsertionFrom(d2, d1, KV1) and k ∉ K1 THEN prov:hadDictionaryMember(d1, e, k) > > (2nd part suggested by Luc) > I do have one immediate question: do we introduce an infinite loop by doing this? (consequent of 1. appears in antecedent of 2., and vice versa) > Or is this covered by http://www.w3.org/TR/prov-constraints/#overview ? > > This got me thinking. If we have this, do we really need Inference D8? https://dvcs.w3.org/hg/prov/raw-file/default/dictionary/Overview.html#insertion-removal-membership-inference > > Couldn't we just specify the same constraint as D4, but for removal? > Suggestion: > Inference D... (membership-removal-membership) Here, K1 is a set of keys. > 1. IF prov:hadDictionaryMember(d1, e, k) and prov:derivedByRemovalFrom(d2, d1, K1) and k ∉ K1 THEN prov:hadDictionaryMember(d2, e, k) > 2. IF prov:hadDictionaryMember(d2, e, k) and prov:derivedByRemovalFrom(d2, d1, K1) THEN prov:hadDictionaryMember(d1, e, k) > Note that in the second case, k ∉ K1 is always true, otherwise constraint D9 is violated. > > Do we then have enough to guarantee that insertions and removals do not introduce any new key-entity pairs, other than those specified? (which is why we had Inference D8) > I think so, so I'd like to propose this solution. Could we have your support or objections via mail or on today's call? > > Regards, > Tom > > > > > > > > >
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Received on Monday, 15 April 2013 10:45:59 UTC