- From: Michael Schneider <schneid@fzi.de>
- Date: Fri, 18 Nov 2011 20:30:31 +0100
- To: <public-rdf-dawg-comments@w3.org>
- CC: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Dear SPARQL Working Group, I am happy with the removal of the fixed datatype map, as well as with the new policy of requiring systems to tell which datatype map they use. I acknowledge that my comment has been answered. Best regards, Michael Am 20:59, schrieb Birte Glimm: > Michael, > > Thank you for your comment about the SPARQL Entailment Regimes document. > > The WG has considered your comment and the D-Entailment Regime has > been changed to no longer prescribe a fixed datatype map. Instead, > systems are required to provide a means to determine which datatype > map they use, e.g., by stating that in the system documentation. The > only requirement is that a canonical mapping must be defined, which is > needed to ensure finiteness of the answers. > > The current editor's draft is available at: > http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml > > We would be grateful if you would acknowledge that your comment has > been answered by sending a reply to this mailing list. > > Birte, on behalf of the SPARQL-WG > > On 26 July 2011 16:30, Michael Schneider<schneid@fzi.de> wrote: >> 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 Friday, 18 November 2011 21:19:10 UTC