Was vorher fertig sein muss
Ein Question Set mit must-have-Fragen und Pflichtdaten pro Frage liegt vor, sodass Shapes die für Antworten nötigen Properties als Constraints fixieren können.
Was vor Start vorliegen muss
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.
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.
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.
Halber Tag pro Domain Slice (4 h)
Repo mit shapes/, data/ und tests/. Validator in CI eingebunden. Beispieldaten geladen. Pro Klasse ein Slot im Workshop-Plan, mit Domain Expert verfügbar.
Die eine Frage, die diese Methode beantwortet
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?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Klassen priorisieren | 30 min | 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. | Wer alles auf einmal modelliert, liefert nichts validierbares. Slice klein halten und in nachfolgenden Iterationen erweitern. |
2Phase 2: Pflicht-Properties | 60 min pro Klasse | Pro Klasse: Property-Liste mit sh:path, sh:datatype, sh:minCount, sh:maxCount, sh:nodeKind. Pflicht-Properties (minCount 1) explizit als Vertragsanker markieren. | 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. |
3Phase 3: Beziehungen und Kardinalitäten | 45 min pro Klasse | 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. | 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. |
4Phase 4: Validierung gegen Beispieldaten | 30-45 min pro Klasse | Validator gegen Beispieldaten laufen lassen. Violations sichten: legitime Datenfehler oder zu strenge Shape? Pro Violation Entscheidung dokumentieren (Shape lockern, Datenquelle fixen, Ausnahme). | Wenn 30% der Beispielinstanzen violations triggern, ist die Shape nicht produktionsreif. Entweder lockern (mit Begründung) oder Data-Owner kontaktieren. |
5Phase 5: Shapes versionieren und in Pipeline integrieren | 30 min | 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. | Ohne CI-Integration sind Shapes Stoffrest. CI muss bei jedem Daten-PR (oder ETL-Lauf) Shapes laufen lassen und broken builds erzwingen. |
6Phase 6: Doku als Datenvertrag | 20 min | Shape pro Klasse als menschlich lesbare Tabelle exportieren (Property, Pflicht, Typ, Kardinalität, Hinweis). Im Repo unter docs/shapes/. Mit Datenproduzenten und Konsumenten reviewen. | Shapes als TTL sind für Modellierer lesbar, nicht für Datenproduzenten. Ohne Tabellen-Doku versteht der Producer den Vertrag nicht. |
Was am Ende rauskommt
shapes/-Verzeichnis mit SHACL- oder ShEx-Files pro Klasse, Validation-Report-Verzeichnis, menschlich lesbare Doku-Tabellen pro Shape, CI-Job-Konfiguration und Changelog für Shape-Versionen.
Shapes mit eigener SemVer (Major bei Breaking-Vertragsänderungen). Pro Release Changelog mit Liste der gelockerten/verschärften Constraints. Migrationshinweise für Producer dokumentieren.
Kompakte Arbeitsvorlage für Shape-First Modeling mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# 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.Konkret gefülltes Szenario
## Shape-First — Service-Klasse (v0.3, 18.05.2026)
**Beispiel-SHACL (Auszug)**:
```
:ServiceShape a sh:NodeShape ;
sh:targetClass :Service ;
sh:property [ sh:path :name ; sh:datatype xsd:string ; sh:minCount 1 ; sh:maxCount 1 ] ;
sh:property [ sh:path :tier ; sh:in ("critical" "standard" "experimental") ; sh:minCount 1 ] ;
sh:property [ sh:path :owner ; sh:class :Team ; sh:minCount 1 ; sh:maxCount 1 ] ;
sh:property [ sh:path :dependsOn ; sh:class :Service ; sh:minCount 0 ] .
```
**Validation-Report** (Beispieldaten Stand 18.05.):
- 312 Service-Instanzen geprüft.
- 14 Violations: 11x fehlender :owner (Service Legacy-Bereich), 3x ungültiger :tier-Wert „prod“.
- Entscheidungen: Legacy-Service als eigene Subklasse :LegacyService mit gelockertem owner-Constraint. Wert „prod“ in :tier wird in ETL auf „critical“ gemappt.
**Doku-Tabelle** (Auszug):
| Property | Pflicht | Typ | Kardinalität | Hinweis |
| --- | --- | --- | --- | --- |
| name | ja | string | 1..1 | Eindeutig, kebab-case |
| tier | ja | enum | 1..1 | critical / standard / experimental |
**Maintenance**: Owner @marcus, Quartalsreview. Breaking-Change-Frist 60 Tage nach Ankündigung.Symptome erkennen, gegensteuern
Shapes werden modelliert, ohne dass Beispieldaten validiert wurden, Validation-Reports erscheinen erst in Produktion.
Pro Shape-Iteration sofort gegen mindestens 50 reale Instanzen validieren. Violations sind Lerndaten, nicht Bug-Reports.
Über 30% der Beispieldaten triggern Violations, ETL-Pipeline bricht in Produktion.
Strikte Constraints in mehreren Severities (sh:Violation, sh:Warning, sh:Info). Erst Warning, dann Verschärfung in Folge-Release.
TTL-Files existieren, aber Datenproduzenten verstehen den Vertrag nicht und liefern weiter falsches Format.
Shape-zu-Tabelle-Generator (z. B. SHACL-Play oder eigenes Script) im CI. Doku-PR ist Pflicht bei Shape-Änderung.
Shapes existieren, aber niemand prüft Daten-PRs gegen sie. Verstöße landen in Produktion.
CI-Job, der bei jedem Daten- oder Shape-PR Validator laufen lässt. Failed Validation = blockierter PR. Bei Shape-Änderung Migrationshinweis pflichtig.
Producer und Consumer arbeiten mit unterschiedlichen Shape-Versionen, niemand weiß was gilt.
SemVer für Shapes, Versions-IRI in jeder Shape-Datei. Producer pinnen auf konkrete Version, Update als bewusster Schritt.
Shapes prüfen nur Typ und Kardinalität, nicht erlaubte Werte. Producer liefert Status „prod“ statt „production“.
Wertelisten (sh:in) und Patterns (sh:pattern) konsequent nutzen, wo der Wert begrenzt ist. ETL-Mappings wo nötig, aber nicht statt Shape.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.