Was vorher fertig sein muss
Ein erstes Competency-Question-Set mit must-have-Fragen und priorisierten Use Cases liegt vor, an dem sich Szenario-Auswahl und Akzeptanztests orientieren.
Eine Übersicht über Domain Experts, Konsumenten, Owner bestehender Vokabulare und Maintainer ist erstellt, damit Reviews und Reuse-Verhandlungen planbar sind.
Was vor Start vorliegen muss
Projektplan-Template; NeOn-Szenarien-Übersicht (1-9) als Card-Deck oder Liste; Reuse-Recherche-Tabelle; Ontology-Editor (Protégé, TopBraid, VocBench); Versionskontrolle (Git mit RDF-Diff); Issue-Tracker.
Ein Ontology Engineer (lead); ein bis drei Domain Experts; ein bis zwei Reuse-Scouts (recherchieren existierende Vokabulare); ein Evaluator (prüft gegen Competency Questions); ein Maintenance-Owner für die Post-Launch-Phase.
Competency Questions; Stakeholder-Map; bekannte Standard-Vokabulare im Domänenkontext; Lizenz- und Governance-Regeln; Toolchain-Entscheidung; geplanter Lifecycle (waterfall vs. iterativ).
Mehrere Wochen bis Monate, in Iterationen
Repository mit Struktur (sources/, modules/, tests/, docs/) anlegen. Szenarien-Auswahl als Entscheidungsdokument vorbereiten. Iterations-Cadence festlegen (z. B. 2-Wochen-Iteration mit Review am Ende).
Die eine Frage, die diese Methode beantwortet
Welche der neun NeOn-Szenarien sind für dieses Ontology-Projekt relevant, und welche Aktivitäten, Reuse-Quellen und Reviews ergeben sich daraus?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Szenario-Auswahl | 1 Tag | Alle neun Szenarien durchgehen (z. B. Reuse Ontological Resources, Reengineering Non-Ontological Resources, Merge, Restructure, Localize). Pro Szenario: relevant oder nicht, mit Begründung. Auswahl dokumentieren. | Wenn alle neun als relevant markiert werden, ist Scope zu groß oder Auswahl nicht ehrlich. Maximal 3-4 Szenarien als Hauptachsen, andere als Folgekandidaten parken. |
2Phase 2: Ontology Requirements Specification (ORSD) | 3-5 Tage | Purpose, Scope, Functional Requirements (Competency Questions), Non-Functional Requirements (Performance, Lizenz, Sprache), bestehende Ressourcen und Pre-Glossary in einem ORSD-Dokument bündeln. | ORSD ist das vertragsähnliche Dokument zwischen Auftraggebern und Modellierern. Wenn es schwammig bleibt, kommt Streit später bei der Abnahme. |
3Phase 3: Reuse-Recherche und Selection | 3-7 Tage | Bestehende Ontologien, Vokabulare und Patterns identifizieren (z. B. via LOV, BioPortal, FAIRsharing). Pro Kandidat bewerten: Coverage, Qualität, Maintenance, Lizenz. Auswahl und Begründung dokumentieren. | Reuse zu früh festlegen verzerrt das Modell auf eine fremde Ontologie. Reuse zu spät erzeugt Eigenkonstruktionen, die später Übersetzungs-Mappings brauchen. |
4Phase 4: Modellierungs-Iterationen | Mehrere Iterationen à 1-2 Wochen | Pro Iteration: Klassen, Properties, Constraints modellieren (oft mit Ontology Design Patterns); gegen Competency Questions testen; Review mit Domain Experts; Versionierung im Repo. | Ohne Tests gegen Competency Questions wird das Modell akademisch. Mindestens 50% der Top-CQs müssen pro Iteration durch Test-Queries beantwortbar sein. |
5Phase 5: Evaluation, Documentation, Publication | 1-2 Wochen | Vollständige Coverage-Prüfung gegen ORSD und CQs. Domain-Expert-Review. Dokumentation automatisiert generieren (z. B. WIDOCO, pyLODE). Veröffentlichung mit Persistent IRI, Lizenz, Changelog. | Wenn 100% Coverage erzwungen wird, kippen Iterationen in Overengineering. 80-90% Coverage mit dokumentierten Lücken ist solider als geschönte 100%. |
6Phase 6: Maintenance-Plan | 1 Tag | Owner, Update-Cadence, Deprecation-Policy, Change-Request-Prozess, Versionsschema (SemVer für Ontologien) festlegen. Plan dokumentieren und Owner verbindlich benennen. | Ohne Maintenance-Owner stirbt die Ontology innerhalb von Monaten. Wenn niemand den Owner-Hut aufsetzt, ist das ein Killkriterium. |
Was am Ende rauskommt
Repository mit ORSD, Szenario-Entscheidungsdokument, Reuse-Selection-Report, modularen Ontology-Files (TTL/OWL), CQ-Test-Suite, automatisch generierter Doku, Evaluation-Report und Maintenance-Plan.
SemVer für Ontology-Releases (Major bei Breaking Changes, Minor bei Erweiterungen). Changelog pro Release. Deprecated Klassen mit owl:deprecated markiert, nicht gelöscht. ORSD wächst mit, alte Versionen archiviert.
Kompakte Arbeitsvorlage für NeOn Methodology mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# NeOn Methodology Arbeitsvorlage
## Ziel
Szenario-basiertes Vorgehen für modulare Ontology-Entwicklung mit gezieltem Reuse.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Ontology Requirements Specification:
- Reuse Plan:
- Ontology Modules:
- Evaluation Report:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## NeOn-Projekt — Knowledge Graph „Klinische Pfade“ (Phase 2 abgeschlossen, 18.05.2026)
**Ausgewählte Szenarien**: Szenario 1 (Reuse Ontological Resources), Szenario 3 (Reengineering Non-Ontological Resources — bestehender SNOMED-Auszug), Szenario 5 (Restructure), Szenario 7 (Localize DE/EN).
**ORSD-Auszug**:
- Purpose: Suche und Reasoning über klinische Pfade in Onkologie.
- Scope: Diagnosen, Therapien, Leitlinien, Patient-Kohorten (ohne Pharmakokinetik in v1).
- Lizenz: CC-BY-SA 4.0.
- CQs: 38 must-have.
**Reuse-Auswahl**: SNOMED CT (Subset Onkologie), HL7 FHIR R5 Konzepte, NCIt für Tumortypen, BFO als Top-Level. SNOMED-Lizenz geklärt mit IHTSDO.
**Iteration 3 Coverage**: 28 von 38 must-have-CQs beantwortbar. Lücken: Therapie-Sequenz (CQ 22-24), Owner @lisa, Sprint 4.
**Maintenance**: Owner @marcus (Ontology Engineer), Quartals-Release, Change-Request via Issue mit Label `cr`. Deprecation-Frist 12 Monate.Symptome erkennen, gegensteuern
Szenario-Liste hat 9 Häkchen, niemand kann sagen, welches Szenario Priorität hat.
Strikt 3-4 Hauptszenarien wählen. Andere parken oder begründet streichen. Wer alle Szenarien füllen will, baut ein Lehrbuch statt ein Projekt.
Scope und Non-Functional Requirements stehen als Allgemeinplätze, Abnahme später strittig.
ORSD mit Auftraggeber wie einen Vertrag durchgehen. Jeder Punkt muss konkret messbar oder klar abgrenzbar sein. Unklare Punkte als offene Frage markieren.
Modell wird von Null gebaut, später entdeckt jemand etabliertes Vokabular, das alles abgedeckt hätte.
Mindestens 2 Tage Reuse-Recherche pflichtig vor Modellierungsstart. LOV, BioPortal, branchenspezifische Register systematisch durchgehen. Negativ-Befund auch dokumentieren.
Modell wächst, niemand prüft, ob CQs damit beantwortbar sind. Coverage-Report fehlt.
Pro Iteration eine CQ-Test-Suite mit SPARQL-Queries laufen lassen. Coverage-Metrik in Release-Notes. Lücken als Backlog-Items mit Sprint-Ziel.
Ontology wird veröffentlicht, nach 3 Monaten gibt es kein Update, Issues bleiben unbeantwortet.
Maintenance-Plan vor Veröffentlichung mit benanntem Owner. Wenn kein Owner findbar, Veröffentlichung verschieben oder Scope verkleinern bis Maintenance leistbar.
Experts werden in Phase 2 eingebunden, in Phase 4 nicht mehr, Modell drifted in Modellierersprache.
Domain-Review als feste Aktivität pro Iteration einplanen. Mindestens 1 Stunde pro 2-Wochen-Iteration. Bei Verzicht: Iteration nicht als done markieren.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.