Email exchange with Pat Hayes, part 2

More correspondence.


----- Forwarded Message -----
From: Pierre-Antoine Champin <pierre-antoine@w3.org>
To: Patrick J. Hayes <phayes@ihmc.org>; Ora Lassila <ora@lassila.org>
Cc: Enrico Franconi <franconi@inf.unibz.it>; Peter F. Patel-Schneider <pfpschneider@gmail.com>; Doerthe Arndt <doerthe.arndt@tu-dresden.de>; adrian.gschwend@zazuko.com <adrian.gschwend@zazuko.com>
Sent: Thursday, June 26, 2025 at 07:51:22 AM EDT
Subject: Re: apologies and questions


Dear Pat,

first of all, thanks a lot for this feedback :)

Below are some quick reactions to some of your comments.
(the other commends will require more thoughts...)
On 23/06/2025 18:31, Patrick J. Hayes wrote:



On Jun 16, 2025, at 12:15 PM, Ora Lassila <ora@lassila.org><mailto:ora@lassila.org> wrote:

Pat,

we (a subgroup of the RDF-star WG) have discussed your questions, and below are our answers; sorry this took a while. I understand that you have further concerns following your discussions with Peter, and we are interested in learning what those are and discussing them with you.

I will take up that in a separate email. This is to respond to the responses below, in-line.

(Apologies for my delay in replying, I am somewhat distracted by family illness issues right now. I will get the other email to you in a few days.)





1/ Having an IRI for the subject of an rdf:reifies triple that is a component of the triple term object is possible and semantically it causes no more problems than the triple :a rdf:type :a. : there is no recursion or non-well-foundedness involved.
OK.


Triple terms can indefinitely nest; this is to allow for graphs like:
_:b rdf:reifies <<( _:a rdf:reifies <<( :s :p :o )>> )>> .
_:a prov:invalidatedAtTime "2024-09-02T01:31:00Z"^^xsd:dateTime .
_:b prov:wasAttributedTo :lab-technician-FE-56 .

without having either <<(:s :p :o)>> nor <<(_:a rdf:reifies <<(:s :p :o)>>)>> being asserted.

But what can possibly be the objection to asserting  <<(_:a rdf:reifies <<(:s :p :o )>> )>> ? All it does is give a name to a triple for internal book-keeping purposes, as it were. How can such an assertion become invalidated, when it has no bearing on anything substantial? And if (as in your graph) it was never asserted in the first place, how can it even be called into question at all?

I see your point, and I agree that the example above may be a bit confusing (there is no real value in retracting a reifying triple).

But the important point is elsewhere: the primary role of a triple term (nested or not) is not to avoid asserting the triple; it is to be able to talks about that triple (or more accurately, about the proposition it encodes...).

So if we want to talk about a reifying triple (or any triple containing a triple term, actually), we need to be able to use that nested triple as a triple term. I hope this clarifies our position.

But whatever, I agree these strange things do not cause any real problems.


Forbidding reifying triples to be themselves reified felt against the general spirit of RDF of “being able to say anything about anything”.

True. But one needs to balance this against the possibility of creating user confusion when intended meanings become very obscure. For example, was your use of blank nodes throughout the above example intentional, and was it intended to convey some subtle point that an example using IRIs would have failed to capture? I am honestly not sure what you had in mind.

Reifiers will be, in many cases, minted implicitly as a fresh blank node, because the emblematic double-pointy-bracket of RDF-star
    << :s :p :o >>
are now syntactic sugar equivalent to
    [ rdf:reifies <<( :s :p :o )>> ]

So we expect that most reifiers will be blank nodes -- although we also provide syntactic sugar to explicitly name them with blank node labels or IRIs.
(...)
And thanks to y'all for responding so politely to my rant, and I apologise for its tone. I was writing to ORA, you understand.

:-D

  pa

Pat



Regards,

- Ora (on behalf of all the people cc'd on this email)

--
Dr. Ora Lassila  ora@lassila.org<mailto:ora@lassila.org>  https://www.lassila.org/




On Friday, May 23, 2025 at 07:12:33 PM EDT, Patrick J. Hayes <phayes@ihmc.org><mailto:phayes@ihmc.org> wrote:


Hi Ora

First, sincere apologies for missing your exposition earlier today. Contrary to Margaret's theory, I really did want and intend to be there, but either I failed to set the alarm correctly or I slept right through it. So I will try to give you here what I would have said if I had been there.

I have many niggles with the way that the 'concepts and abstract syntax' document is written and organized, but most of that is just to do with potentially misleading or poorly worded claims, just editorial stuff. If you like I could detail them in another email. But there are a few things that are more serious.

1. As far as I can tell, this is both syntactically legal and satisfiable:

:name rdf:reifies ( :a :b :name) .

and so, by the way, is this:

_:x rdf:reifies ( :a :b _:x) .

Is this kind of infinite-recursion intentional? What does it mean? It looks like it must define either an infinite chain of reification or a circular self-reifying structure; but the latter is ruled out by the text.

On a related question, the spec allows, and takes pains to point out, that triples can be nested more than two deep, like this:

:name rdf:reifies (:a :b (:c :d :e))  ( or perhaps only  :name rdf:reifies (:a rdf:reifies (:c :d :e))  ?)

Either way, what is the point of allowing such a barbaric construction? Is there an intended use case for this?

2. Also as far as I can tell, after giving an, ahem, proposition a name, there is no way to assert that triple using the name. So you can't do something like this:

:name rdf:reifies ( :a :b :c) .
…
rdf:assert :name .

Is this deliberate? Why? Surely this would be a useful construction; but more to the point, if you can't assert it, it seems rather a stretch to call it a 'proposition'.

3. Again after a quick read, the semantics of your reification seems mirror exactly that of the old reification mess from RDF 1.0. If I have this right, then all of this amounts to just syntactic sugfar for that old construction. Which is I guess is harmless, but to describe it as a missed opportunity would be a huge understatement.

4. While we are talking about missed opportunities, WHY IN GOD'S NAME didn't you allow reification of subgraphs rather than single triples? First, it is a trivial extension. Second, it would allow OWL/RDF to give a name to a single OWL assertion which becomes a 2- or 3-triple subgraph when written in RDF; in your framework, this is impossible, which completely breaks the (painfully achieved) alignment of RDF and OWL. And third, you would then have re-invented a semantic version of named graphs (in the original sense used by Carroll et al in https://www.researchgate.net/publication/225070307_Named_Graphs_Provenance_and_Trust) and could have adopted both the terminology and the semantics from that old (and award-winning :-) paper, one that is somewhat superior to (and much simpler than) yours.

5. The document says that any triple with another triple as object SHOULD have the property rdf:reifies. But it does not say MUST, so you do allow triples-in-triples using other properties. But you don't say what they mean: the semantics seems to only apply to the reifying triples, as far as I can see. So there are syntactically legal (although tut-tutted) RDF 1.2 expressions that have no RDF 1.2 semantic meaning. That has got to be fixed before publication.

6.  OK, now for my main beef. This one is serious. The semantics you have creates entities called "propositions" to be the denotations of triples, and it puts enough of them into the universe to ensure that any reified triple name will have one to denote. But (see 2. above) it doesn't give them any other role, in particular they don't have any relationship to the denotations of the triples they are derived from. And so they don't have any relationship to the truthvalues of those triples in any interpretation. No matter what else is asserted about these propositions, none of that can influence or modify in any way the interpretation of the triple itself.
This means that a lot of what you claim about how RDF 1.2 can be used is just flat wrong. In particular, something like this, that is supposed to qualify or enrich an assertion by saying something about when it is true, cannot possibly work:

:Richard :married :Liz .

:CrazyLove27 rdf:reifies (:Richard :married :Liz .)

:CrazyLove27 :during "1964-1974"^^:datatypeForTimeIntervals .

because there is NO SEMANTIC CONNECTION between the truth-values of the first and third triples.

FWIW, this topic did briefly surface in the first RDF WG back in 2003-2004, and I spent about an afternoon trying to see what it would take for an RDF semantics for reification to actually allow for nontrivial semantic connections like this, and decided that it would need some kind of Kripke modal possible-alternative-worlds semantics, and that that was way above my pay grade for RDF.

————

OK, I could go on, but this will do for now.

(Obviously, when in the above I refer to you, your, etc.., I mean the working group, not you personally.)

Pat