Re: LC Comment on Entailment Regimes: D-Entailment Datatype Map

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
> ==============================================================================
>
>



-- 
Dr. Birte Glimm, Room 309
Department of Computer Science
University of Oxford
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520

Received on Thursday, 10 November 2011 09:17:39 UTC