revised prov-dm-constraints

('binary' encoding is not supported, stored as-is)
I have updated the constraints document and it is (for the moment) available here:

[Luc, if it should be moved somewhere else let me know and I'll readvertise it]

For comparison, the old version is still available:

I may be able to do more work on it before Thursday, but probably not very much, hence I am advertising the revision now in order to give people time to have a look before the vote.  

My goal has been to address the higher-level issues about document structure and purpose, and reorganize / clarify without making significant changes to (what I understood of) what was there before. Accordingly, I have tried to write something that takes a particular tack, with which people may disagree.  There are also lots of potential inferences we could consider and that aren't in the document.  I've tried to avoid inventing things (with the main exception being the notion of equivalence, which I think is important for discussing validity.)

The discussions of accounts and provenance containers have been rearranged, but not substantially changed.  There are many flags where work is needed.  

I think the document can potentially be released with the caveat that it is much more "work in progress" than the others. 

Comments on review concerns: 

* James (mine): some issues remain from my review, but I've deprioritized spending time raising/discussing things like in favor of reorganizing the document into a form that can be released and commented on.

* Tim: I believe I have addressed most issues, except for point #41 (having links to constraints jump to the discussion text, not the constraint box).  This is doable but takes work, since the constraint ids are used as both name and anchor; we can do it later.

* Graham: My reorganization and revisions are aimed at providing one candidate answer to the questions raised by Graham's review.  However, in the process it is becoming very clear that there are a large number of points where I'm not sure what the consensus is because (e.g.) the role of constraints, inferences and so on hasn't really been discussed.  Moreover, I'm nto certain yet whether we need to add a feature to indicate "this is supposed to be valid provenance", or whether it is enough to say that applications MAY apply inferences, SHOULD validate (or generate valid provenance) and if so MUST apply the inferences.  

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Received on Tuesday, 17 April 2012 18:05:08 UTC