W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > July 2011

LC Comment on Entailment Regimes: D-Entailment Datatype Map

From: Michael Schneider <schneid@fzi.de>
Date: Tue, 26 Jul 2011 16:30:20 +0200
Message-ID: <4E2ECF7C.8020704@fzi.de>
To: <public-rdf-dawg-comments@w3.org>
Dear all!

Document: SPARQL 1.1 Entailment Regimes
State: LCWD

The D-Entailment regime comes with a considerable set of XSD datatypes 
(23 datatypes). It is stated that a datatype map for the D-entailment 
regime MUST contain at least all the datatypes in the set.


I propose to drop the normative requirement that any D-regime must come 
with the given set of datatypes. I would even consider dropping the list 
completely, or at least make it just a kind of "primus inter pares example".


* Neither the requirement to have such a list of datatypes included in 
the datatype map of a D-regime, nor the concrete list of datatypes is 
motivated anywhere in the specification; this requirement appears to be 

* The concrete datatype map in the specification document is different 
from all of the datatype maps in other existing specifications on which 
SPARQL 1.1 depends: the RDF specification, the OWL 2 specification 
(Direct/DL and

    * Compared to OWL 2 (Direct and RDF-Based), the
      D-entailment regime spec additionally contains
      "xsd:date" and "xsd:time" (compare Chap 4 in [2],
      and Table 3.3 in [3]). There is a good reason not
      to have these datatypes in the OWL specs, as they
      don't allow to specify unique points on a time line,
      so it is not possible for two given datavalues to
      decide whether they are equal or not, or whether
      one represents a larger value than the other, or a
      smaller (e.g., compare the times "12:00" and "8:00":
      they may be from the same day, or from different days.)

    * In the RDF Semantics spec [1], Chap 5, there
      is an example datatype map, but it is different.
      For example, it contains the datatype
      xsd:gYear, which is not included in the
      D-Entailment Regime spec, while the latter
      includes rdf:PlainLiteral, which is not in
      the RDF Semantics document.

    * The XSD datatypes in the RDF Semantics are /not/
      normative, but are only an example datatype map
      with a specifically defined name: the
      "XSD datatypes". Neither the normative definition
      of the term "D-interpretation" that refers to the
      "General semantic conditions for datatypes"
      (Sec. 5.1), nor the normative definition of the
      terms "D-entails" (Sec. 5.2) uses the XSD datatype
      map. In fact, the only required datatype in a
      D-entailment datatype map is rdf:XMLLiteral,
      because it is already defined in RDFS entailment.

* Requiring support for all these datatypes might be a heavy burden on 
implementers. System providers might be happy with only implementing 
plain RDFS plus, for example, xsd:string, xsd:integer and 
rdf:XMLLiteral, to provide some added value for their users, but this 
would then be by far not a
compliant system w.r.t the D-entailment regime.

My personal understanding of D-entailment, as specified in the RDF 
Semantics [1], has always been that it provides the basic - purely 
technical - semantic framework for creating specifications with 
datatypes on top of purely logic-based RDFS reasoning (or beyond), 
without itself providing concrete datatypes (beyond the one that is 
already defined by RDFS itself). For example, the notion of an OWL 2 
RDF-Based interpretation (see Chap. 4 of [3]) is based on top of 
D-Entailment, and only this specific semantics adds a certain set of 
normative datatypes. (Actually, said specification even extends 
D-entailment to include so called "facets" first, but without adding any 
further datatypes, so if SPARQL would go for adding datatypes to "plain" 
D-entailment, and not to D with facets, there would be a heavy split in 
normative SemWeb specifications). I never understood D-entailment as 
being targeted as a practical entailment regime itself, and I would 
recommend not to go beyond this idea in any derived standard, s.a. 

[1] <http://www.w3.org/TR/2004/REC-rdf-mt-20040210/>
[2] <http://www.w3.org/TR/2009/REC-owl2-syntax-20091027>
[3] <http://www.w3.org/TR/2009/REC-owl2-rdf-based-semantics-20091027>

Best regards,

Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schneider@fzi.de
WWW  : http://www.fzi.de/michael.schneider
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Dipl. Wi.-Ing. Michael Flor, Prof. Dr. rer. nat. Ralf Reussner,
Prof. Dr. rer. nat. Dr. h.c. Wolffried Stucky, Prof. Dr. rer. nat. Rudi 
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
Received on Tuesday, 26 July 2011 14:30:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC