Foundational ontology & modelling frameworks in OPDA — what we built, why, and the benefits

How the schema-derived ontology uses a foundational ontology and a conceptual-modelling framework: the decisions we took, the architecture we deployed, and what it buys us. The one-line summary: OPDA is UFO-informed, never UFO-grounded. We use the Unified Foundational Ontology (UFO) and OntoClean as a design-time decision procedure, and ship only pragmatic SHACL + SKOS + plain RDF that stands on its own — carrying the foundational commitment as an inert, honestly-disclosed, CI-quarantined provenance record.

This document is a reference for our implementation. It is grounded in the decisions recorded in ODR-0030 (the foundational-ontology choice), ODR-0031 (how opda:ufoCategory is represented), ODR-0027 (classification-over-inheritance), ODR-0029 (the entailment regime), ODR-0004 §3a (three-graph separation), and ADR-0034 / ADR-0044 / ADR-0045 (the engineering).

1. The decision: retain UFO as a lens, scoped to the Relator spine

When we reviewed the foundational layer (council session-040 → ODR-0030), the live question was a four-way: retain UFO as a lightweight lens, deepen it to a full OntoUML/UFO import, switch to BFO, or drop the foundational layer entirely. We chose retain-as-lens, scoped to the Relator/Role/RoleMixin spine — and the scoping is the whole point.

---
config:
  layout: elk
---
flowchart TB
    accTitle: OPDA's foundational-ontology decision
    accDescr: The four options OPDA weighed — retain UFO as a lens, deepen to OntoUML, switch to BFO, or drop the foundational layer — and why retain-as-lens was chosen, scoped to the Relator/Role/RoleMixin spine.

    Q["Should the standard rest on
a foundational ontology at all?"]:::warning

    Q --> A["RETAIN UFO as a design-time lens
scoped to the Relator / Role / RoleMixin spine"]:::success
    Q --> B["DEEPEN to OntoUML / full UFO import"]:::error
    Q --> C["SWITCH the foundation to BFO"]:::error
    Q --> D["DROP the foundational layer entirely"]:::error

    B --> BR["Rejected: full UFO is not faithfully
expressible in OWL 2 DL (gUFO authors) —
buys undecidability, no triple a data file cashes"]:::external
    C --> CR["Rejected as a switch: BFO has no native
relator/deontic apparatus; its one decisive win
(ISO/IEC 21838) is captured by a reserved crosswalk"]:::external
    D --> DR["Rejected (held as live dissent): OntoClean is
separable + the vocabulary is droppable, but the
Relator category is categorially load-bearing"]:::external
    A --> AR["The bounded reason: UFO+UFO-L natively unifies
relational reification with Hohfeldian
claim-right ⇔ duty correlativity — which a
conveyancing domain needs"]:::external

The honest account of how we use UFO: our modelling process is governed by a UFO/OntoClean decision procedure; the artefact carries an inert provenance record of that governance. UFO is load-bearing only at the relational-endurant spine — a handful of classes such as opda:Proprietorship and opda:Transaction founding the opda:Seller/opda:Buyer roles. Everywhere else it is documentary. The published claim is therefore "UFO-informed", never "UFO-grounded with guarantees."

Why not deepen? The gUFO authors' own result is decisive: full UFO is not faithfully expressible in decidable OWL 2 DL, so deepening imports non-computable commitments we would only route around. Why not switch to BFO? BFO must reify a claim-right as a directive information entity; its only decisive advantage (ISO/IEC 21838 standing) we hold in reserve via a referenced-not-imported crosswalk, without abandoning UFO-L's superior domain fit. Why not drop it? OntoClean is separable and the vocabulary is droppable — but the Relator does categorial work the alternatives cannot reconstruct, so the foundation is optional, not harmful, and retained behind falsifiable re-open triggers.

2. The architecture: three graphs, one of them inert

The foundational commitment is made safe by physical separation (ODR-0004 §3a). The emitter produces three kinds of graph, and the foundational/meta-level material lives entirely in the third — the annotation graph, which is never reasoned over and never validates instances.

---
config:
  layout: elk
---
flowchart TB
    accTitle: OPDA's three-graph separation
    accDescr: The classes graph feeds the reasoner under a shallow regime; the shapes graph validates instance data; the annotation graph holds the inert UFO/gUFO/OntoClean material and is never an input to either; CI gates enforce the separation including a sixth gate forbidding advisory predicates in the classes graph.

    C1["opda-classes.ttl + opda-{module}.ttl
OWL classes + properties"]:::user
    S1["opda-shapes.ttl + opda-{module}-shapes.ttl
SHACL node/property shapes"]:::security
    A1["opda-annotations.ttl + *-annotations.ttl
UFO categories · gated gUFO types ·
UFOCategoryScheme · IAO crosswalk · DPV — INERT"]:::external
    DATA["Instance data
(PDTF transaction records)"]:::info
    REASON["Reasoner
(ODR-0029 RDFS-Plus: only
rdfs:subClassOf type-propagation)"]:::process
    VALID["pySHACL validator"]:::process

    C1 -->|"input to"| REASON
    S1 -->|"input to"| VALID
    DATA -->|"validated by"| VALID
    A1 -.->|"NEVER an input to"| REASON
    A1 -.->|"NEVER targets"| VALID

    GATE["CI separation gates (six checks)"]:::error
    GATE -.->|"no sh:* in annotations"| A1
    GATE -.->|"6th gate: no advisory predicate
(incl. ufoCategory) in classes"| C1
    GATE -.->|"no owl:imports from shapes"| S1

What reasons over what. The reasoner sees only the classes graph, under the deliberately shallow RDFS-Plus regime (ODR-0029): only rdfs:subClassOf type-propagation fires; domain/range are validated as SHACL, not inferred. The SHACL validator checks instance data against the shapes graph. The annotation graph — where every UFO/gUFO/OntoClean tag lives — is an input to neither. Deleting the entire foundational layer changes zero inferences, zero validation reports, and zero emitted bytes.

The CI gates make this real, not aspirational. Six checks enforce the separation; the sixth (added in ADR-0045) forbids the advisory-predicate family — including opda:ufoCategory — from appearing in the classes graph. It exists because a structured ufoCategory facet was once emitted into the reasoned graph by mistake; the gate is what guarantees that breach cannot silently re-ship.

3. The UFO categories we use — and the Relator spine that earns its keep

OPDA classifies each OWL class under one of nine UFO meta-categories. They are a documentary classification, not a subclass tree.

---
config:
  layout: elk
---
flowchart TB
    accTitle: The nine UFO meta-categories OPDA uses, with example classes and the Relator spine
    accDescr: OPDA's classes are classified under nine UFO categories; the Relator category is load-bearing, with opda:Proprietorship and opda:Transaction founding the Buyer and Seller roles.

    subgraph Substantials["Substantials (existentially independent)"]
      SK["Substance Kind
opda:Person · Property · Organisation ·
LegalEstate · RegisteredTitle · Address"]:::user
      RM["RoleMixin
opda:Buyer · Seller · Evidence"]:::info
      RO["Role
opda:Proprietor"]:::info
      COL["Collective
opda:TransactionChain"]:::user
    end
    subgraph Moments["Moments (existentially dependent)"]
      REL["Relator
opda:Proprietorship · Transaction"]:::data
      QY["Quality
opda:AssuranceLevel"]:::data
      QV["Quality Value
opda:MonetaryAmount · RoomDimension"]:::data
    end
    subgraph Perdurants["Perdurants + information artefacts"]
      EV["Event
opda:Milestone · VerificationActivity ·
UPRNSuccessionEvent"]:::process
      IO["Information Object
opda:Claim · EPCCertificate · Search ·
RiskAssessment · Valuation"]:::service
    end

    REL -->|"founds (mediates)"| RM
    REL -->|"founds"| RO

The Relator is where UFO does irreducible work. The strictly irreducible thing is the relational-reification primitive: reify a relationship as a first-class node that owns the relation's own attributes. The proof in our corpus is the placement of opda:numberOfSellers on the opda:Proprietorship Relator (opda-agent.ttl) — an aggregation attribute of the relationship itself, which OntoClean's monadic meta-properties structurally cannot derive (they have no mediation primitive). UFO's Relator is our chosen, apt expression of that primitive (with FIBO's Arrangement cited as a co-precedent on opda:Transaction), and UFO-L adds the Hohfeldian claim-right ⇔ duty correlativity a conveyancing domain (charges, covenants, easements) needs.

The other categories are facets: a class is classified under "Substance Kind" or "Event" — it is not an instance of a UFO type in any reasoned graph (the level distinction; see §6).

4. How opda:ufoCategory is represented — and the breach we fixed

The category tag went through three states. Understanding the journey is the clearest way to see why the final design is shaped as it is (ODR-0031 / ADR-0045).

1. Free-text in skos:scopeNote prose ("UFO: Substance Kind") — unqueryable.
2. Structured facet, but mis-placed (ADR-0044 Phase 5c): promoted to a real opda:ufoCategory predicate — but declared owl:DatatypeProperty and asserted inline in the reasoned class graphs. This breached the ODR-0030 Rule 1 quarantine ("annotation-graph-only"), and the three-graph gate had no check to catch it.
3. The fix (ADR-0045): relocated to the annotation graph, retyped owl:AnnotationProperty, and given a dereferenceable concept anchor.

The deployed shape decouples the simple tag consumers read from the governed concept that carries the semantics:

flowchart LR
    accTitle: How opda:ufoCategory is represented after ADR-0045
    accDescr: A class carries an inert string tag for its UFO category; the string is keyed by notation to a SKOS concept in opda:UFOCategoryScheme, which carries the OntoClean definition and a closeMatch to the gUFO IRI — all in the annotation graph, never reasoned.

    P["opda:Person
(owl:Class — in the classes graph)"]:::user
    L["'Substance Kind'
(inert xsd:string tag —
owl:AnnotationProperty)"]:::data
    K["opda:SubstanceKindCategory
(skos:Concept in opda:UFOCategoryScheme)
skos:definition = OntoClean signature"]:::service
    G["gufo:Kind
(external gUFO IRI)"]:::external

    P -->|"opda:ufoCategory"| L
    L -.->|"skos:notation key"| K
    K -->|"skos:closeMatch
(reference-not-import)"| G

Everything to the right of opda:Person lives in opda-annotations.ttl. The predicate is an owl:AnnotationProperty (OWL 2 §10.1 — no model-theoretic consequence under any regime, so inertness is intrinsic, not contingent on the shallow reasoner). The opda:UFOCategoryScheme concept is the dereferenceable anchor that carries the OntoClean signature as its skos:definition and a skos:closeMatch to the gUFO IRI — reference-not-import, so we never pull gUFO's rdfs:subClassOf axioms into a graph the reasoner closes over. That last point is the absolute red line: an exactMatch-to-gUFO edge in a reasoned graph would re-import the contested metaphysics the whole architecture exists to keep out.

We also split off the register-deference scheme axis: the codes that read "Quale-in-Region" etc. on the SKOS schemes were value-space shape, not UFO categorial work, so they no longer ride on opda:ufoCategory (ODR-0030 Rule 2).

5. OntoClean as our decision procedure — classification over inheritance

The discipline that actually moved bytes is OntoClean (ODR-0027). It is separable from UFO (it predates it and works with any foundation), and it is what we run to decide, for every type, whether it becomes a coded facet, a role, a subclass, or a relator. The default is classification (a coded SKOS value); a subclass is the exception, admitted only when a type clears the rigidity-plus-distinct-identity bar.

---
config:
  layout: elk
---
flowchart TB
    accTitle: OPDA's classification-over-inheritance cascade (ODR-0027)
    accDescr: The OntoClean cascade OPDA runs — using rigidity, identity and dependence — to decide whether a candidate type is a coded facet, a role, a relator, or a genuine subclass, with worked examples from the corpus.

    T["A candidate type"]:::process --> R{"Rigid?"}:::warning
    R -->|"No — anti-rigid"| ROLE["Model as Role / RoleMixin
— coded, NEVER a subclass of a Kind
e.g. opda:Buyer, opda:Seller, opda:Evidence"]:::service
    R -->|"Yes — rigid"| ID{"Supplies its own
identity criterion?"}:::warning
    ID -->|"No own IC (a value / label)
+R, -I"| FACET["Code as a SKOS facet (sh:in)
e.g. tenureKind, ownerType"]:::service
    ID -->|"Yes, + mediates 2+ bearers (+D)"| REL["Reify as a Relator
e.g. opda:Proprietorship,
VouchEvidence attestation"]:::data
    ID -->|"Yes, distinct IC + own properties"| SUB["Mint an owl:Class
e.g. opda:RiskAssessment,
opda:Person, opda:Property"]:::user

Worked outcomes from the corpus that this cascade produced: tenureKind (+R, −I) → a coded facet, not a subclass tree; VouchEvidence (+D, agent-founded) → re-sorted to a Relator; RiskAssessment (+I, distinct identity) → retained as a class. Enforcement is value-keyed in SHACL (an sh:or material implication on the coded value), not class-keyed — so it holds without depending on entailment.

Is the OntoClean reasoning itself recorded? The verdict of every call is — in the class topology and the coded facets (the tenureKind comment, for instance, records "+R but −I → classification, not a subclass") — and the per-category signature ships in the opda:UFOCategoryScheme skos:definitions (the Relator category reads "(+R, +I, +D)"). Whether to also mark up the meta-properties per type as structured owl:AnnotationProperty data was a held 3–3 (session-041) that session-042 resolved as conditional adoption (ADR-0046): do it — ±R/±I, scoped to the subsumption lattice the check ranges over, never unity — if and only if the canonical OntoClean check (find every anti-rigid type that nonetheless subsumes) ships atomically as a TBox-only CI gate. The principle the council converged on is the same minimum-model discipline that governs the rest of the architecture: you mark up a methodology's worksheet only when a machine reads it — build the gate that reads it, or keep the reasoning as prose.

6. The honesty doctrine — informed, not grounded

The one credibility risk a working data standard cannot afford is overclaiming a guarantee the architecture does not provide. We pre-empt it with explicit honesty dispositions (ODR-0030 Rule 7), and they are machine-readable, not just prose.

---
config:
  layout: elk
---
flowchart TB
    accTitle: The decidability and honesty boundary
    accDescr: What OPDA reasons over, what it validates, and what it merely annotates — with the honesty disclosures attached to the inert layer.

    E["REASON (RDFS-Plus)
rdfs:subClassOf type-propagation only"]:::user
    V["VALIDATE (SHACL)
cardinality, value sets, domain/range-as-checks,
UFO-L correlativity where the use-case demands"]:::security
    A["ANNOTATE (inert)
UFO categories · gated gUFO types ·
OntoClean lineage · IAO/BFO reserve"]:::external

    E -->|"the wire reasons with
nothing UFO-shaped"| A
    V -->|"undecidable UFO constraints
live here, not in OWL"| A

    H1["'UFO-informed', never
'UFO-grounded with guarantees'"]:::warning
    H2["DOLCE lineage disclosed:
the quality categories descend from
DOLCE Quality/Quale/Region (WonderWeb D18)"]:::warning
    H3["UFO-C (social/legal) flagged
as the least-mature layer"]:::warning

    A --> H1
    A --> H2
    A --> H3

Three disclosures ride on the inert layer: we publish "UFO-informed", not "UFO-grounded with guarantees"; a machine-readable skos:scopeNote on opda:ufoCategory discloses that the quality categories descend from DOLCE's Quality/Quale/Region apparatus (WonderWeb D18, 2003), not pure UFO; and we flag UFO-C (the social/intentional/legal layer) as least-mature wherever the standard leans on it. The gated gUFO rdf:type typing pass (ADR-0034) and the IAO information-artefact crosswalk (ODR-0030 Rule 4, adopt-now) follow the same reference-not-import, annotation-graph, never-reasoned discipline.

7. How these decisions get made — the Linked Data Council

The foundational and modelling decisions above were not taken ad hoc. Contested choices are shaped by a Linked Data Council — a dialectic review by a panel of named linked-data authorities (each citing published methodology), with a Devil's Advocate who must explicitly withdraw or hold on every question, producing an auditable transcript. The verdict shapes a proposal; the operator ratifies adoption.

---
config:
  layout: elk
---
flowchart LR
    accTitle: OPDA's decision pipeline from council to artefact
    accDescr: A council session produces a verdict that becomes an ODR and an ADR; the ADR drives the emitter; the emitter output is enforced by CI gates.

    COUNCIL["Council session
(e.g. session-040, session-041)
named panel + Devil's Advocate"]:::user
    ODR["ODR — ontology-modelling decision
(ODR-0030, ODR-0031)"]:::user
    ADR["ADR — engineering realisation
(ADR-0044, ADR-0045)"]:::process
    EMIT["opda-gen emitter
deterministic, byte-identical"]:::service
    GATE["CI gates
three-graph · byte-identity ·
dup-declaration · profile · baspi5"]:::error

    COUNCIL -->|"shapes"| ODR
    ODR -->|"realised by"| ADR
    ADR -->|"drives"| EMIT
    EMIT -->|"enforced by"| GATE

This is why every term carries a dct:source and every non-trivial choice is traceable: the reasons survive, not just the verdicts. When a defect is found — as with the Phase 5c quarantine breach — the same machinery records the finding (session-041), the corrected decision (ODR-0031), and the engineering fix (ADR-0045), with held dissent and its re-open trigger recorded verbatim.

8. The benefits — what this architecture buys us

The synthesis, in one sentence: we keep the one discipline that demonstrably improves the model (the UFO/OntoClean decision procedure and the Relator primitive) and ship only pragmatic SHACL/SKOS/RDF that stands on its own — carrying the foundational commitment as an inert, honestly-disclosed, CI-quarantined provenance record.

9. Glossary

10. Sources

Internal decisions: ODR-0030 (foundational-ontology choice) · ODR-0031 (ufoCategory representation) · ODR-0027 (classification doctrine) · ODR-0029 (entailment regime) · ODR-0004 §3a (three-graph separation) · ODR-0011 §8a (the UFO category framework) · ADR-0034 (gated gUFO typing) · ADR-0044 (ontology as web pages) · ADR-0045 (the quarantine restoration + gUFO scheme + sixth gate). Council transcripts: session-040 and session-041.

External literature: G. Guizzardi, Ontological Foundations for Structural Conceptual Models (2005); Almeida, Guizzardi, Sales & Fonseca, gUFO: A Gentle Foundational Ontology for OWL (the OWL-2-DL expressibility limit); Masolo, Borgo, Gangemi, Guarino & Oltramari, WonderWeb Deliverable D18 — DOLCE (2003); Guarino & Welty, "An Overview of OntoClean" (Handbook on Ontologies, 2009); Griffo, Almeida & Guizzardi (UFO-L legal relations); ISO/IEC 21838-2 (BFO); W3C OWL 2 Structural Specification §10 (annotation properties), SHACL, SKOS Reference; Bernabé et al. (2023, no measured downstream benefit from foundational ontologies); Merrill (2010, BFO interoperability does not require its realism).

This document describes OPDA's deployed implementation. The patterns are reusable, but the choices here are ours — taken for the reasons recorded above, and enforced by the CI gates that ship with the corpus.

Related

The honest counter-view — whether UFO is the right foundation at all, with sourced critiques and the upper-ontology alternatives compared — is on Foundational ontology: critique & alternatives, the sibling critique page.