Which NeOn scenario is most commonly skipped — and most expensive when skipped?

Reuse of existing ontologies and resources — skipping it leads to walled-garden vocabularies that don't interoperate

Your team is building a domain ontology for a multinational retailer. Which NeOn scenario combination most cleanly fits?

#1 (CQ-driven specification) + #3 (reuse e.g. GoodRelations / schema.org for products) + #8 (localise for each country)

#1 alone — build from scratch

#1 (CQ-driven specification) + #3 (reuse e.g. GoodRelations / schema.org for products) + #8 (localise for each country)

#6 alone — merge two random ontologies

#9 only — evolve from a blank graph

The NeOn Methodology

Nine scenarios for building ontologies — reuse, re-engineer, merge, localise, evolve.

0/4 done

Overview

The NeOn Methodology

Nine scenarios for building ontologies — reuse, re-engineer, merge, localise, evolve.

Why it matters

NeOn is the most cited modern methodology because it explicitly addresses reuse — most ontology projects fail by re-inventing instead of importing.

Going deeper

The nine NeOn scenarios, compressed to one line each:

From specification — fresh build from CQs and requirements.
Reuse non-ontological resources — turn thesauri, classifications, DB schemas into ontology fragments.
Reuse ontological resources — import an existing ontology wholesale.
Re-engineer non-ontological resources — deeper than #2: re-architect, not just translate.
Re-engineer ontological resources — fork-and-modify an imported ontology.
Merge — combine two overlapping ontologies into one.
Re-engineer through merge — #6 with an explicit redesign step.
Localise — add multilingual labels and culture-specific axioms.
Evolve — manage successive versions of a deployed ontology.

Most real projects are a combination: e.g. specification (#1) + reuse (#3) for upper terms + localise (#8) for non-English deployments.

Analogy

NeOn is a recipe book for ontology cooks, not a single recipe.

Most cookbooks give you one workflow: 'mise en place, cook, plate'. NeOn instead is closer to The Joy of Cooking: nine scenarios that map to nine kitchen realities — 'starting from scratch', 'adapting a dish you already love', 'combining two recipes', 'translating a recipe for a different audience', 'modernising grandma's recipe'. You pick the scenario that matches your day, not the one in the table of contents.

The single insight people remember from NeOn is: the recipes already exist. Re-inventing 'Person' or 'Organization' or 'TemporalEntity' from scratch is the equivalent of churning your own butter for every recipe.

Tools & resources

NeOn Methodology handbook — Suárez-Figueroa et al., Ontology Engineering in a Networked World: https://link.springer.com/book/10.1007/978-3-642-24794-1
NeOn Toolkit (the original Eclipse-based authoring environment): http://neon-toolkit.org/
Linked Open Vocabularies (LOV) — search before you build: https://lov.linkeddata.es/dataset/lov
schema.org — the most-reused web vocabulary (NeOn scenario #3): https://schema.org/
OBO Foundry — coordinated reuse in the life sciences: https://obofoundry.org/

Make it stick

Use the prompts below to anchor the neon methodology to a real ontology you care about.

›In your last ontology project (or knowledge-graph schema work), which NeOn scenarios actually applied — named or not?
›Where did you re-invent a vocabulary that already existed (schema.org, FOAF, DCAT, SKOS)? What did that cost in interoperability later?
›Which scenario would *most reduce* the cost of your next ontology effort?

Reading in progress · 0 of 4 activities done

Overview

The NeOn Methodology

Why it matters

Going deeper

Analogy

Tools & resources

Tools & resources

💭Make it stick

Make it stick