Technical Foundations

OMDS LD builds on open W3C standards and on widespread interface technologies. This page is meant for insurance companies and for integrators – brokers and software houses – and shows which technologies they deal with, what each one is needed for and how deep each of them has to go.

Overview

Technology Purpose in OMDS LD Insurers Integrators

Knowledge graph, RDF

Basic model: products, processes and business objects are statements about things with globally unique names (IRIs)

understand

basic concepts

Turtle

Notation of the ontology and of the product catalogues

write

be able to read

RDFS and OWL

Vocabulary of the standard: classes, properties, subclasses

understand, extend

basic concepts

SHACL

Rules and checks: what a product configuration or a request must contain

apply

read the validation report and shapes

JSON-LD

Format of the payload over the interface

apply

apply

OpenAPI, JSON Schema

Description of the services, code generation

offer services

call services

MCP

Tools for AI agents in front of the services

optionally operate

for AI agents

For integrators the entry is smaller than the list suggests: requests have a canonical form with JSON Schemas, so they can be built and checked like ordinary JSON. An understanding of IRIs, graphs and validation reports is needed to read the answers correctly and to follow the next steps.

Knowledge Graph and RDF

A knowledge graph describes knowledge as a set of simple statements of the form subject – predicate – object, such as "Motor liability is a component of the motor product". Subjects and predicates are IRIs, that is, globally unique names in the form of a web address. The data model for this is RDF (Resource Description Framework).

Compared with fixed message structures, as OMDS 3 describes them with XML schemas, this has two consequences:

  • Extensible without breaking. An insurer adds statements of its own in its own namespace; whoever does not know them skips them instead of failing on an unknown element.

  • Knowledge at runtime. Products, rules and admissible next steps are data like any other. A client queries them instead of programming them in (Solution Approach).

Turtle

Turtle is the readable text form of RDF. The ontology of the standard and the product catalogues are written in it. An excerpt from the sample catalogue of the standard:

@prefix ex:   <https://vvo.at/omds/ld/example/sample#> .
@prefix p:    <https://vvo.at/omds/ld/productknowledge#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:Motor_Liability
    a               p:ProductComponent ;            # is a product component
    rdfs:label      "Motor liability insurance"@en ;
    p:isComponentOf ex:Motor ;                      # component of the motor product
    p:minOccurrence 1 ;                             # mandatory component
    p:maxOccurrence 1 ;
    p:hasAttribute  ex:Motor_SumInsured .           # with the attribute sum insured

Every line is a statement about ex:Motor_Liability. The prefixes abbreviate the IRIs: p:ProductComponent stands for https://vvo.at/omds/ld/productknowledge#ProductComponent. What the terms mean is described in Product Tree and Instance Tree.

RDFS and OWL

RDFS (RDF Schema) and OWL (Web Ontology Language) define the vocabulary: which classes exist, such as p:Product and p:ProductComponent, which properties they have and which class is a subclass of another. The standard divides its vocabulary into layers, from the foundations to the terms of an insurer. A line of business or a component of an insurer’s own is a subclass of a term of the standard.

SHACL

SHACL (Shapes Constraint Language) describes what data must look like: which statements a node needs, how often and with which range of values. A SHACL check yields a validation report that names every deviation together with the node concerned.

In OMDS LD, SHACL appears in three places:

  • in the rules of the product model, such as mandatory components and the value ranges of attributes;

  • in the request shapes, which define for each operation what a request must contain;

  • in the answers: every answer about a business object contains the validation report, and every next step names the shapes it expects (Checks and Responsibilities).

JSON-LD

JSON-LD is JSON that is at the same time an RDF graph. A @context maps the keys to IRIs, @id gives the IRI of a node, @type its class. Requests and answers go over the interface in JSON-LD; the standard defines a normative context. A request in the canonical form:

{
  "@context": "https://vvo.at/omds/ld/context.jsonld",
  "@type": "bc:AddComponentRequest",
  "bc:target": "https://insurer.example/omds-ld/api/business-cases/4711/calculation/instance",
  "bc:component": "https://vvo.at/omds/ld/example/disrupto#ProdElement34"
}

Details on the context and the notation are given under Canonical Form of the Requests.

OpenAPI and JSON Schema

The services are described in an OpenAPI file (version 3.1): paths, methods, status codes, examples and, for each operation, a JSON Schema of the request. Clients and server skeletons can be generated from it, as for any other REST interface (Interface (OpenAPI)).

MCP

The Model Context Protocol (MCP) is an open protocol through which AI agents call tools. The MCP server of the standard offers every operation of the OpenAPI file as a tool and condenses the answers for the model (AI agents (MCP)). Whoever does not want to connect AI agents does not need MCP.

Libraries

Mature free libraries exist for all the standards mentioned, for instance:

  • Java: Eclipse RDF4J, Apache Jena (RDF, Turtle, JSON-LD, SHACL);

  • JavaScript and TypeScript: jsonld.js, N3.js, rdf-validate-shacl;

  • Python: rdflib, pySHACL;

  • .NET: dotNetRDF.

The reference implementation of OMDS LD is written in Java with Eclipse RDF4J, and in TypeScript for the MCP server (Tools).

Further Reading