Open niklasl opened 1 month ago
If the entailment above is defined, it should probably be identical to the RDF 1.1 "unstarred" form (see also https://github.com/w3c/rdf-star-wg/issues/114).
The third code block IMO illustrates the problem with this approach. This is essentially a row of a relational table, with all the added value of RDF integration technologies (e.g. globally valid IRIs and shared vocabularies), but without its usability promise: an easy to understand and use graph structure, simple triples that each have meaning and immediate purpose. The first code block delivers on that promise - Alice bought SomeComputer - but the third one doesn’t. But let’s face it: simple triples with a self-contained meaning (i.e. no blank nodes or meaningless IDs like
Why shouldn’t we always model like this, with the main fact in plain view and all the detail within easy reach:
<Alice> :bought <SomeComputer> {|
a :Purchase ;
:date "2014-12-15"^^xsd:date
:buyer <Alice> ;
:seller <ComputerStore> ;
:item <SomeComputer> ;
:cost 2500 ;
:currency :USD .
|} .
If that is considered too extreme, we could go for more modularity:
<Alice> :bought <SomeComputer> {| rdfs:seeAlso <purchase1> |} .
<purchase1> a :Purchase ;
:date "2014-12-15"^^xsd:date
:buyer <Alice> ;
:seller <ComputerStore> ;
:item <SomeComputer> ;
:cost 2500 ;
:currency :USD .
IMO that is an application of RDF-star that will work in almost any configuration we will end up with - stated or reified, with or without syntactic sugar, many-to-many-whatever - and it can be adapted not only to relational data structures but also to OWL-ish ontology design patterns, shape expressions, etc..
Even the following would work:
<purchase1> a :Purchase ;
rdf:reifies <<( <Alice> :bought <SomeComputer> )>> ,
<<( <SomeComputer> :boughtBy <Alice>)>> ;
:date "2014-12-15"^^xsd:date
:buyer <Alice> ;
:seller <ComputerStore> ;
:item <SomeComputer> ;
:cost 2500 ;
:currency :USD .
This links back an involved construct to some simple triples. IMO this is already very useful, but it does ask a lot from the user who has to query for these backlinks.
Some of my third example is captured by your OWL-ish mappings above. My first example I think is too extreme to become commonplace - nobody wants to re-create all RDF data in the vein of RDF-star. The second one however can be adapted easily to existing data. Maybe it can be made more precise than just a rather superficial rdfs:seeAlso
. I guess you would have some ideas for that.
A technicality: your second code block, "being shorthand for", should include the triple, i.e. <Alice> :bought <SomeComputer> .
, because that follows too from the annotation syntax used in the first codeblock.
[This is a recurring usage pattern suggested to be captured as a UC in telecon 240725.]
Situation
With RDF-star, it becomes possible to model data using simple binary relationships, and incrementally capture more concrete circumstances behind them, described as resources who reify (with
rdf:reifies
) the simple relationships (encoded as triple terms).Example:
being shorthand for:
When concrete circumstances are known to be needed beforehand, this case is usually instead modeled differently, e.g. as an N-ary relationship, following the general relationship or association class design.
That could look like:
This is sometimes perceived as an obstacle in RDF, since the simpler form is often more desirable, and may initially appear good enough. Only later on are further needs of detail discovered (perhaps in production, when change is expensive). (See e.g. PROV-O and examples thereof in #23.)
Requirement
In the above case, in order to remove the need for remodeling the first example (such as when integrating it with the data in second), it would be beneficial to be able to use semantic technology (OWL) to map these models, to avoid a rewrite of existing queries and readjustments by external data consumers.
Since triple terms are new in RDF 1.2, to be able to do so using the existing OWL 2 standard and tooling, a rule for triple terms to entail its constituent properties appears to be needed.
This has been proposed before by @Antoine-Zimmermann as "RDF-reification interpretations", which seems adequate:
(That was referenced in the "Seeking Consensus" table from 2024-01.)
Solution
Here follows an example of how to map the two models above.
Entailed relationship description
Let's assume that the suggested entailment is part of RDF semantics. Let us also name the reifying resource as
<purchase1>
.Then the reification triple above:
entails:
Ontology
Define a "rolification" property (used to match class membership in property chains):
Define a class for the
:bought
relationship, additionally tied to another "rolified" property:Define subproperty chain axioms:
Entailed purchase description
From this it is entailed that
<purchase1>
is a full-fledged:Purchase
entity:(See live example using the OWL-RL online service.)
Remarks
Conversely, with a chain axiom defined for the simple property:
the simple relationship can be entailed from the purchase description: