Reuse, extend or build an ontology: how to decide

Short answer

Reuse a standard ontology when your domain is regulated, your data will be exchanged or audited, or the concepts are stable and already agreed (drugs, diagnoses, financial instruments, crops and pests). Build your own only when the domain is new or narrow enough that no standard covers it. The usual answer is in between: take the slice of a standard that covers your questions, keep its identifiers, and extend it where your domain is different. Whichever you pick, write the questions the graph must answer first. They decide how much of any ontology you need.

Start with the questions

Before choosing an ontology, write ten to fifteen questions the graph must answer. "Which suppliers share a single-point-of-failure component?" tells you which node types and relationships you need far better than a whiteboard session does. The questions scope the model: if no question needs a Region node, region is probably a property. They also become your acceptance tests later (see How to test a knowledge graph).

If the people who will use the graph can't write these questions, the project is not ready for an ontology of any kind.

When to reuse

• Regulated or interoperable domains. If your data will ever be exchanged, audited or mapped to another system, you need the standard vocabulary. A medical graph with its own invented diagnosis codes can't be joined to anyone else's data without a mapping table someone has to maintain.
• Stable concepts. "Drug", "diagnosis" and "security" have been argued over by standards bodies for years. You are unlikely to model them better than the people who maintain the standard.
• Governance you don't want to run. A maintained standard handles versions, deprecations and mappings to other standards. That is real work taken off your plate.

Some standards worth knowing: SNOMED CT and ICD-11 in healthcare, MedDRA for drug safety, FIBO in finance, GS1 EPCIS and SCOR in supply chains, W3C PROV for provenance, EPPO codes for crops and pests, and schema.org or Wikidata as general-purpose glue. I wrote a longer field guide to them for the Neo4j Developer Blog: The Ontologies You Shouldn't Build Yourself.

When to build your own

• The domain is new or narrow. Sports play-by-play, a proprietary manufacturing process, an internal product taxonomy. No standards body covers these, and forcing them into a generic vocabulary like schema.org loses the detail you need.
• The concepts you need don't exist in any standard. A standard being large is not a reason to build. FIBO has about 2,400 classes, and a graph that needs forty of them should take those forty as a curated slice (next section) and leave the rest.

The usual answer: a curated slice

Take the part of the standard that covers your questions, keep its identifiers, and extend it where your domain is special. For a narrow problem the slice can be small. A graph that only answers questions about a few hundred drugs needs those drugs and their substances with their standard codes, not the whole of SNOMED CT loaded and never looked at.

Three costs come with this, and they are easy to underestimate:

• Curation. Standards deprecate, split and merge concepts. A curated slice only beats a full import if someone refreshes it on a schedule.
• Mapping. Concepts rarely line up one to one between standards, or between a standard and your data. A subtly wrong mapping is worse than none, because people trust it.
• Fit. A standard encodes someone else's view of the domain. To extend it without breaking it you have to understand that view first, which can take longer than people expect. Reuse swaps modelling work for reading and understanding work. It is usually a good trade, but it still costs time.

When you don't need a formal ontology at all

If your data is a hierarchy and you mainly navigate and filter it (product categories, org charts, regions), a taxonomy is enough. If the structure is fixed and you need validation rather than inference, a documented schema of labels and properties is enough. A formal ontology earns its cost when you need shared meaning across systems or teams, or reasoning over the model itself.

Example from a working graph

The plant-protection register graph reuses where it can. Crops and pests from the Polish register are linked to their codes in the EPPO Global Database, run by the European and Mediterranean Plant Protection Organization. It covers more than 99,700 species with scientific names, synonyms and common names in several languages. Once a name is linked, the graph gets one stable code per species and EPPO's biological hierarchy for free, from species up to kingdom. The register's "pszenica", "pszenica ozima" and "pszenica jara" all resolve to TRZAX (Triticum aestivum), while "pszenica orkisz" gets its own code, TRZSP (spelt).

The mapping cost from the list above showed up straight away. EPPO has Polish names for only a small part of what the register uses, so exact name matching linked only about 19% of crops and pests. I then had an LLM translate each unmatched Polish name into a Latin one and kept the link only if that Latin name exists in EPPO. That lifted coverage to about 62% of crops and 67% of pests. On a checked sample, roughly 80-85% of those extra links were right, so they are marked as model-made and kept apart from the exact matches. Names that still don't match stay unlinked on purpose.

EPPO also shows where reuse stops. Winter and spring wheat share one EPPO code because they are the same species, but for a spray recommendation they are different crops. The split between winter and spring crops, and groupings like field crops versus vegetables and orchards, are agronomy rather than taxonomy, and EPPO doesn't carry them. In the graph they are my own extension: a season property on each crop and seven crop groups taken from the register itself. Next to them sits what is specific to Polish registrations: application windows, doses and spray intervals.