Was vorher fertig sein muss
Ein iteratives Competency-Question-Set mit Priorisierung liegt als Backlog vor, gegen das Iterations-Ergebnisse abgenommen werden können.
Domain Experts und spätere Konsumenten der Linked-Data-Ressource sind benannt und für Reviews am Iterationsende verfügbar.
Was vor Start vorliegen muss
Git-Repo mit Ontology-Struktur (vocab/, examples/, docs/, tests/); Backlog-Tool (Linear, Jira, GitHub Issues); CI mit RDF-Validation und Doku-Generierung (WIDOCO, pyLODE); Toolchain für Veröffentlichung (W3ID, GitHub Pages, persistente IRI).
Ein Ontology Engineer (Product Owner für die Ontology); ein bis drei Modellierer; ein Reviewer pro Iteration aus Konsumentenseite; ein Maintenance-Owner für die Maintenance-Phase.
CQ-Backlog; Use Cases mit Priorität; Reuse-Recherche-Ergebnisse; Lizenz- und Governance-Entscheidung; gewählte Toolchain; Iterations-Cadence (typisch 2 Wochen).
Wochen bis Monate in 2-Wochen-Iterationen
Repo mit Vorlage initialisieren. Phasen als GitHub-Project-Spalten (Requirements, Implementation, Publication, Maintenance). Erste Iteration mit 3-5 CQs als Sprint-Backlog. Review-Termin gleich am Iterationsende einplanen.
Die eine Frage, die diese Methode beantwortet
Wie liefert das Team die Ontology in iterativen, releasebaren Inkrementen, die Competency Questions abdecken und für Konsumenten nutzbar sind?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Ontological Requirements Specification | 3-5 Tage initial, dann fortlaufend | Use Cases, CQs, Non-Functional Requirements und Pre-Glossary sammeln. Reuse-Kandidaten identifizieren (LOV, Schema.org, domänenspezifische Vokabulare). Initiales ORSD veröffentlichen. | ORSD wird in Linked Open Terms als lebendes Dokument geführt, nicht eingefroren. Änderungen kommen als Issues, werden im Backlog priorisiert. |
2Phase 2: Implementation in Iterationen | Iterationen à 1-2 Wochen | Pro Iteration: CQs aus Backlog ziehen, Klassen und Properties modellieren, Beispiele schreiben, CI grün, Pull Request mit Review. Patterns und Reuse-Quellen explizit referenzieren. | Wer ohne Test in den PR geht, wird im Review blockiert. CI sollte mindestens RDF-Syntax, Konsistenz (z. B. via HermiT/ELK) und CQ-Test-Queries laufen lassen. |
3Phase 3: Evaluation und Stakeholder-Review | 1-2 h pro Iterationsende | Reviewer prüft Iterationsergebnis gegen abgehakte CQs. Konsumenten testen Beispiele und Doku. Findings als neue Issues im Backlog. Iteration als done oder rework markieren. | Reviews ohne Konsumenten sind Schein-Reviews. Mindestens ein Reviewer aus Konsumentenseite pro Iteration, sonst Iteration nicht als done. |
4Phase 4: Publication | 1-2 Tage pro Release | Release-Versionsnummer (SemVer) setzen. Doku via WIDOCO/pyLODE generieren. Persistent IRI (w3id.org oder eigene Domain) konfigurieren. Lizenz, Changelog, Beispiele veröffentlichen. Content Negotiation prüfen. | Persistent IRI ist Pflicht. Wer auf raw GitHub-URLs verlinkt, bricht jeden Konsumenten beim nächsten Repo-Umzug. |
5Phase 5: Maintenance | Laufend, monatlicher Rhythmus | Change Requests via Issues. Quartals- oder Monatsreleases. Deprecated Klassen mit owl:deprecated markieren, Migrationsleitfaden im Changelog. Konsumenten-Feedback aktiv einholen. | Maintenance ist die teuerste und meistvergessene Phase. Ohne Owner mit echter Zeit (mind. 4 h/Woche) stirbt die Ontology innerhalb von 6 Monaten. |
Was am Ende rauskommt
Git-Repository mit ORSD, modularen Ontology-Files, Beispieldaten, CQ-Test-Suite, CI-Konfiguration, generierter HTML-Doku, Releases mit SemVer, Changelog und Maintenance-Plan. Publiziert unter persistenter IRI.
SemVer (MAJOR bei Breaking Changes, MINOR bei additiven Änderungen, PATCH bei Doku-Fixes). Changelog pro Release. Pre-Releases mit -alpha, -beta. Persistent IRI mit Versions-Pfad (z. B. /v1.2.0/) plus latest-Alias.
Kompakte Arbeitsvorlage für Linked Open Terms mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Linked Open Terms Arbeitsvorlage
## Ziel
Agile, leichtgewichtige Methodologie zur Entwicklung von Ontologien und Linked-Data-Vokabularen.
## 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:
- Conceptual Model:
- Published Ontology:
- Documentation:
- Maintenance Plan:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Linked Open Terms — Ontology „Building Lifecycle“ (Sprint 5, 18.05.2026)
**Iteration 5** (12.05.-23.05.2026, Reviewer @sabine, Bauingenieurin).
**Sprint-Backlog**:
- CQ 14: Welche Bauteile sind in Wartungszyklus „>10 Jahre“? Done.
- CQ 15: Welche Bauteile gemeinsam wechseln (Bündel)? Done.
- CQ 16: Welche Wartung wurde an Bauteil X durchgeführt? Blockiert (Provenance-Pattern fehlt, neuer Spike).
**Implementation**:
- Neue Klasse `MaintenanceCycle` mit Property `cycleLengthYears`.
- Reuse: `schema:Action` für `MaintenanceEvent` (Mapping in mapping.ttl).
**CI**: Alle 38 CQ-Test-Queries grün außer CQ 16 (erwartet).
**Review (@sabine)**: 2 Findings. (1) MaintenanceCycle-Beispiel fehlt für Fassade. (2) Doku-Sprache uneinheitlich. Beide als Issues für Sprint 6.
**Release v0.5.0**: Persistent IRI w3id.org/building-lifecycle/v0.5.0/. Doku unter buildinglifecycle.org/v0.5.0/. Changelog aktualisiert.
**Maintenance**: Owner @marcus, Monatsrelease. CR-Issue-Template aktiviert.Symptome erkennen, gegensteuern
ORSD wird einmal geschrieben, danach nicht mehr angefasst, weicht von Realität ab.
ORSD im Repo halten, Änderungen als PR. Bei jedem Sprint-Review prüfen, ob ORSD aktuell ist. Veraltete Sektionen aktiv updaten oder als deprecated markieren.
Modellierungs-PRs werden ohne Validation gemerged, broken RDF landet im main, Doku-Build schlägt fehl.
CI als Pflicht: RDF-Syntax-Check, Reasoner-Lauf, CQ-Test-Queries, Doku-Generierung. PR ohne grüne CI wird nicht gemerged.
Ontology verlinkt mit raw.githubusercontent.com-URLs, jede Repo-Umstrukturierung bricht Konsumenten.
Vor erster Veröffentlichung w3id.org-Eintrag oder eigene Domain mit Content Negotiation einrichten. Lieber Release verschieben als ohne persistente IRI publizieren.
Sprint-Reviews mit anderen Modellierern, nie mit Konsumenten oder Domain Experts.
Mindestens jede zweite Iteration mit externem Reviewer aus Konsumentenseite. Wenn nicht verfügbar, vorher Recruiting wie für Usability-Tests organisieren.
Nach Launch wird die Ontology nicht mehr gepflegt, Issues bleiben offen, neue Versionen erscheinen nicht.
Maintenance-Plan und Owner vor Launch im Repo dokumentieren. Quartals-Release im Kalender. Wenn Owner ausfällt, neuer Owner oder Deprecation-Ankündigung.
Iteration 4 entdeckt, dass Schema.org dasselbe schon abdeckt, eigene Klassen müssen gemappt werden.
Reuse-Recherche als initiale Aktivität in Phase 1 mit Mindestumfang (z. B. 1 Tag). LOV systematisch durchsuchen. Bei jedem neuen Konzept zuerst Reuse-Frage stellen.
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.