New triple term semantics in the rdf-semantics spec #55

franconi · 2024-12-02T17:46:59Z

Please check the minimal extension I made to the rdf-semantics doc, with the new definitions as in the RDF-star "working alternative baseline" spec we voted.
Note that I had to make a minor fix to the RDF alternative semantics spec, in order to exclude that rdf:type becomes a rdf:ReificationProperty.
The rdf-semantics doc has been monotonically extended with the necessary new definitions about triple terms.
This version implements a minimal change, since it could be possible also to enhance the quality of the current text.

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Dec 3, 2024, 4:46 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 Related URL

Timed out after waiting 30000ms

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

- remove unnecessary HTML elements - not-table content now does not use tables - add semantic elements - modify to be valid HTML5

em elements

Co-authored-by: Ted Thibodeau Jr <[email protected]>

Co-authored-by: Gregg Kellogg <[email protected]>

two columns in CSS

add yet another em

Better HTML

Added the semantics of triple terms, according to the "alternative semantics"

gkellogg

There are a bunch of markup errors, which is what keeps this from building properly.

spec/index.html

Co-authored-by: Gregg Kellogg <[email protected]>

franconi · 2024-12-02T18:49:26Z

I've fixed Greg's comments

gkellogg

Generally, I think the PR Preview "diff" accessor (which seems broken right now) is the best way for people to see the changes for this PR rather than using permanent markup.

ReSpec also has some support for the <ins> and <del> elements, but that's typically used for flagging post-REC changes for consideration for subsequent normative changes. I am wary of using such markup, though.

gkellogg · 2024-12-02T19:15:46Z

spec/index.html

@@ -465,6 +465,7 @@ <h6 class="defcap">Definition of a Simple Interpretation</h6>
            <li>A mapping <em>IEXT</em> from <em>IP</em> into the powerset of <em>IR</em> x <em>IR</em>, i.e., the set of sets of pairs <em>&lt;x, y&gt;</em> with <em>x</em> and <em>y</em> in <em>IR</em>.</li>
            <li>A mapping <em>IS</em> from <em>IRIs</em> into (<em>IR</em> union <em>IP</em>).</li>
            <li>A partial mapping <em>IL</em> from literals into <em>IR</em>.</li>
+            <li><span style="background-color: Cyan;color: Black">6. An injective mapping RE from IR x IP x IR into IR, called the denotation of triple terms</span> </li>


Is the styling of this line intended to be permanent, or only to call attention to it for the purposes of review? If so, there's probably a better way to accomplish this that we won't have to clean up later.

The "Cyan" background coloring is only meant at this stage to emphasise clearly the few additions I've have made - all focussed on the semantics and not on the wording. Once everybody agrees, I will remove the styling.
Maybe the next time I will learn how to achieve the same goal in a cleaner way...

gkellogg · 2024-12-02T19:18:47Z

spec/index.html

@@ -506,16 +507,19 @@ <h6 class="defcap">Definition of a Simple Interpretation</h6>
        from its set-theoretic extension.
        A similar technique is used in the ISO/IEC Common Logic standard [[?ISO24707]].
      </p>
-      <p>The referent of a ground RDF graph in a simple interpretation <em>I</em> is then given by the following rules,
+      <p><span style="background-color: Cyan;color: Black"><s>The referent of a ground RDF graph in a simple interpretation <em>I</em> is then given by the following rules,


A better way to accomplish this type of highlighting might be with editor's notes (e.g., The referent of a ground RDF graph in a simple interpretation I is then given by the following rules, .... But, these also eventually need to be removed when the point of highlighting is past.

+1 I appreciate @franconi 's efforts to help others review the changes, but mixing this metadata (what has change) with the data (the content of the spec) seems like a suboptiomal way to do this...

This is exactly what pr-preview is supposed to do (although it seems to be broken right now...).

Also, I found the previous wording "where the interpretation is also treated as a function" less confusing than the new wording...

Few points:

could you teach me how to use/enable pr-preview?

Due to the parallel radical changes of the formatting in the main branch, it is hard to compare the proposed changes wrt the current main state. That's why I have created a self-standing version (see point 3 below); once a final agreement is found, I will make sure to create a compatible version for merging.

For everybody: in order to see the proposed changes, that is how I would do: Download all https://github.com/franconi/rdf-semantics-altsem/tree/triple-terms-semantics/spec and open index.html in a browser.

could you teach me how to use/enable pr-preview?

PR Preview is a service that is enabled in W3C repositories with a .pr-preview.json configuration file. It automatically builds the preview, and diff and puts links to them at the end of the first comment on the PR. It updates with every new commit. Sometimes the tooling breaks, though. In this case githack.com can be useful.

afs

Should there be changes in section 9 / RDFS Axiomatic Triples?

spec/index.html

TallTed · 2024-12-03T15:58:45Z

It seems this (#55) should wait until the impact of #52 is fully addressed, whether by reversion or otherwise. /cc @gkellogg @pfps @domel

Co-authored-by: Andy Seaborne <[email protected]>

franconi · 2024-12-03T16:50:32Z

Should there be changes in section 9 / RDFS Axiomatic Triples?

I am not sure whether the WG agrees on the RDFS extension with rdfs: states. You tell me :-)

afs · 2024-12-03T18:07:47Z

Should there be changes in section 9 / RDFS Axiomatic Triples?

Should there be changes in section 9 / RDFS Axiomatic Triples?

I am not sure whether the WG agrees on the RDFS extension with rdfs: states. You tell me :-)

Aside from the "exciting" one, aren't there others?

rdf:ReificationProperty rdf:type    rdfs:Class .
rdf:TripleTerm          rdf:type    rdfs:Class .
rdf:reifies             rdfs:subClassOf    rdf:Property .
rdf:reifies             rdfs:domain    rdf:Resource .
rdf:reifies             rdfs:range    rdf:TripleTerm .

and more?

pchampin · 2024-12-06T10:20:12Z

spec/index.html

@@ -957,6 +961,9 @@ <h6 class="defcap"><dfn>RDF vocabulary</dfn></h6>
          <li><code>rdf:subject</code></li>
          <li><code>rdf:predicate</code></li>
          <li><code>rdf:object</code></li>
+          <li><code><span style="background-color: Cyan;color: Black">rdf:TripleTerm</span></code></li>


I would strongly advise against this name, and to use rdf:Triple instead. The triple term is the syntactic element, while the name of the class should be about the domain of discourse.

We already have a similar misnomer in the RDF(S) vocabulary: rdfs:Literal, for which we had to introduce a note explaining that "The class rdfs:Literal is not the class of literals, but rather that of literal values". Let's not make this mistake again.

The domain of discourse of such a class is exactly triple terms (as syntactic objects). E.g., in an unstar procedure, the generated "middle" bnode would be of type triple term, since it is exactly what it is meant to denote.

It is possible that in some future WG, while defining the semantics for named graphs, the type Triple will be used for actual triples in the graph, not just triple terms.

pchampin · 2024-12-06T10:35:57Z

spec/index.html

+          <p id="rdfsemcond6"><span style="background-color: Cyan;color: Black">
+            if <em>[I+A](E) = TRUE</em> and 
+            <em>&lt;[I+A](E.o), [I+A](rdf:TripleTerm)&gt;</em> is in <em>IEXT(I(<code>rdf:type</code>))</em> and
+            <em>E.p ≠ <code>rdf:type</code></em>, then


Why this exception? What is is meant to prevent?
Contrarily to the next rule, this rule will not be triggered by another rule of RDF semantics, and if the user writes something like x rdf:type <<( s p o )>>, then flagging rdf:type as a reification property seems appropriate.

pchampin · 2024-12-06T10:36:48Z

spec/index.html

+          <p id="rdfsemcond7"><span style="background-color: Cyan;color: Black">
+            if <em>[I+A](E) = TRUE</em> and
+            <em>&lt;[I+A](E.s), [I+A](rdf:TripleTerm)&gt;</em> is in <em>IEXT(I(<code>rdf:type</code>))</em>
+            and <em>E.p ≠ <code>rdf:type</code></em>, then


I understand that, without this exception, rdf:type would automatically become an InverseReificationProperty (because of the rules above).

Yet, would that be so bad?

Yes, it would be bad for several reasons, not least, as you say, because "ReificationProperty was proposed as a mere "flag" to allow people to detect errors", while here there is no error.

if the user writes something like x rdf:type <<( s p o )>>, then flagging rdf:type as a reification property IS NOT appropriate, since rdf:type is meant to have a specific meaning (made explicit in RDFS), and the user is expected to respect that intended meaning, and it is not our job to emphasise that they are making a mistake.

I see that my comment below is already made by PA. I also do not see the problem. So, we would want that reification properties have ONLY triple terms in object position or what is our goal here?

spec/index.html

doerthe · 2024-12-06T14:47:00Z

I am fine with the request in general (modulo some details I will report separately), but wonder why rdf:type can't be a rdf:ReificationProperty. How do others see that? How do we want to use that class in general?

And of course, I dislike the injectivity and am afraid that this complicates things without bringing benefit ...
(to add my own "Ceterum censeo Carthaginem esse delendam" ;) )

domel and others added 30 commits November 1, 2024 14:09

improve HTML

32ffd9a

- remove unnecessary HTML elements - not-table content now does not use tables - add semantic elements - modify to be valid HTML5

Update index.html

f2f3916

em elements

add a few s and change <code> to <pre> in block codes

9aef57e

and more s

48ad31b

rephrase by TedTall, part 1

36d17f4

Co-authored-by: Ted Thibodeau Jr <[email protected]>

rephrase by TedTall, part 2

8e84028

Co-authored-by: Ted Thibodeau Jr <[email protected]>

rephrase by TedTall, part 3

86f8214

Co-authored-by: Ted Thibodeau Jr <[email protected]>

whitespaces, part 1

473629d

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 1

4954126

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 2

617791e

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 3

25c3e3e

Co-authored-by: Ted Thibodeau Jr <[email protected]>

whitespaces, part 2

04fb22c

Co-authored-by: Ted Thibodeau Jr <[email protected]>

whitespaces, part 3

eed5467

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 4

031c09f

Co-authored-by: Ted Thibodeau Jr <[email protected]>

rephrase by TedTall, part 4

9e9a371

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 5

c8d557c

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 6

9ac48a9

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 7

89b2c96

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 8

b6220fe

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 9

4e16c34

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 10

535c6bb

Co-authored-by: Ted Thibodeau Jr <[email protected]>

whitespaces, part 4

9d82016

Co-authored-by: Ted Thibodeau Jr <[email protected]>

whitespaces, part 5

a2cfa4f

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 11

09ed385

Co-authored-by: Ted Thibodeau Jr <[email protected]>

new line, part 12

45be7ac

Co-authored-by: Ted Thibodeau Jr <[email protected]>

Update spec/index.html

d73e8df

Co-authored-by: Gregg Kellogg <[email protected]>

Update spec/index.html

1d78fc2

Co-authored-by: Gregg Kellogg <[email protected]>

ul elements in vocab fragments

7dbab27

two columns in CSS

small fix

84888af

add yet another em

Merge pull request w3c#52 from w3c/better-html

06b2096

Better HTML

First commit

fb860f7

Added the semantics of triple terms, according to the "alternative semantics"

gkellogg requested changes Dec 2, 2024

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

spec/index.html Show resolved Hide resolved

franconi and others added 4 commits December 2, 2024 19:39

Update spec/index.html

4742384

Co-authored-by: Gregg Kellogg <[email protected]>

Update spec/index.html

88c55bb

Co-authored-by: Gregg Kellogg <[email protected]>

Fixed from comment by Greg

3d38f3e

Fixed bare "<" and ">", as per Gregg's comment

dfb561d

gkellogg reviewed Dec 2, 2024

View reviewed changes

gkellogg approved these changes Dec 2, 2024

View reviewed changes

afs reviewed Dec 2, 2024

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

franconi and others added 3 commits December 3, 2024 17:45

Update spec/index.html

60dd54e

Co-authored-by: Andy Seaborne <[email protected]>

Update spec/index.html

21539e7

Co-authored-by: Andy Seaborne <[email protected]>

Update spec/index.html

361a210

Co-authored-by: Andy Seaborne <[email protected]>

gkellogg added a commit that referenced this pull request Dec 3, 2024

Fixes some premature changes from PR #55.

c6b4a4a

This was referenced Dec 3, 2024

Fixes some premature changes from PR #55. #57

Closed

semantic conditions for ground graphs damaged #56

Open

pchampin reviewed Dec 6, 2024

View reviewed changes

spec/index.html Show resolved Hide resolved

franconi removed the needs discussion Proposed for discussion in an upcoming meeting label Dec 12, 2024

pchampin force-pushed the main branch from 06b2096 to e29d0aa Compare December 19, 2024 18:25

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New triple term semantics in the rdf-semantics spec #55

New triple term semantics in the rdf-semantics spec #55

franconi commented Dec 2, 2024 •

edited by pr-preview bot

Loading

gkellogg left a comment

franconi commented Dec 2, 2024

gkellogg left a comment

gkellogg Dec 2, 2024

franconi Dec 3, 2024

gkellogg Dec 2, 2024 •

edited

Loading

pchampin Dec 6, 2024

pchampin Dec 6, 2024

franconi Dec 6, 2024

gkellogg Dec 6, 2024

afs left a comment

TallTed commented Dec 3, 2024

franconi commented Dec 3, 2024

afs commented Dec 3, 2024

pchampin Dec 6, 2024

franconi Dec 6, 2024

franconi Dec 6, 2024 •

edited

Loading

pchampin Dec 6, 2024

franconi Dec 6, 2024

pchampin Dec 6, 2024

franconi Dec 6, 2024

franconi Dec 6, 2024 •

edited

Loading

doerthe Dec 6, 2024

doerthe commented Dec 6, 2024

New triple term semantics in the rdf-semantics spec #55

Are you sure you want to change the base?

New triple term semantics in the rdf-semantics spec #55

Conversation

franconi commented Dec 2, 2024 • edited by pr-preview bot Loading

💥 Error: 500 Internal Server Error 💥

gkellogg left a comment

Choose a reason for hiding this comment

franconi commented Dec 2, 2024

gkellogg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gkellogg Dec 2, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

afs left a comment

Choose a reason for hiding this comment

TallTed commented Dec 3, 2024

franconi commented Dec 3, 2024

afs commented Dec 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

franconi Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

franconi Dec 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

doerthe commented Dec 6, 2024

franconi commented Dec 2, 2024 •

edited by pr-preview bot

Loading

gkellogg Dec 2, 2024 •

edited

Loading

franconi Dec 6, 2024 •

edited

Loading

franconi Dec 6, 2024 •

edited

Loading