search

w3c / rdf-tests

Repository for the RDF Tests Community Group
w3c.github.io/rdf-tests
Other
45 stars 23 forks source link

SPARQL: what is "999"^^xsd:byte > 0 ? #45

Open joernhees opened 7 years ago

joernhees commented 7 years ago

999 doesn't fit into xsd:byte, which is a signed 8 bit int...

would be nice to have a test for defined behavior of query: SELECT ( "999"^^<http://www.w3.org/2001/XMLSchema#byte> > 0 AS ?result ) {}

results in the wild:

also see https://github.com/RDFLib/rdflib/issues/737

afs commented 7 years ago

@joernhees - please do generate a pull request.

lisp commented 7 years ago

in which case are not both the stardog and the rdflib results conformant?

joernhees commented 7 years ago

to be honest: i'm neither entirely sure which result i'd actually expect, nor what kind of test this is (syntax / eval?).

And should one argue that while "999"^^xsd:byte isn't "valid", it's certainly >/!= 0? Should it be clipped to 128? But then what about "129"^^xsd:byte > 128 or "129"^^xsd:byte > 129?

afs commented 7 years ago

"999"^^<http://www.w3.org/2001/XMLSchema#byte> is a valid RDF term but not a valid numeric value because "999" is outside the lexical restriction for xsd:byte lexical forms (maxInclusive=127).

The dispatch for the expression "999"^^xsd:byte > 0 is not defined by SPARQL (see section 17.3) and it's an error because "999"^^xsd:byte is not a numeric value.

(And even if it were considered as one, then the operator is op:numeric-greater-than from "XQuery functions and operators" where it's an error.)

What happens on errors is not defined by the SPARQL spec. Usually that allows extension such as new datatypes e.g. "abc"^^:myHexDatatype. xsd:byte is already defined by XML Datatypes.

lisp commented 7 years ago

that last is the question. are extensions truly precluded from defining a result for that term?

Am 02.06.2017 12:34 nachm. schrieb "Andy Seaborne" <notifications@github.com

:

"999"^^http://www.w3.org/2001/XMLSchema#byte is a valid RDF term but not a valid numeric value because "999" is outside the lexical restriction for xsd:byte lexical forms (maxInclusive=127).

The dispatch for the expression "999"^^xsd:byte > 0 is not defined by SPARQL (see section 17.3) and it's an error because "999"^^xsd:byte is not a numeric value.

(And even if it were considered as one, then the operator is op:numeric-greater-than from "XQuery functions and operators" where it's an error.)

What happens on errors is not defined by the SPARQL spec. Usually that allows extension such as new datatypes e.g. "abc"^^:myHexDatatype. xsd:byte is already defined by XML Datatypes.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/w3c/rdf-tests/issues/45#issuecomment-305751459, or mute the thread https://github.com/notifications/unsubscribe-auth/AALs7lvcxydN4xuWoI3QKd08tINGoQCpks5r_-U7gaJpZM4NpfxC .

afs commented 7 years ago

SPARQL perspective - no, it is not precluded as an extension. Extension don't even have to make sense: extending > to return a URI rather than a boolean might be legal but it is somewhat against common sense. Use might well expect that the extensions also cover "999"^^xsd:byte + 1 > 0 which is extending +.

To claim that "999"^^xsd:byte is a valid XSD byte is violating the XSD spec.

A complication in this example is that XSD operations are defined for integer/decimal/float/double. The violation is actually on the promotion of the numeric if the extension is to pass on to op:numeric-greater-than.

lisp commented 7 years ago

so long as the results for well defined terms are those defined by the respective recommendation, where does "extension" lead to "violation"? as it would be acceptable to permit

"999"^^xsd:not-a-byte + 1 > 0

that leaves the exclusion of "999"^^xsd:byte in the realm of "academic" rather than "common sense".

afs commented 7 years ago

Because software is written by reading the xsd: details and datatype xsd:not-a-byte is not in that spec. The semantic web principle of URI management is to create new URIs in areas of the web namespace you control.

"CCC"^^my:romanNumeral is fine.

xsd: is a namespace defined by another community. Trampling all over that is not helpful.

Note that xsd:date is a common extension to SPARQL. Systems use the operations from F&O for that, not redefine the meaning of "date".

VladimirAlexiev commented 6 months ago

rdf4j (GraphDB) also returns true. It seems to ignore the byte-size restriction and treats the number "reasonably", eg "-999"^^xsd:byte<0 is true and "-999"^^xsd:byte>0 is false.

IMHO this should return undef, just like these return undef (on rdf4j):

ericprud commented 6 months ago

Bear in mind the difference between what the culmination of all normatively referenced specs say and what we expect implementations to include (i.e. what we include in the test suite). There are a few cases where we deliberately look away in order to minimize both the implementation and runtime burdens. An example is that SPARQL (and Turtle, etc.) are supposed to consume absolute IRIs. The grammars include productions that limit the character set but in no way ensure conformance with protocols (e.g. all of the things that are allowed or not after "http:").

Similarly, we could avoid making implementations test the ranges of inputs to op:numeric-greater-than.

(I personally think that the the differential interop over semantically-questionable graphs is worth the increased implementation burden, so yeah, add the test and expect it to fail).