How Magellan Uses Ontologies
Why a Concept Layer
Most schema mapping happens one pair at a time: a source field is matched to a target field, and the reason it matched lives in someone's head. That works until the tenth integration, when the same concept — *patient date of birth*, *member identifier*, *diagnosis code* — has been re-mapped a dozen different ways with no shared anchor.
Ontologies fix that by adding a concept tier between source and target schemas. Instead of asking "does patient.dob look like subject.birthDate?", Magellan asks "do both resolve to the same governed concept — Concept:BirthDate?". A mapping becomes an assertion that *both sides denote the same meaning*, which is far more explainable and far more reusable than pairwise string similarity.
In Magellan's Metadata as Code™ model, an ontology is just another first-class, versioned, governed asset — sitting alongside source schema(s), target schema(s), and the mappings that connect them.
What an Ontology Is, in Magellan Terms
A Magellan ontology is a controlled set of concepts and the relations between them:
| Element | What it captures |
|---|---|
| Concept | A governed unit of meaning (e.g. BirthDate, MemberId, DiagnosisCode) |
| Label / synonym | Surface terms that denote the concept (DOB, date_of_birth, birthDate) |
| Relation | How concepts relate (broader, narrower, exactMatch, relatedMatch) |
| Binding | A pointer to an external standard code (SNOMED CT, LOINC, RxNorm, FHIR) |
Lightweight controlled vocabularies are expressed in SKOS (skos:exactMatch, skos:broader). When formal reasoning is genuinely needed — disjointness, equivalence inference — Magellan supports OWL constructs (owl:equivalentClass). Import and export use RDF/Turtle and JSON-LD so concepts move cleanly in and out of existing terminology tooling.
The default is SKOS. OWL is opt-in, because most mapping work needs a governed glossary, not a theorem prover.
How Ontologies Strengthen the Semantic Match Engine
The Semantic Match Engine already ranks candidates across five algorithm classes. Ontology grounding adds a sixth signal — and, importantly, an *authoritative* one.
When a concept layer is active, each candidate target field is also checked for an ontology equivalence: do the source and target both bind to the same concept, or to concepts related by skos:exactMatch / owl:equivalentClass? When that fires, the engine tags the candidate with an ontology_equivalence class:
| Class | What it asserts |
|---|---|
exact_match | Source and target normalize to the same string |
synonym_match | Different surface terms, same concept |
abbreviation_match | One side abbreviates the other |
context_hierarchy | The match holds by structural position |
domain_equivalence | A domain dictionary asserts equivalence |
ontology_equivalence | Both sides resolve to the same governed concept (or an exactMatch relation) |
ontology_equivalence is high-precedence: a match backed by a governed, approved concept binding is stronger evidence than a similarity score. The class label travels into the decision record, so an auditor can reconstruct not just *that* two fields matched, but *which concept* made them equivalent.
Ontologies Are Versioned, ULID-Keyed Assets
Concepts are not free-floating. Each ontology, and each concept within it, is a versioned artifact under Semantic Versioning, identified by a ULID — never a UUID. The same lifecycle that governs schemas and mappings governs ontologies:
- A concept binding is drafted, reviewed, then Approved & Published.
- A mapping version pins the exact concept versions it relies on, just as it pins schema versions.
- A mapping version cannot enter approval until every schema *and* concept version it pins is itself Approved & Published.
This keeps the approval order strict: the meaning is settled and published first, then the mapping that depends on that meaning is submitted for approval.
Healthcare Terminology Bindings
For the health vertical, the concept layer is where standard terminologies plug in. A concept can bind to:
- SNOMED CT for clinical findings and procedures
- LOINC for observations and lab results
- RxNorm for medications
- FHIR terminology bindings for resource-level alignment
- UMLS as a cross-vocabulary bridge
A target field bound to a LOINC concept gives the Semantic Match Engine an authoritative anchor — subject.observation.code :: LOINC:8302-2 is unambiguous in a way that height never is.
Every Resolution Is Auditable
Ontology resolution decisions are not a black box. When the engine resolves a field to a concept, the decision record captures the concept ULID, the concept version, the relation that fired (exactMatch, broader, …), the confidence, and — once an SME accepts — the approver identity.
That record appends to the same hash-chained Audit & Trust Ledger as every other decision, contributing to the evidence Magellan produces for CMMC L2 §3.3 AU-2/AU-3, HIPAA §164.312(b), and 21 CFR Part 11 §11.10(e). A concept binding that drove a mapping years ago can be replayed exactly, at its pinned version.
How to Adopt It
You don't need a formal ontology on day one:
1. Start with a glossary. Stand up a SKOS controlled vocabulary of the concepts your domain already argues about.
2. Turn on resolution. Let the Semantic Match Engine surface ontology_equivalence candidates against that vocabulary.
3. Import standards. For healthcare, bind concepts to SNOMED CT / LOINC / RxNorm / FHIR.
4. Add OWL only if you need it. Reach for formal reasoning when disjointness and equivalence inference actually earn their keep.
The payoff compounds: every concept you govern makes the next mapping more explainable, more reusable, and more defensible in front of an auditor.
To see the concept layer working against your own schemas, request a demo or explore the platform features.
*Magellan AI Corporation — Charting every data connection.*