comments re issue-166

My responses to all the 'easy' suggestions by Michael are in-line below.

Issue-165 will be handled separately.

I have a version of the document ready to commit with all the needed edits made, when/if the WG agrees.


* §3: The chapter introduces the term "entailment regime",
   but does not say much about it. As this term is also
   introduced and quite intensively used in the SPARQL 1.1 spec
   (in particular by the SPARQL Entailment Regimes spec), I
   suggest to be a little more elaborate on the term, in order
   to avoid that the terms are not understood differently in
   the contexts of the two specifications.

Good point. I suggest making this edit:

Each semantic extension defines an entailment regime (used here in the same sense as in the SPARQL 1.1 Entailment Regime recommendation [SPARQLENTAIL]) of entailments which are valid under that extension. 


* §4, 2nd par: I would change the order of "referent and
   denotion" to "denotion and reference" to match the order
   of the two corresponding terms mentioned earlier in the text:
   "denotes and refers to".

Agreed, done.

* §5.3 (and for other entailment regimes as well): I suggest
   to always be explicit on the entailment regimes, when it
   comes to the terms "satisfies", "entails", etc. So it should
   always be "simply entails", or "RDF entails", instead of only
   "entails", even if this may be obvious from the context (it
   probably isn't for everyone). After all, these are definitions
   and should be as precise as possible.

Sigh. OK, all the 'simply's added.

* §5.3: the "Technical Note" on not defining entailment
   between graphs is in fact also a Change Note, and should
   be marked as such in addition.

It is impossible to style something both as a technical and a change note. In fact this is not a change, strictly speaking, since the text simply does not provide the definition (of entailment by a set of graphs) which would have been changed. 

* §5.4: The Simple-semantics theorem "Every graph is
   satisfiable" is followed by the statement that "this
   does not hold for extended notions of interpretation".
   This text should be modified to say that it does not
   _always_ hold for extended notions of interpretation.
   One could still construct some extended notion where
   it does hold, although not for any of the extended
   notions in the RDF 1.1 Semantics.

Agreed, done.

* §5.4, Technical Note: I recommend to remove the claim about
   graphs containing many bnodes that this is "unlikely to
   occur in practice". Actually, it is relatively common,
   namely for OWL documents with many Boolean class expressions
   when serialized in RDF, because for a union or intersection
   class expression, the number of bnodes is proportional to the
   number of classes occuring in the class expression.
   Apart from this concrete case, an assumption of the given kind
   has in my opinion no place in a spec document, specifically
   not within a technical note.

Fair point. I will also clarify the oddity of Jeremy's construction by changing "many bnodes" to "only bnodes". 

* §7, 1st par: typos:
   - "... which datatype is identifier by..." should probably
     say "identified"
   - "... and should treat any literals type": probably
     "typed literals"

Both fixed.

* §7, 2nd par: Why does the text not refer to the term
   "lexical space", which is introduced in the RDF 1.1 Concepts
   document and has been used in the original RDF Semantics
   (and other standards as well)? In the given form, I see no
   reason for the term's omission, and the text reads rather
   awkward without a direct reference to the lexical space.

Fair point. The text is now edited to use "lexical space", as follows:

 A datatype is understood to define a partial mapping, called the <dfn>lexical-to-value mapping</dfn>, from a lexical space (a set of character strings) to values. The function <dfn>L2V</dfn> maps datatypes to their lexical-to-value mapping. A literal with datatype d denotes the value obtained by applying this mapping to the character string sss: L2V(d)(sss). If the literal string is not in the lexical space of the datatype, so that the lexical-to-value mapping gives no value for the literal string, then the literal has no referent. 


* §7, 3rd par: "RDF processors are not REQUIRED". The word
   "not" should also be written in uppercase to avoid
   misconception while reading the text.

ReSpec uses strict RFC 2119 rules, and 'NOT REQUIRED' is not a defined phrase in RFC 2119.

* §8: Why is there no table presenting the "RDF Vocabulary"?
   The RDFS chapter provides such a table, and the original
   RDF Semantics did so as well. It would be useful, at least.

Good point. I have added it.

* Appendices: Several of the appendix titles contain the text
   "(Informative)", directly followed by the sentence
   "This section is non-normative". This is redundant. I suggest
   to remove "(Informative)" from the titles, in accordance
   with the rest of the document.

This is kind of tedious, but there is a reason for it. The italicised sentence is added by ReSpec, but we think it desirable to have the table of contexts clearly indicate normativity and its lack, hence the inclusion of the bracketed qualifier in the section titles. I prefer to keep this for extreme clarity even if it is kind of silly. 

* Appendix D: I don't see a reason to repeat the "non-normative"
   declaration for the appendix in each of its sub-sections.

? In the version I see, they aren't so repeated.

* Appendix D.2, vocabulary table: I suggest to add the additional
   RDFS terms for the container vocabulary as well.

Agreed, done. 

* References: I do not understand why the following documents
   are listed as "normative references":
   - OWL2-SYNTAX
   - RDF-PLAIN-LITERAL

Um, neither do I. Does the WG have any guidance on what the rules are here?

Pat



------------------------------------------------------------
IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 23 October 2013 05:03:58 UTC