W3C home > Mailing lists > Public > public-rdf-comments@w3.org > October 2013

Re: Comments on Last-Call Working Draft of RDF 1.1 Semantics

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 23 Oct 2013 11:10:54 -0500
Cc: Guus Schreiber <guus.schreiber@vu.nl>, "public-rdf-comments@w3.org Comments" <public-rdf-comments@w3.org>
Message-Id: <C9AC13D4-8B06-4DAE-B8B8-A000E383B331@ihmc.us>
To: Michael Schneider <schneid@fzi.de>
Michael, greetings. 

This is a response to your comments on RDF 1.1 Semantics, recorded by the RDF WG as ISSUE-165 and ISSUE-166. I will deal with ISSUE-165 first and the various parts of ISSUE-166 in-line, below.

Regarding ISSUE-165, this matter was debated extensively within the WG, and most of your points were made during this discussion. (see http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0085.html and subsequent threads.) The primary reason for the change was to simplify the presentation of the RDF semantics, which was an overarching goal of the WG. The actual mathematics has not altered, as the 2004 semantics required D-interpretation mappings to conform to the datatype map, so the datatype map is simply a part of (a restriction of) the interpretation mapping itself. Once this is recognized, it is clearly simpler to treat it in this way rather than as a separate mapping. In addition, it had been noted by several commentors that the 2004 definitions allowed for 'pathological' D mappings, such as one which permutes the meanings of the XSD datatype IRIs. It was felt that disallowing such maps was a laudable by-product of the change. We also note that this change does not alter any entailments.

In response to your comment, I have extended the Change Note in section 7 (and moved it to section 7.1) so that it reads as follows:

"In the 2004 RDF 1.0 specification, the semantics of datatypes referred to datatype maps. The current treatment subsumes datatype maps into the interpretation mapping on recognized IRIs. The <dfn>datatype map</dfn> corresponding to D is exactly the restriction of a <a>D-interpretation</a> mapping to the set D of <a>recognize</a>d datatypes. The 2004 definitions permitted "non-standard" datatype maps (such as one that maps the IRI '<code>http://www.w3.org/2001/XMLSchema#decimal</code>' to the datatype identified by <code>http://www.w3.org/2001/XMLSchema#gYearMonth</code>). Semantic extensions based on such non-standard mappings are not sanctioned by this specification."

As you will see, this provides a linkable definition of the term "datatype map" in terms of the new specification, as well as giving more explanation and motivation for the change. 

The WG realizes that you may still have concerns regarding this issue. If you feel it would be useful, we invite you to attend a WG teleconference to discuss this issue in more depth. 

Regarding ISSUE-166, we have made several changes in response to some of your points, as listed below.

> NON-URGENT ISSUES (NOT DESIGN-RELATED):
> 
> * 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 have made this edit, with a reference added:

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.

Reluctantly agreed. I have added all the missing "simply"s.
> 
> * 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 (deliberately) 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 have also clarified 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"

Done
> 
> * 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.

NOT REQUIRED is not an RFC 2119 defined phrase. However, after discussion, we have put REQUIRED itself into a non-normative lowercase. 

> 
> * 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. It has been added.
> 
> * 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.

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

OWL2-SYNTAX was an error, now fixed. RDF-PLAIN-LITERAL is normative because it is used normatively withing the document. (Section 7.)

Please reply to public-rdf-comments@w3.org indicating whether this is an adequate response to your comments.

Pat Hayes (for the RDF WG)

> 
> Best regards,
> Michael Schneider
> 
> 
> 

------------------------------------------------------------
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 16:11:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 23 October 2013 16:11:34 UTC