Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rdf:JSON equality of +0 and -0 #91

Open
pfps opened this issue Jun 28, 2024 · 6 comments
Open

rdf:JSON equality of +0 and -0 #91

pfps opened this issue Jun 28, 2024 · 6 comments
Labels
spec:enhancement Issue or proposed change to enhance the spec without changing the normative content substantively

Comments

@pfps
Copy link
Contributor

pfps commented Jun 28, 2024

Is +0 equal to -0 or not? Equality of IEEE floating point double would indicate so but equality for rdf;JSON says they have to be the same value which means that they are not equal. If the latter is desired there should be a note along the lines of

0 and -0 compare equal in IEEE floating point double. RDF, however, uses a notion of true equality for datatype values. As 0 and -0 are different values in the value space of rdf:JSON they are not equal as far as rdf:JSON is concerned.

@pfps pfps added the spec:enhancement Issue or proposed change to enhance the spec without changing the normative content substantively label Jun 28, 2024
@gkellogg
Copy link
Member

This should be the same as asking if "+0"^^xsd:double is equal to "-0"^^xsd:double. For the XML Schema Datatypes says "Equality is identity, except that 0 = −0 (although they are not identical) ...." so "+0"^^xsd:double == "-0"^^xsd:double. By that reasoning, "+0"^^rdf:json == "-0"^^rdf:json, as the value space for JSON numbers is xsd:double.

@pfps
Copy link
Contributor Author

pfps commented Jun 28, 2024

On the contrary. As far as the value spaces of rdf:JSON and xsd:double are concerned +0 and -0 are different values, and thus not identical and thus, as far as RDF is concerned, not equal. There might be a SPARQL relationship called equality that says that +0 and -0 are equal, but that is a different relationship and why using "equality" for the relationship in the RDF value space is probably not a good idea.

Somewhat similar concerns exist for rdf:HTML and rdf:XMLLiteral. Their value spaces are DOM trees considered as trees, not data structures. So two different structures in memory are the same element of the value space if they compare as equal even though the data structures might have different internal pointers.

@IS4Code
Copy link

IS4Code commented Aug 10, 2024

+0 and -0 are distinct values, not different. As literal terms, they are indeed different, and as xsd:double values, they are distinct (thus not identical), but considered equal by the standard.

"different" means "not equal". "distinct" means "not identical". "identical" implies "equal" (sans NaNs), thus "different" implies "distinct". "equal" means "equivalent by the relation of equality". "identical" means "equivalent by the relation of identity". XML Schema tells you precisely what it considers those relation to be defined as.

There are also numeric types (not in XML Schema though) that consider values 1.0 and 1.00 distinct but equal. This is not some queer notion of equality that language lawyers like to use, this is pretty much what one should want when using the word "equality". If you have a different definition, feel free to elaborate what it is, but you can't argue that the commonly used and standardized definition is wrong because it is different.

By the way, "as far as RDF is concerned" is ambiguous ‒ RDF is concerned mostly about the structure of values and graphs that link them together, and at that level, there is no difference between equality and identity of terms (even data:,%2F is different from data:,%2f). There you can have term-equality of literals, which is pretty much just term identity, and it is even stronger than XML Schema identity (are 1 and 01 different by your notion?). The datatypes defined by the RDF standard are "isolated" in a way that you need some form of interpretation (in RDFS/OWL) of graphs to make their value spaces useful, otherwise they are there just as a definition to be used in your own system.

@pfps
Copy link
Contributor Author

pfps commented Aug 10, 2024

Where RDF says "equal" it mean "identical". +0 and -0 are different values that compare equal in the datatype but that equality is different from RDF equality.

@IS4Code
Copy link

IS4Code commented Aug 10, 2024

If you consider term-equality within RDF, that is completely unrelated to anything that may be defined on the rdf:JSON datatype itself. It just means that to any software accepting, producing, or otherwise processing RDF, the only way terms can be equal is by having the exact same type and constituents, and so a graph that contains :s :p "1"^^xsd:integer is different from a graph containing :s :p "01"^^xsd:integerat that level.

rdf:JSON is not at that level. It is a datatype, not unlike those defined in xsd: behaving according to what datatypes should behave like. Once you operate at the level of individual datatypes and literal values, term-equality is completely meaningless.

@gkellogg
Copy link
Member

The only reasonable interpretation of datatype value equality is to match what SPARQL does in it's operator mappings. For this xsd:float and xsd:double would use op:numeric-equal(A, B) to compare the values derived from "1.0"^^xsd:double and "1.0e0"^^xsd:double for example. These are distinct terms, and so would not be equal according to RDFterm-equal, but are equal according to op:numeric-equal, as both these representations map to the same value. Additionally, XSD specifically says that 0 = -0 for xsd:double and xsd:float.

The rdf:JSON value space is composed of lists, maps, strings, numbers (double value space) and the literals true, false, and null. The datatype describes equality on each of these, recursively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:enhancement Issue or proposed change to enhance the spec without changing the normative content substantively
Projects
None yet
Development

No branches or pull requests

3 participants