Email exchange with Pat Hayes, part 3

I believe this is the last one.


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


Hi again Pat,

to answer the comments that I left unanswered in my previous email, I think it is better to give you some context.

Very early on (i.e. when the Community Group started discussing RDF-star), we realized that, when people used the `<< :s :p :o >>` notation, the had many different things in mind, e.g.

  << :liz :married :richard >> :source <data.ttl> .
  << :liz :married :richard >> :in :montreal .
  << :liz :married richard >> :duration "P9M19D"^^xsd:duration .

In those examples, the intended meaning of the triple terms are clearly very different: a token of a triple, a wedding, a marriage (not to mention that Liz and Richard were notoriously married twice, creating even more ambiguity...). This contrasts with IRIs and literals, which are assumed to have a shared meaning across all RDF graphs.

The Community Group's response to this realization was simply to warn people about this and encourage them to use a level of indirection<https://www.w3.org/community/rdf-dev/2022/01/26/provenance-in-rdf-star/> rather than overloading triple terms. The Working Group went even further, re-defining the well-known RDF-star syntax (`<< :s :p :o >>`) to automatically create that level of indirection.

So, while in RDF-star `<< :s :p :o >>` represented triple terms, in RDF 1.2 those triple terms are now represented by `<<( :s :p :o )>>`, but people are expected to very rarely use this notation, and to prefer the syntactic sugar `<< ... >>` and `{| ... |}`.
This is similar to RDF collections, where people are not expected to use rdf:first and rdf:rest directly, but rather to the syntactic sugar `( ... )`.

So now, the three examples above actually expand to:

  [ rdf:reifies <<( :liz :married :richard )>> ]   :source <data.ttl> .
  [ rdf:reifies <<( :liz :married :richard )>> ]   :in :montreal .
  [ rdf:reifies <<( :liz :married richard )>> ]   :duration "P9M19D"^^xsd:duration .

Now the 3 subjects are 3 distinct blank nodes, which can safely represent three different entities of different kinds. In fact, the rdfs:domain of the properties :source, :in and :duration could be used to help determine the type of each of these blank nodes. Conversely, those 3 different entities are all described by the same entity, denoted by the triple term <<( :liz :married :richard )>>.

To support the variety of use-cases above, we deliberately do not constrain what the reifiers (the subjects of rdf:reifies) denote -- in other words, the domain of rdf:reifies is not constrained. Arguably, this makes this new kind of reification semantically more flexible that old-style reification, which constrained the subject of rdf:subject & co. to be an instance of rdf:Statement. Granted, this had no impact on the models, but the intended meaning of rdf:Statement was constrained ("a concrete realization of an RDF triple, such as a document in a surface syntax").

On the other hand, we did want to somehow constrain the intended meaning of triple terms themselves. In particular, the thing denoted by a triple term is entirely determined by the denotations of its components (which is captured by the RE mapping). We also wanted to define and name a specific class for the things denoted by triple terms, even if this class is not further constrained by the semantics. The goal is mostly to send a signal: people should not feel free to assign arbitrary meaning to triple-terms (as they would for IRIs), as it would hinder interoperability as illustrated above. Instead, people should use reifiers.

After long discussions, the term "Proposition" was chosen to describe this class of "things denoted by triple terms". I read the concerns and questions you had about how we describe this class (especially the issues with the terms "expression", "token" and "occurrence", and I agree that there is room for improvement here...).

Now, on some of your specific questions:
On 23/06/2025 18:31, Patrick J. Hayes wrote:
[///]
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/ )
Could we not just decide that rdfs:Proposition encompasses all the subtle variants described by the Stanford Encyclopedia of Philosophy, but nothing else ?? :)


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.
Agreed; I believe this improper use of the terms "occurrence" and "token" comes from early discussions in the CG, where we identifies that "several occurrences of the same triple term are used to denote different things". Then, our use of those terms shifted from the syntactic level to the semantic level. This is a WG-idiosyncracy, which fortunately didn't leak in our specifications (as far as I can tell). But unfortunately, it leaked in our response to you. Apologies for that.


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.)

[...]

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?
That's not what we mean.

What we mean is that rdf:reifies is not meant to be a functional property. One thing may reify several propositions, so the following is possible:

  <#g1> rdf:reifies
    <<( :s1 :p1 :o1 )>>,
    <<( :s2 :p2 :o2 )>>.

Of course, "reifying multiple propositions" is not something that makes sense for all reifiers... but we wanted to leave this option open (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?
This was also a long and difficult discussion, on which we didn't find consensus -- we had to resort to a chairs decision<https://lists.w3.org/Archives/Public/public-rdf-star-wg/2025Mar/0020.html>.

One can get the same content by using owl:sameAs and a bnode, but it is awkward.

One of the arguments is that people are expected to use reifiers much more often than triple-term, and reifies are allowed in the subject position. So this awkwardness should occur only very rarely if at all.
This seems like an artificial restriction imposed for no good reason, like prohibiting literals in subject position.
...and yet... :-/
(to be clear, at heart I'm in favor of allowing literals and triple terms in the subject position, but I had to make my peace with this)


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.

No, of course. But a graph could be described with a collection of triple terms, e.g.

  <#g> rdf:reifies <<( :s1 :p1 :o1 )>>, <<( :s2 :p2 :o2 )>>.

or potentially, if one wants to close the set of triples

  <#g> rdfs:triples ( <<( :s1 :p1 :o1 )>> <<( :s2 :p2 :o2 )>> ).

As stated in out previous email, this is considered out of scope for the WG, so we did not explore these options in details, but we made a point of keeping them open by
- by allowing rdf:reifies to have several objects for the same subject, and
- by allowing triple-terms to be used as objects of other properties than rdf:reifies

  best,

  pa