What needs to be finished first
A first competency question set with must-have questions and prioritized use cases is available and drives scenario choice and acceptance tests.
An overview of domain experts, consumers, vocabulary owners, and maintainers is available so reviews and reuse negotiations can be planned.
What needs to be ready before start
Project plan template; NeOn scenario overview (1-9) as card deck or list; reuse-research table; ontology editor (Protégé, TopBraid, VocBench); version control with RDF diff; issue tracker.
An ontology engineer as lead; one to three domain experts; one to two reuse scouts researching existing vocabularies; one evaluator checking competency questions; one maintenance owner for post-launch.
Competency questions; stakeholder map; known standard vocabularies in the domain context; licensing and governance rules; toolchain decision; planned lifecycle (waterfall versus iterative).
Several weeks to months, in iterations
Prepare repository structure (sources/, modules/, tests/, docs/). Prepare decision document for scenario selection. Set iteration cadence (for example two-week iteration with end-of-iteration review).
The one question this method answers
Which of the nine NeOn scenarios are relevant for this ontology project, and what activities, reuse sources, and reviews result?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Scenario selection | 1 day | Review all nine scenarios (for example Reuse Ontological Resources, Reengineering Non-Ontological Resources, Merge, Restructure, Localize). For each scenario mark relevant or not with rationale, then document the selection. | If all nine are marked relevant, scope is too large or selection is not honest. Keep three to four scenarios as primary axes and park the rest as follow-up candidates. |
2Phase 2: Ontology Requirements Specification (ORSD) | 3-5 days | Consolidate purpose, scope, functional requirements (competency questions), non-functional requirements (performance, licensing, language), existing resources, and pre-glossary in one ORSD document. | The ORSD is the agreement document between requesters and modelers. If it stays vague, conflict appears later at acceptance. |
3Phase 3: Reuse research and selection | 3-7 days | Identify existing ontologies, vocabularies, and patterns (for example via LOV, BioPortal, FAIRsharing). For each candidate evaluate coverage, quality, maintenance, and license. Document selection and rationale. | Fixing reuse too early bends the model to a foreign ontology. Late reuse selection creates proprietary models needing mapping work later. |
4Phase 4: Modeling iterations | Multiple 1-2-week iterations | Each iteration: model classes, properties, constraints (often with ontology design patterns), test against competency questions, review with domain experts, version in repository. | Without testing against competency questions, the model stays academic. At least 50% of top CQs should be answerable by test queries per iteration. |
5Phase 5: Evaluation, documentation, publication | 1-2 weeks | Run full coverage check against ORSD and CQs. Conduct domain expert review. Generate documentation automatically (for example WIDOCO, pyLODE). Publish with persistent IRI, license, and changelog. | If 100% coverage is forced, iterations become overengineered. 80-90% coverage with documented gaps is usually better than a polished 100% claim. |
6Phase 6: Maintenance planning | 1 day | Define owner, update cadence, deprecation policy, change-request process, and versioning scheme (SemVer for ontologies). Document plan and assign owner explicitly. | Without a maintenance owner the ontology dies within months. If nobody owns maintenance, publication should be delayed or scope reduced. |
What comes out at the end
Repository with ORSD, scenario decision document, reuse selection report, modular ontology files (TTL/OWL), CQ test suite, auto-generated documentation, evaluation report, and maintenance plan.
SemVer for ontology releases (major on breaking changes, minor for additions). Changelog per release. Mark deprecated classes with owl:deprecated rather than deleting. Keep ORSD evolving and archive older versions.
Compact working template for NeOn Methodology with context, input, output artifacts, and next step.
Scenario-based approach for modular ontology development with deliberate reuse.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Selected scenarios: Scenario 1 (Reuse Ontological Resources), Scenario 3 (Reengineering Non-Ontological Resources - existing SNOMED extract), Scenario 5 (Restructure), Scenario 7 (Localize DE/EN).
ORSD excerpt:
Reuse selection: SNOMED CT (oncology subset), HL7 FHIR R5 concepts, NCIt for tumor types, BFO as top-level. SNOMED license clarified with IHTSDO.
Iteration 3 coverage: 28 of 38 must-have CQs are answerable. Gaps: therapy sequence (CQ 22-24), owner @lisa, Sprint 4.
Maintenance: Owner @marcus (ontology engineer), quarterly releases, change requests via issues with label cr. Deprecation period: 12 months.
Recognize symptoms and steer against them
All nine scenarios are checked and nobody can prioritize. The project scope remains unclear.
Strictly select three to four main scenarios. Park or remove the others with justification. Trying to fill all nine produces a textbook, not a project.
Scope and non-functional requirements are generic statements; acceptance will later become contested.
Treat the ORSD like a contract with stakeholders. Every point should be concrete and measurable or clearly bounded. Keep unclear points as open questions.
The model is built from scratch, then someone discovers an established vocabulary that already covers most needs.
Allocate at least two full days for reuse research before modeling. Review LOV, BioPortal, and domain registries systematically. Include negative findings in documentation.
The model grows but nobody checks whether CQs are answerable. No coverage report is produced.
Run a CQ test suite with SPARQL queries per iteration. Include coverage metric in release notes. Create backlog items for gaps with iteration goals.
Ontology is published, but after three months no updates happen and issues remain unanswered.
Create maintenance plan before release with named owner. If no owner can be assigned, delay release or reduce scope until maintenance is feasible.
Experts are involved in Phase 2, then disappear in Phase 4. The model drifts toward modeler language.
Schedule domain reviews as a fixed activity per iteration: at least one hour every two weeks. If omitted, the iteration is not done.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.