Changed semantics of sameValue (RDFterm-equal)?

[kasei]

I believe in the process of updating sameValue, the semantics have changed from the 1.1 definition (RDFterm-equal).

As an example, I’m looking at the semantics of evaluating the expression "a" = 1. Previously, this would fall through the operator mapping table (assuming no extensions) to RDFterm-equal which says this should produce a type error.

However, in the 1.2 draft, the definition of sameValue is much expanded, and the new definition says that this should return false due to step 7:

7. If term1 and term2 are both literals and the SPARQL processor can determine the values can not be equal, then return FALSE.

In my example, these are both datatypes that conformant systems must understand (xsd:string and xsd:integer), so leaving that to “if … the SPARQL processor can determine” language seems a bit vague to me (both "if" and "can" are of concern here). I understand the need for the “if” to expand past the types that must be supported, but I wonder if we should think about better language that explicitly covers the core types.

I found this while working through a query using NOT IN. In that case (and using the equivalences we provide to a combination of '!', =, and logical-or operations), if all the values are numeric with the addition of a single string in the values list (e.g. 1 NOT IN (1, 2, 3, "a")), then the error from that final comparison bubbles up from the =, through the logical-or, and changes the result of the NOT IN.

I’m not sure I had ever realized before. This understanding makes me think that the 1.1 semantics make NOT IN very dangerous to use unless you have a deep understanding of the language semantics and a clear understanding of exactly what extensions your system has made to the operator mapping table. I think the 1.2 language is clearly better for this case, but the “if the processor can determine” language still seems a bit vague.

What do people think?

(I also don't think this change was discussed in the group and I can't find mention of it in the Changes from 1.1 to 1.2 section.)

[hartig]

I agree with the assessment.

[afs]

I believe this was discussed at the time. This isn't new to 1.2; it is a something that is a fact about to value spaces (from XSD datatypes). If term1 and term2 are in different value spaces, they can not be value-equal. It is made more explicit in 1.2 (the issue around "NaNs" aside).

It does depend, in the general case, on the values spaces the engine supports (which maybe partial) which is why it is written as a characteristic.

still seems a bit vague.

Do you have suggestion?
A "note" (c.f. the current notes)?
Or are you asking for something about how extensions must (should?) behave?

[kasei]

This isn't new to 1.2;

Isn't it? Do you disagree with my example "a" = 1 resulting in a type error in 1.1 and false in 1.2?

If there's agreement, I would hope for better wording in the definition (not about extensions), not another note. Will try to come up with something complete, but I think I'd be aiming for replacing "If … processor can determine … then" with something more like "If … term1 and term2 cannot be equal according to the datatypes supported by the processor, then …".

[kasei]

Just to be explicit, the text in 1.1 defining RDFterm-equal includes:

produces a type error if the arguments are both literal but are not the same RDF term;

while 1.2 draft has:

7. If term1 and term2 are both literals and the SPARQL processor can determine the values can not be equal, then return FALSE.

[rubensworks]

It looks like the behaviour for "a" = 1 is indeed different now.

Perhaps step 3 in 17.4.2.2 sameValue could be tweaked to something like:

If term1 and term2 are both literals and the SPARQL processor does not support the = operator for the datatypes of these literals, then produce an error.

[afs]

This isn't new to 1.2;

Isn't it? Do you disagree with my example "a" = 1 resulting in a type error in 1.1 and false in 1.2?

That is not the case because of point 7. Both 6 and 7 require a positive assertion by the processor to return true/false.

these are both datatypes that conformant systems must understand (xsd:string and xsd:integer),

"Understanding" does not have to be a complete coverage of all features of value spaces. There is no requirement in a minimally compliant implementation for the knowledge that string and integer are disjoint values spaces (1.1 or 1.2). It can be enough to implement the dispatch table and the fact that "same term => same value".

Point 9 is the "don't know" case.

That would be the place for Ruben's suggestion, make 9 an error. (Mentioning = in the sameValue definition would be a circularity.) and then, maybe, point 3 can be removed which removes the text "not handled by the SPARQL processor".

Then we have a list of conditions that only mentions the required conditions; no mention of providing/supporting a datatype (c.f. providing value equality but not pair-wise comparision).

See the first note.

Reference:
Issue #187 - RDFterm-equals does not cover different datatypes

[kasei]

"Understanding" does not have to be a complete coverage of all features of value spaces. There is no requirement in a minimally compliant implementation for the knowledge that string and integer are disjoint values spaces (1.1 or 1.2)

Apparently I've never known this. However, I'm not sure it changes my position here.

That is not the case because of point 7. Both 6 and 7 require a positive assertion by the processor to return true/false.

I'm struggling to understand this. Assuming the system does know that integer and string value spaces are disjoint, is that the positive assertion you're referring to here? In that case, I think 1.2 text means the system can (and should) return false. But the 1.1 text seems pretty clear to me that the same comparison should result in a type error.

Point 9 is the "don't know" case.

Point 9 returns FALSE. How does that align with the text in the first note which says "If the SPARQL processor can not be sure, it returns error." Shouldn't the "I don't know" case be a type error?

The full text in the first note seems to be exactly the part that I think has changed (for better!) in 1.2. In 1.1 1 = "a" must return a type error. In 1.2 it seems it may return false (depending on the system's understanding of the value spaces). What am I missing?

[afs]

Point 9 is the "don't know" case.

Point 9 returns FALSE. How does that align with the text in the first note which says "If the SPARQL processor can not be sure, it returns error." Shouldn't the "I don't know" case be a type error?

Yes - I'm suggesting changing point 9 and probably removing point 3.

The full text in the first note seems to be exactly the part that I think has changed (for better!) in 1.2. In 1.1 1 = "a" must return a type error. In 1.2 it seems it may return false (depending on the system's understanding of the value spaces). What am I missing?

Not "must". An error can be overridden to give a true or false result. So 1 = "a" can be false in SPARQL 1.1

In 1.2, it is an error (when point 9 is changed), if the engine does not have the fact that xsd:integer and xsd:string are disjoint value spaces.

I think you are letting your intuition leak into the reading. Or, as we now say, you have a world model that you are using in the prompt.

[kasei]

Not "must". An error can be overridden to give a true or false result. So 1 = "a" can be false in SPARQL 1.1

If we're talking about the logic in RDFterm-equal, I think we've already fallen past the point of overriding errors, no? Extensions could allow a false value by overriding the operator mapping table, but if we're in the RDFterm-equal logic, my reading is that it must return a type error.

In 1.2, it is an error (when point 9 is changed), if the engine does not have the fact that xsd:integer and xsd:string are disjoint value spaces.

Agreed. However, I continue to believe that in cases where the engine does know they are disjoint, this is a semantic change from 1.1. I'm not sure where my intuition is "leaking into the reading" here. I've cited the text I think clearly defines these two cases. And while it does depend on a more specific configuration that I had previously understood, in those cases (no extensions, but where the system knows about the value spaces of xsd:string and xsd:integer), this seems clear to me, and am hoping for an explicit explanation for why my understanding isn't correct.

[afs]

Evaluating a function can produce an error and that can be overridden.

[kasei]

Evaluating a function can produce an error and that can be overridden.

Accepting that, I'd still like to focus on a system with "no extensions, but where the system knows about the value spaces of xsd:string and xsd:integer." I've linked to the spec text that I think clearly shows that for such a system the result of evaluating 1 = "a" is a type error in 1.1 and false in 1.2. That looks very much to me like a change in semantics, and I'm hoping we can agree on that (or that you might provide an explanation for why my interpretation is wrong).

[afs]

I'm suggesting changing point 9 and probably removing point 3.

#343 shows the changes.

• Produce an error as the last outcome
• Remove step containing "a datatype that is not handled by the SPARQL processor"
• Reorder to put a literal handling together
• Handle the case of exactly one triple term

[afs]

focus on a system with "no extensions, but where the system knows about the value spaces of xsd:string and xsd:integer."

A minimal system produces an error.
A system that knows the value spaces of xsd:string and xsd:integer are disjoint can return false as an extension.