Meine Session planen

# Session Brief: Shape-First Modeling

## Ziel
Artefakt: SHACL or ShEx Shapes

## Arbeitsfrage
Welche Shapes legen Pflicht-Properties, Datentypen, Kardinalitäten und Beziehungen so fest, dass reale Daten validierbar und Verträge zwischen Producer und Consumer eindeutig sind?

## Kontext
Klassenliste mit Priorität; Beispieldaten pro Klasse (mindestens 50 Instanzen je Top-Klasse); bekannte Datenqualitätsprobleme; Reuse-Plan für externe Vokabulare; Lizenz und Sprache.

## Setup
- Format: Methoden-Session
- Dauer: Halber Tag pro Domain Slice (4 h)
- Modus: Workshop oder async
- Teilnehmende: Ein Shapes-Modeler (lead); ein Domain Expert pro Klasse; ein Data Producer (Owner der Datenquelle) für Realitäts-Check; ein Data Consumer für Erwartungen an den Vertrag.
- Owner: Ein Shapes-Modeler (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 SHACL or ShEx Shapes hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Shapes-Editor (Protégé mit SHACL-Plugin, TopBraid, Stardog Studio) oder Texteditor mit Turtle-Highlighting; SHACL-Validator (z. B. pySHACL, Apache Jena SHACL, TopBraid); Beispieldaten als Turtle; Repo mit shapes/-Ordner; CI-Validierung.

## Vorbereitung
Repo mit shapes/, data/ und tests/. Validator in CI eingebunden. Beispieldaten geladen. Pro Klasse ein Slot im Workshop-Plan, mit Domain Expert verfügbar.

## Agenda
1. Phase 1: Klassen priorisieren (30 min)
   Owner: Facilitator
   Aktion: Wichtigste 3-5 Knotenklassen für ersten Slice auswählen, gestützt auf CQs und Datenfluss. Pro Klasse Owner, Beispieldaten-Pfad und bekannte Probleme notieren. Hinweis: Wer alles auf einmal modelliert, liefert nichts validierbares. Slice klein halten und in nachfolgenden Iterationen erweitern. 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: SHACL or ShEx Shapes

2. Phase 2: Pflicht-Properties (60 min pro Klasse)
   Owner: Facilitator
   Aktion: Pro Klasse: Property-Liste mit sh:path, sh:datatype, sh:minCount, sh:maxCount, sh:nodeKind. Pflicht-Properties (minCount 1) explizit als Vertragsanker markieren. Hinweis: Wenn Pflicht-Properties in realen Daten unter 80% vorkommen, ist entweder die Pflicht falsch oder die Datenquelle defekt. Vor Schließen klären, welche der beiden. 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: Validation Reports

3. Phase 3: Beziehungen und Kardinalitäten (45 min pro Klasse)
   Owner: Facilitator
   Aktion: Properties mit Class-Range (sh:class) für Verweise. Kardinalität pro Beziehung. sh:or für alternative Zielklassen wo nötig. Self-Referenzen und Zyklen explizit prüfen. Hinweis: Kardinalität 1..* ist häufig zu lax. Wer Mindestmenge nicht definiert, lässt leere Listen zu. Wenn fachlich mindestens 2 sein müssen, sh:minCount 2 setzen. 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: Data Contracts

4. Phase 4: Validierung gegen Beispieldaten (30-45 min pro Klasse)
   Owner: Facilitator
   Aktion: Validator gegen Beispieldaten laufen lassen. Violations sichten: legitime Datenfehler oder zu strenge Shape? Pro Violation Entscheidung dokumentieren (Shape lockern, Datenquelle fixen, Ausnahme). Hinweis: Wenn 30% der Beispielinstanzen violations triggern, ist die Shape nicht produktionsreif. Entweder lockern (mit Begründung) oder Data-Owner kontaktieren. 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: Shape Documentation

5. Phase 5: Shapes versionieren und in Pipeline integrieren (30 min)
   Owner: Facilitator
   Aktion: Shape-File committen, Version taggen (z. B. shapes/v0.3/Service.ttl). CI-Job einrichten, der bei Daten-Updates oder Shape-Updates validiert. Validation-Report als Artefakt speichern. Hinweis: Ohne CI-Integration sind Shapes Stoffrest. CI muss bei jedem Daten-PR (oder ETL-Lauf) Shapes laufen lassen und broken builds erzwingen. 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: SHACL or ShEx Shapes

6. Phase 6: Doku als Datenvertrag (20 min)
   Owner: Owner
   Aktion: Shape pro Klasse als menschlich lesbare Tabelle exportieren (Property, Pflicht, Typ, Kardinalität, Hinweis). Im Repo unter docs/shapes/. Mit Datenproduzenten und Konsumenten reviewen. Hinweis: Shapes als TTL sind für Modellierer lesbar, nicht für Datenproduzenten. Ohne Tabellen-Doku versteht der Producer den Vertrag nicht. 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: Validation Reports

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: SHACL or ShEx Shapes

## Abschluss
- Ergebnisartefakt aktualisieren: SHACL or ShEx Shapes
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# SHACL or ShEx Shapes: Shape-First Modeling

## Arbeitsfrage
Welche Shapes legen Pflicht-Properties, Datentypen, Kardinalitäten und Beziehungen so fest, dass reale Daten validierbar und Verträge zwischen Producer und Consumer eindeutig sind?

## Kontext
Klassenliste mit Priorität; Beispieldaten pro Klasse (mindestens 50 Instanzen je Top-Klasse); bekannte Datenqualitätsprobleme; Reuse-Plan für externe Vokabulare; Lizenz und Sprache.

## Beteiligte
- Owner: Ein Shapes-Modeler (lead)
- Teilnehmende: Ein Shapes-Modeler (lead); ein Domain Expert pro Klasse; ein Data Producer (Owner der Datenquelle) für Realitäts-Check; ein Data Consumer für Erwartungen an den Vertrag.

## Input
Shapes-Editor (Protégé mit SHACL-Plugin, TopBraid, Stardog Studio) oder Texteditor mit Turtle-Highlighting; SHACL-Validator (z. B. pySHACL, Apache Jena SHACL, TopBraid); Beispieldaten als Turtle; Repo mit shapes/-Ordner; CI-Validierung.

## Vorlage
# Shape-First Modeling Arbeitsvorlage

## Ziel

Modellierungsansatz, bei dem Datenshapes und Constraints vor offener Ontology-Semantik definiert werden.

## 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
- SHACL or ShEx Shapes:
- Validation Reports:
- Data Contracts:
- Shape Documentation:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- SHACL or ShEx Shapes 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