W3C home > Mailing lists > Public > public-sparql-dev@w3.org > January to March 2015

Re: Wikidata, SPARQL Y0K Problem

From: james anderson <james@dydra.com>
Date: Fri, 27 Mar 2015 14:39:11 +0000
Message-ID: <0000014c5bac291f-f16e44df-5eb5-432a-a61d-a9f2fe4be9c7-000000@eu-west-1.amazonses.com>
To: public-sparql-dev@w3.org
good afternoon;

On 2015-03-27, at 14:53, Markus Kroetzsch <markus.kroetzsch@tu-dresden.de> wrote:

> Hi Andy, hi Birte,
> Thanks for the swift replies. I will carefully try to consolidate your answers to a consistent view (which I hope you will agree with). You said two important things:
> > The D-Entailment Regime explicitly refers to XSD 1.1.
> That's true, and this is a normative reference in the normative part of the specification [1]. Therefore, it seems clear that SPARQL 1.1 implementations that support datatype semantics should accept year "0000" and understand it as 1 BC.
> > SPARQL refers to XSD Schema 1.0
> This is also true, and again the reference is normative [2]. It seems from the sentence where this reference is used that the IRI xsd:dateTime refers to the datatype of XSD 1.0, but Andy offered an alternative reading: "because XSD 1.1 does not change the URI for datatypes or functions, it's sort of an "upgrade in place"." In any case, this section only refers to the meaning of literals when used as operands in FILTER functions/operators.
> Some things are immediately clear from these observations. In particular, no SPARQL 1.1 processor should ever reject the year "0000" in the input data or BGP.

in terms of strict conformance, no sparql processor can reject any rdf term — even terms which are not lexically valid and any distinctions between sameTerm
on the other hand, a processor may deem them invalid as arguments to operators other than sameTerm, which is the basis for bgp processing.

> Either the processor uses simple entailment (then "0000" is just a string) or the processor supports D-entailment (then "0000" must be interpreted as per XSD 1.1). This is reassuring.
> In the case of FILTERs, there seems to be some leeway for interpretations. In either case, there is no contradiction with D-entailment, since D-entailment is only about BGPs while the XSD 1.0 reference is only used in a section about FILTERs.

which means, in the context of a filter constraint - or any other expression which involves function application, where a temporal term’s value semantics matter, it would be appropriate to agree on the library which would be to serve as the conformance measure for any extensions, in order to provide a consistent interpretation across all temporal domains.
in this regard, given the existence of version three of "XPath and XQuery Functions and Operators”, that provides the reasonable standard for any extensions.
as this version three, in turn, references xsd 1.1, that appears to be the semantics to look for going forward and we decided to adopt that for our temporal extension implementation. 

best regards, from berlin,
james anderson | james@dydra.com | http://dydra.com
Received on Friday, 27 March 2015 14:39:42 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 March 2015 14:39:42 UTC