Was vorher fertig sein muss
Mindestens 5 must-have-Fragen mit identifizierten Konzepten und Beziehungen liegen vor, gegen die Pattern-Auswahl validiert werden kann.
Was vor Start vorliegen muss
Pattern-Katalog (z. B. ODP-Wiki, NeOn-Pattern-Repository, projektinterner Katalog); Modellierungs-Tool (Protégé, TopBraid); Skizzenfläche; Test-Query-Sandbox; Beispieldaten für Pattern-Validation.
Ein Ontology Engineer; ein bis zwei Domain Experts pro Pattern-Sitzung; optional ein Pattern-Reviewer mit Erfahrung aus anderen Projekten.
Modellierungsproblem als ein Satz; relevante Competency Questions; bestehende Modellfragmente; Liste bekannter Patterns (Part-Whole, Time-Indexed Situation, Roles, Provenance).
1-3 h pro Pattern
Modellierungsproblem und CQs sichtbar. Pattern-Katalog griffbereit. Sandbox mit Mini-Beispieldaten vorbereitet, in der Patterns sofort testbar sind.
Die eine Frage, die diese Methode beantwortet
Welches Modellierungs-Pattern löst das aktuelle Problem so, dass es zu Competency Questions, bestehendem Modell und Reuse-Strategie passt?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Problem isolieren | 15-20 min | Modellierungsproblem in einem Satz formulieren (z. B. „wie modelliere ich zeitlich gültige Mitarbeiter-Rollen?“). Betroffene CQs identifizieren. Modellfragment ohne Lösung skizzieren. | Wenn das Problem in 2-3 Sätze zerfällt, sind mehrere Patterns betroffen. Lieber pro Pattern eine eigene Sitzung als alles vermischen. |
2Phase 2: Katalog durchsuchen | 20-30 min | Im Pattern-Katalog passende Kandidaten suchen (Stichwortsuche, Tags, ähnliche Probleme). Pro Kandidat: Beschreibung lesen, Beispiel anschauen, Coverage gegen CQs grob prüfen. | Wenn drei Patterns gleich gut wirken, sind sie verwandt. Variante mit klarster Dokumentation und stärkster Community wählen, nicht die exotischste. |
3Phase 3: Pattern adaptieren | 30-60 min | Pattern an Domain anpassen: Klassen umbenennen, Properties spezialisieren, Constraints ergänzen. Reuse-Beziehung dokumentieren (Pattern-IRI, Anpassungs-Delta). | Wenn Anpassung 80% des Patterns verändert, ist es nicht mehr Reuse, sondern Eigenbau. Dann ehrlich als Eigenmuster dokumentieren oder anderes Pattern wählen. |
4Phase 4: Validieren | 20-30 min | Pattern in Sandbox mit Beispieldaten füllen. Test-Queries für betroffene CQs laufen lassen. Edge Cases prüfen (leere Werte, zeitliche Grenzen, Mehrfachrollen). | Wenn Test-Query unerwartetes Ergebnis liefert, ist die Adaption zu lose. Pattern erneut prüfen oder Constraints nachschärfen, nicht Test-Daten anpassen. |
5Phase 5: Dokumentieren und referenzieren | 15-20 min | Pattern-Auswahl, Quelle, Anpassung, betroffene CQs und Test-Ergebnisse im Modell-Repo dokumentieren. Im Modell als Annotation (z. B. dct:source) auf Pattern-IRI verweisen. | Ohne Referenz vergisst die nächste Generation Modellierer, warum dieses Pattern gewählt wurde. Reverse Engineering von Patterns ist teuer. |
Was am Ende rauskommt
Pattern-Anwendungs-Dokument je Pattern mit Problem, gewähltem Pattern, Quelle (URI), Adaption (Delta), Beispieldaten, Test-Query-Ergebnissen und Verlinkung zu CQs. Plus Annotation im Modell selbst.
Datum, Pattern-Version und Modell-Version im Header. Bei späterer Pattern-Aktualisierung Delta dokumentieren, alte Variante nicht löschen. Modell-Annotation auf konkrete Pattern-Version pinnen, nicht auf moving target.
Kompakte Arbeitsvorlage für Ontology Design Patterns mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Ontology Design Patterns Arbeitsvorlage
## Ziel
Wiederverwendbare Modellierungsmuster für wiederkehrende Probleme in Ontologien und Knowledge Graphs.
## 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
- Selected Patterns:
- Adapted Schema Fragments:
- Pattern Documentation:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Pattern-Anwendung — Time-Indexed Person Role (18.05.2026)
**Problem**: Wie modelliere ich, dass Anna Müller von 2023-01-15 bis 2024-12-31 als Teamlead von Team Discovery agierte, dann als Engineering Manager wechselte?
**Betroffene CQs**: CQ 8 (Wer war zu Zeitpunkt T Teamlead von Team X?), CQ 12 (Historie der Rollen einer Person), CQ 15 (Wer hat Rolle Y zwischen T1 und T2 inne?).
**Pattern**: Time-Indexed Person Role aus odp.cs.ox.ac.uk/wiki/Submissions:TimeIndexedPersonRole.
**Adaption**:
- Klasse `TimeIndexedRole` umbenannt zu `RoleAssignment` (Projektsprache).
- Property `forPerson` umbenannt zu `assignedTo`.
- Constraint: `validFrom` Pflicht, `validTo` optional (offene Intervalle erlaubt).
**Test-Daten** (Auszug TTL):
```
:anna_ra_2023 a :RoleAssignment ; :assignedTo :anna ; :hasRole :TeamLead ;
:inTeam :discovery ; :validFrom "2023-01-15"^^xsd:date ; :validTo "2024-12-31"^^xsd:date .
```
**Test-Query CQ 8** liefert Anna für 2024-06-01. CQ 12 liefert chronologische Liste. CQ 15 liefert korrekt zwei Personen für überlappenden Zeitraum.
**Quelle**: ODP-Wiki, version 2024-03-01. Modell-Annotation: `dct:source <http://...TimeIndexedPersonRole>`.Symptome erkennen, gegensteuern
Patterns werden angewandt, ohne dass eine CQ dies erfordert, Modell wird unnötig komplex.
Jede Pattern-Anwendung mit betroffener CQ rechtfertigen. Wenn keine CQ profitiert, Pattern nicht anwenden, einfache Property reicht.
Pattern ist nach Adaption nur noch namensmäßig erkennbar, Reuse-Nutzen geht verloren.
Delta tracken. Wenn mehr als 50% verändert, ehrlich als Eigenmuster führen oder anderes Pattern suchen. Kataloge sind nicht religiös.
Pattern wird ins Modell übernommen, ohne dass jemand getestet hat, ob CQs damit funktionieren.
Sandbox mit minimalen Beispieldaten ist Pflicht. Mindestens eine Test-Query pro betroffener CQ. Ohne Test kein Merge in main.
Zwei angewandte Patterns überlappen oder widersprechen sich (z. B. zwei Zeit-Modelle), kein Konflikt-Check.
Bei Anwendung eines neuen Patterns prüfen, welche bisherigen Patterns mit denselben Klassen interagieren. Konflikte dokumentieren und auflösen, bevor beide ins Modell wandern.
Pattern wurde angewandt, aber im TTL/OWL keine Annotation, drei Monate später weiß niemand warum so modelliert wurde.
Mindestens `dct:source` oder vergleichbare Annotation pro Pattern-instanziierter Klasse. Doku-Generator (WIDOCO) zeigt das später im Browser.
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.