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

Adds RDF term equality definitions #161

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Adds RDF term equality definitions #161

wants to merge 2 commits into from

Conversation

hartig
Copy link
Contributor

@hartig hartig commented Feb 25, 2025

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.

@@ -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>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@pchampin pchampin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +943 to +944
<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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +617 to +620
<li>|t| and <var>t'</var> are [=IRIs=] that are [=IRI equality|equal=].</li>
<li>|t| and <var>t'</var> are [=literals=] that are [=literal term equality|equal=].</li>
<li>|t| and <var>t'</var> are [=blank nodes=] that are [=blank node equality|equal=].</li>
<li>|t| and <var>t'</var> are [=triple terms=] that are [=triple term equality|equal=].</li>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<li>|t| and <var>t'</var> are [=IRIs=] that are [=IRI equality|equal=].</li>
<li>|t| and <var>t'</var> are [=literals=] that are [=literal term equality|equal=].</li>
<li>|t| and <var>t'</var> are [=blank nodes=] that are [=blank node equality|equal=].</li>
<li>|t| and <var>t'</var> are [=triple terms=] that are [=triple term equality|equal=].</li>
<li>|t| and <var>t'</var> are [=IRIs=] that are [=IRI equality|equal=] (per [=IRI equality=]).</li>
<li>|t| and <var>t'</var> are [=literals=] that are [=literal term equality|equal=] (per [=literal term equality=]).</li>
<li>|t| and <var>t'</var> are [=blank nodes=] that are [=blank node equality|equal=] (per [=blank node equality=]).</li>
<li>|t| and <var>t'</var> are [=triple terms=] that are [=triple equality|equal=] (per [=triple equality=]).</li>

I would not fight for this change, but I think it makes the rendered text more readable. It can easily be overlooked that the four occurrences of "equal" do not refer to the same definition.

Also, I think it is better to refer directly to "triple equality" than to "triple term equality". See my remark below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or the pattern:

  <li>|t| and <var>t'</var> are [=IRIs=] that are [=IRI equality|equal as IRIs=].</li>

Comment on lines +916 to +918
<p><dfn>Triple term equality</dfn>:
Since triple terms are [=triples=], equality of triple terms is the same as [=triple equality=].</p>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p><dfn>Triple term equality</dfn>:
Since triple terms are [=triples=], equality of triple terms is the same as [=triple equality=].</p>
<p>Triple term equality:
Since triple terms are [=triples=], equality of triple terms is the same as [=triple equality=].</p>

For the sake of regularity, I understand that it is desirable to have a paragraph about "Triple term equality". But I think that making it a definition is not required and adds confusion. As this paragraph explains, triples terms are triples, so triple equality applies here.

@afs
Copy link
Contributor

afs commented Feb 25, 2025

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

Copy link
Contributor

@afs afs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One suggestion, non-blocking.

@hartig
Copy link
Contributor Author

hartig commented Feb 25, 2025

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?

@afs
Copy link
Contributor

afs commented Feb 25, 2025

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>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RDF term equality definitions
3 participants