Meine Session planen

# 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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 Run Sheets.

## 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