Integrating different ontology designs through entailment upon triple terms

[niklasl]

[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) .

Completing Detail

It is necessary to distinguish the reifier as a :Purchase:

<Alice> :bought <SomeComputer> ~ <purchase1> {| a :Purchase ; :date "2014-12-15"^^xsd:date |} .

This is because there may be other kinds of reifiers for a :bought relationship, such as a :Transaction.

(Another way to achieve this would be to use a property in its description with a rdfs:domain of :Purchase, such as an appropriately defined :seller relation.)

Entailed purchase description

From this the remaining :buyer and :item relationships are entailed, making the <purchase1> description match an explicitly modeled N-ary relationship 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.

[niklasl]

If the entailment above is defined, it should probably be identical to the RDF 1.1 "unstarred" form (see also w3c/rdf-star-wg#114).

[rat10]

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 <purchase1>) 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.

[pchampin]

This was discussed during the rdf-star meeting on 26 September 2024.

View the transcript

Define an interpretation of Triple Terms 5

niklasl: I propose to use the rdf:subject/predicate/object properties for the interpetation

niklasl: This might not good to entail old reification from triple terms

<Zakim> pfps, you wanted to ask how this relates to the semantics from Enrico?

<niklasl> w3c/rdf-ucr#27

<gb> Issue 27 Integrating different ontology designs through entailment upon triple terms (by niklasl) [use case]

<pfps> Where are the semantics from Enrico, by the way?

ora: If we need some clarification on this, does it means we differ this one until Enrico shows up?

pchampin: Does this point to a specific use case or is this a nice to have,

<niklasl> https://gist.github.com/niklasl/69428b043be6f1d33fd45f89cbe52632#file-statement-entailment-ttl

niklasl: there are use cases I defined previously

AndyS: This seems to relate to the discussion around unstar

AndyS: Done this way I don't see how we can add multiple triples to the same reifier

tl: I have developed in a github issue multiple variants and they are all many-to-many

one is RDF-vocabulary based

<niklasl> Here is a comment on the unstarring issue I made yesterday w3c/rdf-star-wg#114 (comment) which relates to this issue about interpretation.

<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f]

ora: I don't think we can reach a concensus here, is it a good discussion topic for next week after voting?

<Zakim> tl, you wanted to ask about when rdfs:states will be discussed

<gkellogg> JSON-LD-star slides – https://json-ld.github.io/w3c-tpac-2024-presentations/json-ld-star/

<AndyS> +1 to having the JSON-LD presentation in a focused meeting.

ora: Thank you everybody

---

[william-vw]

@niklasl I believe you are missing a definition for the Purchase class. E.g.,

:Purchase rdf:type owl:Class ;
    owl:equivalentClass [ 
        owl:onProperty rdf:reifies ;
        owl:someValuesFrom _:BoughtRelationship
] ;

Then <purchase1> will have type :Purchase and the rest will follow.

[william-vw]

Using the following input:

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex: <http://example.com/> .
@prefix : <http://example.com/> .

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

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

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

_: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) .

Gives rise to the following output using the OWL2 RL service.

[william-vw]

(i.e., it doesn't seem to work :-)

[william-vw]

FYI, if you try the following in Protege - @niklasl code extended with the Purchase class definition - then it produces the desired inference. triple_terms_to_triples.owl.txt

[niklasl]

Ah, yes @william-vw, I see what you mean. With that added axiom, we can infer that any reifier of a :bought relationship is a :Purchase. I see how the description text seems to seek that.

However, the data in the linked example contains a bit more, representing in RDF 1.1 what we would in RDF 1.2 may express with:

<Alice> :bought <SomeComputer> ~ <purchase1> {| a :Purchase ;
    :date "2014-12-15"^^xsd:date ;
    :seller <ComputerStore> ;
    :cost 2500 ;
    :currency :USD |} .

That together with the initial axioms in the description (i.e. without the addition) entails the additional:

<purchase1> :buyer <http://example.org/Alice> ;
    :item <http://example.org/SomeComputer> .

So even though the additional axiom gets us a full round-trip without having a type on the reifier (which in some cases may be very valuable!), I think there is a catch. This does imply that reifiers of :bought triples are always a :Purchase. We might not want that—some reifiers may be of another kind, like a :Transaction recording the purchase fact. (As exemplified in these slides.)

In any case, I should update the text to reflect these considerations. Thank you for the analysis!

[william-vw]

@niklasl Ah I see. I thought you only wanted to transform the "entailment" of the reified triple, i.e.,

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

At any rate, it was more of a detail :-)

This does imply that reifiers of :bought triples are always a :Purchase. We might not want that—some reifiers may be of another kind, like a :Transaction recording the purchase fact.

Totally agree!

[niklasl]

@william-vw An important detail though, since without it the description was incomplete and somewhat misleading. I've added a small "Completing Detail" section (and edited the leading sentence in the section that follows), to hopefully clarify this a bit better.

[TallTed]

@rat10 — Please revisit #27 (comment) and code fence the <purchase1> which is currently invisible in the first paragraph, so the sentence ceases to read meaningless IDs like ), and instead reads meaningless IDs like `<purchase1>`). This will help future readers of this thread.