Meine Session planen

# Session Brief: Linked Open Terms

## Ziel
Artefakt: Ontology Requirements

## Arbeitsfrage
Wie liefert das Team die Ontology in iterativen, releasebaren Inkrementen, die Competency Questions abdecken und für Konsumenten nutzbar sind?

## Kontext
CQ-Backlog; Use Cases mit Priorität; Reuse-Recherche-Ergebnisse; Lizenz- und Governance-Entscheidung; gewählte Toolchain; Iterations-Cadence (typisch 2 Wochen).

## Setup
- Format: Methoden-Session
- Dauer: Wochen bis Monate in 2-Wochen-Iterationen
- Modus: Workshop oder async
- Teilnehmende: 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.
- Owner: Ein Ontology Engineer (Product Owner für die Ontology)
- 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 Ontology Requirements hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
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).

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

## Agenda
1. Phase 1: Ontological Requirements Specification (3-5 Tage initial, dann fortlaufend)
   Owner: Facilitator
   Aktion: Use Cases, CQs, Non-Functional Requirements und Pre-Glossary sammeln. Reuse-Kandidaten identifizieren (LOV, Schema.org, domänenspezifische Vokabulare). Initiales ORSD veröffentlichen. Hinweis: ORSD wird in Linked Open Terms als lebendes Dokument geführt, nicht eingefroren. Änderungen kommen als Issues, werden im Backlog priorisiert. 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: Ontology Requirements

2. Phase 2: Implementation in Iterationen (Iterationen à 1-2 Wochen)
   Owner: Facilitator
   Aktion: 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. Hinweis: 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. 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: Conceptual Model

3. Phase 3: Evaluation und Stakeholder-Review (1-2 h pro Iterationsende)
   Owner: Facilitator
   Aktion: Reviewer prüft Iterationsergebnis gegen abgehakte CQs. Konsumenten testen Beispiele und Doku. Findings als neue Issues im Backlog. Iteration als done oder rework markieren. Hinweis: Reviews ohne Konsumenten sind Schein-Reviews. Mindestens ein Reviewer aus Konsumentenseite pro Iteration, sonst Iteration nicht als done. 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: Published Ontology

4. Phase 4: Publication (1-2 Tage pro Release)
   Owner: Facilitator
   Aktion: 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. Hinweis: Persistent IRI ist Pflicht. Wer auf raw GitHub-URLs verlinkt, bricht jeden Konsumenten beim nächsten Repo-Umzug. 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: Documentation

5. Phase 5: Maintenance (Laufend, monatlicher Rhythmus)
   Owner: Owner
   Aktion: Change Requests via Issues. Quartals- oder Monatsreleases. Deprecated Klassen mit owl:deprecated markieren, Migrationsleitfaden im Changelog. Konsumenten-Feedback aktiv einholen. Hinweis: Maintenance ist die teuerste und meistvergessene Phase. Ohne Owner mit echter Zeit (mind. 4 h/Woche) stirbt die Ontology innerhalb von 6 Monaten. 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: Maintenance Plan

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: Ontology Requirements

## Abschluss
- Ergebnisartefakt aktualisieren: Ontology Requirements
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Ontology Requirements: Linked Open Terms

## Arbeitsfrage
Wie liefert das Team die Ontology in iterativen, releasebaren Inkrementen, die Competency Questions abdecken und für Konsumenten nutzbar sind?

## Kontext
CQ-Backlog; Use Cases mit Priorität; Reuse-Recherche-Ergebnisse; Lizenz- und Governance-Entscheidung; gewählte Toolchain; Iterations-Cadence (typisch 2 Wochen).

## Beteiligte
- Owner: Ein Ontology Engineer (Product Owner für die Ontology)
- Teilnehmende: 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.

## Input
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).

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

## Fertigstellungscheck
- Ontology Requirements 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