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

[joernhees]

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:

• jena: undef
• rdflib, stardog: true
• virtuoso: 0 ("0"^^xsd:int)

also see RDFLib/rdflib#737

[afs]

@joernhees - please do generate a pull request.

[lisp]

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

[joernhees]

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]

"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]

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" <[email protected]

:

"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 <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALs7lvcxydN4xuWoI3QKd08tINGoQCpks5r_-U7gaJpZM4NpfxC> .

[afs]

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]

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]

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]

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):

• "zzz"^^xsd:byte<0
• "2024-02-30"^^<http://www.w3.org/2001/XMLSchema#date> < "2024-02-27"^^<http://www.w3.org/2001/XMLSchema#date> (the first date is invalid)

[ericprud]

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).