Session Brief: Ontology Design Patterns

Ziel

Artefakt: Selected Patterns

Arbeitsfrage

Welches Modellierungs-Pattern löst das aktuelle Problem so, dass es zu Competency Questions, bestehendem Modell und Reuse-Strategie passt?

Kontext

Modellierungsproblem als ein Satz; relevante Competency Questions; bestehende Modellfragmente; Liste bekannter Patterns (Part-Whole, Time-Indexed Situation, Roles, Provenance).

Setup

• Format: Methoden-Session
• Dauer: 1-3 h pro Pattern
• Modus: Workshop oder async
• Teilnehmende: Ein Ontology Engineer; ein bis zwei Domain Experts pro Pattern-Sitzung; optional ein Pattern-Reviewer mit Erfahrung aus anderen Projekten.
• Owner: Ein Ontology Engineer
• Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
• Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Selected Patterns hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

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.

Vorbereitung

Modellierungsproblem und CQs sichtbar. Pattern-Katalog griffbereit. Sandbox mit Mini-Beispieldaten vorbereitet, in der Patterns sofort testbar sind.

Agenda

1. Phase 1: Problem isolieren (15-20 min) Owner: Facilitator Aktion: Modellierungsproblem in einem Satz formulieren (z. B. „wie modelliere ich zeitlich gültige Mitarbeiter-Rollen?“). Betroffene CQs identifizieren. Modellfragment ohne Lösung skizzieren. Hinweis: Wenn das Problem in 2-3 Sätze zerfällt, sind mehrere Patterns betroffen. Lieber pro Pattern eine eigene Sitzung als alles vermischen. Output: Selected Patterns

2. Phase 2: Katalog durchsuchen (20-30 min) Owner: Facilitator Aktion: Im Pattern-Katalog passende Kandidaten suchen (Stichwortsuche, Tags, ähnliche Probleme). Pro Kandidat: Beschreibung lesen, Beispiel anschauen, Coverage gegen CQs grob prüfen. Hinweis: Wenn drei Patterns gleich gut wirken, sind sie verwandt. Variante mit klarster Dokumentation und stärkster Community wählen, nicht die exotischste. Output: Adapted Schema Fragments

3. Phase 3: Pattern adaptieren (30-60 min) Owner: Facilitator Aktion: Pattern an Domain anpassen: Klassen umbenennen, Properties spezialisieren, Constraints ergänzen. Reuse-Beziehung dokumentieren (Pattern-IRI, Anpassungs-Delta). Hinweis: Wenn Anpassung 80% des Patterns verändert, ist es nicht mehr Reuse, sondern Eigenbau. Dann ehrlich als Eigenmuster dokumentieren oder anderes Pattern wählen. Output: Pattern Documentation

4. Phase 4: Validieren (20-30 min) Owner: Facilitator Aktion: Pattern in Sandbox mit Beispieldaten füllen. Test-Queries für betroffene CQs laufen lassen. Edge Cases prüfen (leere Werte, zeitliche Grenzen, Mehrfachrollen). Hinweis: Wenn Test-Query unerwartetes Ergebnis liefert, ist die Adaption zu lose. Pattern erneut prüfen oder Constraints nachschärfen, nicht Test-Daten anpassen. Output: Selected Patterns

5. Phase 5: Dokumentieren und referenzieren (15-20 min) Owner: Owner Aktion: 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. Hinweis: Ohne Referenz vergisst die nächste Generation Modellierer, warum dieses Pattern gewählt wurde. Reverse Engineering von Patterns ist teuer. Output: Adapted Schema Fragments

6. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Selected Patterns

Abschluss

• Ergebnisartefakt aktualisieren: Selected Patterns
• Ablageort, Version und Review-Empfänger festlegen.
• Owner, nächster Schritt und Reviewtermin festlegen.

Selected Patterns: Ontology Design Patterns

Arbeitsfrage

Welches Modellierungs-Pattern löst das aktuelle Problem so, dass es zu Competency Questions, bestehendem Modell und Reuse-Strategie passt?

Kontext

Modellierungsproblem als ein Satz; relevante Competency Questions; bestehende Modellfragmente; Liste bekannter Patterns (Part-Whole, Time-Indexed Situation, Roles, Provenance).

Beteiligte

• Owner: Ein Ontology Engineer
• Teilnehmende: Ein Ontology Engineer; ein bis zwei Domain Experts pro Pattern-Sitzung; optional ein Pattern-Reviewer mit Erfahrung aus anderen Projekten.

Input

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.

Vorlage

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 Runsheets.

Ergebnisartefakte

• Selected Patterns:
• Adapted Schema Fragments:
• Pattern Documentation:

Annahmen und offene Fragen

• ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

• Selected Patterns ist vollständig genug für Review:
• Ablageort:
• Version / Status:
• Review durch:
• Nächster Schritt:

Nächster Schritt

• Ergebnis prüfen
• offene Fragen markieren
• Review oder Entscheidung terminieren