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

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