Refining RDFTerm-equals

[afs]

#185 shows that RDFTerm-equals needs some attention.
(#25 is the issue for renaming this. Trying it out here.)

In the definition of RDFTerm-equals says:

The function is defined as follows:

• Returns TRUE if term1 and term2 are equal RDF terms, as defined below.
• Produces a type error if term1 and term2 are both literals having the same datatype IRI; this datatype IRI is not in the set of recognized datatype IRIs; and the lexical forms of the two literals are different from one another.
• Returns FALSE otherwise.

Bullet 2 applies if the terms have the same dataype IRI. What if there are two diffrerent but related datatype IRIs?

"recognized" is about the data generally, and so could apply elsewhere such a comparision (if it matters), not just this function.
Currently, there is a proposal to remove it from RDF Concepts because it is also defined by RDF Semantics.

We would be better having a SPARQL-focused definition we can limit to this function (e.g. a system may be able to determine equality in some, but not all, cases).

Example 1

sameValue("0.13"^^xsd:precisionDecimal, "0.13"^^xsd:decimal) 

• Not dispatched by the operator mapping table.
• Different terms.
• Not the same datatype IRI.

Returns false.
But they are the same value - and only error allows extension.

(xsd:precisionDecimal is not derived from xsd:decimal nor the other way round)

Example 2

sameValue("IV"^^my:romanNumeral, "4"^^xsd:decimal)

• Not dispatched ("IV"^^my:romanNumeral is not mentioned in Operand Data Types
• Different terms.
• Different datatypes.

Returns false.

my:romanNumeral can't be made derived because the lexical space is not digits.

Example 3

sameValue("2025-01-01T00:00:00Z"^^xsd:dateTime, "2025-01-01T00:00:00Z"^^xsd:dateTimeStamp) 

Returns False.

xsd:dateTimeStamp is a derived datatype of xsd:dateTime but the spec only covers numeric derived types.

Example 4

Systems involving units (different value space to numbers)

sameValue("32"^^x:meters, "3200"^^y:centimeters)

Not error so can't be an extensions. This is an erratum.

Example 5

sameValue("abc"^^xsd:string, "IV"^^my:romanNumeral)

All it takes is to know to return FALSE is that my:romanNumeral is a number or not a legal value, without

Not error so can't be an extension. This is an erratum IMO.

Example 6

sameValue("abc"^^xsd:integer, "123"^^xsd:integer)

Probably, this should be FALSE because the operator mapping does apply to = and a SPARQL processor must understand xsd:integer.
It could be error because it can't be 123. c.f.

sameValue(1 + "abc"^^xsd:integer, "123"^^xsd:integer)

which is an error before sameValue is invoked.

Proposal

Instead of adding one or more cases, I propose defining RDFTerm-equals more in the style of "by contract"
(not exact wording for now): in order:

1. If one or both arguments are known to be ill-typed, then error.
2. If the arguments are the sameTerm then return TRUE.
3. If the SPARQL processor can determine the values of both terms and it can determine the values are equal, then return TRUE.
4. If the SPARQL processor can determine the values of the terms can not be equal, the return FALSE.
5. Otherwise error.

The 4th case does not necessarily require values themselves because a processor may know they are different value spaces so can't be value-equal. Case 1 removes know-to-ill-typed.

Because of the order of cases 1 and 2, "sameTerm=true" does not imply "sameValue=true". They could be swapped so that is the case.

I don't think there can be a perfect solution in all cases - we are going from terms to values with incomplete knowledge in some situations.

[rubensworks]

The note in https://www.w3.org/TR/sparql12-query/#func-RDFterm-equal starts with:

An extended implementation may support additional datatypes for literals.

Based on my interpretation, this note indicates that implementations can choose to support the examples you listed above.

Unless the point of this issue is that this note should be removed in favor of a more precise definition?

[afs]

Based on my interpretation, this note indicates that implementations can choose to support the examples you listed above.

Unless the point of this issue is that this note should be removed in favor of a more precise definition?

Yes, a more precise definition (better coverage of possible cases) - extensions can added where there is error. That's why some of the examples can be seen as errata - e.g. two different extension datatypes.

Leave the note, even expand it. It is explaining what is going on in more accessible language.