Explain how classic RDF reification relates to triple terms and rdf:reifies

[niklasl]

It would be valuable to explain how "classic" RDF reification relates to the concepts of triple terms and reifiers.

This was asked for on the mailing list on 2024-12-07 and mentioned during the WG meeting on 2014-12-12.

Given the (informative) description of reifications (resources of type rdf:Statement):

The subject of a reification is intended to denote a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object. This supports use cases where properties such as dates of composition or provenance information are applied to the reified triple, which are meaningful only when thought of as denoting a particular instance or token of a triple.

it is my belief is that a resource of type rdf:Statement is conceptually a specific kind of reifiers. More details in comments.

[niklasl]

With an interpretation of triple terms, OWL can be used, as is, to define a useful connection in RDF 1.2 environments. This can also be bridged with systems still using RDF 1.1 through support for "classicizing" RDF 1.2. (Note that the latter currently uses different terms, but those could be defined as sub-terms of the interpretation terms.)

It would then be possible to use reifiers while staying compatible with existing applications relying on classic reification. (A recommendation could be to move to reifiers for all but very special cases.)

The following (where the triple term is commented out and instead represented in its proposed interpretation):

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX : <http://example.org/ns#>
BASE <http://example.org/>

##
# Bridging axioms:

[ owl:onProperty _:selfIsStmt ; owl:hasSelf true ] owl:equivalentClass rdf:Statement .

[] rdfs:subPropertyOf rdf:subject ;
    owl:propertyChainAxiom (_:selfIsStmt rdf:reifies rdf:tripleTermSubject) .

[] rdfs:subPropertyOf rdf:predicate ;
    owl:propertyChainAxiom (_:selfIsStmt rdf:reifies rdf:tripleTermPredicate) .

[] rdfs:subPropertyOf rdf:object ;
    owl:propertyChainAxiom (_:selfIsStmt rdf:reifies rdf:tripleTermObject) .

##
# Domain of discourse:
<stmt1> a rdf:Statement ;
    :date "2014-12-15"^^xsd:date ;
    :source <SomeDatabase> ;
    :trust 0.8 ;
    # rdf:reifies <<( <Alice> :bought <SomeComputer> )>> ;  # "classicized" as:
    rdf:reifies [ a rdf:TripleTerm ;
                  rdf:tripleTermSubject <Alice> ;
                  rdf:tripleTermPredicate :bought ;
                  rdf:tripleTermObject <SomeComputer> ] .

entails (among other triples):

<stmt1>
    rdf:subject <http://example.org/Alice> ;
    rdf:predicate :bought ;
    rdf:object <http://example.org/SomeComputer> .

This can be tested e.g. using OWL-RL:

$ owlrl -m -t -i turtle -o turtle reifies2statement.ttl

[niklasl]

When this is resolved, https://github.com/w3c/rdf-schema may also need to be updated accordingly.

The definition of rdf:Statement in Schema:

An RDF statement is the statement made by a token of an RDF triple.

appears less clear in comparsion to its introduction in Semantics. It can be read such that a statement is not a token sentence, but its (propositional) meaning.)

[pfps]

This would be, at best, some sort of non-normative note in the document.

[franconi]

Similar to the comment on OWLish considerations. We better explain this without referring to OWL - being about meta modelling.

[niklasl]

It might be explained in prose. And/or using SPARQL, along the lines of:

INSERT {
  ?a rdf:subject ?s ; rdf:predicate ?p ; rdf:object ?o .
} WHERE {
  ?a a rdf:Statement ; rdf:reifies <<( ?s ?p ?o )>> .
}

Since the section on RDF reification is already a non-normative part of the RDF Semantics document, could that—and some variant of this explanation—be moved to another document?

[franconi]

It might be explained in prose. And/or using SPARQL, along the lines of:

INSERT {
?a rdf:subject ?s ; rdf:predicate ?p ; rdf:object ?o .
} WHERE {
?a a rdf:Statement ; rdf:reifies <<( ?s ?p ?o )>> .
}

But this would makes sense only in the unstar section.

[niklasl]

But this would makes sense only in the unstar section.

How so? "Unstarring" RDF 1.2 can be similarly explained (to an extent) using SPARQL. But that is about encoding propositions using only basic RDF; to work with in legacy systems (and give those a better chance of sending data to RDF 1.2 systems, if those can "re-star" again).

In basic RDF, one needs to understand the abstract type vs. concrete token difference to model appropriately. Using triple terms and reifiers ensures that the usage patterns are more naturally guided towards the well-formed and meaningful design, to lessen or fully avoid that conceptual burden. But a subset of the reifier use cases is still about the classic reification case:

This supports use cases where properties such as dates of composition or provenance information are applied to the reified triple, which are meaningful only when thought of as denoting a particular instance or token of a triple.

Thus, this issue is about explaining how users should think about the relationship between "classic" reification using rdf:Statement and reifiers ("reified triples"). And to explain or at least propose how classic reification data can be upgraded to, or otherwise be integrated with, RDF 1.2 data.

These are related cases, but of course dangerous to conflate. They may be explained together though, if that is what you mean? I am not opposed to move sections, or even make a dedicated Note about all of this, rather than put more non-normative things in the Semantics document.

[franconi]

Unstar is a process which will be suggested as a way to encode reasoning with triple terms using only basic RDF.
It will be clearly explained that this would work only in basic RDF and simple entailment.
Your proposal is basically the same, and would have exactly the same limitations.
I don't see the difference.
Then, unstar can give users some intuition about the difference between classic reification and rdf:reifies, but, again, as a precise mechanism it would work ONLY with simple entailment.
Clearly the sections about unstar and about explaining the difference between classical and 1.2 reifications have to be closely related. But we can not introduce the unstar procedure as a "general" way to talk about triple terms.

[franconi]

Also it is important that the unstar process DOES NOT PRESERVE THE SEMANTICS, it is only an entailment-preserving procedure. So it can not be part of anything else than as a way to reason with triple terms.

[niklasl]

My recent suggestion above here (giving up on #154) was to only describe a one-way pattern from a specifically typed reified triple and a classic reification. That in itself is different from defining unstarring (simpler, but also weaker, and less reusable).

And yes, the unstar process does not preserve the semantics; there is no way to uniquely denote a proposition in RDF 1.1. But #154 is different from that; it "just" adds three axioms to the new semantics. Does that break anything in itself? Or does it only become dangerous since it is dangerous to involve OWL, and I use those axioms and OWL to define patterns for data integration? I am not proposing to mandate OWL. (And only reluctantly to mention it, preferably in a Note to decouple it from the RDF specs.) Users are free to use any other reasoning mechanism.

What should be used as the general way of reasoning with triple terms (or, rather, RDF propositions)?

[franconi]

INSERT {
  ?a rdf:subject ?s ; rdf:predicate ?p ; rdf:object ?o .
} WHERE {
  ?a a rdf:Statement ; rdf:reifies <<( ?s ?p ?o )>> .
}

Technically this would be wrong, since ?a may match the same reifier of two distinct triple terms, and the outcome would be a mess of indistinguishable subjects, predicates, and objects.

[niklasl]

Technically this would be wrong, since ?a may match the same reifier of two distinct triple terms, and the outcome would be a mess of indistinguishable subjects, predicates, and objects.

Yes, this is the known limitation with classical reification. I would say a reifier with a type of rdf:Statement but of multiple triple terms (unless they all denote the same proposition) is a usage error. (An error that reifiers in RDF 1.2 obviates.)

But that doesn't mean that some usage patterns of reifiers will be intentionally limited to one triple term (proposition). In fact, the << s p o >> syntax appears to deliberately cater for that. (And as we've discussed before, one might use OWL restrictions on rdf:reifies as a way to formally define such designs.)

Note that I do not at all see this as a substitute for unstarring of triple terms in general. I merely suggested this as a direct explanation, due to lack of support for my initial proposal here to define an entailment as a basis for this and other interoperability patterns (which is only possible using more powerful semantics than RDF(S) provides).

Without such entailment, I do agree that the only way do define reasoning-based interoperability patterns seems to be by leverage "unstarring". But that appears to be a design for 1.1 system compatibility (or RDF 1.2 basic), rather than the way forward. (And I'd rather see "unstarring" as the fallback option when there is no proper entailment going on; rather than something different, and a cul-de-sac at that.)

[franconi]

Mmmhhh.
Unstar for RDF simple entailment would correspond to this:
First, a parser asserts a triple with a fresh bnode for each triple term appearing in the graph:
_:s-p-o :myDenotes <<(S P O)>>
Then, the following triples are also asserted - here I use SPARQL to define those triples:

INSERT {
  ?tt rdf:subject ?s ; rdf:predicate ?p ; rdf:object ?o . 
  ?reifier rdf:reifies ?tt .
} WHERE {
  ?reifier rdf:reifies <<( ?s ?p ?o )>> . 
  ?tt :myDenotes <<( ?s ?p ?o )>> .
}

I guess you should be happy with this, or not?

[franconi]

It would be interesting to find a way to generate bnodes denoting triple terms using SPARQL.
In the case of top level triple terms only, we could try the following:

INSERT {
  _:b :myDenotes ?tt .
} WHERE {
  _:w rdf:reifies ?tt .
}

This of course is wrong, since it generates several fresh bnodes for the same triple term, if the triple term is used more than once in the graph. We may try to fix it.
(note that the definition of appears in collapses the multiple occurrences of the same triple term into just one).
Moreover, maybe with some regular expression, we can do it for arbitrary nested triple terms.