Email exchange with Pat Hayes, part 1

Folks,

Below is the email thread of a discussion some of us had with Pat Hayes earlier this summer. There were some messages that followed that did not embed the whole message trail, I will send those separately to the list after this.

Ora

--
Dr. Ora Lassila
Principal Technologist, Amazon Neptune


----- Forwarded Message -----
From: Patrick J. Hayes <phayes@ihmc.org>
To: 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>; Pierre-Antoine Champin <pierre-antoine@w3.org>
Sent: Monday, June 23, 2025 at 12:31:14 PM EDT
Subject: Re: apologies and questions




On Jun 16, 2025, at 12:15 PM, Ora Lassila <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?

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.

2/ An rdf:assert predicate with semantic bite has been discussed. There is no bar against just having the triple term as a triple in the graph as in:
_:reifier rdf:reifies <<( :a :b :c )>> .
:a :b :c .

I agree. But...


An RDF triple encodes a proposition — a simple logical expression

…whoah. Do you really mean that a proposition is a logical /expression/? A syntactic entity? Surely that would imply that the proposition denoted by a triple term IS that same triple. (If not, then you need to specify the syntax of this other language of which it is an expression…) And that renews my anxiety about nonwellfoundedness (this time of the actual syntax, so one cannot appeal to the name->object->extension trick that RDF uses to avoid this issue with properties.)

, describing a relationship between two entities. An asserted triple is a claim that the corresponding proposition is true. Propositions are defined as elements of the domain that are the interpretations of triple terms.

Yes, exactly. But again:


Each specific occurrence of a proposition (a token)

What do you mean here by 'occurrence' and 'token'? This language suggests that the things being denoted are syntactic in nature. It does not make sense to talk about occurrences or tokens of, say, people or cities or numbers or other elements of typical semantic universes, and it does not make sense to use this language when talking about propositions, either.  For example, numerals are syntactic entities which denote (abstract) numbers. It makes sense to make a type/token distinction when talking about numerals, and to ask what the grammar of numerals might be. None of that makes sense when talking about numbers.

With the semantics as written now, not only do triple terms and reifiers not denote tokens, even the way they refer to triples is transparent to equality, so that for example (forgive the careless syntax)

x:what rdf: reifies (:a :p :b) .
:Bill :asserted x:what .
:b owl:sameAs :zzzz .

entails

:Bill :asserted (:a :p :zzzz)

regardless of whether or not poor Bill actual knew anything about :zzzz.

is denoted by a reifier, namely the subject of an rdf:reifies triple.

Is the reifier the actual syntactic subject, or what that subject denotes? If the former, you will need to be very exact about bnode mappings in the truth conditions when the syntactic subject is a bnode, since interpretations do not, of course, specify a denotation for bnodes. If the latter, then you seem to be putting IRIs into the semantic universe, which might be a good idea but isn't what the semantics says.

Either way, talking about propositions is stepping into a can of worms. My advice would be to not mention propositions at all. I don't think you actually need to. But if you must, then first decide exactly what kind of thing they are, and then stick to that decision. (FWIW, the Stanford Encyclopedia of Philosophy isn't sure what they are, either: https://plato.stanford.edu/entries/propositions/ )

3/ The main difference with RDF 1.1 reification is the introduction of a distinction between a triple term denoting an abstract proposition and its reifiers denoting specific occurrences (tokens) of the abstract proposition (only the latter is provided by “old-style” reification).

This sounds muddled to me. The phraseology "specific occurrences (tokens) of the abstract proposition" is meaningless, a category mistake, as I mentioned above. Abstract propositions are not the kinds of thing that have occurrences or tokens. That terminology applies to linguistic, syntactic, entities rather than abstract ones.

But in any case, I do not see anything in your current semantics which justifies the claim you seem to be making here, even if the terminology "token of a proposition" could be made coherent. Where is this type/token distinction mentioned in the semantics? (If you are thinking about the difference between elements of the domain and range of the new RE function, that does not cut it.)

By the way, old-style reification deliberately, by design, did not mention or introduce 'propositions' at all, let alone their tokens or instances. It defined a reification as denoting an actual triple instance, ie a syntactic object, then interpreting the component names of that syntactic triple in "a two-stage interpretation process: one has to interpret the reified node - the subject of the triples in the reification - to refer to another triple, then treat that triple as RDF syntax and apply the interpretation mapping again to get to the referent of its subject." (quote from RDF Semantics 2004). This puts syntactic things into the semantic domain, so that talk of tokens vs types makes sense, and there is no need to even mention anything called a "proposition". And in fact, again by design, we chose to make them instances – tokens – rather than abstract triples. That was an arbitrary choice as far as I was concerned –  we could have gone either way and it did not change the truth conditions in the semantics – but TimBL wanted reified names to refer to things that have dates, are part of documents, have provenance and so on.


Of course what was missing was, there was no way provided to actually attach a name to a triple token, as this was considered outside the scope of RDF at the time, for no rational reason I could ever discover. The 2014 spec is more explicit about this being external to RDF, using the newly introduced terminology of an IRI "identifying" something rather than referring to it. But if we had been allowed to use a construction like ":name rdf:reifies (:a :p :b)" then the triple term would have referred to itself (either considered as a triple or as a token of a triple) and rdf:reifies would simply have been equality; indeed in 2014 we could have allowed users to write owl:sameAs instead. All of which seems to me to be the simplest and most intuitive way to handle reification.

In RDF 1.2 there may be more reifiers for the same abstract proposition,

OK. (That was of course also true in earlier versions.) But...


and the same reifier may reify more than one triple term.

…not OK, if I follow you. Do you mean that one name (triple term) can refer to multiple referents, ie that names are ambiguous in a single interpretation? That would be a fundamental design mistake. But if you don't mean this, what do you mean?


Moreover, the working group was chartered to add RDF-star’s embedded triples or equivalent: with the addition of triple-terms, RDF 1.2 reification requires a single asserted triple (a reifying triple) where “old-style” reification required 4 asserted triples, with more opportunities for mistakes or ill-formedness (e.g. missing or duplicate value for rdf:subject)

I will not even attempt to defend 1.1-style reification. But if 1.2 claims backward compatibility, it had better check the semantics carefully. The intended interpretation of old-style reification was described fairly carefully (if not mathematically) in both the 2004 and 2014 specs.


4/ This was discussed by the group, but the conclusion was that reification of (sub)graphs is beyond the charter of the working group.

I understand. Sigh.


Also, while RDF-star (and other earlier variants) have already been implemented and used to annotate/reify individual triples, the group felt that it lacked hindsight and implementation feedback to standardize reification of graphs.

But naming of graphs has been in many, perhaps most, implementations for years now. And that is all reification is, at bottom.

However, the group was careful to leave the door open to leverage triple terms to represent some form of reified graphs (see below).

5/ rdf:reifies is just one possible property. A triple with a property different from rdf:reifies and with a triple term as object is both syntactically permissible and causes no semantic problems.

OK. But as an aside, if you allow triple terms as objects, why not also as subjects? One can get the same content by using owl:sameAs and a bnode, but it is awkward. This seems like an artificial restriction imposed for no good reason, like prohibiting literals in subject position.


For example, it could be used by a future WG to give a possible RDF semantics to named graphs.

I don't see how. A triple term can't specify a multi-triple graph. Even if the future WG were to invent a syntax which allows 'graph terms' (like a form of bracketing, perhaps, or a quad-based syntax), this would require redefining the syntax, so would be a whole new language (RDF 1.7?) rather than a semantic extension of 1.2. And wIth your semantics, the only entities that can be reified are single triples in any case, so the semantics would also need to be re-vamped..

6/ As you say, currently there is no way to make connections between propositions and truth in an interpretation
But the simple semantics could be extended in different ways to support such a connection. We did consider a modal extension of the semantics unsuitable for simple RDF, due to its complexity.

I agree about the unsuitable complexity of a modal semantics.


NOTE: for an extensive set of examples of reification in RDF 1.2 see the document "RDF 1.2 reification examples": https://github.com/w3c/rdf-star-wg/wiki/RDF-1.2-reification-examples


Thanks, that is very useful.

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.

Pat



Regards,

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

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




On Friday, May 23, 2025 at 07:12:33 PM EDT, Patrick J. Hayes <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