Integrating different ontology designs through entailment upon triple terms

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

<Alice> :bought <SomeComputer> {| :date "2014-12-15"^^xsd:date |} .

being shorthand for:

<Alice> :bought <SomeComputer> .
_:r1 rdf:reifies <<( <Alice> :bought <SomeComputer> )>> ;
    :date "2014-12-15"^^xsd:date .

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:

<purchase1> a :Purchase ;
    :date "2014-12-15"^^xsd:date ;
    :buyer <Alice> ;
    :seller <ComputerStore> ;
    :item <SomeComputer> ;
    :cost 2500 ;
    :currency :USD .

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:

An ^azinterpretation 𝓘 = (Δ, 𝓟, 𝓘S, 𝓘L, 𝓘T, 𝓘EXT, rs, rp, ro) is an ^azRDF-reification interpretation if it additionally satisfies the following: 𝓘S(rdf:subject) = rs; 𝓘S(rdf:predicate) = rp; 𝓘S(rdf:object) = ro.

(That was referenced in the "Seeking Consensus" table from 2024-01.)

[!NOTE] For this use case, it is not necessary to reuse the "classic reification" terms. It seems frugal to do so, but if there are reasons for minting new properties, that should also work with the suggested solution.

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:

<purchase1> rdf:reifies <<( <Alice> :bought <SomeComputer )>> .

entails:

<purchase1> rdf:reifies [ rdf:subject <Alice> ; rdf:predicate :bought ; rdf:object <SomeComputer> ] .

Ontology

Define a "rolification" property (used to match class membership in property chains):

:Purchase rdfs:subClassOf [ owl:onProperty _:RolifiedPurchase ; owl:hasSelf true ] .

Define a class for the :bought relationship, additionally tied to another "rolified" property:

_:BoughtRelationship owl:equivalentClass [ owl:onProperty rdf:predicate ;
                                            owl:hasValue :bought ] ;
    rdfs:subClassOf [ owl:onProperty _:RolifiedBoughtRelationship ; owl:hasSelf true ] .

Define subproperty chain axioms:

_:boughtRelation rdfs:subPropertyOf rdf:reifies ;
    owl:propertyChainAxiom (_:RolifiedPurchase rdf:reifies _:RolifiedBoughtRelationship) .

:buyer rdfs:domain :Purchase ;
    owl:propertyChainAxiom (_:boughtRelation rdf:subject) .

:item rdfs:domain :Purchase ;
    owl:propertyChainAxiom (_:boughtRelation rdf:object) .

Entailed purchase description

From this it is entailed that <purchase1> is a full-fledged :Purchase entity:

    <purchase1> a :Purchase ;
        :date "2014-12-15"^^xsd:date ;
        :buyer <Alice> ;
        :item <SomeComputer> .

(See live example using the OWL-RL online service.)

[!NOTE] The <purchase1> could also reify <Alice> :shoppedAt <ComputerStore> (making it another case for many-to-many); which with more rules can entail <purchase1> :seller <ComputerStore>.

See full examples in this gist.

Remarks

Conversely, with a chain axiom defined for the simple property:

:bought owl:propertyChainAxiom ( [ owl:inverseOf :buyer ] :item ) .

the simple relationship can be entailed from the purchase description:

<Alice> :bought <SomeComputer> .

[!NOTE] Note that full rdf:reifies relationships are not entailed in the converse example. That may be beyond what is achievable, and should be taken into account when modeling in use cases like this.

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 ) can capture only the most basic facts. Everything reasonably complex needs to branch out - and there goes the triplehood. That’s the problem, and to me that’s what makes the promise of being able to annotate triples with additional detail so attractive - not orthogonal detail like provenance, but detail from the same domain as the main relation, just - you know - secondary.

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.

w3c / rdf-ucr