Evaluating & Adopting a Standard

Adopting a standard is a dependency decision

Depending on a standard ontology is like depending on a software library: powerful, but you inherit its constraints. Evaluate it along these axes before you build on it:

• Licence & cost — Is it open (FIBO, OSDU, schema.org, OBO), affiliate-licensed (SNOMED CT needs a member/affiliate licence), or paywalled (ISO IDMP, ISO 15926 are purchased ISO documents)? Licensing decides whether you can even redistribute the terms in your product.
• Governance & cadence — Who maintains it, how often does it version, and how are change requests handled? A standard with no active steward is a liability.
• Expressivity / profile — Is it a lightweight vocabulary (schema.org, SKOS thesauri), a rich OWL 2 ontology (FIBO), or an OWL 2 EL terminology built for fast classification of huge hierarchies (SNOMED CT's OWL form)? The profile dictates what reasoning you can afford.
• Upper-ontology anchoring — Many standards anchor to a foundational ontology for consistency: BFO (OBO Foundry, ISO 15926-14/IDO) or a pragmatic upper like gist. Anchoring helps alignment later.
• Coverage & fit — Does it actually model your slice of the domain, or only 60% of it?

Two reuse strategies

1. Import (owl:imports) the standard and use its terms directly — maximal interoperability, but you inherit its full size and axioms.
2. Thin domain layer — reference the standard's IRIs and rdfs:subClassOf them from a small local ontology (the Atlas-Bank-on-FIBO pattern). You stay aligned without swallowing the whole import.

Use Case Example: A pharma team needs medicinal-product identity. IDMP fits, but the ISO texts are paywalled and huge, so they model a thin local layer whose classes rdfs:subClassOf the IDMP concepts and carry the regulator's required identifiers — aligned to the standard, without importing thousands of out-of-scope terms.

Choosing a standard is choosing a dependency. You don't add a library to production because it's popular — you check its licence (can I even ship it?), its maintenance (is it alive?), its API surface (does it fit, or drag in the world?) and its community (who'll help at 3am?). Importing a giant ontology you barely use is the data equivalent of pulling a 200 MB framework to format one date.

An adoption decision tree

Walk licence → fit → expressivity → reuse strategy before you commit a single triple to the standard.

Vocabulary field guide: what every standard is for

A standard's name is less useful than the job it does. Keep this table nearby while reading the track:

The intuition

A standard usually gives you one or more of four things: names (classes/terms), keys (identifiers), rules (constraints/axioms), and governance (who maintains it). Learners get lost when those are blurred. GS1 is identifier-heavy. FIBO is axiom-heavy. SNOMED is terminology-heavy. OSDU is schema/platform-heavy. Good adoption starts by asking which of the four you actually need.

Most-used examples you will see at work

These are the recurring production patterns behind the standards in this track:

The senior habit is to name the production pattern first, then choose the standard. 'We need SNOMED' is vague. 'We need fine-grained diagnosis meaning carried in FHIR and mapped to ICD for billing' is an architecture.

Licence and adoption checklist

Before importing, copying, publishing or embedding any industry standard, answer these questions explicitly:

1. Can we use it internally? Open vocabularies usually allow this; SNOMED CT, ISO IDMP and ISO 15926 may require membership, affiliate licensing or purchased documents.
2. Can we redistribute terms or definitions? Pointing to public IRIs is different from shipping the standard's labels, definitions, hierarchy, or extracts in your product.
3. Can we expose derived data? Marketplace datasets, GS1 services, clinical terms and regulator-provided reference data can have downstream use restrictions.
4. Which version are we bound to? Standards change. Record version, release, edition, jurisdiction and mapping date for every crosswalk.
5. Who owns updates? A standard without an internal product owner rots inside your system after the first external release.

Practical rule

In learning content and demos, use illustrative, structurally faithful fragments unless the standard is clearly open and attribution-safe. In production, ask legal/procurement before redistributing licensed clinical or ISO content. This is not legal advice; it is engineering hygiene.