Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
niklasl opened this issue Dec 12, 2024 · 18 comments
Open
Labels
spec:editorial Minor change in the specification (markup, typo, informative text; class 1 or 2)

Comments

@niklasl
Copy link
Contributor

niklasl commented Dec 12, 2024

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
Copy link
Contributor Author

niklasl commented Dec 12, 2024

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
Copy link
Contributor Author

niklasl commented Dec 12, 2024

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
Copy link
Contributor

pfps commented Dec 13, 2024

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

@pfps pfps added the spec:editorial Minor change in the specification (markup, typo, informative text; class 1 or 2) label Jan 8, 2025
@franconi
Copy link
Contributor

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

@niklasl
Copy link
Contributor Author

niklasl commented Jan 29, 2025

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
Copy link
Contributor

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
Copy link
Contributor Author

niklasl commented Jan 29, 2025

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

niklasl commented Jan 29, 2025

My recent suggestion above here (giving up on #49) 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 #49 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
Copy link
Contributor

franconi commented Jan 29, 2025

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
Copy link
Contributor Author

niklasl commented Jan 29, 2025

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
Copy link
Contributor

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
Copy link
Contributor

franconi commented Jan 31, 2025

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.

@franconi
Copy link
Contributor

OK, I will have a look at Converting RDF 1.2 data to RDF 1.1(bis)

@doerthe
Copy link
Contributor

doerthe commented Feb 6, 2025

We can easily write your idea also in N3:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://www.example.org#> .

_:x rdf:reifies <<( :s :p :o )>>. 
{?x ?y <<( ?s ?p ?o)>>}=>{_:x rdf:subject ?s; rdf:predicate ?p; rdf:object ?o; :myDenotes <<( ?s ?p ?o)>> }.

Here the Link to try it (and play with it). It even works with recursion Link2 and we can also make it work for multiple occurrences of the same triple (using Skolem IRIs):Link3

(Please ignore the fact that the syntax checker of the editor does not support RDF-star yet)

@pfps
Copy link
Contributor

pfps commented Feb 6, 2025

@niklasl If you want changes made to the document, you should either suggest them or have a WG discussion on them.

@franconi
Copy link
Contributor

franconi commented Feb 7, 2025

The N3 rule by @doerthe indeed captures exactly my idea.
So, we need to discuss (maybe today at the Semantics TF) where exactly and how this should appear.
It plays the role of being the unstar, the explanation of RDF 1.2 reification vs RDF 1.1 reification, and it can be shown how to make it complete by using OWL axioms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:editorial Minor change in the specification (markup, typo, informative text; class 1 or 2)
Projects
None yet
Development

No branches or pull requests

4 participants