-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
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 |
When this is resolved, https://github.com/w3c/rdf-schema may also need to be updated accordingly. The definition of
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.) |
This would be, at best, some sort of non-normative note in the document. |
Similar to the comment on OWLish considerations. We better explain this without referring to OWL - being about meta modelling. |
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? |
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:
Thus, this issue is about explaining how users should think about the relationship between "classic" reification using 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. |
Unstar is a process which will be suggested as a way to encode reasoning with triple terms using only basic RDF. |
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. |
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)? |
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 But that doesn't mean that some usage patterns of reifiers will be intentionally limited to one triple term (proposition). In fact, the 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.) |
Mmmhhh.
I guess you should be happy with this, or not? |
It would be interesting to find a way to generate bnodes denoting triple terms using SPARQL.
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. |
OK, I will have a look at Converting RDF 1.2 data to RDF 1.1(bis) |
We can easily write your idea also in N3:
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) |
@niklasl If you want changes made to the document, you should either suggest them or have a WG discussion on them. |
The N3 rule by @doerthe indeed captures exactly my idea. |
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
):it is my belief is that a resource of type
rdf:Statement
is conceptually a specific kind of reifiers. More details in comments.The text was updated successfully, but these errors were encountered: