Product Model: Product Tree and Instance Tree

The product model of the standard consists of two vocabularies that describe the same tree from two perspectives:

  • The product definition (prefix p:) describes in advance – a priori – and identically for all customers what is possible: which components a product has, how often they may occur, which attributes they carry (see Insurance Products as Rule Sets).

  • Product instances (prefix i:) describe the specific case: which components are actually selected for a customer and which values the attributes have.

Both vocabularies have the same structure: an abstract node, a root and sub-nodes nested to any depth. Every node of the instance tree refers via i:basedOn to the node of the product tree on which it is based. The product tree is thus the template, the instance tree its concrete form.

produktbaum-instanzbaum

Product tree (product knowledge, p:)

The product tree, in business terms also called the coverage tree, is the hierarchical structure of an insurance product. It is defined by the insurer and transmitted to the clients at runtime.

Product node (p:ProductNode)

The product node is the abstract generic term for every node in the product tree. It bundles what product and product component have in common:

  • name and description (rdfs:label, rdfs:comment), each language-tagged, at least one name in German,

  • availability (available from, available until), against which the → reference date is checked,

  • subordinate product components (p:hasComponent),

  • product attributes such as sum insured or deductible (p:hasAttribute),

  • associated terms and conditions and clauses.

A product node never occurs in the product tree itself: every node is either a product or a product component. The term is used when a statement applies to all nodes, such as "every product node has a name".

Product (p:Product)

The product is the root of the product tree: what is offered to a customer for conclusion. It corresponds to the sales product in OMDS 3. A product tree has exactly one product; it has no parent element. Examples: "motor insurance" (ex:Motor) and "life insurance" (ex:Life) of the sample catalogue of the standard.

Product component (p:ProductComponent)

The product component is a sub-node of the product tree. It is located either directly under the product or deeper under another product component. In addition to the properties of a product node, it defines how often it must or may occur in an instance (p:minOccurrence, p:maxOccurrence). This is how the product definition distinguishes mandatory components (at least once) from optional components (at least zero times). Examples: motor third-party liability as a mandatory component, below it the optional breakdown service; full casco as an optional component next to liability that may occur up to three times.

OMDS 3 gives the levels of the product tree different names (sales product, product component, cover, …). For the interface it is sufficient to distinguish root and sub-nodes; the standard therefore only knows product and product component. The depth of the tree is not limited.

Instance tree (product instances, i:)

The instance tree is the concrete form of a product tree for one case. It is created at the broker or AI agent from the product definition (initially as a → default instance), is configured and then passes through the application process.

Instance node (i:InstanceNode)

The instance node is the abstract generic term for every node in the instance tree, the counterpart of the product node. Every instance node

  • refers via i:basedOn to exactly the product node on which it is based,

  • can have subordinate instance components (i:hasComponent),

  • carries the instance attributes with the specific values (i:hasAttribute).

Like the product node, the instance node never occurs itself; every node is either an instance or an instance component.

Instance (i:Instance)

The instance is the root of an instance tree: the specific instance of a product. It is based on a product (i:basedOn points to a p:Product), has no parent element and carries the information that concerns the tree as a whole, such as the start of insurance.

One and the same instance accompanies the entire process: the → product configuration is an instance that meets the product rules. The → calculation determines the premium for an instance. → Offer, → application and → contract contain the same instance, extended by information the respective business object needs, such as application questions, persons and payment details (see Insurance Products as Rule Sets). The instance tree itself does not change its structure in the process; only the rules applied to it depend on the business object and its state.

Instance component (i:InstanceComponent)

The instance component is a sub-node of the instance tree. It is based on a product component (i:basedOn points to a p:ProductComponent) and has exactly one parent element (i:isComponentOf), which in turn must be based on the parent product node. This keeps the hierarchy of the instance congruent with that of the product. How often an instance component may occur under its parent node is determined by the product component through its minimum and maximum occurrences.

Instance attribute (i:InstanceAttribute)

The instance attribute is the concrete form of a product attribute at an instance node. It is based on the product attribute (i:basedOn), belongs to exactly one instance node (i:isAttributeOf) and carries at most one value (i:value). The datatype of the value follows the attribute class: text (i:StringAttribute), integer (i:IntAttribute), decimal (i:DecimalAttribute) or boolean (i:BooleanAttribute). Default, bounds and the required flag are not part of the instance attribute but of the product attribute; a new instance takes the default as its value.

Comparison

Role in the tree Product tree (p:) Instance tree (i:) Link

Abstract node

Product node (p:ProductNode)

Instance node (i:InstanceNode)

i:basedOn points to a product node

Root

Product (p:Product)

Instance (i:Instance)

i:basedOn points to the product

Sub-node

Product component (p:ProductComponent)

Instance component (i:InstanceComponent)

i:basedOn points to the product component

Property of a node

Product attribute (p:ProductAttribute)

Instance attribute (i:InstanceAttribute)

i:basedOn points to the product attribute

Risk objects

Risk object rule (p:riskObjectRule): kind, minimum and maximum

List at the instance (i:hasRiskObject), reference at the instance node (i:riskObject)

the rule of the product node determines the references of its instance nodes (see Risk Objects)

Hierarchy

p:hasComponent / p:isComponentOf

i:hasComponent / i:isComponentOf

both directions must match

In both vocabularies the tree structure is linked in both directions: the parent node knows its components, every component knows its parent node. Attributes, risk objects, persons and roles are not nodes of the tree; they are attached to a node or referenced by it (see Objects).

Sample catalogue of the standard

The standard ships with a small, informative sample catalogue that shows every concept of the product model at least once. It belongs to no insurer, is not derived from any of the example insurers and changes only with the standard. The validation rules of the standard are tested against it, as well as against negative examples that each violate one rule.

Property Value

Namespace, prefix

https://vvo.at/omds/ld/example/sample#, ex:

Catalogue in the repository

standard/standard-definition/…/omds-ld/examples/products/sample/ (SampleMotor.ttl, SampleLife.ttl, SampleProcessKnowledge.ttl)

Example instances

…/omds-ld/examples/instances/SampleInstance_01_Motor_Min.ttl, SampleInstance_02_Motor_Max.ttl, SampleInstance_03_Life.ttl

The "motor insurance" ex:Motor has this product tree:

Product component Kind Occurrence Attributes

Motor third-party liability (ex:Motor_Liability)

mandatory component

1..1

sum insured (decimal, required), engine power in kW (integer, required)

  Breakdown service (ex:Motor_BreakdownService)

optional component below liability

0..1

–

Full casco 2025 (ex:Motor_FullCasco_2025)

optional component, available until 2025-12-31

0..3

deductible (decimal)

Full casco 2026 (ex:Motor_FullCasco_2026)

optional component, successor of full casco 2025

0..3

deductible (decimal), new value cover (yes/no)

Partial casco (ex:Motor_PartialCasco)

optional component

0..1

–

Assistance (ex:Motor_Assistance)

optional component without upper limit

0..

–

The product itself carries the attribute licence plate (text). Full casco 2025 and full casco 2026 are two versions of the same component (p:hasPrevious, p:hasSuccessor); the reference date decides which one applies. The "life insurance" ex:Life is a product without components: its instance consists of the root only.

Example

An instance of the motor insurance starting 2026-07-01 in which liability, breakdown service and full casco 2026 are selected looks like this as an instance tree (attributes omitted; complete in SampleInstance_02_Motor_Max.ttl):

i:Motor_JD_8812 a i:Instance ;
    i:basedOn      ex:Motor ;                   # the product
    i:startDate    "2026-07-01"^^xs:date ;
    i:hasComponent i:JD_Liability ;
    i:hasComponent i:JD_FullCasco .

i:JD_Liability a i:InstanceComponent ;
    i:basedOn       ex:Motor_Liability ;        # product component motor third-party liability
    i:isComponentOf i:Motor_JD_8812 ;
    i:hasComponent  i:JD_BreakdownService .

i:JD_BreakdownService a i:InstanceComponent ;
    i:basedOn       ex:Motor_BreakdownService ; # product component breakdown service
    i:isComponentOf i:JD_Liability .

i:JD_FullCasco a i:InstanceComponent ;
    i:basedOn       ex:Motor_FullCasco_2026 ;   # product component full casco 2026
    i:isComponentOf i:Motor_JD_8812 .

If full casco is omitted, the instance remains valid because full casco is optional. If liability is omitted, it is invalid because the product component is required at least once.

Validation by shapes

The standard defines the structure of both trees with SHACL shapes that client and server can evaluate alike. Among other things, the following is checked:

  • Product nodes and instance nodes are never used directly, only their concrete subclasses.

  • A product or an instance has no parent element; a product component or an instance component has exactly one.

  • Every instance node refers to exactly one product node of the matching type: instance to product, instance component to product component.

  • The parent node of an instance component is based on the parent node of the associated product component.

  • The number of instance components under a node lies within the minimum and maximum occurrences of the product component.

  • The value of an instance attribute has the datatype of its attribute class and lies within the bounds of the product attribute; a required attribute has a value.

Violations are returned as → messages at the affected node or attribute; one element can carry several messages. The insurer always validates completely, even if the client has already evaluated the same shapes itself (see Solution Approach, product knowledge).