SDC4 Alignment to BFO 2020 (ISO/IEC 21838-2:2021)

Overview

SDC4's ontologies (sdc4.owl, sdc4-meta.owl) are aligned to the Basic Formal Ontology (BFO) 2020 via a separate mapping ontology (sdc4-bfo.owl). This alignment satisfies the DoD/ODNI/CDAO requirement for BFO + CCO as baseline formal ontology standards (January 2024 mandate).

Why a Separate Mapping File

The alignment is implemented as sdc4-bfo.owl / sdc4-bfo.ttl rather than modifying sdc4.owl directly:

1. No propagation needed -- sdc4.owl exists in 14+ copies across 4 repositories and cookiecutter templates. A separate file avoids touching any of them.
2. Zero owl:imports in sdc4.owl -- Adding an import would break offline and air-gapped deployments.
3. Optional by deployment -- Government customers load it; commercial customers skip it.
4. No version bump -- sdc4.owl stays at 4.0.0. The mapping ontology has its own version (1.0.0).
5. Reversible -- Removing the file breaks nothing.

Why BFO Directly, Not Through CCO

The Common Core Ontologies (CCO) add 11 mid-level ontologies with hundreds of classes. Since SDC4 maps almost entirely to a single BFO class (GenericallyDependentContinuant), CCO adds bulk without value. The mapping is BFO-compatible, so SDC4 interoperates with CCO-based ontologies without importing them.

If a government reviewer demands CCO, a sdc4-cco.owl can be added later using the same separate-file pattern.

Class Mapping

SDC4 is a meta-level ontology about data structures and information artifacts, not a domain ontology about real-world entities. Every SDC4 class is an information artifact specification, which maps to BFO's GenericallyDependentContinuant (BFO_0000031).

Axioms (4 total)

The CMC axiom is the critical one. Because all SDC4 data-modeling classes (Cluster, XdString, XdQuantity, XdTemporal, etc.) are subclasses of CMC, the reasoner infers they are all GenericallyDependentContinuant instances via transitivity. The three non-CMC classes need explicit axioms because they sit outside the CMC hierarchy.

Files

These files exist in: - src/rm/sdc4/ -- reference model source - All cookiecutter template ontologies/ directories (lightweight and enterprise)

Enabling BFO Alignment

Enterprise Deployments (GraphDB)

Add to your Django settings:

LOAD_BFO_ALIGNMENT = True

Then run:

python manage.py init_graphdb

This loads bfo-2020.owl and sdc4-bfo.ttl into GraphDB alongside the core ontologies. The OWL 2 RL ruleset will infer all SDC4 classes as BFO GenericallyDependentContinuant subclasses.

Lightweight Deployments (Fuseki)

Load the files manually into your Fuseki dataset:

# Load BFO first, then the alignment
curl -X POST http://localhost:3030/dataset/data \
  -H "Content-Type: application/rdf+xml" \
  --data-binary @ontologies/bfo-2020.owl

curl -X POST http://localhost:3030/dataset/data \
  -H "Content-Type: text/turtle" \
  --data-binary @ontologies/sdc4-bfo.ttl

Note: Fuseki without a reasoning configuration will store the explicit axioms but will not infer transitive subclass relationships. This is sufficient for SPARQL queries that directly reference the 4 axioms.

Disabling

Omit LOAD_BFO_ALIGNMENT = True (or set it to False). The system behaves identically to before the alignment was introduced.

Verification

Protege

Open sdc4-bfo.owl, run the HermiT reasoner. Confirm: - Zero unsatisfiable classes - No disjointness violations - All SDC4 classes inferred as GenericallyDependentContinuant subclasses

GraphDB SPARQL

After loading with LOAD_BFO_ALIGNMENT = True:

SELECT ?class WHERE {
  ?class rdfs:subClassOf <http://purl.obolibrary.org/obo/BFO_0000031> .
}

All SDC4 classes should appear in the results.

Negative Test

Confirm that omitting sdc4-bfo.ttl produces identical behavior to the pre-alignment state (no BFO types inferred).

BFO Version

Pinned to BFO 2020, which corresponds to ISO/IEC 21838-2:2021. The local copy (bfo-2020.owl) is bundled to avoid network dependencies. Source: http://purl.obolibrary.org/obo/bfo/2020/bfo.owl