Meine Session planen

# Session Brief: NeOn Methodology

## Ziel
Artefakt: Ontology Requirements Specification

## Arbeitsfrage
Welche der neun NeOn-Szenarien sind für dieses Ontology-Projekt relevant, und welche Aktivitäten, Reuse-Quellen und Reviews ergeben sich daraus?

## Kontext
Competency Questions; Stakeholder-Map; bekannte Standard-Vokabulare im Domänenkontext; Lizenz- und Governance-Regeln; Toolchain-Entscheidung; geplanter Lifecycle (waterfall vs. iterativ).

## Setup
- Format: Methoden-Session
- Dauer: Mehrere Wochen bis Monate, in Iterationen
- Modus: Workshop oder async
- Teilnehmende: Ein Ontology Engineer (lead); ein bis drei Domain Experts; ein bis zwei Reuse-Scouts (recherchieren existierende Vokabulare); ein Evaluator (prüft gegen Competency Questions); ein Maintenance-Owner für die Post-Launch-Phase.
- Owner: Ein Ontology Engineer (lead)
- 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 Specification hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Projektplan-Template; NeOn-Szenarien-Übersicht (1-9) als Card-Deck oder Liste; Reuse-Recherche-Tabelle; Ontology-Editor (Protégé, TopBraid, VocBench); Versionskontrolle (Git mit RDF-Diff); Issue-Tracker.

## Vorbereitung
Repository mit Struktur (sources/, modules/, tests/, docs/) anlegen. Szenarien-Auswahl als Entscheidungsdokument vorbereiten. Iterations-Cadence festlegen (z. B. 2-Wochen-Iteration mit Review am Ende).

## Agenda
1. Phase 1: Szenario-Auswahl (1 Tag)
   Owner: Facilitator
   Aktion: Alle neun Szenarien durchgehen (z. B. Reuse Ontological Resources, Reengineering Non-Ontological Resources, Merge, Restructure, Localize). Pro Szenario: relevant oder nicht, mit Begründung. Auswahl dokumentieren. Hinweis: Wenn alle neun als relevant markiert werden, ist Scope zu groß oder Auswahl nicht ehrlich. Maximal 3-4 Szenarien als Hauptachsen, andere als Folgekandidaten parken. 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 Specification

2. Phase 2: Ontology Requirements Specification (ORSD) (3-5 Tage)
   Owner: Facilitator
   Aktion: Purpose, Scope, Functional Requirements (Competency Questions), Non-Functional Requirements (Performance, Lizenz, Sprache), bestehende Ressourcen und Pre-Glossary in einem ORSD-Dokument bündeln. Hinweis: ORSD ist das vertragsähnliche Dokument zwischen Auftraggebern und Modellierern. Wenn es schwammig bleibt, kommt Streit später bei der Abnahme. 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: Reuse Plan

3. Phase 3: Reuse-Recherche und Selection (3-7 Tage)
   Owner: Facilitator
   Aktion: Bestehende Ontologien, Vokabulare und Patterns identifizieren (z. B. via LOV, BioPortal, FAIRsharing). Pro Kandidat bewerten: Coverage, Qualität, Maintenance, Lizenz. Auswahl und Begründung dokumentieren. Hinweis: Reuse zu früh festlegen verzerrt das Modell auf eine fremde Ontologie. Reuse zu spät erzeugt Eigenkonstruktionen, die später Übersetzungs-Mappings brauchen. 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 Modules

4. Phase 4: Modellierungs-Iterationen (Mehrere Iterationen à 1-2 Wochen)
   Owner: Facilitator
   Aktion: Pro Iteration: Klassen, Properties, Constraints modellieren (oft mit Ontology Design Patterns); gegen Competency Questions testen; Review mit Domain Experts; Versionierung im Repo. Hinweis: Ohne Tests gegen Competency Questions wird das Modell akademisch. Mindestens 50% der Top-CQs müssen pro Iteration durch Test-Queries beantwortbar sein. 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: Evaluation Report

5. Phase 5: Evaluation, Documentation, Publication (1-2 Wochen)
   Owner: Facilitator
   Aktion: Vollständige Coverage-Prüfung gegen ORSD und CQs. Domain-Expert-Review. Dokumentation automatisiert generieren (z. B. WIDOCO, pyLODE). Veröffentlichung mit Persistent IRI, Lizenz, Changelog. Hinweis: Wenn 100% Coverage erzwungen wird, kippen Iterationen in Overengineering. 80-90% Coverage mit dokumentierten Lücken ist solider als geschönte 100%. 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 Specification

6. Phase 6: Maintenance-Plan (1 Tag)
   Owner: Owner
   Aktion: Owner, Update-Cadence, Deprecation-Policy, Change-Request-Prozess, Versionsschema (SemVer für Ontologien) festlegen. Plan dokumentieren und Owner verbindlich benennen. Hinweis: Ohne Maintenance-Owner stirbt die Ontology innerhalb von Monaten. Wenn niemand den Owner-Hut aufsetzt, ist das ein Killkriterium. 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: Reuse Plan

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

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

# Ontology Requirements Specification: NeOn Methodology

## Arbeitsfrage
Welche der neun NeOn-Szenarien sind für dieses Ontology-Projekt relevant, und welche Aktivitäten, Reuse-Quellen und Reviews ergeben sich daraus?

## Kontext
Competency Questions; Stakeholder-Map; bekannte Standard-Vokabulare im Domänenkontext; Lizenz- und Governance-Regeln; Toolchain-Entscheidung; geplanter Lifecycle (waterfall vs. iterativ).

## Beteiligte
- Owner: Ein Ontology Engineer (lead)
- Teilnehmende: Ein Ontology Engineer (lead); ein bis drei Domain Experts; ein bis zwei Reuse-Scouts (recherchieren existierende Vokabulare); ein Evaluator (prüft gegen Competency Questions); ein Maintenance-Owner für die Post-Launch-Phase.

## Input
Projektplan-Template; NeOn-Szenarien-Übersicht (1-9) als Card-Deck oder Liste; Reuse-Recherche-Tabelle; Ontology-Editor (Protégé, TopBraid, VocBench); Versionskontrolle (Git mit RDF-Diff); Issue-Tracker.

## Vorlage
# NeOn Methodology Arbeitsvorlage

## Ziel

Szenario-basiertes Vorgehen für modulare Ontology-Entwicklung mit gezieltem Reuse.

## 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 Specification:
- Reuse Plan:
- Ontology Modules:
- Evaluation Report:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

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