Skip to content

BPMN Deep Dive

Teams that lift BPMN process models into an architecture knowledge graph face a choice: reproduce every execution detail, or capture only what matters for cross-model reasoning. Get it wrong and you either drown in geometry triples or lose the process semantics you needed. This deep dive explains why BPMN differs from ArchiMate, then offers two ontology profiles — full spec fidelity and a thin EA-level lift — so you can query, validate, and reason across BPMN and other notations.

1. What is BPMN

Business Process Model and Notation (BPMN) is the OMG standard for graphical representation of business processes. Version 2.0.2 (formal/2013-12-09) defines a rich metamodel with 130+ classes covering:

  • Process orchestration — activities, events, gateways, sequence flows
  • Collaboration — participants (pools), message flows between organizations
  • Choreography — expected message exchange sequences between parties
  • Conversation — logical groupings of message exchanges
  • Data — data objects, stores, inputs/outputs, associations
  • Diagram interchange — geometry, shapes, edges, labels, styles

The specification is available at omg.org/spec/BPMN/2.0.2.

2. BPMN vs ArchiMate — Different Density, Different Purpose

BPMN is execution-oriented. It was designed so that a process model can be directly executed by a BPMN engine (Camunda, jBPM, etc.). This means every detail matters: timer durations, conditional expressions, data mappings, correlation keys, multi-instance loop cardinalities.

ArchiMate is governance-oriented. A Business Process in ArchiMate is a single element with a name and maybe a description. It exists to show how processes relate to capabilities, applications, and technology — not to specify execution logic.

The density difference is dramatic. A single ArchiMate Business Process element might correspond to an entire BPMN model with 50+ elements (tasks, gateways, events, lanes, data objects, sequence flows, boundary events).

Dimension ArchiMate BPMN
Purpose Cross-layer governance Process execution
Process granularity 1 element per process 10–100 elements per process
Relationships Typed (Triggering, Flow, Access) Sequence Flow, Message Flow, Data Association
Events Not modelled 13 event types × 3 positions (start/intermediate/end)
Data DataObject (passive structure) DataObject, DataInput, DataOutput, DataStore, DataState, ItemDefinition, I/O Specifications
Diagram interchange Not in the standard Full geometry model (BPMNDI/DI/DC)

This density difference has direct implications for ontology design.

3. The Density Problem

A faithful 1:1 lift of every BPMN-XML element into RDF creates many triples whose semantic value at the enterprise architecture level is near zero:

  • Pool/lane geometry (x, y, width, height)
  • Sequence flow waypoints (arrays of coordinate pairs)
  • Marker styles (isExpanded, isMarkerVisible, participantBandKind)
  • I/O specifications (InputSet, OutputSet, DataInput, DataOutput bindings)
  • Correlation keys and subscriptions
  • Extension elements and attribute values

If the goal is rendering BPMN diagrams, RDF buys nothing over the native XML. The value of RDF materializes only when you intend to query, validate, or reason across BPMN and other models.

This is why Linked.Archi provides two BPMN profiles:

Profile Location Classes Properties Use case
BPMN Full modelingLanguages/bpmn/ 144 199 Spec fidelity, round-tripping, tooling, execution
BPMN Lite modelingLanguages/bpmn-lite/ 29 10 EA reasoning, cross-model queries, thin lift

The choice is a designer decision. Both are available as building blocks.

4. BPMN Full — Spec-Faithful Ontology

The full suite (modelingLanguages/bpmn/) is a 1:1 OWL mapping of the BPMN 2.0.2 XMI/CMOF, validated against the normative XSD artifacts. It preserves the compositional structure of the spec.

4.1 Example: Timer Start Event (Nobel Prize Process)

The BPMN 2.0.2 spec examples include a Nobel Prize nomination process that starts on a timer:

<!-- .reference/omg/bpmn202/2010-06-03/Nobel Prize/Nobel Prize Process.bpmn -->
<startEvent name="September Year n-1" id="_6-84">
    <timerEventDefinition>
        <timeDate/>
    </timerEventDefinition>
</startEvent>

In the full ontology, this becomes:

@prefix bpmn: <https://meta.linked.archi/bpmn/onto#> .
@prefix ex:   <https://example.org/nobel-prize/> .

ex:sept_start a bpmn:StartEvent ;
    bpmn:name "September Year n-1" ;
    bpmn:id "_6-84" ;
    bpmn:eventDefinitions ex:sept_start_timer .

ex:sept_start_timer a bpmn:TimerEventDefinition ;
    bpmn:timeDate [] .

The compositional pattern (event + event definition) supports events with multiple triggers without combinatorial subclass explosion.

bpmn:name alone is correct here. bpmn:StartEvent is an arch:Element — it is a node in the process graph — but BPMN makes an event's name optional, so bpmnsh:RequiredNameShape does not target it and no label rule applies. Classes that are required to be named need a skos:prefLabel as well — see §4.2b.

4.2 Example: Collaboration with Message Flow

Use this pattern to model two participants exchanging a message across pools:

@prefix bpmn: <https://meta.linked.archi/bpmn/onto#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:   <https://example.org/order-process/> .

ex:customer_pool a bpmn:Participant ;
    bpmn:name      "Customer" ;
    skos:prefLabel "Customer"@en .

ex:supplier_pool a bpmn:Participant ;
    bpmn:name      "Supplier" ;
    skos:prefLabel "Supplier"@en .

ex:order_collab a bpmn:Collaboration ;
    bpmn:name      "Order Fulfillment" ;
    skos:prefLabel "Order Fulfillment"@en ;
    bpmn:participants ex:customer_pool, ex:supplier_pool ;
    bpmn:messageFlows ex:order_msg_flow .

ex:order_msg_flow a bpmn:MessageFlow ;
    bpmn:name "Purchase Order" ;          # a relationship, not an element — no prefLabel required
    bpmn:sourceRef ex:send_order_task ;
    bpmn:targetRef ex:receive_order_task ;
    bpmn:messageRef ex:purchase_order_msg .

ex:purchase_order_msg a bpmn:Message ;
    bpmn:name      "Purchase Order" ;
    skos:prefLabel "Purchase Order"@en .

4.2b Labelling — emit both bpmn:name and skos:prefLabel

Note the pattern in the two examples above. bpmn:Participant, bpmn:Collaboration and bpmn:Message are aligned to arch:Element and required to be named, so each carries both properties. bpmn:MessageFlow is a relationship, not an element. bpmn:StartEvent is an element — events are nodes in the process graph — but BPMN makes its name optional, so it is not required to carry a skos:prefLabel. For both of those, bpmn:name alone is correct.

Note the distinction: being an element and being required to have a name are separate questions. BPMN has 49 arch:Element classes; bpmnsh:RequiredNameShape requires a label on 33 of them. The other 16 are the Gateway and Event subtypes.

skos:prefLabel bpmn:name
Purpose canonical Linked.Archi label verbatim BPMN XML name attribute
Datatype rdf:langString — language tag mandatory plain xsd:string
Required on the 33 classes bpmnsh:RequiredNameShape reaches retained wherever BPMN defines it (33 classes)
Read by tooling yes — docs, palettes, templates, SPARQL, SHACL no

Two traps for converter authors:

  • An untagged literal fails validation. skos:prefLabel "Customer" is rejected; "Customer"@en passes. bpmnsh:RequiredNameShape asserts sh:datatype rdf:langString.
  • bpmn:name is not a substitute. The shape does not accept it. Emitting only bpmn:name leaves every named element failing validation, even though the model looks correctly named.

The two properties are not redundant: of the 33 classes with a bpmn:name constraint, only 6 are arch:Element. For the other 27 — bpmn:Error, bpmn:Signal, bpmn:Interface, bpmn:Operation, bpmn:CorrelationKey and the rest — bpmn:name is the only name-bearing property, and no label shape reaches them because they are not architecture elements. See DD-24 for the full contract, including why rdfs:subPropertyOf is deliberately not used to bridge them.

4.3 SPARQL: Find all tasks in a process

Run this query to list every task within a process:

PREFIX bpmn: <https://meta.linked.archi/bpmn/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?process ?task ?taskName WHERE {
    ?process a bpmn:Process ;
             bpmn:flowElements ?task .
    ?task a/rdfs:subClassOf* bpmn:Task ;
          skos:prefLabel ?taskName .
}

Query skos:prefLabel, not bpmn:name. Tasks are arch:Element, so the canonical label is what tooling and cross-notation queries rely on — and it is the only one that joins cleanly against ArchiMate, C4 or Backstage elements in the same graph.

5. BPMN Lite — EA-Level Thin Lift

The lite profile (modelingLanguages/bpmn-lite/) converts only the BPMN constructs that carry semantic value at the EA level. Layout and notation detail stays in the original .bpmn file, referenced by URI.

5.1 Same Example: Timer Start Event

Compare the same timer start event in the lite profile — three triples instead of five:

@prefix bpmnl: <https://meta.linked.archi/bpmn-lite/onto#> .
@prefix arch:  <https://meta.linked.archi/core#> .
@prefix skos:  <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:    <https://example.org/nobel-prize/> .

ex:sept_start a bpmnl:StartEvent ;
    skos:prefLabel "September Year n-1"@en ;
    bpmnl:eventType "timer" ;
    bpmnl:sourceRef <file:///models/nobel-prize.bpmn> .

Three triples instead of five. No separate EventDefinition instance. The eventType property captures the trigger type as a simple string. The sourceRef points back to the original BPMN file for full detail.

5.2 Same Example: Collaboration with Message Flow

Use this lite pattern when you want the collaboration flattened into directly joinable triples:

@prefix bpmnl: <https://meta.linked.archi/bpmn-lite/onto#> .
@prefix arch:  <https://meta.linked.archi/core#> .
@prefix skos:  <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:    <https://example.org/order-process/> .

ex:customer a bpmnl:Participant ;
    skos:prefLabel "Customer"@en .

ex:supplier a bpmnl:Participant ;
    skos:prefLabel "Supplier"@en .

ex:order_msg a bpmnl:MessageFlow ;
    arch:source ex:customer ;
    arch:target ex:supplier ;
    skos:prefLabel "Purchase Order"@en .

Flat, queryable, and directly joinable with ArchiMate or C4 elements in the same graph.

5.3 Validating BPMN Lite with SHACL

The lite profile includes SHACL shapes (linkedarchi-bpmn-lite-shacl.ttl) that enforce basic constraints:

# From modelingLanguages/bpmn-lite/linkedarchi-bpmn-lite-shacl.ttl

:StartEventShape a sh:NodeShape ;
    sh:targetClass bpmnl:StartEvent ;
    sh:property [
        sh:path bpmnl:eventType ;
        sh:in ( "none" "timer" "message" "signal" "conditional" ) ;
        sh:message "A StartEvent eventType must be one of: none, timer, message, signal, conditional." ;
    ] ;
.

:SequenceFlowShape a sh:NodeShape ;
    sh:targetClass bpmnl:SequenceFlow ;
    sh:property [
        sh:path arch:source ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:message "A SequenceFlow must have exactly one source." ;
    ] ;
    sh:property [
        sh:path arch:target ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:message "A SequenceFlow must have exactly one target." ;
    ] ;
.

5.4 SPARQL: Cross-model query (BPMN Lite + ArchiMate)

The real value of the lite profile — querying across notations in a single graph:

PREFIX bpmnl: <https://meta.linked.archi/bpmn-lite/onto#>
PREFIX archi:  <https://meta.linked.archi/archimate3/onto#>
PREFIX arch:   <https://meta.linked.archi/core#>
PREFIX skos:   <http://www.w3.org/2004/02/skos/core#>

# Find ArchiMate ApplicationServices that are realized by BPMN ServiceTasks
SELECT ?service ?serviceName ?task ?taskName WHERE {
    ?service a archi:ApplicationService ;
             skos:prefLabel ?serviceName .
    ?task a bpmnl:ServiceTask ;
          skos:prefLabel ?taskName .
    ?service arch:realizedBy ?task .
}

Run this to list every task grouped by its owning participant:

PREFIX bpmnl: <https://meta.linked.archi/bpmn-lite/onto#>
PREFIX archi:  <https://meta.linked.archi/archimate3/onto#>
PREFIX arch:   <https://meta.linked.archi/core#>
PREFIX skos:   <http://www.w3.org/2004/02/skos/core#>

# Find all processes owned by a participant, with their tasks
SELECT ?participant ?participantName ?task ?taskName WHERE {
    ?participant a bpmnl:Participant ;
                 skos:prefLabel ?participantName .
    ?task a/rdfs:subClassOf* bpmnl:Task ;
          skos:prefLabel ?taskName ;
          arch:partOf ?participant .
}

6. When to Use Which

Scenario Recommended profile
Building a BPMN modeller or execution engine Full
Round-tripping BPMN XML ↔ RDF ↔ BPMN XML Full
Validating BPMN models against the spec Full
Cross-model EA queries (BPMN + ArchiMate + C4) Lite
Populating an architecture knowledge graph from Camunda/jBPM exports Lite (thin lift)
Tracing business capabilities to process tasks Lite
Governance: "which processes handle PII data?" Lite
Academic research on BPMN semantics Full

Nothing prevents using both in the same graph — the lite classes carry skos:exactMatch links to the full ontology classes, so data can be promoted or demoted between profiles.

7. Linking BPMN to Other Notations

Cross-notation linking is handled outside the BPMN ontologies themselves. Available mechanisms:

Mechanism Example When to use
skos:exactMatch ex:bpmn_task skos:exactMatch ex:archi_service Equivalent concepts across notations
arch:partOf / arch:hasPart ex:task arch:partOf ex:capability Structural decomposition
arch:refines / arch:refinedInto ex:bpmn_process arch:refines ex:archi_bp Refinement across abstraction levels
Project-specific IDs ex:task ex:camundaId "proc-123" Tool integration
Cross-mapping extensions Dedicated bridge ontology Reusable organizational standard

The choice depends on the organization's integration strategy. Linked.Archi provides the building blocks; the organization owns the model.

8. File Inventory

BPMN Full (modelingLanguages/bpmn/)

File Content
bpmn-metamodel.ttl Metamodel manifest
bpmn-viewpoints.ttl 4 viewpoints
bpmn-deliverable-templates.ttl Deliverable templates
linkedarchi-bpmn-onto.ttl Core ontology (144 classes, 199 properties)
linkedarchi-bpmn-shacl.ttl SHACL shapes
linkedarchi-bpmn-infra-onto.ttl Infrastructure (Definitions, Import)
linkedarchi-bpmn-infra-shacl.ttl Infrastructure shapes
linkedarchi-bpmndi-onto.ttl BPMN Diagram Interchange
linkedarchi-bpmndi-shacl.ttl BPMNDI shapes
linkedarchi-di-onto.ttl DI abstract classes
linkedarchi-di-shacl.ttl DI shapes
linkedarchi-dc-onto.ttl DC datatypes (Bounds, Point, Font)
linkedarchi-dc-shacl.ttl DC shapes
linkedarchi-bpmn-suite-imports.ttl Import aggregator
linkedarchi-bpmn-suite-shapes.ttl Combined shapes

BPMN Lite (modelingLanguages/bpmn-lite/)

File Content
bpmn-lite-metamodel.ttl Metamodel manifest
linkedarchi-bpmn-lite-onto.ttl Lite ontology (29 classes, 10 properties)
linkedarchi-bpmn-lite-shacl.ttl SHACL shapes

9. References