The Standards Atlas: How to Read Any Data Standard
Over the next module you will meet a parade of standards: IFC and Uniclass in construction, ISO 15926 and its successor in industry, FIBO in finance, SNOMED CT in health, IES in government, GS1 in commerce. You could memorise them one by one and be obsolete in five years, or you could learn to read any data standard cold in an afternoon and be dangerous for a career. This lesson is the second option: a map of how standards are layered, a decoder for what words like conformance actually commit anyone to, and a five-axis evaluation method we apply, in public tooling and in paid engagements, before trusting any standard with anything.
The three-layer map
Almost every standard you will ever meet occupies one of three layers. Foundational (top-level) standards fix the basic categories of existence: what counts as an object, a process, a quality, a part. This is the terrain of the ISO/IEC 21838 series, whose part 1 defines what a top-level ontology must provide and whose part 2 standardises BFO; the 4D lineage of lesson 26 competes at the same altitude. Foundational standards contain no domain words at all: no pumps, no invoices, no genes. Mid-level standards bridge downward with cross-domain vocabulary that nearly every domain needs, agents, artifacts, information entities, units, events; the Common Core Ontologies play this role in the BFO world, and HQDM’s pattern catalogue plays much of it in the 4D world. Domain standards are where the pumps and invoices finally live: the Gene Ontology, FIBO, IFC, FoodOn, each anchored (well or badly) to something above it.
The layer diagnosis is your first reading move, because it tells you what a standard can and cannot do for you. A domain vocabulary cannot settle identity-and-change questions; that is foundational work, and if the domain standard never says which foundation it assumes, it has one anyway, implicit and probably inconsistent. Conversely a top-level ontology will never give you a parts catalogue. Most integration disasters we get called into involve someone asking a layer to do another layer’s job.
Spec, schema, or ontology?
The second reading move is to identify what kind of artifact you are actually holding, because the word “standard” covers three different species with different powers.
A specification document is prose with normative force: definitions, requirements, conformance clauses, aimed at human implementers. A schema is a machine-checkable description of data structure: an XSD, a relational DDL, an EXPRESS schema in the ISO 10303 tradition, a SHACL shapes graph. It constrains syntax and structure but carries little or no logical semantics: nothing follows from a schema except valid or invalid. An ontology, in the sense this course uses, is a logical theory: its axioms license inference, so something new can follow from your data. The three species are complements, not rivals, and mature ecosystems ship all three; buildingSMART, for instance, publishes IFC as schema, prose documentation around it, and machine-checkable delivery specifications, while the industrial world’s ISO 15926 lineage has been renumbered and reworked into the ISO 23726 series on ontology-based interoperability, whose part 3, the Industrial Data Ontology, reached FDIS stage as a genuine OWL ontology maintained through the Industrial Ontologies Foundry orbit and POSC Caesar community. Meanwhile GQL, published as ISO/IEC 39075 in April 2024 and the first new ISO database language in over three decades, is neither schema nor ontology but a query language standard. Naming the species tells you what verification is even possible: documents get compliance reviews, schemas get validators, ontologies get reasoners and test suites.
Beware the halo effect that flows between species. A gorgeous ontology rendering does not make the underlying committee prose precise, and an ISO number does not make a vocabulary logically strong. Some published “ontologies” are schemas wearing OWL syntax: every class primitive, no disjointness, no restrictions, nothing at stake. Lesson 27 gave you the name for this condition, refutation-inert, and the test for it.
What breaks · adopting the class names without the commitments
The register team, preparing for construction-domain data, discovers that IFC has a pump class and reaches for the strongest available glue:
ex:Pump owl:equivalentClass ifc:IfcPump . # same word, job doneBut IFC splits the world deliberately: IfcPumpType carries the design-level facts, and an IfcPump occurrence is an element placed in a building model, which is far closer to the register’s functional position than to its physical serial unit; the physical unit’s story arrives later, at handover. Our ex:Pump, after lesson 26, means the physical worm. The equivalence therefore welds positions to units, which is lesson 1’s model-versus-unit disease re-imported with an ISO badge on it: pump counts drift again, and warranty history starts attaching to positions that have hosted three different machines. Nobody misread IFC; the failure was transplanting its vocabulary while discarding its ontological commitments, then asserting definitional equality where at best a directional, documented mapping holds. The next lesson’s machinery, explicit mapping predicates with justification, exists precisely so this one-line convenience never gets written.
What conformance actually means
Here is the paragraph that saves you from procurement theatre. When a vendor or a project claims conformance to a standard, the claim means exactly what the standard’s conformance clause says and not one word more. Reading moves: find the conformance section first, note whether conformance targets are data, software, or processes, and check whether conformance is testable in principle, whether an automated checker could decide it, or whether it merely requires assent to a worldview. The ISO/IEC 21838 series is admirably explicit in this respect, stating machine-verifiable requirements a top-level ontology and its documentation must meet. At the other extreme sit standards whose conformance clause amounts to “uses the terms in this document”, which permits two conformant systems to disagree about everything that matters. In between sit profile mechanisms, such as OWL 2’s EL, QL and RL profiles from lesson 6, where conformance to a named subset carries precise computational guarantees. When two systems each conform to the same weak standard and still cannot exchange data, nobody has lied; the conformance bar was simply below the interoperability bar. Measure the gap before you sign anything.
The five-axis evaluation method
When we assess a standard, for a client, for a crosswalk, or for our own published tooling, we score it on five axes. None requires insider knowledge; all can be completed from public artifacts in a few hours.
| Axis | The question | Where the evidence lives |
|---|---|---|
| Scope | What does it actually cover, at which layer, and what does it silently assume from other layers? | Stated scope section versus the actual term inventory; check for an explicit upper-level commitment |
| Axiomatic strength | Could data ever contradict it? Disjointness, restrictions, cardinalities, or bare term lists? | The machine-readable artifact itself; corruption testing as in lesson 27 |
| Tooling | Can you validate, reason over, diff and convert it with maintained software? | Reference implementations, validators, active repositories, library support |
| Governance | Who changes it, how often, through what process, with what deprecation policy? | Issue trackers, release cadence and notes, change procedures, editor lists |
| Adoption | Who has bet real systems on it, and is the trend rising or falling? | Named deployments, mandates, procurement requirements, ecosystem registries |
Two scoring habits matter. First, the axes do not average: a standard can be strong on four axes and still be disqualified by a single fatal one, most often governance (the last release was 2017 and the mailing list is dead) or tooling (no maintained parser exists outside one vendor’s paid product). Second, score against your use, not in the abstract: for a regulatory reporting pipeline, governance dominates; for a safety case, axiomatic strength dominates; for a hiring market, adoption dominates. The OBO Foundry is worth studying as the ecosystem that operationalised these axes as membership principles, open licensing, defined scope, common format, documented governance, and automated dashboard checks, which is a large part of why life sciences interoperate better than any other domain.
Worked example · the Aberdeen-2 asset register
Where we left it: a tested, governed model. Before the domain tour, one full read of a neighbouring standard, IFC, using this lesson’s method.
An afternoon with the public artifacts, following the reading moves in order. Layer: domain standard; it will not settle identity and change for us, and does not claim to. Species: a schema with prose specification and machine-checkable delivery specs, EXPRESS by heritage, not a logical theory; so verification means validators, not reasoners, and axiomatic strength stays our job on our side of the fence. Conformance: targeted at data deliveries, and testable, which is the good kind. Then the register’s three standing questions. Identity: IFC’s type/occurrence split maps beautifully onto lesson 25, IfcPumpType to our HX-300 level, occurrences to our functional positions, but note the false friend dodged in the block above: an occurrence is not our physical unit. Units of measure: explicit unit assignment, so our QUDT module needs one mapping table, not guesswork. Identifiers: every element carries a GlobalId, persistent by intent, though in practice tool exports can re-mint them, so the register treats them as per-model identifiers and never mints its own IRIs from them, lesson 5’s discipline applied to someone else’s IDs.
State of the register: one standard read cold, its commitments located, its false friends flagged. The domain tour now has a method to march to, and the crosswalk lesson supplies the bridge-building tools.
False friends: the trap between standards
The final reading skill is the one that bites hardest in crosswalk work. Standards are written in natural language, natural language recycles words, and identical terms across standards routinely name different things. “Activity” in a provenance vocabulary, an occurrent in BFO, and a scheduled task in a construction schedule share a spelling, not an extension. “System” means an engineered assembly in one standard and an information system in the next. “Function” might be a mathematical mapping, an engineering capability, or an organisational role. Treat every cross-standard term match as a false friend until proven otherwise: pull both definitions, compare what each class actually includes and excludes, and test a handful of instances against both. This is precisely why, when detail flows between standards in practice, a large fraction of it dies in translation, and why lesson 29 will insist that mappings carry explicit predicates, confidence and provenance rather than bare equals signs. The atlas habit and the bridge discipline are two halves of one competence, and our crosswalk certification course drills both against live standards.
Carry the method into the domain tour that follows. For each standard you meet, ask: which layer, which species, what conformance actually commits, how it scores on five axes, and which of its terms are false friends of terms you already know. Standards stop being a parade to memorise and become instances of a pattern you can read, and reading standards is, quietly, one of the highest-leverage professional skills in data: the people who can do it decide what everyone else integrates against.
Check yourself
Reading a standard’s documentation for the register, you find four statements. Which one tells you about the standard’s identity criteria, the thing lesson 3 taught you to hunt for first?
- “Each element occurrence carries a GlobalId that persists for the life of the element within the model.”
- “IfcPump is a subtype of IfcFlowMovingDevice.”
- “Conforming files shall be encoded in the STEP physical file format.”
- “The schema defines several hundred entity types covering the built environment.”
Show the answer, and why each wrong option is wrong
A is correct. It answers the question “what makes two records the same thing, and for how long”: identity is carried by an identifier, scoped to the model, persisting per element lifetime. Every caveat in that sentence is load-bearing for integration, including what it does not promise, namely identity across independently exported models.
B is classification: it places the class in a hierarchy and says nothing about when two pumps are one pump. Subsumption and identity are different questions, which is most of what OntoClean was about. C is encoding, the outermost skin of a standard; syntax tells you how bytes are arranged, never what survives a re-export. D is the size metric, and lesson 27 already dismantled it: entity count without axiom placement is coverage theatre. The reader who reflexively reaches for A-type sentences first, in any standard, has acquired the atlas skill this lesson exists to teach.
