119 lines
5.9 KiB
Plaintext
119 lines
5.9 KiB
Plaintext
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.
|