- From: Michael Schneider <schneid@fzi.de>
- Date: Tue, 26 Jul 2011 16:30:20 +0200
- 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. Proposal -------- 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". Rational -------- * 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 arbitrary. * 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 RDF-Based/Full: * 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. SPARQL 1.1. [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, Michael -- 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 Studer Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus ==============================================================================
Received on Tuesday, 26 July 2011 14:30:49 UTC