Adds RDF term equality definitions #161

hartig · 2025-02-25T08:44:50Z

Closes #154 by adding definitions of 'blank node equality', 'triple term equality', 'RDF term equality', and 'triple equality'. Additionally, this PR makes the definitions of graph comparison and dataset comparison more explicit by using these notions of equality.

Preview | Diff

…DF term equality', and 'triple equality'

hartig · 2025-02-25T08:51:25Z

spec/index.html

@@ -925,8 +952,6 @@ <h3>Graph Comparison</h3>
      the triple (|s|, |p|, |o|) is in |G| if and only if
      the triple ( |M|(|s|), |M|(|p|), |M|(|o|) ) is in <var>G'</var>.</p>

-    <p>See also: <a>IRI equality</a>, <a>literal term equality</a>.</p>


Note that I have removed this one because the cross-references to these definitions are integrated directly into the definition above now.

pchampin

The only change that I really "request" is the one in 'Graph Comparison', because (unless I'm missing something) it introduces an error.

The others are merely an expression of my preferences, but I can live without them.

spec/index.html

pchampin · 2025-02-25T12:57:49Z

spec/index.html

+      <li>For every [=literal=] |lit|, |M|(|lit|) is a [=literal=] that is [=literal term equality|equal=] to |lit|.</li>
+      <li>For every [=IRI=] |iri|, |M|(|iri|) is an [=IRI=] that is [=IRI equality|equal=] to |iri|.</li>


I could live with that, but I find it needlessly verbose and confusing. The point here is not to produce a new value that happens to be equal to the argument, the point is to return the argument itself...
I would slightly prefer to keep '=' here.

.. The point here is not to produce a new value that happens to be equal to the argument, the point is to return the argument itself...

In this case, it would actually be a better idea to replace the = by "is" (e.g., "M(iri) is iri" instead of "M(iri) = iri").

Notice, however, that this wording makes a difference for literals: Consider two literals, lit1 and lit2, which both have the same lexical form, both have rdf:langString as their datatype, and one of them has "EN" as its language tag whereas the other one has "en" instead. In this case, lit1 is not lit2, but they are equal according to literal term equality. So, if we say "M(lit) is lit" in this definition here, then M(lit1) cannot return lit2 but must return lit1; in contrast, if the definition says "M(lit) = lit" (and assuming = means literal term equality), then M(lit1) may also return lit2 (as an alternative to returning lit1).

I am not even sure which of these two cases we actually want.

In this case, it would actually be a better idea to replace the = by "is" (e.g., "M(iri) is iri" instead of "M(iri) = iri").

Yes, I like that.

Notice, however, that this wording makes a difference for literals:

You gave me a lot to think about with this puzzle :) My conclusion (which I will explain in more detail in the main conversation of this PR) is that this is not (or should not be) an issue.

spec/index.html

afs · 2025-02-25T13:57:17Z

There isn't a preview/diff? Is this because the boilerplate was not included in the description?

afs

One suggestion, non-blocking.

hartig · 2025-02-25T14:34:50Z

There isn't a preview/diff? Is this because the boilerplate was not included in the description?

Strange. I have never put anything special in my PRs before. What would this boilerplate be?

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

afs · 2025-02-25T15:38:44Z

There isn't a preview/diff? Is this because the boilerplate was not included in the description?

Strange. I have never put anything special in my PRs before. What would this boilerplate be?

It should be added when the PR is created via the github UI.

I don't know if it can be retrospectively added.
For this PR, it isn't to hard to get the PR branch and look at that. But if text is altered in several places, or text moved around, I find it useful to see the diff.

#159 for example has ("edit" the description to see it):

<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/rdf-concepts/pull/159.html" title="Last updated on Feb 14, 2025, 9:18 AM UTC (fcb12f0)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/rdf-concepts/159/df7b9db...fcb12f0.html" title="Last updated on Feb 14, 2025, 9:18 AM UTC (fcb12f0)">Diff</a>

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

hartig · 2025-02-25T16:36:37Z

It should be added when the PR is created via the github UI.

That's what is strange. I did create the PR via the GitHub UI, exactly as I have done it for earlier PRs. But this time the link to the preview was not added.

Oh, wait, the only thing that I can imagine being the reason is that I edited the PR text a few minutes after having created the PR. Maybe that edit made a concurrently running auto-edit fail?

afs · 2025-02-25T16:58:37Z

Could well be!

spec/index.html

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

pchampin · 2025-02-26T11:01:15Z

This PR got me thinking (and re-reading the specs) for a long time... but I think I finally put my finger on what bothers me.

My major issue is that it approaches "term equality" (for each category of terms) as if the abstract syntax had a notion of equality that was different from the notion of identity. And in fact, it does not. And after my long mulling, I'm very much convinced that it must not make such a distinction (see pathological example below).

Those "term equality" sections exist mostly to emphasize how variations in concrete syntaxes and internal representations are not relevant for the abstract syntax. But granted, the pre-existing sections (esp. the one about literals) were already not very clear about that. (I just noticed how the last sentence of the definition of language tag is baroque in that respect: "Two language tags are the same if they only differ by case." -- and I may very well be responsible for this wording...).

The sections added in this PR are going further in the direction of "distinct but equal", with wording such as "are considered equal".

I'll try to suggest changes to this PR to clarify all this, or possibly make a counter-proposal.

Pathological example showing that the distinction between identity and equality in the abstract syntax is detrimental:

Consider the following two graphs

# G1
:s :p1 "chat"@en-US.
:s :p2 "chat"@en-US.

# G2
:s :p1 "chat"@en-us.
:s :p2 "chat"@EN-US.

I would like to consider that they are isomorphic, right? Because all the objects are equal. But if we consider the literals to be distinct in the abstract syntax, then per our definition of isomorphism, they are not isomorphic. We would need a mapping M that maps "chat"@en-US sometimes to "chat"@en-us and sometimes to "chat@EN-US!...

Note also that in RDF 1.1, the two graphs above are not isomorphic, nor are they simply-equivalent (but they are D-equivalent if D contains rdf:langString, and therefore RDF-equivalent).

spec/index.html

afs · 2025-02-26T14:21:26Z

Wording (not in this PR) that I found potentially weak:

"the two language tags (if any) compare equal"

what if one has a language and one does not? "abc" and "abc"@en. Only one language tag.

pchampin · 2025-02-26T14:23:40Z

Wording (not in this PR) that I found potentially weak:

"the two language tags (if any) compare equal"

what if one has a language and one does not? "abc" and "abc"@en. Only one language tag.

I'll prepare a PR to improve the section on literals, in the light of my remarks above. For the rest, I think the suggestions I just made on this PR are enough.

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

hartig · 2025-02-26T15:15:56Z

@pchampin I applied your three edit suggestions as I agree that the artificial distinction between equality and identity is confusing and useless. I will wait, however, with changing the definition in the 'Graph Comparison' section until I have seen your PR for improving the part about literal equality. Related to that PR that you are planning, notice that the definition of literal term equality has been changed already by our WG. The tricky part is probably not to improve the wording of the four bullet points but the paragraph that follows after the bullet points. There is some explanation for this paragraph in the 'Changes' section (see the point that begins with: "Implementations were previously allowed to normalize ..."). Some parts of this came in with PRs #48, #59, #74, but the main one then was PR #105 with the corresponding issue #100

… use identity for the cases of IRIs and literals

hartig · 2025-02-27T09:27:37Z

@pchampin Given your PR #162 with the improved definition of literal term equality, I have now pushed the remaining change to this PR here to change the definition in the 'Graph Comparison' section as per my proposal that you liked (i.e., replacing "M(lit) = lit" by "M(lit) is lit", and likewise for the case of IRIs). That should address the remaining point of your previous review of this PR.

pchampin

Thanks a lot. I'm very happy with this PR, now, modulo what I believe to be a typo.

spec/index.html

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

hartig · 2025-02-28T06:43:05Z

@TallTed I applied your edit suggestions. Are you okay with this PR now?

TallTed · 2025-03-01T00:07:57Z

spec/index.html

+        the following are true:
+        <ul>
+          <li>|M|(|n|) is [=RDF term equality|equal=] to <var>n'</var>.</li>
+          <li>The triple (|s|, |p|, |o|) is in |G| if and only if


See #161 (comment)

Suggested change

<li>The triple (|s|, |p|, |o|) is in |G| if and only if

<li>The triple (|s|, |p|, |o|) is in |G| and

adds definitions of 'blank node equality', 'triple term equality', 'R…

358399e

…DF term equality', and 'triple equality'

hartig requested review from gkellogg, afs and pchampin February 25, 2025 08:44

hartig mentioned this pull request Feb 25, 2025

Revise RDFterm-equal and function sameTerm w3c/sparql-query#194

Open

hartig commented Feb 25, 2025

View reviewed changes

pchampin requested changes Feb 25, 2025

View reviewed changes

afs approved these changes Feb 25, 2025

View reviewed changes

revert incorrect change in definition of 'isomorphic RDF-term mapping'

1ec1807

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

Apply suggestions from code review

96c4ef2

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

gkellogg approved these changes Feb 25, 2025

View reviewed changes

TallTed suggested changes Feb 25, 2025

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

spec/index.html Outdated Show resolved Hide resolved

spec/index.html Outdated Show resolved Hide resolved

Apply suggestions from code review

c8a7545

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>

This comment was marked as outdated.

Sign in to view

pchampin reviewed Feb 26, 2025

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

pchampin reviewed Feb 26, 2025

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

pchampin reviewed Feb 26, 2025

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

Apply suggestions from code review

8a301f0

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

pchampin mentioned this pull request Feb 26, 2025

improve definition of Literal #162

Open

changes the definition of 'isomorphic RDF-term mapping' to explicitly…

ca48f3f

… use identity for the cases of IRIs and literals

pchampin approved these changes Feb 28, 2025

View reviewed changes

spec/index.html Outdated Show resolved Hide resolved

fix: and --> if and only if

6e621f0

Co-authored-by: Pierre-Antoine Champin <github-100614@champin.net>

TallTed reviewed Mar 1, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adds RDF term equality definitions #161

Adds RDF term equality definitions #161

hartig commented Feb 25, 2025 •

edited by pr-preview bot

Loading

hartig Feb 25, 2025

pchampin left a comment

pchampin Feb 25, 2025

hartig Feb 25, 2025

pchampin Feb 26, 2025

afs commented Feb 25, 2025

afs left a comment

hartig commented Feb 25, 2025

afs commented Feb 25, 2025

hartig commented Feb 25, 2025

afs commented Feb 25, 2025

pchampin commented Feb 26, 2025 •

edited

Loading

This comment was marked as outdated.

afs commented Feb 26, 2025 •

edited

Loading

pchampin commented Feb 26, 2025 •

edited by afs

Loading

hartig commented Feb 26, 2025

hartig commented Feb 27, 2025

pchampin left a comment

hartig commented Feb 28, 2025

TallTed Mar 1, 2025

		<li>For every [=literal=] \|lit\|, \|M\|(\|lit\|) is a [=literal=] that is [=literal term equality\|equal=] to \|lit\|.</li>
		<li>For every [=IRI=] \|iri\|, \|M\|(\|iri\|) is an [=IRI=] that is [=IRI equality\|equal=] to \|iri\|.</li>

	<li>The triple (\|s\|, \|p\|, \|o\|) is in \|G\| if and only if
	<li>The triple (\|s\|, \|p\|, \|o\|) is in \|G\| and

Adds RDF term equality definitions #161

Are you sure you want to change the base?

Adds RDF term equality definitions #161

Conversation

hartig commented Feb 25, 2025 • edited by pr-preview bot Loading

hartig Feb 25, 2025

Choose a reason for hiding this comment

pchampin left a comment

Choose a reason for hiding this comment

pchampin Feb 25, 2025

Choose a reason for hiding this comment

hartig Feb 25, 2025

Choose a reason for hiding this comment

pchampin Feb 26, 2025

Choose a reason for hiding this comment

afs commented Feb 25, 2025

afs left a comment

Choose a reason for hiding this comment

hartig commented Feb 25, 2025

afs commented Feb 25, 2025

hartig commented Feb 25, 2025

afs commented Feb 25, 2025

pchampin commented Feb 26, 2025 • edited Loading

This comment was marked as outdated.

afs commented Feb 26, 2025 • edited Loading

pchampin commented Feb 26, 2025 • edited by afs Loading

hartig commented Feb 26, 2025

hartig commented Feb 27, 2025

pchampin left a comment

Choose a reason for hiding this comment

hartig commented Feb 28, 2025

TallTed Mar 1, 2025

Choose a reason for hiding this comment

hartig commented Feb 25, 2025 •

edited by pr-preview bot

Loading

pchampin commented Feb 26, 2025 •

edited

Loading

afs commented Feb 26, 2025 •

edited

Loading

pchampin commented Feb 26, 2025 •

edited by afs

Loading