The argument, up front

Thesis

The generic parts of your domain — time, agents, organizations, locations, quantities, codes, metadata, provenance — are already modeled, standardized and maintained by people who spent years getting them right. Import those, align to them, and reserve your modeling effort for the concepts that make your business your business.

Reuse is not a shortcut — it is the discipline that makes an ontology interoperable, trustworthy and affordable to maintain. A model built on shared standards speaks a language other systems already understand, inherits years of expert design, and stays small enough to own. This brief makes the case, catalogues the standards worth knowing, gives criteria for choosing among them, shows the mechanisms for reusing them, and is honest about when not to.

The pattern the rest of this brief recommends is always the same: vendor the shared standards your model leans on — time, parties, codes, metadata, provenance — and add your own axioms on top of them, in your own modules, never inside theirs.

01 — WHY IT MATTERS

The advantages of reuse

Every benefit below compounds. A model that reuses standards is cheaper to build, easier to connect, and safer to trust than one modeled from scratch.

interoperability

Speak a shared language

When your “organization” is org:Organization, other systems, datasets and tools already know what you mean. Integration and data exchange stop being translation projects.

economy

Don’t reinvent the wheel

Modeling time or parties well is genuinely hard. Importing a finished, correct vocabulary saves months and removes an entire class of design decisions from your plate.

quality

Inherit expert design

Standards are peer-reviewed and battle-tested across thousands of deployments. You inherit their edge cases already handled and their pitfalls already avoided.

tooling

Ride the ecosystem

Reasoners, validators, editors and libraries already understand widely-adopted vocabularies. Popular standards come with converters, examples and Stack Overflow answers.

people

Shared understanding

New team members and partners already know SKOS, Dublin Core, FOAF. Reuse lowers the onboarding cost and widens the set of people who can read your model.

linkability

Connect to the wider web

Using common IRIs lets you link out to external, authoritative datasets — GeoNames, Wikidata, registries — for enrichment you never have to maintain.

longevity

Someone else maintains it

A standards body versions and stewards the vocabulary. You inherit its updates and its stability instead of carrying the maintenance yourself.

focus

Spend effort where you differ

Every hour not spent re-modeling money or dates is an hour spent on the concepts that are actually yours to get right — the ones no standard will ever model for you.

02 — WHICH STANDARDS

The vocabularies worth knowing

Start with the languages — RDF, RDFS, OWL and SHACL are themselves the first standards you reuse. On top of them sit the cross-domain building blocks nearly every enterprise graph needs.

Cross-domain building blocks

Standard	Prefix	Covers	Status
SKOS	skos	Concept schemes, taxonomies, thesauri, code lists	W3C Rec
Dublin Core Terms	dct	Metadata: title, creator, dates, identifier, source	DCMI
PROV-O	prov	Provenance: entities, activities, agents, lineage	W3C Rec
OWL-Time	time	Instants, intervals, temporal relations	W3C Rec
W3C Organization	org	Organizations, units, membership, roles, posts	W3C Rec
FOAF / vCard	foaf / vcard	People and agents / contact details	community / W3C Note
schema.org	schema	Broad web vocabulary: things, orgs, events, products	industry
QUDT / OM	qudt	Quantities, units of measure, dimensions	community
GeoSPARQL	geo	Geometries and spatial querying	OGC
DCAT / VoID	dcat / void	Describing datasets and RDF data catalogs	W3C
SOSA / SSN	sosa	Sensors, observations, samples, actuation	W3C Rec
RDF Data Cube	qb	Multi-dimensional statistical & aggregate data — observations over dimensions and measures	W3C Rec

Upper ontologies & domain standards

Standard	Kind	Covers	Status
BFO	upper	Top-level categories (continuants, occurrents) for rigorous alignment	ISO/IEC 21838
gist	upper	A deliberately small, business-friendly upper ontology	Apache-2
DOLCE / SUMO / UFO	upper	Foundational categories from different philosophical stances	academic
FIBO	domain — finance	Financial instruments, agreements, parties, monetary concepts	EDM Council / OMG
ACORD	domain — insurance	Insurance data standards — a terminology source (message-oriented)	industry
FHIR / SNOMED CT	domain — health	Clinical data exchange / clinical terminology	HL7 / SNOMED
ISO code lists	reference data	Currency (4217), country (3166), language (639) — as SKOS	ISO

A note for domains without a dominant standard

Some domains have no single authoritative ontology — insurance, for instance, unlike finance with FIBO. The strategy there is to reuse the cross-domain building blocks (parties, time, codes, units, money), mine any industry data standard for its agreed terminology — not its message structure — and model the genuinely domain-specific concepts yourself. Reuse the shared layer; build only the specialized core.

03 — HOW TO CHOOSE

Criteria for adopting a standard

Reuse is a decision, not a reflex. Weigh a candidate standard against these before you import it.

Fit

Does it actually model your concepts — can it answer your competency questions? A close-but-wrong standard costs more than modeling from scratch.

Right granularity

Neither too thin to be useful nor so heavy it drags in a universe you don’t need. Match the standard’s scope to your need.

Maturity & governance

Backed by a standards body (W3C, ISO, OGC), stable, versioned. A recommendation outlives a hobby project.

Adoption & tooling

Widely used means more tools, more examples, more people who know it, and more datasets you can link to.

License

Openly and permissively licensed for your use. Confirm you can import, extend and redistribute without friction.

Quality & profile

Logically consistent, well documented, and compatible with your reasoning profile — an OWL-Full vocabulary can break OWL 2 DL reasoning.

Modularity

Can you import just the slice you need, or is it monolithic? A modular standard lets you keep the import closure small.

Alignment cost

How cleanly does it sit beside your model and your upper ontology? Clashing ontological commitments make alignment expensive.

04 — HOW TO REUSE

Import, extend, or align

Reuse is a spectrum from “use as-is” to “merely point at.” Pick the lightest mechanism that meets the need.

1 · use as-is

Import and use the terms directly

owl:imports the standard and use its classes and properties unchanged — dct:created, skos:broader, time:hasBeginning. The cheapest, highest-interoperability option.

2 · specialize

Import and extend under the standard

Subclass or sub-property your concepts beneath the standard’s, so your terms inherit its meaning — for example declaring your local party class an rdfs:subClassOf org:Agent, or your category a skos:Concept. The bridge axiom goes in your module, never in the vendored file.

3 · reference without adopting

Align by mapping — and MIREOT

When you don’t want the whole ontology, link to it: owl:equivalentClass, rdfs:subClassOf, skos:exactMatch/closeMatch. Or apply MIREOT — import only the few external terms you actually reference, not their entire closure.

4 · control the dependency

Vendor and pin

Rather than importing a live network IRI, keep a local, version-pinned copy of each vocabulary you depend on. You gain offline builds, reproducible reasoning and protection from upstream churn — at the cost of updating deliberately.

What “MIREOT” means

MIREOT — the “Minimum Information to Reference an External Ontology Term” — is how you reuse one term without importing its whole ontology. Rather than let owl:imports pull in the full closure, you bring in just the term’s IRI, its label and definition, and one parent to place it — keeping the canonical IRI (so interoperability holds) but not its full axiomatization. Your import closure stays small and reasoning stays tractable. Tools such as OntoFox and ROBOT’s extract command generate these minimal reference modules for you.

Two rules that keep reuse clean

Never redefine a standard’s term in your namespace — use skos: for SKOS, don’t mint your own myns:broader (see the namespace policy). And never hand-edit a vendored standard to add your concepts — put your axioms in your own module and reach up to the standard, so you can drop in a new version of it without losing your work.

05 — TYPICAL USE CASES

What to reach for, and when

The recurring needs of an enterprise graph and the standard that already solves each.

When you need to model…	Reach for	Why
Metadata — title, author, dates, identifiers	dct (Dublin Core)	Tiny, universal, understood everywhere
Provenance & lineage	prov (PROV-O)	The standard for who/what/when produced data — see workflows & provenance
Time & validity intervals	time (OWL-Time)	Instants, intervals, ordering — e.g. validity periods and lifecycle events
Parties & organizations	org, foaf, vcard	Orgs, membership, roles, people, contact points
Controlled vocabularies & code lists	skos	Taxonomies, thesauri, ISO country/currency codes
Locations & geometry	geo (GeoSPARQL)	Spatial features and spatial query for risk/territory
Units & quantities	qudt / FIBO money	Dimensioned values, currencies, conversions
The graph’s own datasets	dcat / void	Catalog and describe what you publish
Aggregate, statistical or KPI data	qb (RDF Data Cube)	Observations over shared dimensions and measures — totals, rates, time series
Public-facing, discoverable data	schema (schema.org)	Broad adoption, search-engine understanding
Financial concepts	FIBO	Money, instruments, agreements, financial parties
Linking out for enrichment	Wikidata, GeoNames	Authoritative external reference data you don’t maintain

06 — THE OTHER SIDE

The costs, and when not to reuse

Reuse is the default, not a dogma. Reused badly it imports problems, so weigh these against the advantages.

reasoning cost

Heavy imports bloat the closure

Pull in a large ontology for two terms and every reasoning run pays for axioms you never use. Mitigate: import a module, or apply MIREOT.

forced fit

A near-miss distorts your model

Bending your domain to fit a standard that doesn’t quite match produces worse modeling than doing it yourself. Mitigate: align loosely, or model it and map later.

semantic clash

Incompatible commitments

Two standards (or a standard and your upper ontology) can make contradictory assumptions. Mitigate: align only at the boundary; pick a compatible foundation.

profile traps

OWL-Full by accident

Mixing vocabularies can push you out of OWL 2 DL and break your reasoner. Mitigate: check each import’s profile before adopting.

dependency risk

Upstream churn

An external vocabulary can change or disappear beneath you. Mitigate: vendor and pin a version; update deliberately (see versioning).

over-loose

The wrong altitude

A web-scale vocabulary like schema.org may be too loose for internal precision. Mitigate: use it at the edge for interop, a tighter model at the core.

07 — IN PRACTICE

Recommendations

Reuse before you build. Before modeling any generic concept — time, party, place, money, code, metadata — check whether a standard already covers it. Most do.
Let competency questions test the fit. A standard earns adoption when it answers your questions; if it can’t, it is the wrong standard, not a reason to distort the questions.
Prefer the lightest mechanism. Use as-is over extend, extend over align, align over copy. Keep the import closure as small as the need allows.
Vendor and pin your dependencies. Keep local, versioned copies for reproducible builds, and add your axioms in your own modules — never in the vendored files.
Guard the namespaces. Use each standard’s terms under its own namespace; mint your own only for what is genuinely yours.
Reserve your originality for your domain. The point of reuse is to free your effort for the concepts that make your business distinct — the ones no standard will model for you.

The one habit to keep

When a concept feels generic — a date, an organization, a code, a unit, a source — assume someone has already standardized it, and go look before you model. The rare time nothing fits, model it yourself and align outward. An ontology that stands on shared foundations is interoperable, trustworthy and small; one that reinvents them is none of the three.