Vocabulary Layers

This page arranges the vocabulary of the standard into two pillars, five layers and their carriers. The pillars themselves are described by the concept pages Business Objects and Operations (process) and Product Tree and Instance Tree (structure); the terms are in the Glossary.

The vocabulary with which the standard describes insurance services is modular. It answers two questions that cannot be reduced to one another:

What is exchanged? Which things exist – products, product instances, persons, contracts –, which data do they carry, and which values are permitted?
How is work done? Which business objects exist in a business case, which states do they have, which operations are permitted in which state, who triggers them, and which of this does an insurer implement?

Each question is answered by one pillar of the vocabulary. Both pillars reach from general, market-independent terms down to what a single insurer defines; these levels of generality are the layers. Across them stand the carriers: the technical means through which the vocabulary reaches the client and is executed.

Two Pillars

	Structural pillar ("what")	Process pillar ("how")
Question	Which things exist, which data do they carry, which values are permitted?	Which business objects exist, in which state do they permit which operation, who triggers it, what does the insurer implement?
Terms	product, product component, product attribute, product instance, person, role, contract data, code list, shape	business case, business case type, business object, assessed and set state, operation kind, transition, derivation, next step, process variant, process knowledge
Concept pages	Product Tree and Instance Tree, Product and Product Tree, Insurance Products as Rule Sets, Objects, Persons and Roles, Application Questions	Business Objects and Operations, Application Process, State Diagram Motor, Process Knowledge

Structural pillar ("what")

Process pillar ("how")

Question

Which things exist, which data do they carry, which values are permitted?

Which business objects exist, in which state do they permit which operation, who triggers it, what does the insurer implement?

Terms

product, product component, product attribute, product instance, person, role, contract data, code list, shape

business case, business case type, business object, assessed and set state, operation kind, transition, derivation, next step, process variant, process knowledge

Concept pages

Product Tree and Instance Tree, Product and Product Tree, Insurance Products as Rule Sets, Objects, Persons and Roles, Application Questions

Business Objects and Operations, Application Process, State Diagram Motor, Process Knowledge

The pillars are connected by references, not by inheritance: a business object of the process pillar – an application, say – carries objects of the structural pillar as its content (the product instance, persons with their roles, contract data). A next step of the process pillar names a shape of the structural pillar as the expected form (bc:expects). Which state is assessed for a business object is decided by the process pillar; whether its content is conforming and complete for that is checked by the structural pillar with its shapes.

Five Layers, the Same for Both Pillars

Each pillar has the same five layers. They order by generality, not by technology:

General: vocabularies that exist independently of the standard and also make sense outside insurance. The standard adopts them but does not define them.
Foundation: the basic terms and principles that apply to all markets – the meta-models for product and business process as well as the internationally shared domain terms and lines of business.
Standard Europe: what applies on top of that to all European markets because it stems from European law or European standards.
Country-specific standardisation (e.g. Austria): what OMDS LD defines on top of that for a single national market, currently the Austrian one.
Insurer: what a single insurer declares or adds on top of that, retrievable at runtime.

Foundation, Standard Europe and the country-specific standardisation build on one another: Standard Europe uses terms from the foundation, the country-specific standardisation uses terms from both, never the other way round. All three are normative and the same for all insurers.

Each layer consists of vocabularies. A vocabulary has a namespace of its own, lies in exactly one layer and serves exactly one purpose; a layer usually has several vocabularies. The layer of a term therefore follows from its vocabulary. The namespaces of the foundation lie directly below https://vvo.at/omds/ld/, those of Standard Europe below …/eu/, the Austrian ones below …/at/.

Layer Structural pillar ("what") Process pillar ("how")

Layer	Structural pillar ("what")	Process pillar ("how")
General	Schema.org (`schema:`): person, organisation, address. External domain ontologies such as FIBO or Schema4i are not a layer of the standard; where needed, terms of the standard are mapped onto them via `rdfs:subClassOf` or `owl:equivalentClass` without changing instance data.	Currently empty: the standard uses no external process vocabulary (Hydra is not used). If there were one, terms of the standard would be mapped onto it as in the structural pillar via `rdfs:subClassOf` or `owl:equivalentClass`.
Foundation	Product definition (`p:`) and product instance (`i:`): the meta-models of product tree and instance tree with the shapes of the standard (Product Tree and Instance Tree). Risk objects (`risk:`): what several lines of business insure – the abstract base risk object and its kinds, the person as a risk, the vehicle, the building (Risk Objects). Contract data and roles (`ct:`): start, payment method, main due date; policyholder, premium payer, insured person. Lines of business (one vocabulary per line, e.g. `motor:`): what a line of business has in common in all markets, for motor e.g. third-party liability and casco.	Business process core (`bc:`): business case as the bracket, business object with assessed and set states, general lifecycle (draft, ready, handed over, in processing at the insurer, query, completed, rejected), the six operation kinds, the four checks in a fixed order, next steps (`bc:nextStep`, `bc:expects`), responsibilities and the inquiry "retrieve state changes". Vocabulary of the declaration (`pk:`): `pk:Declaration` with its properties. Business case types (`bct:`): application process, contract change, conversion, claim notification and claims handling with their business objects, the type-specific names of the state ready (calculable, acceptable, submittable, reportable), transitions, derivations and responsibilities. Shown for humans as state diagrams of the concept page or in BPMN.
Standard Europe	Currently empty. Planned are European domain terms (`eu:`), such as the product information document (IPID) or the SEPA payment method, and per line of business a vocabulary for European requirements (e.g. `eumotor:` with the obligation to have third-party liability insurance).	Currently empty. Planned for mandatory steps and checks from European law (`eupv:`), such as information obligations before the conclusion of the contract.
Country-specific standardisation (e.g. Austria)	Austrian domain terms and code lists (`at:`), for example the type of application. Lines of business (one vocabulary per line, e.g. `atmotor:`): what a line of business knows only in Austria, for motor the registration districts as a code list with the registration district as a mandatory characteristic of the vehicle (Risk Objects), in future bonus-malus, the rules for alternating number plates and the tax treatment. Mapping to OMDS 3 (`omds:`): the structures and codes of OMDS 3 that a wrapper and the migration need.	Process variants (`atpv:`): the exhaustive list of the permitted process variants and the default case per business case type; the mapping to the operations of OMDS 3.
Insurer	Product catalogues in the insurer’s namespace (examples: `dis:`, `aa:`, `pfm:`), product-specific shapes, additions to lines of business and attributes that only this insurer knows (Example Insurers).	Declaration of the process knowledge per insurer: an instance of `pk:Declaration` in the insurer’s namespace that states per business case type which process variants it implements and where it deviates from the default case, whether it keeps drafts (draft at the server), from when a business case is persisted and jointly editable, which parameters its transitions expect, which inputs a state requires and whether it additionally delivers state changes.

General

Schema.org (schema:): person, organisation, address. External domain ontologies such as FIBO or Schema4i are not a layer of the standard; where needed, terms of the standard are mapped onto them via rdfs:subClassOf or owl:equivalentClass without changing instance data.

Currently empty: the standard uses no external process vocabulary (Hydra is not used). If there were one, terms of the standard would be mapped onto it as in the structural pillar via rdfs:subClassOf or owl:equivalentClass.

Foundation

Product definition (p:) and product instance (i:): the meta-models of product tree and instance tree with the shapes of the standard (Product Tree and Instance Tree).
Risk objects (risk:): what several lines of business insure – the abstract base risk object and its kinds, the person as a risk, the vehicle, the building (Risk Objects).
Contract data and roles (ct:): start, payment method, main due date; policyholder, premium payer, insured person.
Lines of business (one vocabulary per line, e.g. motor:): what a line of business has in common in all markets, for motor e.g. third-party liability and casco.

Business process core (bc:): business case as the bracket, business object with assessed and set states, general lifecycle (draft, ready, handed over, in processing at the insurer, query, completed, rejected), the six operation kinds, the four checks in a fixed order, next steps (bc:nextStep, bc:expects), responsibilities and the inquiry "retrieve state changes".
Vocabulary of the declaration (pk:): pk:Declaration with its properties.
Business case types (bct:): application process, contract change, conversion, claim notification and claims handling with their business objects, the type-specific names of the state ready (calculable, acceptable, submittable, reportable), transitions, derivations and responsibilities. Shown for humans as state diagrams of the concept page or in BPMN.

Standard Europe

Currently empty. Planned are European domain terms (eu:), such as the product information document (IPID) or the SEPA payment method, and per line of business a vocabulary for European requirements (e.g. eumotor: with the obligation to have third-party liability insurance).

Currently empty. Planned for mandatory steps and checks from European law (eupv:), such as information obligations before the conclusion of the contract.

Country-specific standardisation (e.g. Austria)

Austrian domain terms and code lists (at:), for example the type of application.
Lines of business (one vocabulary per line, e.g. atmotor:): what a line of business knows only in Austria, for motor the registration districts as a code list with the registration district as a mandatory characteristic of the vehicle (Risk Objects), in future bonus-malus, the rules for alternating number plates and the tax treatment.
Mapping to OMDS 3 (omds:): the structures and codes of OMDS 3 that a wrapper and the migration need.

Process variants (atpv:): the exhaustive list of the permitted process variants and the default case per business case type; the mapping to the operations of OMDS 3.

Insurer

Product catalogues in the insurer’s namespace (examples: dis:, aa:, pfm:), product-specific shapes, additions to lines of business and attributes that only this insurer knows (Example Insurers).

Declaration of the process knowledge per insurer: an instance of pk:Declaration in the insurer’s namespace that states per business case type which process variants it implements and where it deviates from the default case, whether it keeps drafts (draft at the server), from when a business case is persisted and jointly editable, which parameters its transitions expect, which inputs a state requires and whether it additionally delivers state changes.

A line of business thus has a vocabulary of its own per layer, created only when there are definitions on that layer. Motor is similar in many markets but differs in individual rules: third-party liability and casco belong to the foundation (motor:), the obligation to have third-party liability insurance to Standard Europe (eumotor:); bonus-malus, the rules for alternating number plates and the tax treatment are Austrian (atmotor:). Another country replaces these parts with a vocabulary of its own, for example with no-claims classes in Germany, and keeps the foundation and the European part. Lines of business with a common core get a shared vocabulary, for example buildings and household; the risk objects do not lie in the lines of business but in risk:, so that accident, life and health use the same insured person.

Carriers

The carriers are not a layer of the vocabulary. They are the means by which both pillars reach the client and are executed (Interface Technology):

Carrier Role

Carrier	Role
JSON-LD	Exchange format of both pillars: the objects of the structural pillar travel as JSON-LD; so do the states and next steps in every response and the declaration of process knowledge, because the process pillar is RDF just like the structural pillar.
SHACL shapes	Validate the structural pillar: shapes of the standard (e.g. `p:`, `i:`, `risk:`, `ct:` and the lines of business) and product-specific shapes of the insurer (Validation by shapes). The process pillar refers to them: the next step names the shape of the expected content with `bc:expects`, and the declaration of process knowledge is itself validated against a shape of the standard.
OpenAPI	Executes the process pillar: every operation of the standard is an OpenAPI operation whose `operationId` reveals the operation kind and the business object.
MCP tools	The same operations as tools for AI agents; the tool name is the `operationId` (Tools).
Next-step links	Carry the process pillar into every response at runtime: at the business case and at each business object, the operations permitted now are listed with target resource and expected shape. What is not listed is not permitted (Business Case and Next Steps).

JSON-LD

Exchange format of both pillars: the objects of the structural pillar travel as JSON-LD; so do the states and next steps in every response and the declaration of process knowledge, because the process pillar is RDF just like the structural pillar.

SHACL shapes

Validate the structural pillar: shapes of the standard (e.g. p:, i:, risk:, ct: and the lines of business) and product-specific shapes of the insurer (Validation by shapes). The process pillar refers to them: the next step names the shape of the expected content with bc:expects, and the declaration of process knowledge is itself validated against a shape of the standard.

OpenAPI

Executes the process pillar: every operation of the standard is an OpenAPI operation whose operationId reveals the operation kind and the business object.

MCP tools

The same operations as tools for AI agents; the tool name is the operationId (Tools).

Next-step links

Carry the process pillar into every response at runtime: at the business case and at each business object, the operations permitted now are listed with target resource and expected shape. What is not listed is not permitted (Business Case and Next Steps).

Profiles Cut Across

The profiles of the standard are scopes that an insurer fulfils – neither a layer nor a pillar. They cut across the grid:

The base profile comprises the process pillar in all layers (without the operation kinds edit and delta derivation) and the structural pillar without the product definition: product instances (i: without i:basedOn), risk objects (risk:), contract data and roles (ct:), the domain terms and lines of business of the standard and Schema.org. A wrapper over the existing SOAP services can fulfil it.
The product knowledge profile adds the product definition (p:) and the product knowledge for the instance in the structural pillar, and the edit of the stored draft in the process pillar.