Example 4: Relators and extrinsic aspects

Employment & marriage -- gufo:Relator, gufo:mediates, rights & duties, MaterialRelationshipType

gufo:Relator gufo:mediates gufo:ExtrinsicMode gufo:externallyDependsOn gufo:isAspectProperPartOf gufo:MaterialRelationshipType gufo:isDerivedFrom

What you'll learn

An OWL object property like :employedBy can link an employee to their employer, but it cannot, by itself, say when the employment began, or that it comes with a right to be paid and a duty to show up. gUFO's gufo:Relator reifies a relationship into an individual in its own right, built from the roles it connects (see example 1) and, optionally, from the reciprocal rights and duties (extrinsic modes) that make it up. This example builds an employment relator the full way, and a marriage relator the lightweight way, and shows how the two connect back to a plain object property.

The domain

Dana works for Globex Corp.; John and Mary are married. Both are relationships that exist as more than just "these two are linked" -- they have a start date, they came into being at some point (see example 5 for the wedding itself), and, in the employment case, they carry concrete rights and duties for each side.

Step by step

The roles a relator connects

A relator mediates entities playing roles -- here, the same :Employee and :Employer roles that would be declared exactly as in example 1:

:Employee a owl:Class , gufo:Role ; rdfs:subClassOf :Person .
:Employer a owl:Class , gufo:Role ; rdfs:subClassOf :Organization .

The relator itself, and sub-properties of gufo:mediates

:Employment is declared a gufo:Relator. Two sub-properties of gufo:mediates, one per side, let the data distinguish which mediated party plays which role -- important once a relator connects more than two parties, or connects parties of the same kind on both sides:

:Employment rdfs:subClassOf gufo:Relator .

:involvesEmployee rdfs:subPropertyOf gufo:mediates ;
    rdfs:domain :Employment ; rdfs:range :Employee .
:involvesEmployer rdfs:subPropertyOf gufo:mediates ;
    rdfs:domain :Employment ; rdfs:range :Employer .

:DanaGlobexEmployment a :Employment ;
    :involvesEmployee :Dana ;
    :involvesEmployer :GlobexCorp ;
    gufo:hasBeginPointInXSDDate "2020-01-06"^^xsd:date .

gUFO itself requires every gufo:Relator to mediate at least two endurants (a qualified cardinality restriction on gufo:mediates) -- one reason a DL reasoner would in fact reject a relator individual asserted to mediate fewer than two things, unlike the sortality mistakes in example 1, which OWL cannot see at all.

Decomposing the relator into rights and duties

A relator can be more than an opaque link: gUFO lets you reveal the reciprocal gufo:ExtrinsicModes it is made of -- a right on one side is matched by a duty on the other, each inhering in one party and externally depending on the other, and each declared a proper part of the relator via gufo:isAspectProperPartOf:

:RightToSalary rdfs:subClassOf gufo:ExtrinsicMode .
:DutyToPaySalary rdfs:subClassOf gufo:ExtrinsicMode .

:DanasRightToSalary a :RightToSalary ;
    gufo:inheresIn :Dana ;
    gufo:externallyDependsOn :GlobexCorp ;
    gufo:isAspectProperPartOf :DanaGlobexEmployment .

:GlobexsDutyToPaySalary a :DutyToPaySalary ;
    gufo:inheresIn :GlobexCorp ;
    gufo:externallyDependsOn :Dana ;
    gufo:isAspectProperPartOf :DanaGlobexEmployment .

The full ontology mirrors this for the other direction of obligation (:DutyToWork / :RightToLabor), giving the employment four extrinsic-mode parts in total -- exactly the "rights towards Amazon, Inc." pattern from the gUFO usage guide, applied to employment instead.

A shortcut property, with its provenance recorded

Applications often still want a plain binary link for querying ("who works where"). gUFO lets you add one without losing the connection to the relator it stands for, by declaring it a gufo:MaterialRelationshipType and pointing gufo:isDerivedFrom at the relator class:

:employedBy a owl:ObjectProperty , gufo:MaterialRelationshipType ;
    rdfs:domain :Employee ;
    rdfs:range :Employer ;
    gufo:isDerivedFrom :Employment .

:Dana :employedBy :GlobexCorp .

gufo:isDerivedFrom is metadata about the property, not a logical link between :Dana :employedBy :GlobexCorp and the specific :DanaGlobexEmployment individual: it tells a reader (or a tool) that this kind of edge always corresponds to some relator of that type, without forcing every use of :employedBy to also assert the relator explicitly. See example 7 for more on this style of typing an object property itself, using OWL 2 punning.

The lightweight alternative: an existential restriction

Not every relator needs distinguishable roles in the data. John and Mary's marriage does not, here, need to tell "husband" from "wife" apart, so :Marriage uses a plain existential restriction on gufo:mediates instead of two dedicated sub-properties:

:Marriage rdfs:subClassOf gufo:Relator ,
    [ a owl:Restriction ; owl:onProperty gufo:mediates ; owl:someValuesFrom :Person ] .

:JohnMaryMarriage a :Marriage ;
    gufo:mediates :John , :Mary ;
    gufo:hasBeginPointInXSDDate "2001-12-12"^^xsd:date .

This is a genuine trade-off, not a shortcut with no cost: querying "who is John's spouse" now means looking at every gufo:mediates value of :JohnMaryMarriage other than John, rather than following a role-specific property directly.

The full ontology

See ontology.ttl for the complete file.

How this is checked

cd examples/tests
.venv/bin/pytest -v -k relators