- From: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Date: Wed, 26 Sep 2012 16:47:06 +0100
- To: James Cheney <jcheney@inf.ed.ac.uk>
- CC: W3C provenance WG <public-prov-wg@w3.org>
Hi James, Response interleaved. On 09/26/2012 04:37 PM, James Cheney wrote: > Hi, > > This seems like a good idea. Some pedantic suggestions: > > - There is a MUST in section 6 and SHOULD in section 7 - if these sections are not normative then this is confusing. The MUST constrains extensions to PROV, while the SHOULD restates something that is said in PROV-CONSTRAINTS, so I think both can be restated to avoid over-specification. well spotted: I think it is safe to rephrase these statements. > > - I think everything that could be considered normative in section 2 is restated (in more detail) in section 5. If both sections are normative, then it there is greater possibility of confusion. I thought section 2 was a summary or overview. That being the case, I suggest it could be left as informative. Or, we should specify which part is definitive in case of an apparent inconsistency. I considered this. However, that's where we really introduce core/expanded. > - Appendix A is basically just a table expressing the links between PROV-DM concepts and their expressions in PROV-N and PROV-O. Since we do not formalize anything further about how PROV-N and PROV-O interrelate (and we've placed this out of scope AFAIK), I don't see what is normative here, so I think this can also be left informative. Any other view on this? > > - It is not stated whether figures 2,3,4 are normative. I assume that fig. 2, 3 are not normative since they are in non-normative sections. Fig. 4 doesn't seem to have any normative content (it just illustrates the six components in an abstract way), so I suggest that it would be safe to state that all of the figures (including UML diagrams) are purely informative. Or, if there are figures with normative content, we should identify them. agreed, fig 4. can be informative. > > - To avoid confusion, perhaps all non-normative sections could be explicitly marked "informative", so that their status is clear to someone who links into the document without reading the compliance section. A related, even more pedantic suggestion is to state that the compliance section itself is normative. Yes, respec.js can take care of that. Luc > > --James > >> On Tue, Sep 25, 2012 at 5:57 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote: >>> Dear all, >>> >>> In his review of prov-dm (ISSUE-495), Ivan asked which sections were >>> normative. >>> I propose to introduce the following section >>> >>> 1.1 Compliance with this document. >>> >>> For the purpose of compliance, the normative sections of this document >>> are sections 2 and 5, and appendix A. Information in tables is >>> normative if it appears in a normative section. UML diagrams (figure 1, >>> 5, 6, 7, 8, 9, 10, 11) are informative. Text in boxes labeled "Example" >>> is informative. >>> >>> Do we have support for this? >>> >>> Luc >>> >>> >>> -- >>> 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 >>> >>> >>> >> >> >> -- >> -- >> Dr. Paul Groth (p.t.groth@vu.nl) >> http://www.few.vu.nl/~pgroth/ >> Assistant Professor >> - Knowledge Representation & Reasoning Group | >> Artificial Intelligence Section | Department of Computer Science >> - The Network Institute >> VU University Amsterdam >> >> > -- 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 Wednesday, 26 September 2012 15:47:44 UTC