- From: Michael Schneider <schneid@fzi.de>
- Date: Tue, 22 Oct 2013 01:29:31 +0200
- To: "public-rdf-comments@w3.org Comments" <public-rdf-comments@w3.org>
Dear RDF Working Group!
This is my review of the Last-Call Working Draft of the
"RDF 1.1 Semantics" specification.
I like to repeat that I wasn't able to finish my review in the
very short given time since the announcement of the LCWD
as of 3 October, and that I have a strong stake on this document.
As for my review of the "Concepts and Abstract Syntax" LCWD,
I have created the review for the most-current Editor Draft,
available at
<https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html>
In general, I am quite pleased with this document, even with most
of the deliberate changes being made to the original RDF Semantics,
and most of my comments are only about small details, and are not
design-related (and can thus be, in principle, be dealt with later
in the context of the upcoming CR). However, there is a single,
design-related, issue which I consider urgent (as for to be
treated in the context of the Last-Call phase), and important.
URGENT ISSUES (DESIGN-RELATED):
* §7: The notion of a "datatype map" has been effectively
replaced by a new notion of "recognized IRIs". No further
explanation is being given for this change. I have to note
that the notion of datatype maps has been used and is
deeply integrated in several of the other core Semantic Web
specifications: SPARQL 1.1 (in the SPARQL Entailment
Regimes spec), OWL 2 (specifically in the RDF-Based Semantics),
and RIF (in the RDF-and-OWL Compatibility spec), and it is
probably generally in quite wide use, for example in many
scientific papers and books. I believe the notion of a
datatype map as very basic and relevant for the stack of
semantics specifications that are based on the RDF Semantics
spec. In addition, I have never encountered any bigger problem
with this notion, even though I have been highly involved with
it during the years, in particular in my work as the editor
of the OWL 2 RDF-Based Semantics. So under these circumstances,
I consider this change harmful for the foundation of the Semantic
Web, and with the lack of any rational the change even appears
to me to be an arbitrary choice. In my opinion, it goes too far
for a "1.1-style revision" of the RDF specification. In summary,
I cannot accept this change and ask the WG to bring back
the old notion of a datatype map.
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.
* §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".
* §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.
* §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.
* §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.
* §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.
* §7, 1st par: typos:
- "... which datatype is identifier by..." should probably
say "identified"
- "... and should treat any literals type": probably
"typed literals"
* §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.
* §7, 3rd par: "RDF processors are not REQUIRED". The word
"not" should also be written in uppercase to avoid
misconception while reading the text.
* §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.
* 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.
* Appendix D: I don't see a reason to repeat the "non-normative"
declaration for the appendix in each of its sub-sections.
* Appendix D.2, vocabulary table: I suggest to add the additional
RDFS terms for the container vocabulary as well.
* References: I do not understand why the following documents
are listed as "normative references":
- OWL2-SYNTAX
- RDF-PLAIN-LITERAL
Best regards,
Michael Schneider
Received on Monday, 21 October 2013 23:29:56 UTC