Detaillierung der Anforderungen an die Prozessvarianten.
This commit is contained in:
@@ -1 +1,118 @@
|
||||
Folgende Ebenen sind vorgesehen:
|
||||
Das Vokabular zur Beschreibung von Versicherungsservices muss modular aufgebaut sein und folgt einer Hierarchie von
|
||||
der allgemeinen semantischen Bedeutung bis hin zur spezifischen lokalen Ausprägung.
|
||||
|
||||
Dabei wird zwischen der **strukturellen Beschreibung** (Daten) und der **funktionalen Beschreibung** (API-Verhalten) unterschieden.
|
||||
|
||||
Ziel ist, zwei Artefakte konsistent zu definieren:
|
||||
|
||||
* Austauschobjekte (Datenobjekte): Welche Felder und Typen werden übertragen und validiert?
|
||||
* Prozessvarianten (Abläufe): Welche Zustände existieren, welche Aktionen sind in welchem Zustand erlaubt?
|
||||
** Welche der normierten Prozessvarianten werden von der Versicherungsgesellschaft tatsächlich unterstützt
|
||||
** Welche zusätzlichen Services gibt es für ein spezielles Themengebiet (z.B. Versicherungsbestätigung für
|
||||
Sparte Kfz)
|
||||
** Wie genau wurde ein Prozess von der Versicherungsgesellschaft implementiert: Bei der Antragsstrecke haben wir
|
||||
derzeit eine stateles und eine stateful Variante. Es sollte für den Client erkennbar sein, welche Variante
|
||||
implementiert wurde.
|
||||
** Welche zusätzlichen Services werden von der Versicherungsgesellschaft angeboten
|
||||
|
||||
=== Schichtenmodell des Vokabulars
|
||||
|
||||
Die Vokabulare bauen aufeinander auf ("Inheritance & Extension"), um Interoperabilität zu gewährleisten.
|
||||
|
||||
[cols="1,1,2,2"]
|
||||
|===
|
||||
|Kategorie |Bezeichnung | Zweck | Lieferobjekt
|
||||
|
||||
.2+| **Technische Ebene** (API & Validierung)
|
||||
| Hydra
|
||||
| Definiert die *Dynamik* und *Businessprozesse*. Beschreibt Hypermedia-Controls, Operationen (z.B. `POST`, `PUT`) und wie Clients durch den Service navigieren können (State Transitions).
|
||||
| Operation, Link, Collection, Erwartungen an Zustandswechsel
|
||||
|
||||
| SHACL
|
||||
| Definiert die *Validierungslogik*. Es beschränkt die offenen Vokabulare (FIBO, Schema.org) auf konkrete, validierbare Shapes ("Welche Felder sind Pflicht?", "Welche Wertebereiche sind erlaubt?").
|
||||
| Shape, Constraint, Severity
|
||||
|
||||
| **Allgemeine Semantik**
|
||||
| Schema.org
|
||||
| Bietet das *gemeinsame Vokabular* (Upper Ontology) für Suchmaschinen (SEO) und KI-Agenten. Basisklassen wie `Person`, `Organization` oder `FinancialProduct` werden hier verankert.
|
||||
| Klassen/Properties als generische Basistermine
|
||||
|
||||
.2+| **Fachdomäne** (Core Domain)
|
||||
| FIBO
|
||||
| Die *Financial Industry Business Ontology* liefert die präzise, branchenübergreifende Definition von Finanzbegriffen (Vertragsrecht, Zinsen, wirtschaftliche Eigentümer), die Schema.org fehlen.
|
||||
| Fachklassen/Properties, referenzierbare Definitionen
|
||||
|
||||
| **Schema4i**
|
||||
| (Optional) Spezifische Erweiterung für die *Versicherungswirtschaft*, basierend auf BiPro-Modellen, um Lücken zwischen FIBO (Finanzfokus) und Versicherungsprodukten zu schließen.
|
||||
| Versicherungs-spezifische Klassen/Properties
|
||||
|
||||
.4+| **Lokalisierung** (Specific Domain)
|
||||
| OMDS Commons
|
||||
| Marktübergreifende Begriffe, die spezifisch für den OMDS-Standard sind, aber noch keine nationale Besonderheit darstellen.
|
||||
| Harmonisiertes Domänenvokabular
|
||||
|
||||
| OMDS Austria
|
||||
| Begriffe von lokaler österreichischer Bedeutung (z.B. Abbildung spezifischer Steuergesetze z.B. motorbezogene Kfz-Steuer, lokale Elemente wie "Bonus-Malus").
|
||||
| Lokale Erweiterungen/Constraints
|
||||
|
||||
| OMDS Domänen & Sparten
|
||||
| Festlegung von Begriffen und Regeln für einzelne Domänen und Sparten.
|
||||
| Produkt-/Spartenprofile
|
||||
|
||||
| VU-spezifische Ergänzungen
|
||||
| VU-spezifische Ergänzungen für Domänen und Sparten.
|
||||
| Lokale Profile/Regeln
|
||||
|
||||
|
||||
|===
|
||||
|
||||
=== Unterscheidung: Geschäftsobjekte vs. Prozesse
|
||||
|
||||
Für eine saubere Architektur ist die Trennung der Anliegen (Separation of Concerns) im Vokabular notwendig:
|
||||
|
||||
1. **Geschäftsobjekte (Structural Vocabulary):**
|
||||
Beschreiben das "WAS".
|
||||
* Hierbei handelt es sich um RDF-Klassen und Properties (z.B. definiert durch Schema.org/FIBO).
|
||||
* Beispiel: Eine Instanz einer `InsurancePolicy` mit Attributen wie `startDate`, `premium`.
|
||||
* Diese Definitionen sind meist zustandslos und wiederverwendbar.
|
||||
|
||||
2. **Businessprozesse (Behavioural Vocabulary / Hydra):**
|
||||
Beschreiben das "WIE".
|
||||
* Hier wird definiert, welche *Aktionen* auf den Geschäftsobjekten ausgeführt werden dürfen.
|
||||
* Hydra `Operation`: Definiert den API-Aufruf (z.B. `SubmitClaim`).
|
||||
* Status-Modelle: Definition von Prozesszuständen (z.B. `ClaimProcessingStage`), die oft im OMDS-Layer definiert werden müssen, da sie sehr spezifisch für die Abwicklungslogik sind.
|
||||
|
||||
=== Prozessvarianten modellieren (Hydra + Zustandsmodell)
|
||||
|
||||
Um Varianten sauber zu kommunizieren, wird ein Prozess als Zustandsmaschine beschrieben. Wichtig ist: Die **zulässigen Operationen sind objekt- und kontextabhängig zur Laufzeit**. Ein Objekt signalisiert also seinen aktuellen Handlungsspielraum durch die angebotenen Hydra-Operationen (Hypermedia als State of the Resource).
|
||||
|
||||
* **State**: benannter Zustand eines Geschäftsobjekts (z.B. `ClaimDraft`, `ClaimSubmitted`).
|
||||
* **Transition**: definierter Wechsel zwischen Zuständen, ausgelöst durch eine Operation.
|
||||
* **Preconditions**: fachliche Bedingungen, die vor Ausführung erfüllt sein müssen.
|
||||
* **Result-Objekt**: welches Objekt bzw. welcher Status nach der Operation resultiert.
|
||||
|
||||
Hydra definiert dabei die Operationen und Links, SHACL validiert die Datenobjekte, die als Input/Output der Operationen verwendet werden.
|
||||
|
||||
=== Austauschobjekte & Profile (SHACL)
|
||||
|
||||
Ein **Profil** definiert ein austauschbares Datenobjekt als Kombination aus:
|
||||
|
||||
* **Subset** der Klassen/Properties aus Schema.org/FIBO/OMDS.
|
||||
* **Constraints** (Pflichtfelder, Kardinalität, Wertebereiche).
|
||||
* **Businessregeln** (z.B. bedingte Pflichtfelder) als SHACL-Constraints.
|
||||
|
||||
So lassen sich Datenobjekte eindeutig und testbar zwischen Partnern definieren.
|
||||
|
||||
=== Minimales Beispiel (Skizze)
|
||||
|
||||
```json
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "InsuranceProduct",
|
||||
"name": "Haushalt Premium",
|
||||
"category": "PropertyInsurance"
|
||||
}
|
||||
```
|
||||
|
||||
* **Hydra Operation**: `RequestOffer` auf `InsuranceProduct` erlaubt nur im Zustand `ProductActive`.
|
||||
* **SHACL Shape**: `InsuranceProductShape` fordert `name` und `category` als Pflichtfelder.
|
||||
|
||||
Reference in New Issue
Block a user