Annotations on assserted triples are based on operational semantics

[rat10]

Add clarification that, according to the model-theoretic semantics, annotations on reified triples can't annotate asserted triples, but that an operational semantics establsihed voa best practices, examples, etc may establish such a semantics in practice.

---

Preview | Diff

[franconi]

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.

[rat10]

@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]

[pfps]

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

[pfps]

I am against this change.

[lisp]

franconi's remarks are very much about semantics.

[franconi]

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.

[lisp]

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.

[TallTed]

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.

[pfps]

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.

[franconi]

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

[niklasl]

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.

[rat10]

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

[pchampin]

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

[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". 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.

[rat10]

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!

[pfps]

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.

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

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

[franconi]

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

[pfps]

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

[rat10]

@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".

[afs]

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.

[pchampin]

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

[TallTed]

@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]

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

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

[rat10]

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

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

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

[rat10]

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