I disagree totally - as I told you several times.

This document advises to understand an assertion on a reified triple as an assertion on an asserted triple of the same form, if such a triple occurs in a graph as both a reified triple and an asserted triple. However, this understanding is not backed by the model-theoretic semantics as layed out in RDF 1.2 Semantics.

As I already replied to you at the last meeting, there is a precise and intuitive formal connection. Given the graph with the asserted triples:
:s :p :o.
:r rdf:reifies <<(:s :p :o)>>.
then in each model I of the graph the denotation of the reifier :r is connected via the denotation of rdf:reifies to the corresponding fact in that model, which is an element of F(I). Recall that facts in F(I) are exactly the propositions associated to each asserted triple in the graph, namely the propositions which are true in the model.

On this ground, I can not accept this PR.

@franconi

I disagree totally - as I told you several times.

I find your tone a bit harsh. I repeatedly asked for clarification but from you I only got "The specs are clear enough".

This document advises to understand an assertion on a reified triple as an assertion on an asserted triple of the same form, if such a triple occurs in a graph as both a reified triple and an asserted triple. However, this understanding is not backed by the model-theoretic semantics as layed out in RDF 1.2 Semantics.

As I already replied to you at the last meeting,

Similarly both my memory and the transcript don't mention any explanation.

there is a precise and intuitive formal connection. Given the graph with the asserted triples: :s :p :o. :r rdf:reifies <<(:s :p :o)>>. then in each model I of the graph the denotation of the reifier :r is connected via the denotation of rdf:reifies to the corresponding fact in that model, which is an element of F(I). Recall that facts in F(I) are exactly the propositions associated to each asserted triple in the graph, namely the propositions which are true in the model.

On this ground, I can not accept this PR.

Thank you for this explanation, and I agree that it contradicts what my PR says, and I'm fine with that. I really wanted to get clarification on what the semantics means (since I'm not semanticist enough to interpret with certainty what it says).

Would you be willing to turn what you said above into a PR for addition to the semantics document, or should I give it a try? I think it should be part of RDF 1.2 Semantics rather than Concepts because it is concerned with the model-theoretic foundation of that connection.

[Edit: wrong PR, I'll propose the same in Semantics PR 144]

This is not suitable for RDF Semantics either as it is not about semantics.

franconi's remarks are very much about semantics.

franconi's remarks are very much about semantics.

My remarks are about semantics indeed, but in this document, which just introduces the semantics formal definitions, there is no mention to the reification process, which is described in Concepts. So - if you want to keep my remarks - they should be integrated somehow in Concepts.

franconi's remarks are very much about semantics.

My remarks are about semantics indeed, but in [that] document, which just introduces the semantics formal definitions, there is no mention to the reification process, which is described in Concepts. ...

as reification is the principle change introduced to rdf by 1.2, unless one intends to introduce reification on the order of an entailment regime, its semantics should be described where everything else is described.

All — We need to figure this out. We're all smart people, even on our dumbest day, and we're talking about some very complex topics, and somehow talking past each other. I don't believe that anyone is intentionally misunderstanding nor misguiding another, but somehow disagreement is happening. I am hopeful that no-one in the WG will Formally Object to any of the documents when we reach CR or better, and moreso that we will reach actual consensus by transition time.

To that end: it seems inevitable that multiple people outside of our group will read things in the same way as @rat10 (et al), and others as @franconi (et al). I feel that it is incumbent upon all of us to try to read and understand all of our documents, and especially any documents where conflicting opinions persist about their content. This is the only way to arrive at the consensual interoperability of the powerful model we're specifying.

I repeatedly asked for clarification but from you I only got "The specs are clear enough".

Let us take it as read that the above is a paraphrase of what has been repeatedly said by multiple people to multiple people. I have witnessed such. Repeatedly, with varying actors reading the simple script, in different directions.

To be blunt: If someone recognizes that they don't understand something in the documents we've written, and asks an author or editor for clarification or further explanation of any kind — this is an absolute statement that that spec is not clear enough, and the person(s) being asked for clarification must work to bring the questioner to clarity, and then to edit the text of the specs such that the same clarity is delivered to other readers, without their needing to ask for more — because at that point the specs will indeed be "clear enough".

So: If @rat10's or @franconi's (or anyone else's) understanding of what we've written appears to differ from your understanding of what's written — please try to find where what we've written might be adjusted to bring their understanding to match yours (or vice versa). This must be a group effort, as the disagreements are longstanding, and despite many iterations over the text, they persist, with similar people on either side.

as reification is the principle change introduced to rdf by 1.2, unless one intends to introduce reification on the order of an entailment regime, its semantics should be described where everything else is described.

Triple terms are the principle change introduced, not reification. Reification via rdf:reifies is only a mechanism to help prevent users from making the same mistake as was made in the seminal example. Perhaps that is what is needed to be described in Concepts or, probably better, in a Primer or What's New document.

as reification is the principle change introduced to rdf by 1.2, unless one intends to introduce reification on the order of an entailment regime, its semantics should be described where everything else is described.

Triple terms are the principle change introduced, not reification. Reification via rdf:reifies is only a mechanism to help prevent users from making the same mistake as was made in the seminal example. Perhaps that is what is needed to be described in Concepts or, probably better, in a Primer or What's New document.

See my comment in PR #144 w3c/rdf-semantics#144

Since there seems to be agreement here that the semantics does specify what is required (that the facts of an interpretation are the propositions which are true in it), I hope there will be less disagreement (if any) on the way triple terms and reification is presented in Concepts. I also really hope that the work now done through #214 will clarify things in general in that section, for as many as possible.

Since there seems to be agreement here that the semantics does specify what is required (that the facts of an interpretation are the propositions which are true in it),

I still can't see how that is all that is required. My question is: how is it established in model-theoretic terms that an annotation on a reifier annotates an asserted triple in the same graph (if the reified triple term and the asserted triple represent the same triple)? And maybe, probably, that is a question best answered not in the Concepts but the Semantics spec, but that's another issue.

I hope there will be less disagreement (if any) on the way triple terms and reification is presented in Concepts. I also really hope that the work now done through #214 will clarify things in general in that section,

#214 is definitely a good step forward, and to me it seems quite acceptable now!

for as many as possible.

However, it doesn't answer the question of how exactly, i.e. in model-theoretic terms, the connection between a reifier of a triple term and an asserted triple of the same form is established. I have now two descriptions, one by @franconi above,

Given the graph with the asserted triples:

:s :p :o.
:r rdf:reifies <<(:s :p :o)>>.

then in each model I of the graph the denotation of the reifier :r is connected via the denotation of rdf:reifies to the corresponding fact in that model, which is an element of F(I). Recall that facts in F(I) are exactly the propositions associated to each asserted triple in the graph, namely the propositions which are true in the model.

one by @pchampin in a comment to WG issue #169 (scroll down to "but there is"),

A proposition is an element of the set { RE(x, y, z)｜x is in IR, y is in IP, z is in IR } . Such propositions are facts (i.e. true in the interpretation) if furthermore <x, z> is in IEXT(y) .

As for the (thing denoted by the) reifier, it is trivially connected to the proposition (as part of IEXTrdf:reifies, per the definition of a reifier in RDF Concepts). Et voila!

They seem to say the same thing, but I'm not convinced of the construction they describe (ie refer to), because in a way that connection between (reified) triple term and asserted triple still seems merely coincidental. Does that have the necessary semantic bite to establish a semantic connection between annotation and asserted triple with enough model-theoretic weight? I'm not sure, and that will take some more thinking on my side. Or maybe someone else can chime in.

And then there's the discussion if these clarifying comments can be reconciled into an additional explaining sentence or paragraph (to help those that are as lost as I am in this respect), and where such a sentence or paragraph should go (I lean towards the semantics specification, but we'll see).

@rat10, your previous comment contains two questions:

how is it established in model-theoretic terms that an annotation on a reifier annotates an asserted triple in the same graph

how exactly, i.e. in model-theoretic terms, the connection between a reifier of a triple term and an asserted triple of the same form is established

you seem to consider that they are two wordings of the same question. In the following, I will try to explain that they are not, that the response you got previously from @franconi and myself respond to the second one, and that the response to the first one is different (which might explain why you get the impression that we are contradicting each other or ourselves, and why other complain about your questions being "moving targets"). Apologies for a long comment.

The 2nd question is relatively general: it asks about "the connection" between the reifier and an asserted triple (or more precisely, between their denotees). The connection exists in IEXT(I(rdf:reifiers)).

Let me also point out something in the wording of question 2 that may explain why we keep misunderstanding each other: "an asserted triple of the same form [as the triple term]". Note that those things (the asserted triple and the triple term) are not two distinct entities that coincidentally have the same form: they are the same thing (an RDF triple) used in two different ways (once as a term, once as the element of the graph).

In a sense, distinguishing them is similar to distinguishing a subject IRI and an object IRI "of the same form". This distinction is irrelevant in RDF Semantics, because they are the same IRI, and so by definition always denote the same thing -- and so anything connected to "one" is connected to "the other".

The 1st question is unclear: the terms "annotation" and "annotates" are not currently defined in RDF-Concepts nor in RDF-Semantics (although a definition of "triple annotation" is given in #214). I don't mean to be pedantic, but you will not get precise answers to your questions until your questions are precise enough...

I assume that by "annotation on a reifier", you mean any triple (other than the reifying triple) that use a reifier as its subject (and possibly its object?).

I also assume that by "an asserted triple in the same graph" you mean to add "that is the same ("has the same form") as the triple term related to the reifier".

Then what you mean by "annotates" is also unclear. Let me take an example. Given the following graph

_:r rdf:reifies <<( :s :p :o )>> . # introduce the reifier
_:r :a :b . # the annotation on the reifier
:s :p :o .  # the reified triple is also asserted

what would it mean that "the annotation on the reifier annotates the asserted triple"?
If I had to guess, I would go for

<<( :s :p :o )>> :a :b . # in generalized RDF

but another (more literal) interpretation would be something like

<<( _:r :a :b )>> :annotates <<( :s :p :o )>>. # still in generalized RDF

Either way, the answer is no: RDF semantics does not provision for any of those inferences...

As a conclusion, I notice that those questions relate to the semantics, not RDF-Concept, so they rather belong to w3c/rdf-semantics#144, and I support @niklasl 's suggestion above to defer to #214.

@pchampin, thank you for the clarifications.

tl;dr It seems clear by now that the proposed reification mechanism does not provide for "statements about statements", as the WG charter asks for, but rather for something like "statements about (abstract) propositions". But what does that mean? The real moving target here is how the model-theoretic specification of the rdf:reifies mechanism is to be interpreted, and if that interpretation meets the requirement of the charter at least closely enough, with or without the help of examples and other operational means to define a semantics.

@rat10, your previous comment contains two questions:

how is it established in model-theoretic terms that an annotation on a reifier annotates an asserted triple in the same graph

how exactly, i.e. in model-theoretic terms, the connection between a reifier of a triple term and an asserted triple of the same form is established

you seem to consider that they are two wordings of the same question.

I think we should be in agreement that the WG is tasked to define "statements about statements", as its charter puts it. That should provide enough context to infer that the two sentences are intended to refer to the same issue. But you are right in that the first one is more precise than the second one in that respect.

In the following, I will try to explain that they are not, that the response you got previously from @franconi and myself respond to the second one, and that the response to the first one is different (which might explain why you get the impression that we are contradicting each other or ourselves, and why other complain about your questions being "moving targets").

What you describe in the following - and thank you again for the effort and precision - confirms to me that the current specifications don't define what the WG is chartered to define, but how exactly they deviate is not easy to understand. In that respect the moving target are indeed the specifications. Claiming that the spec says it all, as @franconi does, or that a PR is needed, as @pfps does, puts me in a position where I have to tediously probe for answers through successive proposals, asking from different perspectives, propose interpretations or even PRs. The question how the new mechanism differs from RDF standard reification - which is not only the most similar existing construct, but also pretty exactly defined - was not a moving target at all, but still didn't gather any clarifying response.

Apologies for a long comment.

The 2nd question is relatively general: it asks about "the connection" between the reifier and an asserted triple (or more precisely, between their denotee). The connection exists in IEXT(I(rdf:reifiers)).

Assuming you mean ÌEXT(I(rdf:reifies)) that is not a very precise definition. As @franconi explained elsewhere "reification" (which the verb "reifies" refers to) may also be called "objectification" or "thingification", but those are all rather abstract terms that don't mean much to a person trying to learn from the specification what this new mechanism means.

Let me also point out something in the wording of question 2 that may explain why we keep misunderstanding each other: "an asserted triple of the same form [as the triple term]". Note that those things (the asserted triple and the triple term) are not two distinct entities that coincidentally have the same form: they are the same thing (an RDF triple) used in two different ways (once as a term, once as the element of the graph).

In a sense, distinguishing them is similar to distinguishing a subject IRI and an object IRI "of the same form". This distinction is irrelevant in RDF Semantics, because they are the same IRI, and so by definition always denote the same thing -- and so anything connected to "one" is connected to "the other".

I accept that criticism, but note that we all sometimes use examples like :s :p :o . and the phrase "of the same form" is just another means to the same effect.

You bring out to an essential aspect: the difference between a triple and its application - although the way you use the term is rather akin to the newly introduced term rdf:Proposition: a triple in the abstract, without any commitment about its asserted-ness or any other form of application.
But indeed, to take up your thought, the reified triple (term) and the asserted triple may have the same triple in common, but neither does the reification refer to or even entail the assertion, nor does the assertion refer to or even entail the reification. There is no "connection" between them beyond being applications of the same triple (different applications of course). Crucially, the WG's charter to define "statements about statements" speaks about an application, namely assertions, not about the (abstract) triple (or proposition).

B.t.w. I used the term "connection" because it was used in some recent semi-public conversation between some editors and a well-known capacity in the field, and nobody in that conversation seemed to have any difficulty to understand what the term refers to.

The 1st question is unclear: the terms "annotation" and "annotates" are not currently defined in RDF-Concepts nor in RDF-Semantics (although a definition of "triple annotation" is given in #214). I don't mean to be pedantic, but you will not get precise answers to your questions until your questions are precise enough...

Since it seems that #214 has now been merged, there should not still exist any uncertainty about what is meant by an "annotation". The term has been used in this WG and the preceding CG without anyone ever questioning its meaning. See my remark above about the term "connection". Conversations like these need a little terminological wiggle room to be sustainable.

Also, it is still the task of specifications to translate what it formally defines into a language that users can understand and that describes in terms of users' expected intuitions and vocabulary what it specifies. A user is allowed a reasonable amount of imprecision. Using the term "annotation" or missing the difference between the two sentences above IMO is absolutely within reasonable limits, and can't justify calling my questions and sketches of possible understanding "moving targets".

I assume that by "annotation on a reifier", you mean any triple (other than the reifying triple) that use a reifier as its subject (and possibly its object?).

I also assume that by "an asserted triple in the same graph" you mean "that is the same ("has the same form") as the triple term related to the reifier".

Then what you mean by "annotates" is also unclear.

See above, but lets also reinforce that, as already mentioned, the task of this WG is to define "statements about statements". The two instances of the term "statements" in that quote indicate that they refer to the same category of things. We know without reasonable doubt that the first instance of the term in that quote refers to something that is also known as "asserted triples" or "facts". From that we can infer that the second instance of the term "statements" in that quote also refers to "asserted triples" or "facts". I.e. the WG is not tasked to define "statements about triples" or "statements about propositions" or "statements about reifications", but "asserted triples about asserted triples". The WG charter is specific and clear with respect to which specific application of triples it is concerned about. IMO that pretty well captures the expectations of users in both precise and intuitive terms.

Meanwhile it's getting clearer what that thing is that the specified mechanism allows to make statements about. It seems very much that it is not a statement in the sense that the charter uses the word, i.e. it doesn't denote a fact, an asserted statement as per your elaboration below. That's good to know (although not exactly reassuring), but what is it then? Saying that it is a reification/objectification/"thingification" in the rdfs:domain of rdf:reifies really doesn't describe much. In particular it leaves unclarified how an annotation of (i.e. assertion on) a reifier relates (i.e. connects to) an asserted triple (i.e. fact, "statement" in the WG charter sense).

Let me take an example. Given the following graph

_:r rdf:reifies <<( :s :p :o )>> . # introduce the reifier
_:r :a :b . # the annotation on the reifier
:s :p :o .  # the reified triple is also asserted

what would it mean that "the annotation on the reifier annotates the asserted triple"? If I had to guess, I would go for

<<( :s :p :o )>> :a :b . # in generalized RDF

Instantly no, because that <<( :s :p :o )>> would be the type. An instance of the type would be better, but even then it would still all be a proposition, not a fact (or where do you see assertion encoded in this example?), and would still not help dissolve my confusion about what it refers to.

On the other hand, take the 2017 version of RDF*, and add an identifier to refer to it as an instantiation:

<< :s :p :o ~ :r >> :a :b .  # RDF* from 2017

Here :s :p :o is asserted, and annotated. From a semantic standpoint this constitutes entailment. It is always said that entailment is out of reach for RDF simple, but did any implementers of RDF* complain? Who forces us to make the impossible possible? Why not just say that a sound solution requires entailment, but in this case that is a reasonable and practical demand?

And, btw, since this seems to be the main reason why many semanticists in this WG are opposed to a sound connection between asserted triple and annotation, did anybody get into trouble with Kripke'ian modalities? Or, for that matter, did singleton properties get? Does an ordinary n-ary relation, which maps the connection symbolized by the triple term to some blank nodes and an instance-of relation? No, not that I'm aware of in any of those cases. Which makes the contortions and indirections in the current specifications all the more suspect.

but another (more literal) interpretation would be something like

<<( _:r :a :b )>> :annotates <<( :s :p :o )>>. # still in generalized RDF

I'm not sure what that means.

Either way, the answer is no: RDF semantics does not provision for any of those inference...

Well, that was my take too when formulating the PRs, and I tried to build a golden bridge by describing how the lack of entailment (which would give a solid model-theoretic connection between "statement" and "about statement") is worked around by an "operational" convention. But it seems like @franconi vividly disagrees, so we'll have to see where this discussion goes. But thank you for confirming my assumption.

As a conclusion, I notice that those questions relate to the semantics, not RDF-Concept, so they rather belong to w3c/rdf-semantics#144, and I support @niklasl 's suggestion above.

I conclude that the gist of my PRs is correct, and therefore both Semantics and Concepts documents provide essential parts to what as a whole tries to define "statements about statements" without entailment. W.r.t. where exactly that is best discussed I'd still prefer the issue instead of PRs, but I will take the discussion over to the PR on RDF 1.2 Semantics.

Technical comment: I updated the PR according to TallTed's proposal. As in the meantime the spec was updated I had to resolve a conflict, and commit my updates to the "main branch". No guarantees that I did everything according to best practices. Apologies upfront if I messed things up!

Suppose that one actually wanted to make a closer connection between truth in an interpretation and triple terms in Semantics. The way to go would be to define the set of triples in an interpretation as the range (the mathematical range not the RDFS range) of RE and define IEXT as a subset of the set of triples. Then an asserted triple reifier of a triple term, x y z, in an interpretation is just a domain element, a, for which RE(a,IS(rdf:reifies),t) is in IEXT and t is in IEXT, for t = RE(I(x),I(y),I(z))).

But all this can already be done, simply by stating the above in terms of the current semantics somewhere (maybe in Semantics, maybe in Concepts, maybe in some other place). So Semantics already supports the notion of annotations of facts in an interpretation.

In fact, Semantics already includes part of this in its definition of the set of facts in an interpretation. So an asserted triple reifier in an interpretation is just the first element of a fact whose predicate is the denotation of rdf:reifies and whose object is also a fact.

EDIT: I believe that the right place to discuss assertions on facts is in Schema, as this is part of the intended meaning of rdf:reifies, and in tutorial material, to show how rdf:reifies is supposed to be used.

@rat10

@pchampin, thank you for the clarifications.

tl;dr It seems clear by now that the proposed reification mechanism does not provide for "statements about statements", as the WG charter asks for, but rather for something like "statements about (abstract) propositions".

I lack time to respond to all the points, but I strongly disagree with this first point.
Reifiers can describe many different things, including statements. The example below contains a statement about a statement.

<<( :s :p :o ~ :r1 )>> a rdf:Statement; dc:creator :alice; :source <another_file.ttl> .

From previous conversation, I suspect that this example will not satisfy you, as you are rather interested about "statements about statements from the same graph", but as you insist on the letter of the charter, I would argue that my example above does satisfies the charter.

Furthermore, the example can be easily adapted to talk about statements from the same graph, for example:

:s :p :o ~ :r2 {| a rdf:Statement; dc:creator :pchampin; :source <> |}.

(using the relative IRI <> to indicate that I'm talking about a statement in the very RDF document we are looking at).

What I suggest to do with an application-specific predicate (:source), it seems that you would like to define it in RDF semantics itself. Here are some reasons why I would disagree:

• it only makes sense for a subset of reifiers (those that denote "statements", as opposed to those that denote "events", "situations", "opinions"...)
• even this notion of "statement" will probably have subtle variations in different applications, for which different solutions will be needed (a statement in an RDF file is different from a statement in a triple-store, which is different from a statement that I make in English and that one may decide to encode in RDF...)

To strengthen the argument by @pchampin, let me rephrase his example using standard vocabularies:

@PREFIX prov: <http://www.w3.org/ns/prov#> .
@PREFIX dc: http://purl.org/dc/elements/1.1/>.

<< :s :p :o ~ :r1 >> a rdf:Statement; 
  dc:creator :alice ; 
  prov:invalidatedAtTime "2024-09-02T01:31:00Z"^^xsd:dateTime ;
  prov:PrimarySource <another_file.ttl> .

tl;dr It seems clear by now that the proposed reification mechanism does not provide for "statements about statements", as the WG charter asks for, but rather for something like "statements about (abstract) propositions". But what does that mean? The real moving target here is how the model-theoretic specification of the rdf:reifies mechanism is to be interpreted, and if that interpretation meets the requirement of the charter at least closely enough, with or without the help of examples and other operational means to define a semantics.

Either "statement" in the charter means instances of rdf:Statement, or is it some under-defined term that is up to the working group to define. I believe that it is not the intent of the charter to refer to instances of rdf:Statement so it is the business of the working group to come up with a suitable meaning for "statement". The coordination group report uses "statement" as a partial synonym for syntactic "triple" and as the informal notion of natural language phrases. (Notably the use of "statement" in the Turtle grammar is different from the meaning of "statement" elsewhere. The use of "statement" in N-Quads is closer.)

For quite some time RDF 1.2 has had annotations on reifiers of quoted triples, which appear to me to provide the ability to make "statements about statements".

@pfps said:

Suppose that one actually wanted to make a closer connection between truth in an interpretation and triple terms in Semantics.

IMO that would be even mandatory to fully carry out the WG's charter.

The way to go would be to define the set of triples in an interpretation as the range (the mathematical range not the RDFS range) of RE and define IEXT as a subset of the set of triples. Then an asserted triple reifier of a triple term, x y z, in an interpretation is just a domain element, a, for which RE(a,IS(rdf:reifies),t) is in IEXT and t is in IEXT, for t = RE(I(x),I(y),I(z))).

If I interpret this correctly it means that a reification of a triple term (vulgo: a reifier) is defined as entailing the triple iff that triple is also asserted. That sounds like a clever approach to me.

But all this can already be done, simply by stating the above in terms of the current semantics somewhere (maybe in Semantics, maybe in Concepts, maybe in some other place). So Semantics already supports the notion of annotations of facts in an interpretation.

And it's good to hear that it can "already be done" - which I take as synonymous to "can be added to the model-theoretic semantics without much extra effort and without breaking anything we already have".

In fact, Semantics already includes part of this in its definition of the set of facts in an interpretation. So an asserted triple reifier in an interpretation is just the first element of a fact whose predicate is the denotation of rdf:reifies and whose object is also a fact.

Yes, but only part of this ;-) If someone could draft a PR to add the missing part, that would be great.

@franconi

As I said, my opinion is that no change is required in Concepts (possibly fine-tuning #214) or Semantics (even if I will propose an addition in order to explain rdf:reifies as rdf:type is already explained - PR is coming). A forthcoming FAQ/note document based on examples should be the way out.

Why not try to draft the addition that @pfps suggests? A solid, model-theoretic definition of annotations on facts ("statements about statements") would benefit everybody. The forthcoming FAQ/note document based on examples will still be much needed to instruct users on the basics and subtleties of this mechanism.

@pchampin

@rat10

@pchampin, thank you for the clarifications.
tl;dr It seems clear by now that the proposed reification mechanism does not provide for "statements about statements", as the WG charter asks for, but rather for something like "statements about (abstract) propositions".

I lack time to respond to all the points,

I understand, but maybe later?

but I strongly disagree with this first point. Reifiers can describe many different things, including statements. The example below contains a statement about a statement.

<<( :s :p :o ~ :r1 )>> a rdf:Statement; dc:creator :alice; :source <another_file.ttl> .

The question here is not the interpretation but how to address the asserted triple in the first place. An annotation can be about the asserted triple itself (e.g. source, date of assertion, etc) or about its interpretation (adding detail to what it describes). But before such differentiation can be usefully made (and, notwithstanding the well known identity crisis argument, that is mostly the job of vocabularies) one has to be sure what one is talking about: an asserted triple, or a reified (but still abstract) triple. That is the core of the issue at hand.

From previous conversation, I suspect that this example will not satisfy you, as you are rather interested about "statements about statements from the same graph", but as you insist on the letter of the charter, I would argue that my example above does satisfies the charter.

No, I don't insist on that. It's quite hard to avoid your criticism of not being specific enough, and then also not to be overly specific.

Furthermore, the example can be easily adapted to talk about statements from the same graph, for example:

:s :p :o ~ :r2 {| a rdf:Statement; dc:creator :pchampin; :source <> |}.

(using the relative IRI <> to indicate that I'm talking about a statement in the very RDF document we are looking at).

Agreed, and indeed useful in some situations, but not what this issue/PR is about

What I suggest to do with an application-specific predicate (:source), it seems that you would like to define it in RDF semantics itself.

No, by no means. Neither would I nor is it the topic of this issue/PR.

[...]

As an aside, your usage of rdf:Statement is problematic since those are clearly defined to not refer to asserted triples. If we change that, we change all existing uses of RDF 1.0/1.1 reification. Or is your example intended to illustrate exactly that case?

@pfps

Either "statement" in the charter means instances of rdf:Statement, or is it some under-defined term that is up to the working group to define.

Neither, IMO. We agree that it can't possibly be meant to refer to rdf:Statement which specifically types an RDF 1.0/1.1 reification quad. But the term "statement" is defined in RDF Concepts as follows:
"Asserting an RDF triple says that some relationship, indicated by the predicate, holds between the resources denoted by the subject and object. This statement corresponding to an RDF triple is known as an RDF statement."
We can assume that the charter left out the "RDF" part for the sake of conciseness and readability. The charter is also not concerned with specific syntaxes. Therefore the charter's "statements about statements" has to be understood as referring to asserted triples whenever it uses the term "statement".

https://www.w3.org/TR/rdf11-concepts/#resources-and-statements
https://www.w3.org/TR/rdf12-concepts/#resources-and-statements
"1.2 Resources and Statements"

This statement corresponding to an RDF triple is known as an RDF statement.

@rat10

If I interpret this correctly it means that a reification of a triple term (vulgo: a reifier) is defined as entailing the triple

A reifier is a term. It can not entail anything: entailment is a relationship between graphs -- and therefore, no, that's not what @pfps is saying.

My understanding of what @pfps is writing above is: an "asserted triple reifier" is a reifier that reifies a triple that happens to be asserted. This is the point I've been making earlier.

As an aside, your usage of rdf:Statement is problematic since those are clearly defined to not refer to asserted triples.

That's simply not true. It is perfectly OK to put in the same graph a triple :s :p :o. and the reification quad _:b a rdf:Statement; rdf:subject :s ; rdf:predicate :p; rdf:object :o . Again, _:b is about the triple _:s _:p _:o and _:s _:p _o happens to be asserted, so _:b is about an asserted triple.
(I use the term "is about" because _:b does not refer to the triple itself, it refers to a "token of the triple", per RDF Semantics D.1, but I believe this is orthogonal to the question).

No, I don't insist on that [the letter for the charter]

Prior to my comment, you had written 5 times in this thread "statements about statements" in quote, citing the charter. I would consider this as insisting on the letter of the charter. Which, by the way, is your right entirely -- I didn't mean that pejoratively, I just thought it called for an answer -- even though, as you point out, we are getting side-tracked from the topic of this PR.

The PR contains the text:

an assertion on a reified triple is an assertion on an asserted triple of the same form, if such a triple occurs in a graph as both a reified triple a and an asserted triple.

if a triple T "occurs in a graph as both a reified triple and an asserted triple, then any assertion on T (a refied triple) is also an assertion on T (an asserted triple)! This is a tautology, and therefore claiming that

this understanding is not backed by the model-theoretic semantics"

is plain wrong.

@pchampin — Please edit #220 (comment) and correct the typo of @ofps to @pfps. They will keep getting unsolicited notifications about this thread, but hopefully it will end soon, and no copy-pastes of that comment will non-consensually re-engage that user.

@rat10

If I interpret this correctly it means that a reification of a triple term (vulgo: a reifier) is defined as entailing the triple

A reifier is a term. It can not entail anything: entailment is a relationship between graphs -- and therefore, no, that's not what @[p]fps is saying.

And neither it is what I'm saying,. It's only what the "vulgo" says, a clear indication that "reification of a triple term" is the correct expression, and the one you should comment on if you care for that kind of precision.

My understanding of what @pfps is writing above is: an "asserted triple reifier" is a reifier that reifies a triple that happens to be asserted. This is the point I've been making earlier.

IMO the interesting part of what @pfps is saying is that we could make this point in model-theoretic terms, instead of just through convention, examples or other forms of operational semantics.

As an aside, your usage of rdf:Statement is problematic since those are clearly defined to not refer to asserted triples.

That's simply not true. It is perfectly OK to put in the same graph a triple :s :p :o. and the reification quad _:b a rdf:Statement; rdf:subject :s ; rdf:predicate :p; rdf:object :o . Again, _:b is about the triple _:s _:p _:o and _:s _:p _o happens to be asserted, so _:b is about an asserted triple.

No, if you are being that picky then you have to accept that a triple may be asserted, or reified, or none of that, and a reference to that triple would say nothing about either asserted or reified triples but speak only about the abstract proposition.

Ahaa... maybe I do now get the argument the current semantics tries to make: that an assertion on the proposition itself is inherited by its sub-types, asserted and reified alike. Is that it? But that seems far fetched, considering that reifications refer to tokens (or objectifications/thingifications) of the type, not the type itself.

That last inference - "so _:b is about an asserted triple" - is simply not true in model-theoretic terms. However, IIUC @pfps proposal could make it true, and I would like that.

(I use the term "is about" because _:b does not refer to the triple itself, it refers to a "token of the triple", per RDF Semantics D.1, but I believe this is orthogonal to the question).

No, I don't insist on that [the letter for the charter]

Prior to my comment, you had written 5 times in this thread "statements about statements" in quote, citing the charter.

My "that" wasn't referring to "the letter of the charter" but to your assumption that I'm worried about those statement being "from the same graph", which you added to the quote, see above. Some misunderstandings can be avoided by trying a bit harder to understand what the other side might mean.

I would consider this as insisting on the letter of the charter. Which, by the way, is your right entirely -- I didn't mean that pejoratively, I just thought it called for an answer -- even though, as you point out, we are getting side-tracked from the topic of this PR.

I would consider it a notable deviation from the charter, and not just an necessary interpretation, if "statements about statements" became a second class application, and "statements about propositions" the main focus of what RDF 1.2 defines. That goes beyond what a deviation from a "to the letter" interpretation would suggest (taking into account that such a deviation is almost always necessary).

The PR contains the text:

an assertion on a reified triple is an assertion on an asserted triple of the same form, if such a triple occurs in a graph as both a reified triple a and an asserted triple.

if a triple T "occurs in a graph as both a reified triple and an asserted triple, then any assertion on T (a refied triple) is also an assertion on T (an asserted triple)! This is a tautology,

What is the tautology here? IIUC you said the same, by means of an example, two paragraphs above.

and therefore claiming that

this understanding is not backed by the model-theoretic semantics"

is plain wrong.

Still seems right/true to me.

Just as we can refer to, say, persons:

:x :rel :y .
:y a :Person .

We can now, with the RDF 1.2 semantics as currently defined, refer to facts:

:x :rei <<( :a :b :c )>> .
:a :b :c .

I interpret @pfps commment as seeking perhaps a slightly more formal definition of the set of facts? I think that'd be great, to make the above even more abundantly clear.

But @rat10, you seem to seek a narrower pattern still? Just like we can define that (what is denoted by) :rel just refers to persons (denoted by :Person), using:

:rel rdfs:range :Person .

IIUC, you want to express that the interpretation of :rei above only refers to facts (in all uses thereof). With a definition of the set of facts formally as, lets say rdfx:Fact (rdfs:subPropertyOf rdfs:Proposition), you'd be able to express that as:

:rei rdfs:range rdfx:Fact .

I suppose that would require a semantic condition akin to the existing:

If exist x,y,z such that RE(x,z,y)=r
then < r,I(rdfs:Proposition)> is in IEXT(I(rdf:type))

such as:

If < I(x), I(y)> is in IEXT(I(z)) and RE(x,z,y)=r
then < r,I(rdfx:Fact)> is in IEXT(I(rdf:type))

I could sympathize with this; and I recall others might too (as I think you've also noted before), as long as we do not restrict annotations to this narrower definition!

But this opens up further questions. Given that you'd use it like above, it also seems to warrant an even stronger semantics. For one, and we've been here before, would a triple term inferred to be an rdfx:Fact also be asserted under RDFS semantics? Reasonably yes. Also, would relationships to facts be expected to follow notions of variance? Not necessarily, but it may leave things wanting for any users of such stronger semantics.

So to motivate spending even more time on this, I think we need substantive (real-world-based) use cases where something is not possible to do without this. But if only defining rdfx:Fact (as rdfs:Fact, presumably) is enough, as denoting the subset of (the denotation of) rdfs:Proposition which are true in the interpretation, then maybe that's OK?

(Aside: here's an amended attempt at defining facts using OWL, from my previous attempt last year. So in OWL, with some perhaps far-fetched meta-modelling, this is already possible. And of course, it relies on an extended proposition interpretation, per w3c/rdf-star-wg#150. Again, I strongly believe this extension is far more important for achieving practical semantic interoperability using OWL (since there are use cases that require it). It still does not require rdfx:Fact though; but such semantics doesn't seem too wildly different in the stronger semantics (OWL) it leverages; and as in this mentioned attempt, might be achieved with just that. (Not the notion of variance though, AFAICS; that may be a missing piece. I'll think more about if "fact-entailment" might be useful for that; and if so, it might go into the note.))

@niklasl

Just as we can refer to, say, persons:

:x :rel :y .
:y a :Person .

We can now, with the RDF 1.2 semantics as currently defined, refer to facts:

:x :rei <<( :a :b :c )>> .
:a :b :c .

I interpret @pfps commment as seeking perhaps a slightly more formal definition of the set of facts? I think that'd be great,

Good! It would be great if also @franconi and @doerthe would agree and if someone (probably not me, because I mostly lack the required abilities) could draft a PR to that effect.

to make the above even more abundantly clear.

Note that I don't share the connotations of "slightly more formal" and "abundantly clear". References to facts are currently not defined with model-theoretic semantics and therefore IMO have more than just slightly un-formal semantics. The perceived abundance in clarity can easily be called into question by comparing that to the other parts of the semantics that are based on a proper model theory.

But @rat10, you seem to seek a narrower pattern still?

You seem to refer to my rdfs:states proposal, but please note that this thread of issue and PRs grew out of my frustration of not being able to pin down what the current specifications actually define. Any useful proposal of rdfs:states or similar does of course need to build on a solid understanding of what we already have, so I started to inquire.

• I would take it as a useful result if the specs explicitly describe that assertions on facts are based on an operational semantics, informed by examples and best practices - because that at least provides the necessary clarity of what we have.

• I would take it as a much more useful result if the model theoretic semantics were amended as sketched by @pfps above. That would elevate assertions on facts to the same level of semantics soundness as assertions on any other thing (represented by IRI or blank node).

I will probably not uphold my proposal of an rdfs:states property if the model theoretic semantics are so extended, as I have found that the issues with it that you pointed out are indeed problematic.
And my biggest concern would indeed be removed if RDF 1.2 could specify the semantics of assertions on facts, not just propositions, in model-theoretic terms. I never cared for assertions on un-asserted propositions all that much anyway ;-)

I still entertain the possibility of mapping Turtle 1.2 syntactic sugar for annotated or just reified triples to two subproperties of rdf:reifies - tentatively named rdfs:states and rdf:mentions - which would preserve that syntactic sugar in round tripping to N-triples. If that is helpful or not, or if to the contrary the syntactic sugar is not be as helpful as it seems, and how the issues that you found can be discussed in more abstract terms - that would all be part of a follow-up discussion on rdfs:states. I have had a draft laying around for weeks, or even months - but as I said, I first need a resolution on what we have now to continue that discussion in a meaningful way.

[...] 

The rest of your comment covers some interesting terrain, but I'm not able to properly digest it right now.

• I would take it as a much more useful result if the model theoretic semantics were amended as sketched by @pfps above. That would elevate assertions on facts to the same level of semantics soundness as assertions on any other thing (represented by IRI or blank node).

Semantics already has a suitable definition of facts.

Providing information about the intended meaning of rdf:reifies is, in my opinion, only suitable for Schema.

@pfps

• I would take it as a much more useful result if the model theoretic semantics were amended as sketched by @pfps above. That would elevate assertions on facts to the same level of semantics soundness as assertions on any other thing (represented by IRI or blank node).

Semantics already has a suitable definition of facts.

But not of assertions on facts.

Providing information about the intended meaning of rdf:reifies is, in my opinion, only suitable for Schema.

What you outlined above,

Suppose that one actually wanted to make a closer connection between truth in an interpretation and triple terms in Semantics. The way to go would be to define the set of triples in an interpretation as the range (the mathematical range not the RDFS range) of RE and define IEXT as a subset of the set of triples. Then an asserted triple reifier of a triple term, x y z, in an interpretation is just a domain element, a, for which RE(a,IS(rdf:reifies),t) is in IEXT and t is in IEXT, for t = RE(I(x),I(y),I(z))).

is not the stuff for RDF Schema, it belongs into RDF Semantics.

But all this can already be done, simply by stating the above in terms of the current semantics somewhere (maybe in Semantics, maybe in Concepts, maybe in some other place). So Semantics already supports the notion of annotations of facts in an interpretation.

In fact, Semantics already includes part of this in its definition of the set of facts in an interpretation. So an asserted triple reifier in an interpretation is just the first element of a fact whose predicate is the denotation of rdf:reifies and whose object is also a fact.

EDIT: I believe that the right place to discuss assertions on facts is in Schema, as this is part of the intended meaning of rdf:reifies, and in tutorial material, to show how rdf:reifies is supposed to be used.

I agree that discussing the application of rdf:reifies doesn't belong into RDF Semantics, but rather into Concepts, Primer and other planned "user-facing" documents and/or notes. However, laying the model-theoretic foundation for its interpretation w.r.t. assertions on facts can only happen in RDF Semantics.

This needs to be resolved before CR.

@pfps,

This piece was discussed yesterday in the call:

Suppose that one actually wanted to make a closer connection between truth in an interpretation and triple terms in Semantics. The way to go would be to define the set of triples in an interpretation as the range (the mathematical range not the RDFS range) of RE and define IEXT as a subset of the set of triples. Then an asserted triple reifier of a triple term, x y z, in an interpretation is just a domain element, a, for which RE(a,IS(rdf:reifies),t) is in IEXT and t is in IEXT, for t = RE(I(x),I(y),I(z))).

But all this can already be done, simply by stating the above in terms of the current semantics somewhere (maybe in Semantics, maybe in Concepts, maybe in some other place). So Semantics already supports the notion of annotations of facts in an interpretation.

In fact, Semantics already includes part of this in its definition of the set of facts in an interpretation. So an asserted triple reifier in an interpretation is just the first element of a fact whose predicate is the denotation of rdf:reifies and whose object is also a fact.

EDIT: I believe that the right place to discuss assertions on facts is in Schema, as this is part of the intended meaning of rdf:reifies, and in tutorial material, to show how rdf:reifies is supposed to be used.

and this made me think a lot, because it misled me very much. At first, I thought you were bringing a formal argument, so that we had to interpret all this as a sketched mathematical proof of a claim. But interpreting what you say here as a formal proof requires non trivial extrapolation. Yet, @franconi claimed yesterday that this is all trivial.

After putting much thought into it, I believe that you are not particularly trying to make a formal point, but with all due respect, your post is clumsy because it misleads very much. At first, you introduce some formalism suggesting that what @rat10 requests could be done if only we changed the formal semantics. Immediately after, you say that the same thing is doable without any change; yet you only keep the example of how to do it in the revised semantics, without explaining how to do it in the actual RDF 1.2 semantics.

My understanding now of what you are saying is that one can always make statements about an asserted statement by 1) asserting the statement (i.e., adding an RDF triple to the graph that asserts it); 2) assuming that the statement exists in the universe of discourge (i.e., the domain of interpretation IR) and having a syntactic element that's intended to denote it (whether it is a URI, or a triple term mapped to it via the function RE); 3) if using a triple term, make the connection a little tigher by making the triple term exactly the triple that asserts the statement.

E.g., assume we want to state something about the fact that Tim Berners-Lee invented the Web. Let us name $s$ this statement. Then, write a triple that denotes this statement:

w3:timbl onto:invented w3:www .

By writing this, we assume that the interpretation contains Tim Berners-Lee, contains the Web, contains the relation of inventing something, even though the formal semantics does not enforce in any way that this triple means what we intend it to mean. So we continue:

<r> rdf:reifier << w3:timbl onto:invented w3:www >> .

Again, nothing formally connects this to the statement, but we can assume that our intention is that RE(I(w3:timbl),I(onto:invented),I(w3:www)) = $s$. Or, if we wanted to make statements about the RDF triple itself, rather than the statement it denotes, we could assume that RE(I(w3:timbl),I(onto:invented),I(w3:www)) = (w3:timbl, onto:invented, w3:www).

It is indeed obvious that we can do this with the current semantics, but we could make the same point with only RDF 1.1. We can mint a URI intended to denote $s$, assert the triple w3:timbl onto:invented w3:www, then make the connection tighter by relating the URI to the triple using syntax like:

ex:isTriple "w3:timbl onto:invented w3:www"^^dt:turtle .

and assume that ex:isTriple is intended to denote a relation between a statement and a string that serialises an RDF triple that denotes the statement.

The problem that I see in this is that if "all this can already be done" in RDF 1.1, then why introduce the machinery of triple terms, and stop introducing more that brings something that "cannot already be done"? Wouldn't it be equally satisfying to interpret triple terms as syntactic sugar for RDF reification?

Well, yes, in some strong sense RDF 1.1 can already do everything because it has triples. Even more so, it has vocabulary for statements. But somehow that vocabulary has been deemed insufficient.

Further, I have found all the discussion around this issue very confusing. I have never been able to figure out either what the problem is or what the solution should be. I've even still confused as to whether the desired solution to the problem is supposed to be some fundamental change to the semantics, some ancillary change to the semantics, or just some explanatory text. So I guess it is not surprising that my comments might be considered confusing.

My goal in the referenced post was two-fold. First, to describe how the 1.2 semantics might be changed in a way that might solve what might be the problem. (There are lots of ways that this might be done and I only described one of these.) Second, to state that the current 1.2 semantics already has machinery that does essentially the same as the semantics change. I didn't make this a formal argument. So why would I do this? My goal was to show that the current 1.2 semantics gets you to essentially the same place as you would get to with the potentially more-explicit machinery.

The post above appears to be complaining that there is no, or maybe insufficient, connection between:

:a :b :c .

and

<<( :a :b :c )>>

It is certainly true that one might want to have a logical formalism where there is closer connection. But what, formally, is this connection supposed to be? And without adding A LOT to RDF?

One might also want to have more description about how triple terms are to be used to make "annotations on statements". But what? And what part of this needs to be in Semantics, a document that is not likely to be read by RDF users who just want to do things like:

<< :NotreDame :reconstructed "2024"^^xsd:gYear >> :accordingTo :NYT .

Still, I think the heart of the confusion is exactly what you both point to: what is the expected relationship between an asserted triple like :a :b :c . and the triple term << :a :b :c >>.

If the claim is that "this can already be done," then triple terms appear as little more than syntactic sugar for RDF 1.1-style reification or URI-minting practices. If, however, the community expectation is that triple terms bring a tighter, more formalised connection between asserted triples and triple terms, then this needs to be made explicit in the semantics or at least in the explanatory material.

From my perspective, it would be very helpful to separate more clearly:

1. what RDF 1.1/1.2 already enables in practice (via URIs, reification, ad-hoc properties, etc.),
2. what triple terms are meant to add beyond convenience, and
3. whether the intended value is primarily semantic precision (a new formal guarantee), or primarily syntactic convenience (a cleaner way of doing what was already possible).

Making that distinction explicit, perhaps in Concepts or Schema (I feel that there is something like that in Schema), supported by tutorial-style examples, could reduce the risk of misinterpretation and align expectations about what triple terms are for.

I've never been of the opinion that the task of the WG was anything more than adding triple terms (quoted triples) to RDF. As an aside, this doesn't even cover rdf:reifies so the WG is over-delivering. It is my view that this machinery is adequate to support (in RDF style) all that is covered in the seminal paper, the CG final report, the WG charter, and everything in the current WG documents.

Is there more that could be done in this area? Absolutely! Should it be part of RDF? For almost all of it, absolutely not! For any remaining bits, there is now (and, by the way, there already was in RDF 1.1) adequate machinery to do so, but these bits are intended meaning and custom and practice and so not part of the RDF 1.2 semantics.

[@pfps] I've never been of the opinion that the task of the WG was anything more than adding triple terms (quoted triples) to RDF. As an aside, this doesn't even cover rdf:reifies so the WG is over-delivering.

I think you should revise your opinion. I refer you to our charter which says, in part —

The scope of this Working Group is to update the recommendations defining RDF 1.1 and SPARQL 1.1, extending them with the features introduced by RDF-star. More precisely, RDF-star introduces the notion of quoted triple to express statements about statements. The abstract and concrete syntaxes of RDF and SPARQL, as well as their respective semantics, are to be extended to support this new feature. The group will then maintain the set of resulting recommendations (RDF 1.2 and SPARQL 1.2).

The community group has identified, in its final report, which recommendations should be updated, and a possible path for updating them. The Working Group may however reconsider this and proceed differently from the Community Group's proposal. For every recommendation updated by this Working Group, pending errata will also be addressed. The Working Group will also consider allowing new features in these recommendations, according to Section 6.3.11.4 of the W3C process, to ease and speed up future evolution.

I am pretty confident that those who review our eventual transition request will think rdf:reifies counts as "proceed[ing] differently from the Community Group's proposal" with the aim of "express[ing] statements about statements", as I do.

In an attempt to clear up what notions we are and aren't agreeing on, I have three questions (two followed by my claims), mainly directed to those who find the current RDF 1.2 triple and reifier concepts and/or triple semantics lacking:

1. Do you agree that a triple being asserted (i.e. a member of the graph set) and the same triple used as a term (e.g. as the object of a reifying triple) are the same triple? Or do you think otherwise, for instance that the two uses of identical triples in different roles somehow should turn that triple into two different (yet identical) triples?

   Given the current definitions, it is the same triple, denoting the same proposition, one used for assertion (assigning truth value), one for reference (reification).

2. Do you consider a proposition which happens to be true (in the set of facts) to A) be a statement? Or B) that a statement is a situation involving a proposition necessitating it being true? Or C) that a statement is a claim for the proposition to be a fact, but does not in itself make it true?

   Given the current definitions, option #C is possible to express (similar to what "classic" reification defined, i.e. "tokens"); but also many things beyond statements. Option #A is not the case; the stating of a proposition and that proposition being true are not the same resource. Option #B might be considered the definition of RDF statement in concepts, although it does refer to the act of stating the truth, not necessarily that which makes it true. (That would be at odds with various epistemological notions; but some models are arguably much simpler than that, and may conflate such principal notions.)

3. Are you agreeing with 1, but are perhaps in doubt about 2#C being the only option, and are asking for the additional ability, in core RDF/RDFS, to assign truth value to a proposition using other means than assertion (including, but not restricted to, "truth-making" statements)?

@niklasl thank you for structuring the notions so clearly. Let me respond directly to your three questions, and then point out what I believe is still missing from the specifications.

1) “The same triple” in two roles?
Yes. I agree that we are talking about the same RDF triple, which in one place appears as an element of the graph (assertion), and in another place as a term (triple term) used for reification/reference. This role distinction does not change the identity of the triple itself.

2) What is a “statement” with respect to propositions and facts?
In current RDF 1.2 Semantics the closest fit is option C: a “statement” can be seen as the act of stating (making a truth-claim) about a proposition; the proposition itself may be true (and thus enter the set of facts), but the act of stating and being true are not the same thing.
That said, community expectations (and the wording of the charter “statements about statements”) point to talking about statements as facts — i.e., about assertions, not just bare propositions. This is where the gap lies: we have a clear layer for propositions (rdfs:Proposition) and the triple term machinery, but no equally precise, model-theoretic “hook” for facts (true propositions derived from asserted triples in the graph).

3) Am I asking for an additional ability to assign truth beyond simple assertion?
Yes, what I am asking for is a minimal, explicit strengthening of the semantics that allows us to recognize reifiers of asserted triples (“fact-reifiers”), and to consistently carry this through when annotating.

Concretely, this would mean adding a short clarification:

• explicitly state that triples in an interpretation can be considered as candidates for facts,
• define facts as those triples that are actually asserted (i.e., true in the interpretation),
• and describe a “fact reifier” simply as a reifier that refers to such an asserted triple.

This would:

• remain fully compatible with RDF 1.2 as it stands,
• explicitly name and ground the case that users intuitively treat as “annotations on statements (facts)”,
• not restrict other uses of reifiers (events, situations, opinions, etc.), since “fact-reifier” is an additional characterization, not a universal constraint.

If the group prefers not to touch Semantics, an acceptable fallback is to place this in RDF Schema (as the “intended meaning” of rdf:reifies) and clarify it in Concepts/Primer. However, I believe the cleanest solution is a short clarification in Semantics (in the section on the set of facts), with Concepts/Primer showing two usage patterns:

1. annotations on propositions (general case),
2. annotations on facts (when the triple is also asserted in the same graph), making clear that in this second case we are indeed covering “statements about statements” in the sense of the charter.

@pfps You deleted a lot of text. It's very difficult to recreate. I wasted a lot of time, but I think I copied the text correctly. Please be more careful next time.

Ooops, how do I revert my inadvertent edit to domel's post?

2) What is a “statement” with respect to propositions and facts? In current RDF 1.2 Semantics the closest fit is option C: a “statement” can be seen as the act of stating (making a truth-claim) about a proposition; the proposition itself may be true (and thus enter the set of facts), but the act of stating and being true are not the same thing. That said, community expectations (and the wording of the charter “statements about statements”) point to talking about statements as facts, i.e., about assertions, not just bare propositions. This is where the gap lies: we have a clear layer for propositions (rdfs:Proposition) and the triple term machinery, but no equally precise, model-theoretic “hook” for facts (true propositions derived from asserted triples in the graph).

How can a stating and truth be distinguished in a symbolic system? Inside the system, every stating is truth. Outside the system any stating of truth in the system is just another claim.

1. Do you agree that a triple being asserted (i.e. a member of the graph set) and the same triple used as a term (e.g. as the object of a reifying triple) are the same triple? Or do you think otherwise, for instance that the two uses of identical triples in different roles somehow should turn that triple into two different (yet identical) triples?
   Given the current definitions, it is the same triple, denoting the same proposition, one used for assertion (assigning truth value), one for reference (reification).

My belief is that the whole idea behind quoted triples (triple terms), is that there is only one quoted triple (triple term) for any triple, and that the quoted triple (triple term) is the triple, just in a different context (part of another triple instead of directly an element of the graph).