explain that rdf:reifies is deliberately abstract

[pchampin]

• I moved out the first part of the "note" at the end of §1.5; it felt like it was more than an aside
• I added a paragraph explaining that rdf:reifies is deliberately underspecified

I hesitated explaining that a more specific relationship between (the denotee of) the reifier and the proposition could be derived based on the specific nature of the former, but I considered that it was a bit too much for an intro (§1.5 is quite long already).

---

Preview | Diff

[niklasl]

👍 (nit-pick suggestion optional)

[rat10]

I find the logic and intuition behind the added paragraph flawed.

A reifier creates a reference to a proposition. That reference can then be used in many different ways, but it still predominantly references the proposition. For example in the following graph

:r rdf:reifies <<( :s :p :o )>> ;
   :b :c ;   # maybe a statement or belief that the proposition holds
   :v :w ;   # maybe an event or circumstance that makes the proposition true
   :y :z .   # maybe additional detail, or provenance, or something else entirely

one can take away :b :c, :v :w or :y :z and there is still some useful information about :r, but if one takes away rdf:reifies <<( :s :p :o )>> then it's completely unclear what the graph is talking about. The example illustrates that the domain of rdf:reifies is first and foremost a reference to the proposition in object position. Anything else to be said about :r comes second.

Imagine the spec would declare that rdf:type is not foremost a typing relation because the subject in its domain may be annotated, used, understood, etc in so many ways old and new and unforseeable even. That wouldn't make much sense either. But while a type is just a type, the rdf:reifies relation describes the very essence of its subject: the proposition to be annotated.

The added paragraph alsp makes no sense from the standpoint of monotonicity: no further annotations can alter what rdf:reifies creates, namely a reference to a proposition. That's its meaning, irrespective of how the reifier so created is then used.

Therefore the proposed paragraph not only doesn't make sense, but is outright wrong. It produces a skewed impression of what is really going on. To the contrary it would be much better if the specification limited itself to clearly stating what the reifier stands for: a reference to the proposition encoded in the triple term it reifies, plain and simple.

[pchampin]

I find the logic and intuition behind the added paragraph flawed.

A reifier creates a reference to a proposition.

No. That's not what RDF concepts nor RDF semantics are saying.
What they are saying is that the triple term itself references (denotes) a proposition.
Reifiers, on the other hand, can denote many things different kinds of things (as was already written in RDF concepts before this PR).

Could you point to any part of the specification that gave you the impression that a reifier references a proposition?
If anything, that's the part of the specification that we need to clarify.

[rat10]

I find the logic and intuition behind the added paragraph flawed.
A reifier creates a reference to a proposition.

No. That's not what RDF concepts nor RDF semantics are saying. What they are saying is that the triple term itself references (denotes) a proposition. Reifiers, on the other hand, can denote many things different kinds of things (as was already written in RDF concepts before this PR).

Could you point to any part of the specification that gave you the impression that a reifier references a proposition? If anything, that's the part of the specification that we need to clarify.

No, I'm saying that the specification is wrong, and I explained above why.

[w3cbot]

This was discussed during the #rdf-star meeting on 11 September 2025.

View the transcript

w3c/rdf-concepts#237

<gb> Pull Request 237 explain the rdf:reifies is deliberately abstract (by pchampin) [needs discussion]

pchampin: This is the counter part of the one we just discussed, in the hope of clarifying everything on reifiers

tl: I have been reading though specs in the last days, I came to the conclusion that semantics is indeed not the place to specify rdf:reifies and the reification process. The schema is a very lean definition of rdf:reifies so it should be in concepts. But it's even more vague than I though, I made a PR to state my understanding.

<gb> Pull Request 144 No connection between propositions and facts in model-theoretic semantics (by rat10) [ms:CR] [spec:enhancement]

<gb> Issue 144 [Editorial] capitalization of "SPARQL string", "SPARQL Query string", and "SPARQL Update string" (by TallTed) [documentation]

tl: I worry that the current state is too vague. I disagree it's a feature, not a bug

tl: I made that rdfs:state proposal, I am fully aware it won't be part of this spec but maybe in the future

tl: In the way it's done now, all the semantic is in the triple term

<Zakim> Enrico, you wanted to comment on closing PR #144 in RDF-Semantics w3c/rdf-semantics#144

<niklasl> +1 for closing that now

Enrico: I think w3c/rdf-semantics#144 should be closed without actions

pfps: I completely disagree, the wording in concept is adequate, at this point the way ahead is either to vote that everything is fine or have a competing proposal as a PR, then the WG in a very short time could vote to accept it or not

pchampin: tl, our disagreement seems to rely on "reifier denote proposition". There is nothing in either spec that justify that

tl: you are right, it's not there but it should be

<niklasl> It should not be.

pchampin: I disagree, if it should, it should be in SEMANTICS. Denotation is the business of SEMANTICS. You said you agree on what SEMANTICS said

Souri: Just to make sure, we are talking about concepts section 1.5

Souri: For readers, is it possible to put a tiny example when you are defining "triple annotation". It always help. I am not sure if the document is the right place but it would be very helpful

<pchampin> https://www.w3.org/TR/rdf12-concepts/#fig-asserted-triple-term is such an example

ora: I like that

tl: I came to the conclusion that SEMANTICS is a very abstract document. The semantics define the proposition but CONCEPT defines the triple terms.

tl: I hope you can define the semantic via rdf:reifies

tl: The triple term would be the encoding of the proposition. That's it. Everything else can be defined with rdf:reifies, allowing other properties to define something else

AndyS: The section 1 is informational, it does not define anything. The semantic comes from triples, not individual terms.

<niklasl> +1 to AndyS ; I agree that it does not stop any other use of triple terms.

Enrico: This is an explanation, saying what triple terms are in 1.5

Enrico: This does not say you can't have properties for whatever you want.

<Souri> It will be nice to have a single example in 1.5 (of Concepts spec), for illustration purposes: showing say three reifying triples (two of them sharing the same reifier) and then pointing out the reifying triples, the reifiers, and the triple annotation.

Enrico: I would propose this to close it today

<niklasl> also +1 to Enrico; it explains an expected use.

<niklasl> See w3c/rdf-schema#62 which adds explanation to rdf-schema (in draft state since we first need Concepts stable).

<gb> Pull Request 62 Align Triple-term reification text with Concepts section (pending CR) (by domel)

lisp: The language introduced in the diff, does not help the reader. The structural relationship says nothing about the interpretation. Any interpretation is left to the application.

tl: With rdfs:state, it would not be a problem, it would be a stronger definition. In case of rdfs:mention, and in no way endorses it, I fear is not possible. Concept says "the triple term encode the proposition, if it is asserted in the graph, it also refers to that".

pchampin: It is generic in the sense that the semantics does not enforce any structure on the property. Every property denote something in the interpretation. The question is that if it's constraint on not by the spec. rdf:reifies is not really constraint outside of its range

pchampin: As pfps suggested, if there is enough support for the PR I put, I propose we merge

pchampin: It seems we agree there should be a paragraph on rdf:reifies. If James can make a PR if you think of a better term than "generic", it would be welcome

Enrico: To answer to James, if we look the text at section 9, there was a notion of type and class. There was a missing part were we talk about rdf:reifies and proposition. What about talking more on rdf:reifies? In RDFS we have more properties related to classes and types, that refers to these concepts

Enrico: We have rdf:reifies that uses the concept of proposition. But it's not used anywhere else, so you can't say more about it.

Enrico: We have a special property rdf:reifies for the users to introduce the reifiers, but it's not formal

Enrico: In semantics we should not say more than we say about class, but then there are the usual patterns

<Zakim> pfps, you wanted to state that I see no reason that "mention" is precluded

Enrico: I think we cannot do much more in section 9 because there is no structural properties. On the other hand, it's interesting to do a good job on RDF concepts

pfps: I am puzzled as why there is anything in our documents that prevents "mention"

ora: To clarify, the thing that worries me is that we venturing again in the temporal progression of the graph, which is completely outside of what we are considering

tl: I am talking about view points, not endorsed statement

lisp: The core of my concern is that the annotation that are applied to the subject of the reifying statement have no necessary bearing on the assertion of the proposition in the graph

<Enrico> to lisp: I blelieve that your concern is addressed in section 1.5 of RDF concepts

lisp: Enrico, post a very short message to the WG about if assertions on the subject of the reifying statement are intended to be assertions on the reifying statement [badly worded, please fix]

<Enrico> my answer: section 1.5

pchampin: tl, about weaker properties than rdf:reifies, a triple does not endorse an other triple. A graph can endorse/entail a given triple. A reifying triple cannot endorse the reified triple

<niklasl> +1 to pchampin

<pfps> ditto

<Enrico> +1 to pchampin

---

[franconi]

I propose to modify:

It should also be noted that, because of the diversity of use cases that reifiers aim to serve, the meaning of the rdf:reifies property is deliberately generic.

to

It should also be noted that, because of the diversity of use cases that reifiers aim to serve, the type of the denotation of the rdf:reifies property is deliberately generic.

[hartig]

@franconi how strong would you push for this change that you are proposing?

The reason for asking: to me, talking about "the meaning of the rdf:reifies property" is something that shouldn't be difficult to grasp by many readers, whereas talking about "the type of the denotation of the rdf:reifies property" is something for which I assume that many readers have a much harder time understanding.

So, is your proposal meant in a way to fix something that you would otherwise consider as completely wrong or misleading, or is it more about trying to be as accurate as possible?

[niklasl]

I agree with @hartig on the current formulation; but @franconi, did you mean that the type of the denotation of the reifier is deliberately generic? Or the domain of the denotation of rdf:reifies? (Since its type is the class denoted by rdf:Property...)

[franconi]

OK, ok. I agree with @hartig.

[afs]

Could you point to any part of the specification that gave you the impression that a reifier references a proposition? If anything, that's the part of the specification that we need to clarify.

I'm saying that the specification is wrong, and I explained above why.

@rat10 - do you agree that your review comment relates to the overall design? and that this PR explains the design, not change the design (as per response #237 (comment))?

[pchampin]

FTR, I just rebased this PR on top of the latest main branch.

The comment now includes an extensive list of "example use cases for reifiers", because this list is no more present in the section. I also adapted a word in the next paragraph for consistency.

[rat10]

Could you point to any part of the specification that gave you the impression that a reifier references a proposition? If anything, that's the part of the specification that we need to clarify.

I'm saying that the specification is wrong, and I explained above why.

@rat10 - do you agree that your review comment relates to the overall design? and that this PR explains the design, not change the design (as per response #237 (comment))?

No, but I allowed the discussion to be side-tracked. I'll resume it in a reply to @pchampin .

[rat10]

I find the logic and intuition behind the added paragraph flawed.
A reifier creates a reference to a proposition.

No. That's not what RDF concepts nor RDF semantics are saying. What they are saying is that the triple term itself references (denotes) a proposition. Reifiers, on the other hand, can denote many things different kinds of things (as was already written in RDF concepts before this PR).

I may have again gotten the difference between triple terms and propositions wrong, but that is not the point. Even for triple terms, and even if the range of rdf:reifies does not need to be constrained to triple terms, usage of the property characterizes its subject. It provides the essential hint about its identity. Everything else is secondary, is additional detail or annotation or "assertion on". If there is no characteristics whatsoever, then why not just use rdf:value? Or make rdf:reifies a subproperty of rdf:value to honor its more specific range?

Could you point to any part of the specification that gave you the impression that a reifier references a proposition? If anything, that's the part of the specification that we need to clarify.

I might be in too deep to not be biased, but it very much runs counter my intuition, and what I expect the spec to specify. I think that in the attempt to not get into troubles with the RDF semantics, the specification of triple terms and rdf:reifies has become so arcane that it doesn't cover expected real world usage anymore - which is reflected in the fact that the examples convey an intuition that the text doesn't support. However, and that is the really bad thing, the text isn't even outspoken about that divergence, but tries to be formally right AND meet peoples expectations.

[franconi]

Why you want to use rdf:value? It is clearly not appropriate; the spec defines it as follows:

The intended use for rdf:value is explained intuitively in the RDF Primer document [RDF-PRIMER]. It is typically used to identify a 'primary' or 'main' value of a property which has several values, or has as its value a complex entity with several facets or properties of its own.
Since the range of possible uses for rdf:value is so wide, it is difficult to give a precise statement which covers all the intended meanings or use cases. Users are cautioned, therefore, that the meaning of rdf:value may vary from application to application. In practice, the intended meaning is often clear from the context, but may be lost when graphs are merged or when conclusions are inferred.

At this point why do you complain to have rdf:reifies?

[rat10]

Why you want to use rdf:value? It is clearly not appropriate; the spec defines it as follows:

The intended use for rdf:value is explained intuitively in the RDF Primer document [RDF-PRIMER]. It is typically used to identify a 'primary' or 'main' value of a property which has several values, or has as its value a complex entity with several facets or properties of its own.
Since the range of possible uses for rdf:value is so wide, it is difficult to give a precise statement which covers all the intended meanings or use cases. Users are cautioned, therefore, that the meaning of rdf:value may vary from application to application. In practice, the intended meaning is often clear from the context, but may be lost when graphs are merged or when conclusions are inferred.

referring to the primary value of a resource it is clearly appropriate as i just explained in my reply to @pchampin above.

At this point why do you complain to have rdf:reifies?

well, i'm just pointing out that rdf:reifies is so vaguely defined - and so on purpose, as @pchampin is adament to claim - that i fail to see how it brings anything important to the table... but i'm repeating myself

[pfps]

It was decided today at the WG meeting to merge this PR. If anyone wants to discuss issues related to this PR, just open a new issue and point to this PR.