The "<" operator (see the Operator Mapping and 17.3.1 Operator Extensibility) defines the relative order of pairs of numerics, simple literals, xsd:strings, xsd:booleans and xsd:dateTimes. Pairs of IRIs are ordered by comparing them as simple literals.
This suggests that the < operator does not handle IRIs, even within ORDER BY handling. The ordering of IRIs is handled as a special case in evaluating OrderBy.
"If sparql-compare(SUBJECT(A), SUBJECT(B)) != 0, then return this value" (and similarly for predicate and object)
I think these things combined suggest that when evaluating an ORDER BY, IRIs that are contained within RDF-star triple terms are not comparable (but that they are intended to be).
I believe the sparql-star-order-2 test relies on the intended semantics here, but fails as written.
I think the definitions need to be updated to allow the special IRI comparability introduced in SPARQL 15.1 to apply to the non-triple term rule in sparql-compare when evaluating within the context of an OrderBy operator.
SPARQL 15.1 says:
This suggests that the
<operator does not handle IRIs, even within ORDER BY handling. The ordering of IRIs is handled as a special case in evaluatingOrderBy.But RDF-star 4.4.11 Triple terms with ORDER BY says:
RDF-star 4.4.10 adds an entry to the operator mappings for RDF triple terms:
and RDF-star 4.4.8 sparql-compare is defined recursively with:
<,=,>"sparql-compare(SUBJECT(A), SUBJECT(B)) != 0, then return this value" (and similarly for predicate and object)I think these things combined suggest that when evaluating an
ORDER BY, IRIs that are contained within RDF-star triple terms are not comparable (but that they are intended to be).I believe the sparql-star-order-2 test relies on the intended semantics here, but fails as written.
I think the definitions need to be updated to allow the special IRI comparability introduced in SPARQL 15.1 to apply to the non-triple term rule in sparql-compare when evaluating within the context of an OrderBy operator.