Skip to content

Related Work: ArchiMEO Enterprise Ontology

1. Executive Summary

ArchiMEO and Linked.Archi are two independent projects that share the same foundational insight: enterprise architecture metamodels can be formalized as OWL ontologies to enable semantic interoperability, automated reasoning, and cross-domain integration. Despite this shared premise, they differ substantially in era, scope, architectural philosophy, and intended use. This report provides a detailed comparison of each ontology module, the overall strategy of each project, references to the published academic literature, and concludes with actionable recommendations for what Linked.Archi can adopt from ArchiMEO's approach and ontologies.

2. Project Origins and Academic Context

2.1 ArchiMEO

ArchiMEO was developed at FHNW (University of Applied Sciences Northwestern Switzerland) starting around 2010, primarily by Andreas Martin, Barbara Thönssen, Knut Hinkelmann, and collaborators including Roman Brun, Simon Nikles, Sandro Emmenegger, Emanuele Laurenzi, Devid Montecchiari, and Maja Spahic.

The name "ArchiMEO" indicates its foundation in ArchiMate ("Archi") plus its adaptation and enhancements to serve as a Meta Enterprise Ontology ("MEO") (MODELSWARD 2020, Section 4).

Key publications:

  • Hinkelmann et al. (2020) — ArchiMEO: A Standardized Enterprise Ontology based on the ArchiMate Conceptual Model, MODELSWARD 2020 (8th International Conference on Model-Driven Engineering and Software Development), pp. 417–424. DOI: 10.5220/0009000204170424. This is the primary reference paper describing the ontology structure, development methodology, and five application domain extensions.
  • Hinkelmann et al. (2016a) — A new paradigm for the continuous alignment of business and IT: Combining enterprise architecture modelling and enterprise ontology, Computers in Industry, 79:77–86. Describes the broader vision of integrating graphical EA models with ontologies.
  • Hinkelmann et al. (2018) — Ontology-based metamodeling, in Business Information Systems and Technology 4.0, pp. 177–194. Advances the concept of seamlessly integrating modeling languages and ontologies.
  • Martin (2016) — PhD thesis on ICEBERG (Interlinked Case-Based Reasoning), which uses ArchiMEO as its enterprise ontology foundation.
  • Hinkelmann et al. (2026) — Ontology-Based Validation of Enterprise Architecture Principles, Applied Sciences, 16(7):3352. The most recent paper extending ArchiMEO with SHACL/SPARQL-based automated compliance checking of EA principles.

ArchiMEO's stated goal is to serve as a "standardized Enterprise Ontology" providing a shared conceptualization for integrating heterogeneous enterprise data sources (MODELSWARD 2020, Section 1). It was validated through five applied research projects: contract management, supply-risk management, experience management (case-based reasoning), workplace learning, and Business Process as a Service (BPaaS) (MODELSWARD 2020, Section 5).

2.2 Linked.Archi

Linked.Archi is a more recent effort (2019+) by Kalin Maldzhanski. It is positioned as a platform and ecosystem for building architectural knowledge graphs, with a practitioner-oriented focus on modular composition, SPARQL queryability, AI-agent integration, and tooling.

Linked.Archi is organized as a three-layer ecosystem:

  1. meta.linked.archi — Shared ontologies and vocabularies (this repository)
  2. linked.archi — Platform tools and services (converters, generators, visualizers, MCP server)
  3. pub.linked.archi — Publications, guides, and case studies

The core thesis is stated explicitly: "An ontology is a DSL — a metamodel is a domain-specific language used to describe enterprise or IT architecture in a specific context." Unlike ArchiMEO, Linked.Archi does not position itself as an enterprise ontology but rather as a metamodel platform — it defines the language for expressing architecture, not the enterprise content itself.

3. Development Methodology

3.1 ArchiMEO's Approach

ArchiMEO followed the widely-used ontology development methodology described by Noy et al. (2001), as detailed in MODELSWARD 2020, Section 3:

  1. Competency questions were created as benchmarks — natural language questions that the ontology must be able to answer. The complete list is documented in Thönssen (2013).
  2. Practitioner interviews refined the extracted concepts. Interviewees proposed a holistic Enterprise Ontology covering multiple standards and architectures at a general level, with extensibility for company-specific domains.
  3. Existing ontology analysis — TOVE, The Enterprise Ontology, Context-Based Enterprise Ontology, CEO, and REA were analyzed but found to be proprietary with no evidence of practical use, making them unsuitable as standards.
  4. ArchiMate selection — Given its broad acceptance in practice, ArchiMate was chosen as the most suitable EA framework backbone.
  5. Standard ontology engineering steps — Enumerate terms, define classes and hierarchy, define properties and facets, create instances.

3.2 Linked.Archi's Approach

Linked.Archi follows a design-decision-driven approach documented in doc/guide/design-decisions.md, with 18 explicit design decisions (DD-1 through DD-18) plus conformance principles (P-1 through P-7) and ArchiMate-specific decisions (AM-DD-1, AM-DD-2) capturing rationale, trade-offs, and anti-patterns. The approach is more iterative and practitioner-driven, with emphasis on:

  • ISO 42010 alignment as the conceptual foundation
  • Modular ontology design with versioned IRIs
  • Separation of concerns (OWL for meaning, SHACL for validity)
  • PROV-O qualified relation pattern for relationship modeling
  • Continuous validation via SHACL shapes including principle shapes and viewpoint shapes

3.3 Comparison

ArchiMEO's methodology is more formally grounded in ontology engineering literature, with explicit competency questions and practitioner validation. Linked.Archi's approach is more agile and architecture-decision-oriented, with explicit design decisions but less formal evaluation methodology. ArchiMEO has the advantage of academic peer review and multi-project validation; Linked.Archi has the advantage of modern design patterns and broader tooling integration.

4. Module-by-Module Ontology Comparison

4.1 Upper/Top-Level Ontology

ArchiMEO: TOP (http://ikm-group.ch/archiMEO/top)

ArchiMEO includes a custom Top-Level Ontology with concrete domain concepts:

  • TopLevelElements — Root class (rdfs:subClassOf owl:Thing)
  • Location hierarchy: PhysicalLocation (City, Country, Continent, Street, PartOfCountry), LogicalLocation
  • Time hierarchy: TimePoint, TimeInterval, CalendarElement, TimeZone, TimeElement
  • Event hierarchy: ForceMajeureEvent → ActOfGod, MenMadeEvent
  • Geographic properties: cityIsLocatedInCountry, countryIsLocatedInContinent, partOfCountryBelongsToCountry

The TOP ontology also defines inverse properties (e.g., ContinentIncludesCountry / countryIsLocatedInContinent).

As stated in MODELSWARD 2020, Section 4: "ArchiMate does not provide general concepts, like location or time. Therefore, we introduced a Top-Level Ontology following Bertolazzi et al. (2001)."

Linked.Archi: No Upper Ontology

Linked.Archi deliberately has no upper ontology. It uses standard W3C vocabularies (SKOS, PROV-O, Dublin Core, Schema.org) and keeps the core minimal. The core-onto.ttl defines architecture-specific foundational concepts (ModelConcept, Element, QualifiedRelationship, View, Viewpoint, Model, Metamodel, System, Architecture) but does not model generic world concepts like time, location, or events.

Assessment

ArchiMEO's TOP ontology is useful for applications that need to reason about geographic and temporal context (e.g., supply-risk management where supplier locations matter). However, it mixes schema-level definitions with instance data (specific countries, cities) in the same ontology, which is an anti-pattern in modern ontology engineering. Linked.Archi's approach of deferring to standard vocabularies is cleaner but means users must bring their own upper ontology if needed.

4.2 Enterprise Objects / Core Ontology

ArchiMEO: EO (http://ikm-group.ch/archiMEO/eo)

The Enterprise Object ontology is the largest module (~2,769 lines) and serves as the integration hub. Key characteristics:

  • EnterpriseObject is the root class for all enterprise concepts (rdfs:subClassOf owl:Thing)
  • All ArchiMate core concepts (ActiveStructureElement, BehaviourElement, PassiveStructureElement, Service, Interface, Relationships) are subclasses of eo:EnterpriseObject
  • Extensive business domain content baked in:
  • Organizational roles: Employee, ManagerRole, ChiefOfficerRole (CEO, CFO, COO), DirectorsBoardRole, ExpertRole, ClerkRole
  • Business partners: Client, Customer, Supplier, Contractor, Consultant, Consumer, Influencer
  • Documents: ContractDocument, DocumentTemplate, Specification, Bid, Tender, RegulationDocument
  • Business events: FinancialBusinessEvent (Bankruptcy), LegalBusinessEvent, BusinessProcessEvent
  • Products: TangibleProduct, IntangibleProduct, Component
  • Calendar: CalendarDay1–31, CalendarMonth (January–December), CalendarWeekday, CalendarYear
  • Geography instances: Switzerland, Germany, Japan, Italy, specific cities (Ludwigshafen, Camerino, Tokio, Iwaki)
  • Natural disasters: Earthquake, Tsunami, Hurricane, Flood, Fire, VulcanicEruption (as instances of top:ActOfGod)
  • IT systems: DataBaseManagementSystem, EnterpriseResourcePlanningSystem, InformationManagementSystem, DocumentManagementTool
  • Data structures: DataSet, DataElement, IdentificationData, ContractDataSet
  • SWOT concepts: Strength, Weakness, Opportunity, Threat (as subclasses of bmm:AssessmentCategory)
  • Business model concepts: Channel, DistributionChannel, ValueProposition, RelationshipMechanism

The EO module also defines extensive properties linking behaviors to means, actors to locations, actions to tools, etc.

Linked.Archi: core-onto.ttl (https://meta.linked.archi/core#)

The core ontology (~1,336 lines) is focused exclusively on architecture description concepts:

  • ModelConcept — Base class for all concepts used in architecture models
  • Element — Nodes in models
  • QualifiedRelationship — First-class relationship resources with identity and metadata
  • View — Representations (Catalog, Matrix, Diagram)
  • Viewpoint — Specification for a kind of view
  • Model — Selective representation of a system
  • Metamodel — Definition of the modeling language (rdfs:subClassOf owl:Ontology)
  • Architecture — Abstract concept mapping to a System
  • System — Subject of interest
  • Framework — Architecture framework (rdfs:subClassOf schema:CreativeWork)
  • Stakeholder — First-class element (rdfs:subClassOf Element)
  • Concern, Aspect, Perspective — Considerations hierarchy
  • QualityAttribute, QualityMeasure — Quality modeling
  • Folder — UI/navigation container
  • Governance properties: conceptOwner, masterDataSource
  • Relationship properties: source, target, domainIncludes, rangeIncludes, unqualifiedForm

Assessment

The two approaches reflect fundamentally different design philosophies. ArchiMEO's EO is an enterprise ontology — it models the enterprise itself (people, places, products, events). Linked.Archi's core is a metamodel platform — it models the language for describing enterprises.

The Three Patterns in EO

The EO module is notable for mixing three fundamentally different modeling patterns in a single vocabulary:

Pattern 1 — Parent classes OF ArchiMate elements (upward extension). eo:EnterpriseObject is the root class that all ArchiMate core concepts inherit from (archi:ActiveStructureElement rdfs:subClassOf eo:EnterpriseObject). This makes EnterpriseObject the integration hub — everything in the enterprise is an EnterpriseObject, enabling cross-notation queries like "find all enterprise objects related to this supplier" regardless of whether the object came from ArchiMate, BPMN, or BMM.

Pattern 2 — Child classes OF ArchiMate elements (downward specialization). EO defines domain-specific specializations of ArchiMate elements: - eo:Person rdfs:subClassOf archi:BusinessActor — a person is a specific kind of business actor - eo:Client, eo:Customer, eo:Supplier rdfs:subClassOf eo:BusinessPartner rdfs:subClassOf archi:BusinessRole - eo:DataBaseManagementSystem rdfs:subClassOf archi:ApplicationService - eo:ContractDocument rdfs:subClassOf foaf:Document rdfs:subClassOf archi:Representation - eo:BusinessActivity rdfs:subClassOf archi:BusinessBehaviourElement (and then bpmn:Activity rdfs:subClassOf eo:BusinessActivity — bridging BPMN to ArchiMate)

This is the "enterprise vocabulary" layer — it takes the generic ArchiMate metamodel and makes it concrete for a specific enterprise context. A modeling tool can offer "Customer" instead of just "BusinessRole" in the palette.

Pattern 3 — Individuals (instances, not classes). EO also contains actual instance data mixed in with the class definitions: - Geographic instances: eo:Switzerland a top:Country, eo:Germany a top:Country, eo:Japan a top:Country - City instances: eo:Ludwigshafen a top:City, eo:Camerino a top:City - Natural disaster instances: eo:Earthquake a top:ActOfGod, eo:Tsunami a top:ActOfGod - Role instances (typed as their class, not as owl:Class): eo:ChiefExecutiveOfficerRole a eo:ChiefOfficerRole - Media type instances: eo:Image a dcmi-type-vocabulary:DCMITYPE - Legal instances: eo:SwissCodeOfObligations a nco:GeneralArchivingLaw

Why this mixture exists. ArchiMEO was designed for applied research projects (contract management, supply-risk management, experience management) where the ontology needed to be immediately usable with real enterprise data. The MODELSWARD 2020 paper (Section 4) describes this as a four-layer architecture: (1) Top-Level Ontology — generic world concepts, (2) Enterprise Upper Ontology — ArchiMate as OWL, (3) Meta Enterprise Ontology (ArchiMEO/EO) — domain specializations and enterprise vocabulary, (4) Application-Specific Ontology — project-specific extensions. The EO module is layer 3 — it bridges the abstract metamodel with real enterprise content. The individuals (countries, disasters, roles) are reference data that multiple application-specific ontologies can reuse. For example, the supply-risk management extension needed geographic locations to reason about supplier risk based on where suppliers are located.

The design tension. This works for a research group building integrated prototypes, but creates problems for a reusable ontology: 1. Schema and data mixed — class definitions and instance data in the same file makes it impossible to load just the schema without the reference data 2. Tight coupling — circular imports (EO imports ArchiMate, ArchiMate imports EO) mean you can't use ArchiMate without EO's entire enterprise vocabulary 3. Scope creep — calendar days (CalendarDay1–31 as separate OWL classes), timezone classes, and individual cities are domain data that doesn't belong in a metamodel 4. Inconsistent typing — some roles are classes (eo:ManagerRole a owl:Class) while others are individuals (eo:ChiefExecutiveOfficerRole a eo:ChiefOfficerRole), making it unclear whether you create instances of CEO or use the CEO individual directly

What Linked.Archi does differently. Linked.Archi keeps these layers strictly separated: the ontology (-onto.ttl) defines only the metamodel (classes and properties), the taxonomy (-tax.ttl) provides SKOS navigation (no OWL classes, no instances), domain-specific specializations go in separate modules (extensions/, frameworks/), and reference data (countries, roles, etc.) would go in instance data, not the ontology. No circular imports — each module imports core and extends it independently. This sacrifices immediate usability for modularity and clean separation.

4.3 ArchiMate Modeling Language

ArchiMEO: ARCHIMATE (http://ikm-group.ch/archiMEO/archimate)

Based on ArchiMate 2.1 (2013). Key characteristics:

  • Elements are OWL classes organized by ArchiMate core concepts:
  • ActiveStructureElement → BusinessActor, BusinessRole, ApplicationComponent, ApplicationCollaboration, Node, Device, CommunicationPath
  • BehaviourElement (labeled "Action") → BusinessProcess, BusinessFunction, BusinessInteraction, BusinessEvent, ApplicationFunction, ApplicationInteraction, InfrastructureFunction, SystemSoftware
  • PassiveStructureElement → BusinessObject, DataObject, Artifact, Contract, Meaning, Representation, Value, Product
  • Service → BusinessService, ApplicationService, InfrastructureService
  • Interface → BusinessInterface, ApplicationInterface, InfrastructureInterface
  • Relationships are modeled as both OWL classes AND ObjectProperties:
  • Classes: Relationships → StructuralRelationships (Access, Aggregation, Assignment, Association, Composition, Realisation, UsedBy), DynamicRelationships (Flow, Triggering), OtherRelationships (Grouping, Junction, Specialisation)
  • Properties: archi:accesses, archi:aggregates, archi:assignedTo, archi:associatedWith, archi:composedOf, archi:flowsTo, archi:realizes, archi:triggers, archi:usedBy, archi:specializes, archi:influence
  • All elements are subclasses of eo:EnterpriseObject, creating tight coupling to the EO module
  • Uses rdfs:domain and rdfs:range on properties (inference-triggering)
  • References ArchiMate 2.1 specification (OpenGroup 2009, 2013) in rdfs:comment annotations
  • Includes ISO 42010 integration via archi:LibraryViewpoint and viewpoint-related properties

Linked.Archi: archimate3.2 / archimate4.0 modules (https://meta.linked.archi/archimate3#)

Based on ArchiMate 3.2 and 4.0. Key characteristics:

  • Elements are OWL classes, all subclasses of :ArchimateElement (which extends arch:Element):
  • Full ArchiMate 3.2 coverage including Strategy layer (Resource, Capability, CourseOfAction), Motivation layer (Stakeholder, Driver, Assessment, Goal, Outcome, Principle, Requirement, Constraint, Meaning, Value), and Implementation & Migration elements
  • Each element carries: skos:definition, skos:scopeNote (detailed usage guidance from the spec), arch:prefVisNotation (SVG icon URL), arch:specURL (link to official spec section)
  • Relationships follow the three-part qualified pattern:
  • owl:ObjectProperty for direct graph traversal (e.g., am:serves)
  • arch:QualifiedRelationship subclass as first-class resource (e.g., am:Serving)
  • Qualified predicate for navigation (e.g., am:qualifiedServes) with rdf:reifies (RDF 1.2) bridging direct triple to resource
  • Uses arch:domainIncludes / arch:rangeIncludes instead of rdfs:domain / rdfs:range
  • Separate SHACL shapes files for validation (archimate3.2-element-shapes.ttl, archimate3.2-relationship-shapes.ttl, archimate3.2-principle-shapes.ttl, archimate3.2-viewpoint-shapes.ttl)
  • Separate SKOS taxonomy (archimate3-tax.ttl) for classification by layer and aspect, with skos:altLabel, skos:scopeNote, skos:changeNote, skos:editorialNote on taxonomy concepts
  • Derivation rules (archimate3.2-derivation-rules.ttl) for derived relationships
  • Relationship validity matrix generated from the official ArchiMate XML matrix

Assessment

The most significant differences:

Dimension ArchiMEO Linked.Archi
ArchiMate version 2.1 (2013) 3.2 and 4.0
Missing elements Strategy layer, Implementation & Migration, many Motivation elements Full coverage
Relationship modeling Dual class+property, loosely typed Three-part qualified pattern with RDF 1.2
Domain/range rdfs:domain/rdfs:range (inference) domainIncludes/rangeIncludes (guidance)
Validation None in ontology SHACL shapes with relationship validity matrix
Taxonomy OWL class hierarchy only OWL class hierarchy (semantics) + SKOS concept scheme (navigation), linked via rdfs:seeAlso
Documentation rdfs:comment with spec quotes skos:definition + skos:scopeNote + spec URLs
Taxonomy annotations rdfs:comment skos:altLabel, skos:scopeNote, skos:changeNote, skos:editorialNote
ArchiMate 4.0 Not applicable Draft available
Visual notation Not modeled arch:prefVisNotation SVG references

4.4 ISO 42010 Alignment

ArchiMEO: ISO42010 (http://ikm-group.ch/archimeo/iso42010)

A dedicated module with 12 classes and 17 object properties:

  • Classes: ADMetaModel (grouping root), Architecture, ArchitectureDescription, ArchitectureModel, ArchitectureRationale, ArchitectureView, ArchitectureViewpoint, Concern, Correspondence, CorrespondenceRule, ModelKind, Stakeholder, System-of-Interest
  • Properties use verbose naming: architectureDescriptionExpressesArchitecture, architectureViewpointGovernsArchitectureView, stakeholderHasConcern, etc.
  • All classes are subclasses of iso42010:ADMetaModel (which extends owl:Thing)
  • Rich rdfs:comment annotations quoting directly from the ISO 42010 conceptual model website
  • Standalone module — not tightly integrated with the ArchiMate module

Linked.Archi: Integrated in core-onto.ttl

ISO 42010 concepts are integrated directly into the core ontology rather than as a separate module:

ISO 42010 Concept Linked.Archi Class Notes
System-of-Interest arch:System Simplified name
Architecture arch:Architecture Abstract concept
Architecture Description arch:Model More general term
Architecture Viewpoint arch:Viewpoint Direct mapping
Architecture View arch:View (+ Catalog, Matrix, Diagram) Specialized subtypes
Stakeholder arch:Stakeholder Also subclass of Element
Concern arch:Concern Under Consideration hierarchy
Model Kind arch:Metamodel Extended to rdfs:subClassOf owl:Ontology
Architecture Rationale Not explicit class Handled via ad:justification in decisions module
Correspondence Not modeled Gap
Correspondence Rule Not modeled Gap — could map to SHACL shapes

Assessment

ArchiMEO's ISO 42010 module is more complete and faithful to the standard, including Correspondence and CorrespondenceRule which Linked.Archi lacks. However, ArchiMEO's module is somewhat isolated — the classes are not deeply integrated with the ArchiMate module. Linked.Archi's integration approach is more practical (concepts are directly usable in the core) but sacrifices completeness.

4.5 Business Motivation Model (BMM)

ArchiMEO: BMM (http://ikm-group.ch/archiMEO/BMM)

A dedicated module implementing the OMG Business Motivation Model standard:

  • MotivationElement — Root class for BMM concepts
  • End hierarchy: Vision, DesiredResult → Goal, Objective
  • Means hierarchy: Mission, CourseOfAction → Strategy, Tactic; Directive → BusinessPolicy, BusinessRule
  • Assessment, PotentialImpact → PotentialReward, Risk
  • Asset — Resources available to the enterprise
  • Supporting categories: InfluencerCategory, AssessmentCategory, OrganizationCategory
  • All classes carry rdfs:comment annotations quoting the OMG BMM specification (OMG 2007)

Linked.Archi: No BMM Module

Linked.Archi does not have a dedicated BMM module. Some BMM concepts are partially covered: - ArchiMate Motivation layer elements (Goal, Outcome, Principle, Requirement, Constraint, Driver, Assessment, Stakeholder) in the ArchiMate ontology - Architecture Decision ontology (archDecision.ttl) covers Force, Requirement, Constraint, Policy, Principle - But no explicit BMM concepts like Vision, Mission, Strategy, Tactic, BusinessPolicy, BusinessRule, Asset

Assessment

ArchiMEO's BMM module provides a formal bridge between business motivation and architecture. This is valuable for organizations using BMM alongside ArchiMate. Linked.Archi partially covers this through ArchiMate's Motivation layer and the decisions ontology, but lacks the explicit BMM standard mapping.

4.6 BPMN

ArchiMEO: BPMN (http://ikm-group.ch/archiMEO/BPMN)

A focused module covering BPMN 2.0 core constructs:

  • FlowElement hierarchy: FlowNode → Activity → Task (UserTask, ServiceTask, ManualTask, ScriptTask, SendTask, ReceiveTask, BusinessRuleTask), SubProcess, CallActivity
  • Event hierarchy: StartEvent (ConditionalStartEvent, MessageStartEvent, TimerStartEvent), IntermediateEvent (various types), EndEvent (ErrorEndEvent, MessageEndEvent, TerminateEndEvent)
  • Gateway hierarchy: ExclusiveGateway, InclusiveGateway, ParallelGateway
  • Participant hierarchy: Pool, Lane
  • Flow types: SequenceFlow, MessageFlow, DataAssociation, Association
  • Data: Data class
  • Annotations: Annotation, Group
  • Cross-ontology integration: bpmn:Activity rdfs:subClassOf eo:BusinessActivity, bpmn:Gateway rdfs:subClassOf archi:Junction, bpmn:SequenceFlow rdfs:subClassOf archi:Triggering, bpmn:MessageFlow rdfs:subClassOf archi:Flow
  • Bridge property: bpmn:bpmnProcessRepresentsBusinessProcess linking BPMN Process to ArchiMate BusinessProcess

Linked.Archi: BPMN 2.0.2 Suite (16 files)

A comprehensive modular suite derived from the BPMN 2.0.2 XMI specification, validated against the official OMG normative artifacts (Semantic.xsd, BPMNDI.xsd, DI.xsd, DC.xsd, Infrastructure.cmof):

  • bpmn-metamodel.ttl — Metamodel manifest tying all modules together
  • bpmn-viewpoints.ttl — 4 viewpoints (Process, Collaboration, Choreography, Conversation)
  • bpmn-deliverable-templates.ttl — Deliverable templates
  • linkedarchi-bpmn-onto.ttl — Core BPMN ontology (130+ classes, 150+ properties)
  • linkedarchi-bpmn-shacl.ttl — SHACL validation shapes
  • linkedarchi-bpmn-infra-onto.ttl — Infrastructure/foundation classes (Definitions, Import)
  • linkedarchi-bpmn-infra-shacl.ttl — Infrastructure shapes
  • linkedarchi-bpmndi-onto.ttl — BPMN Diagram Interchange
  • linkedarchi-bpmndi-shacl.ttl — DI shapes
  • linkedarchi-dc-onto.ttl — DC (Diagram Common) ontology
  • linkedarchi-dc-shacl.ttl — DC shapes
  • linkedarchi-di-onto.ttl — DI (Diagram Interchange) ontology
  • linkedarchi-di-shacl.ttl — DI shapes
  • linkedarchi-bpmn-suite-alignment.ttl — Alignment with Linked.Archi core
  • linkedarchi-bpmn-suite-imports.ttl — Import aggregation
  • linkedarchi-bpmn-suite-shapes.ttl — Suite-level shapes

Assessment

Dimension ArchiMEO BPMN Linked.Archi BPMN
Classes 45 (core process modeling subset) 144 (full BPMN 2.0.2 metamodel)
Properties 1 (bpmnProcessRepresentsBusinessProcess) 150+ (all attributes/associations from XMI)
Spec coverage BPMN 2.0 core (tasks, events, gateways, flows) Full BPMN 2.0.2 including Choreography, Conversation, Correlation, Data, Infrastructure
Diagram Interchange Not covered Full BPMNDI/DI/DC stack (6 classes, geometry properties)
Validation None SHACL shapes per module
Spec fidelity Selective — adds event subtypes not in the metamodel (e.g., TimerStartEvent) Strict — 1:1 with XSD/CMOF, validated against normative artifacts
Cross-notation integration Direct subclass axioms to ArchiMate/EO Separate alignment file (suite-alignment.ttl) mapping to arch:Element
Hierarchy root emo:BPMN_MetaModel (enterprise model layer) bpmn:BaseElement (spec-native)

Key differences in modeling approach:

  1. ArchiMEO flattens event types into concrete subclasses (TimerStartEvent, MessageEndEvent, etc.) — a convenience for tooling but not how the BPMN metamodel works. The spec uses composition: StartEvent + TimerEventDefinition, not inheritance. Linked.Archi follows the spec's compositional pattern in the full suite, and also provides a simplified profile (BPMN Lite) that uses a flat eventType property — a designer choice depending on the use case.

For example, the Nobel Prize Process from the BPMN 2.0.2 examples defines a timer-triggered start event:

<!-- BPMN 2.0.2 XML (from .reference/omg/bpmn202/2010-06-03/Nobel Prize/) -->
<startEvent name="September Year n-1" id="_6-84">
    <timerEventDefinition>
        <timeDate/>
    </timerEventDefinition>
</startEvent>

ArchiMEO models this as a single typed instance:

# ArchiMEO approach — flattened subclass
ex:sept_start a bpmn:TimerStartEvent ;
    rdfs:label "September Year n-1" .

Linked.Archi full suite models it as composition, mirroring the XML structure:

# Linked.Archi full BPMN — compositional (spec-native)
ex:sept_start a bpmn:StartEvent ;
    bpmn:name "September Year n-1" ;
    bpmn:eventDefinitions ex:sept_start_timer .

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

Linked.Archi BPMN Lite uses a flat property, trading spec fidelity for simplicity:

# Linked.Archi BPMN Lite — simplified for EA reasoning
ex:sept_start a bpmnl:StartEvent ;
    arch:name "September Year n-1" ;
    bpmnl:eventType "timer" .

The compositional pattern supports events with multiple triggers (e.g., a start event with both a timer and a signal definition) without requiring combinatorial subclass explosion. The flat pattern produces fewer triples and is simpler to query at the EA level. Both are available; the choice depends on whether the use case requires full BPMN round-tripping or cross-model reasoning.

This reflects a broader point: BPMN is execution-oriented and much denser than ArchiMate. A faithful 1:1 lift of every BPMN-XML element creates many triples whose semantic value at EA level is near zero — pool/lane geometry, sequence flow waypoints, marker styles. If the goal is just rendering BPMN diagrams, RDF buys nothing over the native XML. The value materializes when you intend to query, validate, or reason across BPMN and other models. A "thin lift" converts only the BPMN constructs that have analogues in ArchiMate (Process, Task, Lane/Participant, DataObject, MessageFlow, Event) and leaves layout/notation in the original .bpmn file referenced by URI.

  1. ArchiMEO bridges directly to ArchiMate via rdfs:subClassOf (Gateway → archi:Junction, SequenceFlow → archi:Triggering, MessageFlow → archi:Flow). This enables cross-notation reasoning but couples the BPMN ontology to ArchiMate. Linked.Archi keeps the BPMN ontology spec-pure and handles cross-notation alignment in a separate file. In practice, cross-notation linking in Linked.Archi is handled through multiple mechanisms depending on context: skos:exactMatch between equivalent elements, arch:partOf/arch:hasPart or arch:refines/arch:refinedInto for structural relationships, project-specific identifier properties (e.g., leanixId, bpmnId, archimateId), or dedicated cross-mapping extension modules.

  2. ArchiMEO introduces non-spec classes (FlowObject, FlowElementContainer, Pool, Data, Annotation) that don't exist in the BPMN 2.0.2 metamodel or use different names. Linked.Archi uses the exact spec names (FlowElementsContainer, Participant, DataObject, TextAnnotation).

  3. ArchiMEO models Lane rdfs:subClassOf Participant — treating lanes as a specialization of participants. The BPMN 2.0.2 XSD/CMOF defines Lane as a partition owned by a LaneSet (itself owned by a Process), not as a Participant subtype. Linked.Archi follows the XSD structure with Lane rdfs:subClassOf BaseElement. Both are valid design choices; ArchiMEO's reflects a user-facing simplification, Linked.Archi's reflects spec fidelity.

  4. Coverage gap: ArchiMEO omits Choreography (8 classes), Conversation (5 classes), Correlation (5 classes), all loop characteristics, all data I/O specifications, all resource/performer classes, and the entire extension mechanism. Linked.Archi covers all of these.

On cross-notation integration: Cross-notation bridging reflects a fundamental architectural decision: whether to convert source artifacts into standard notation-specific ontologies (BPMN, ArchiMate, C4, etc.) and then map between them, or to convert directly into a tailored organisation-specific metamodel that unifies concepts at ingest time. The first approach preserves notation fidelity and requires explicit cross-mappings (whether via skos:exactMatch, arch:partOf/arch:refines, project-specific identifier properties, or dedicated extension modules). The second collapses all notations into a single domain vocabulary — simpler to query but harder to trace back to source semantics. ArchiMEO leans toward the second pattern (BPMN elements are subclasses of ArchiMate/EO concepts from the start). Linked.Archi provides a repository of domain-specific modeling language and framework standards as a bootstrap, but strongly promotes tailoring and owning an organisation-specific model — the standard ontologies serve as reusable building blocks, not as the final target schema.

4.7 Enterprise Model Ontology (EMO)

ArchiMEO: EMO (http://ikm-group.ch/archiMEO/emo)

The EMO module (~1,085 lines) serves as the integration layer between model types and enterprise objects:

  • BusinessMetaModel — Root class for all metamodel types
  • BPMN_MetaModel, BusinessMotivationMetaModel, CaseManagementMetaModel, DocumentMetaModel, OrganisationMetaModel
  • Aspect and Perspective — Classification dimensions for enterprise objects
  • Extensive "ConsistsOf" properties linking model types to their constituent elements (e.g., ArchimateConsistsOfBusinessProcess, BPMNConsistsOfTask, BMMConsistsOfGoal)
  • "BelongsTo" properties linking model types to aspects and perspectives (with Leo and N suffixes for different classification schemes)
  • modelTypeConsistsOfEnterpriseObject — Generic property for model-to-element composition
  • aspectCoversObject — Links aspects to enterprise objects

Linked.Archi: No EMO Equivalent

Linked.Archi does not have an explicit model-type-to-element mapping layer. Instead: - The arch:Metamodel class (subclass of owl:Ontology) serves as the modeling language definition - owl:imports provides composition - SKOS taxonomies provide classification by layer and aspect - The relationship between models and their elements is implicit through RDF graph membership

Assessment

ArchiMEO's EMO provides explicit, queryable mappings between model types and their constituent elements. This is valuable for answering questions like "What elements can appear in a BPMN model?" or "Which model types cover the application architecture aspect?" Linked.Archi handles this implicitly through ontology imports and SHACL shapes, which is less explicit but more maintainable.

4.8 Non-Categorized Objects (NCO)

ArchiMEO: NCO (http://ikm-group.ch/archiMEO/nco)

A utility module for concepts that don't fit elsewhere:

  • NCO — Root class
  • Authority — RACI responsibility concept
  • Category — Generic categorization
  • Language — Natural languages
  • LawAndRegulation → DataProtectionAct, GeneralArchivingLaw, ProductLiability
  • SpecificationStandard → GICS_Code

Linked.Archi: No NCO Equivalent

Linked.Archi uses standard vocabularies (Dublin Core, Schema.org) for metadata and does not model laws, regulations, or specification standards as ontology classes.

4.9 Utility Module (UTIL)

ArchiMEO: UTIL (http://ikm-group.ch/archiMEO/util)

A module providing:

  • Process control constructs from the OntoGov project: AtomicBusinessProcess, CompositBusinessProcess, ProcessControlConstruct (Join, Sequence, Split, Switch)
  • Document metadata properties — Extensive Dublin Core property wrappers: documentHasCreator, documentHasContributor, documentHasDate, documentHasFormat, documentHasLanguage, etc.
  • DCMI Type Vocabulary and MIME Type classes
  • FOAF Document integration — foaf:Document rdfs:subClassOf archi:Representation
  • Person properties — personHasFirstName, personHasFamilyName

Linked.Archi: No UTIL Equivalent

Linked.Archi uses Dublin Core and Schema.org properties directly without wrapping them in custom properties.

4.10 Architecture Decisions

ArchiMEO: No Dedicated Module

ArchiMEO does not have a dedicated architecture decision module. The ISO 42010 module includes ArchitectureRationale as a class, but there is no formal decision modeling framework.

Linked.Archi: archDecision.ttl (https://meta.linked.archi/arch-decision#)

A rich architecture decision ontology:

  • Decision — Core class (rdfs:subClassOf arch:Element)
  • Issue — Problem requiring a decision
  • Option — Alternative for a decision
  • Force hierarchy — Influences on decisions:
  • Principle, Requirement (FunctionalRequirement, QualityAttributeRequirement), Trend, PersonalPreference, Constraint (TechnicalConstraint, BusinessConstraint), Policy
  • ForceInfluence — Qualified relationship for force-to-decision influence (ImpendingInfluence, SupportingInfluence)
  • DecisionState — Lifecycle state
  • Impact, Iteration — Supporting concepts
  • Rich property set: hasIssue/hasDecision, hasSelectedOption/hasAlternative, influencedByForce, addressesForce, opposingForce/complementaryForce, justification, relatedDecision (causedBy, dependsOn, replaces, conflictsWith)
  • Quality Attribute Scenario properties: qasSourceOfStimulus, qasStimulus, qasEnvironment, qasArtifact, qasResponse, qasResponseMeasure
  • Integration with reference architecture: appliedInOption links tactics/patterns to options

Assessment

This is a significant gap in ArchiMEO. Linked.Archi's decision ontology is one of its strongest differentiators, providing formal modeling of the decision process that ArchiMEO lacks entirely.

5. Overall Strategy Comparison

5.1 Philosophical Orientation

Dimension ArchiMEO Linked.Archi
Self-description "Standardized Enterprise Ontology" "Ecosystem for architectural knowledge graphs"
Primary purpose Data integration across heterogeneous enterprise sources Metamodel platform for architecture modeling and querying
Scope Enterprise content + metamodel Metamodel + tooling platform
Target user Researchers, enterprise integrators Practicing architects, AI agents
Validation approach Academic (competency questions, prototypes, publications) Practitioner-driven (design decisions, tooling)

5.2 Ontological Design Patterns

Pattern ArchiMEO Linked.Archi
OWL profile Full OWL DL with reasoning Minimal OWL profile
Closed-world constraints OWL axioms + SPIN rules (later SHACL) SHACL from the start
Relationship modeling Dual class + property Three-part qualified pattern (PROV-O)
Classification OWL class hierarchies OWL class hierarchy (rdfs:subClassOf for semantics) + SKOS concept schemes (for navigation, with altLabels, scopeNotes, changeNotes, editorialNotes)
Domain/range rdfs:domain/rdfs:range (inference) domainIncludes/rangeIncludes (guidance)
Punning Used (relationship types as both class and property) Explicitly avoided (DD-4 and P-5)
Reification Not used RDF 1.2 rdf:reifies
Provenance Not modeled PROV-O integration
Namespace strategy http://ikm-group.ch/archiMEO/ (unversioned) https://meta.linked.archi/ (versioned IRIs)

5.3 Integration Strategy

ArchiMEO integrates modeling languages by making their concepts subclasses of a shared EnterpriseObject hierarchy. For example, archi:BehaviourElement rdfs:subClassOf eo:EnterpriseObject and bpmn:Activity rdfs:subClassOf eo:BusinessActivity rdfs:subClassOf archi:BusinessBehaviourElement. This creates a single unified class hierarchy where cross-notation queries are natural.

Linked.Archi integrates modeling languages through a shared core ontology (arch:Element, arch:QualifiedRelationship) with separate alignment modules. Each modeling language ontology imports the core and extends it independently. Cross-notation integration is achieved through SPARQL queries over the shared graph rather than through class hierarchy unification.

5.4 Extensibility Model

ArchiMEO's extensibility is described in MODELSWARD 2020, Section 4: the ontology is structured into four layers — Top-Level Ontology, Enterprise Upper Ontology (ArchiMate), Meta Enterprise Ontology (ArchiMEO), and Application-Specific Ontology. Extensions are created by adding domain-specific concepts as subclasses of existing ArchiMEO classes.

Linked.Archi's extensibility is based on modular ontology composition via owl:imports. New modeling languages or domain extensions are separate ontologies that import the core and define their own class hierarchies. This is more loosely coupled but requires explicit alignment work.

5.5 Semantic Lifting

Both projects support "semantic lifting" — transforming graphical models into ontology instances. ArchiMEO describes this in MODELSWARD 2020, Section 6: "the representation of the ArchiMate metamodel as an ontology allows for semantic lifting of ArchiMate models... Because of this 1:1 correspondence of language constructs and ontology concepts, an architecture model can be transformed into an ontology."

Linked.Archi implements this through a toolbox of converters (ArchiMate Exchange XML → RDF, BPMN 2.0.2 XML → RDF, PlantUML → RDF) that produce three named graphs: semantic, views, and provenance (DD-13).

5.6 Reasoning and Querying

ArchiMEO emphasizes OWL reasoning and inference rules. The supply-risk management extension (MODELSWARD 2020, Section 5.2) used semantic rules fired against extended ArchiMEO concepts for risk assessment. The workplace learning extension (Section 5.4) used semantic rules for recommendation purposes.

Linked.Archi emphasizes SPARQL querying and SHACL validation over OWL reasoning. The design explicitly minimizes the OWL profile to avoid reasoning complexity, preferring explicit SHACL constraints for governance.

6. Strengths and Weaknesses

6.1 ArchiMEO Strengths

  1. Academic rigor — Peer-reviewed publications, formal competency questions, multi-project validation
  2. Rich enterprise domain coverage — Organizational roles, business events, documents, geography, calendar — immediately usable for enterprise applications
  3. Cross-notation integration — Unified class hierarchy enables natural cross-notation reasoning
  4. Proven application domains — Contract management, supply-risk, experience management, workplace learning, BPaaS
  5. BMM integration — Formal bridge between business motivation and architecture
  6. Semantic lifting pipeline — Demonstrated 1:1 correspondence for model transformation
  7. Continued evolution — The 2026 principle validation paper shows active development with modern SHACL adoption

6.2 ArchiMEO Weaknesses

  1. Outdated ArchiMate version — Based on 2.1 (2013), missing Strategy layer, Implementation & Migration, and many current elements
  2. Monolithic coupling — Circular imports between modules (EO imports ArchiMate, ArchiMate imports EO) make selective adoption difficult
  3. Instance data in schema — Geographic instances (countries, cities, disasters) mixed with class definitions
  4. No validation layer — No SHACL shapes for constraint validation (until the 2026 extension)
  5. Verbose property naming — Properties like architectureDescriptionExpressesArchitecture are unwieldy
  6. No visual notation modeling — No support for diagram interchange or visual representation metadata
  7. No provenance model — No PROV-O integration for tracking data lineage
  8. Unversioned namespaces — http://ikm-group.ch/archiMEO/ makes version management difficult
  9. No relationship validity constraints — No formal specification of which ArchiMate relationships are valid between which elements

6.3 Linked.Archi Strengths

  1. Modern ArchiMate 3.2 + 4.0 coverage — Full element and relationship coverage with validity matrix
  2. Clean separation of concerns — OWL for semantics (class hierarchy for aspect/layer), SKOS for navigation (taxonomy for UI), SHACL for validation, predicates vs relationship resources
  3. Rich taxonomy annotations — altLabels, scopeNotes, changeNotes, editorialNotes on both 3.2 and 4.0 taxonomies
  4. Modular architecture — Independently publishable ontologies with versioned IRIs
  5. Rich tooling ecosystem — Converters, generators, MCP server for AI agents
  6. PROV-O integration — Provenance tracking for data lineage
  7. RDF 1.2 support — Modern reification via rdf:reifies
  8. Comprehensive BPMN — Full XMI-derived mapping including diagram interchange
  9. Architecture decisions — Rich decision modeling ontology
  10. Multiple modeling languages — C4, Backstage, LeanIX, BMC, BPMN in addition to ArchiMate
  11. SHACL-first validation — Closed-world constraints from the start
  12. Principle-based validation — 20 SHACL shapes for architecture governance principles
  13. Viewpoint validation — SHACL shapes for viewpoint conformance
  14. Specialization via rdfs:subClassOf — Cross-language composition without dedicated profile mechanism (AM-DD-2)

6.4 Linked.Archi Weaknesses

  1. No formal evaluation methodology — No published competency questions or academic validation
  2. No upper ontology — Users must bring their own time, location, event concepts
  3. No BMM module — Missing formal business motivation modeling
  4. No enterprise domain content — No organizational roles, business events, or document types
  5. No cross-notation class hierarchy — Integration relies on SPARQL rather than unified hierarchy
  6. No case-based reasoning integration — No CBR framework for experience management
  7. Limited ISO 42010 coverage — Missing Correspondence and CorrespondenceRule
  8. Draft status — Some modules still in draft

7. What Linked.Archi Can Adopt from ArchiMEO

This section identifies specific concepts, patterns, and approaches from ArchiMEO that could strengthen Linked.Archi, organized by priority and feasibility.

7.1 High Priority — Ontology Enhancements

7.1.1 ISO 42010 Correspondence and CorrespondenceRule

ArchiMEO's ISO 42010 module includes Correspondence and CorrespondenceRule classes that Linked.Archi currently lacks. These are valuable for:

  • Expressing cross-view consistency constraints (e.g., "every ApplicationComponent in the application view must have a corresponding Node in the technology view")
  • Formalizing architecture governance rules
  • Mapping naturally to SHACL shapes — a CorrespondenceRule could be implemented as a SHACL NodeShape that validates cross-view consistency

Recommendation: Add arch:Correspondence and arch:CorrespondenceRule to the core ontology. CorrespondenceRule could be aligned with or implemented via SHACL shapes, creating a formal bridge between ISO 42010 governance concepts and the existing validation infrastructure.

7.1.2 Business Motivation Model (BMM) Module

ArchiMEO's BMM module provides concepts not covered by ArchiMate's Motivation layer:

  • Vision and Mission — Strategic direction concepts
  • Strategy and Tactic — Course of action decomposition (ArchiMate has CourseOfAction but not the BMM decomposition)
  • BusinessPolicy and BusinessRule — Governance directives
  • Asset — Enterprise resources (broader than ArchiMate's Resource)
  • PotentialImpact → PotentialReward, Risk — Impact assessment

Recommendation: Create a frameworks/bmm/ module that maps BMM concepts to the Linked.Archi core, similar to how TOGAF is handled. This would complement the existing ArchiMate Motivation layer and the architecture decisions ontology. The BMM module should use SKOS for classification and arch:domainIncludes/rangeIncludes for property guidance, following Linked.Archi conventions.

7.1.3 Cross-Notation Alignment Properties

ArchiMEO's approach of making BPMN elements subclasses of ArchiMate concepts (e.g., bpmn:Gateway rdfs:subClassOf archi:Junction, bpmn:SequenceFlow rdfs:subClassOf archi:Triggering) enables cross-notation reasoning. While Linked.Archi has a BPMN alignment file (linkedarchi-bpmn-suite-alignment.ttl), the pattern could be extended.

Recommendation: Strengthen the alignment modules between modeling languages. For each modeling language, provide explicit rdfs:subClassOf, skos:closeMatch, or skos:exactMatch mappings to ArchiMate concepts where applicable. This enables queries like "find all behavioral elements across ArchiMate and BPMN models."

7.2 Medium Priority — Approach and Methodology

7.2.1 Competency Questions as Validation Framework

ArchiMEO's use of competency questions (Grüninger and Fox, 1995) as formal benchmarks for ontology completeness and appropriateness is a well-established ontology engineering practice that Linked.Archi could adopt.

Recommendation: Define a set of competency questions for each Linked.Archi module. For example: - Core: "What viewpoints address a given stakeholder's concerns?" - ArchiMate: "Which application services serve a given business process?" - Decisions: "What forces influenced a specific architecture decision?" - Quality: "Which quality attributes are affected by a given tactic?"

Document these in the module documentation and use them as regression tests (SPARQL queries that must return results against test data).

7.2.2 Semantic Lifting Patterns from Applied Research

ArchiMEO's five application domains (MODELSWARD 2020, Section 5) provide proven patterns for extending the ontology:

  1. Contract management — Automatic metadata extraction from documents, linking to enterprise events (bankruptcy triggers contract review). Pattern: external event monitoring → ontology reasoning → automated alerts.

  2. Supply-risk management — Semantic Risk Model with RiskEvent, RiskIndicator, CrisisPhase, WarningSignal. Pattern: bottom-up risk aggregation from atomic indicators using inference rules.

  3. Experience management (ICEBERG) — Ontology-based case-based reasoning using ISO 42010 viewpoints to provide stakeholder-specific case retrieval. Pattern: CBR system using enterprise ontology for case indexing and retrieval.

  4. Workplace learning — Competency profiles, learning preferences, and recommendation system. Pattern: ontology-based recommendation using competency matching.

  5. BPaaS — Aligning business requirements (BPMN) with cloud offerings using semantic matching. Pattern: ontology-based questionnaire for requirements elicitation.

Recommendation: Document these patterns as reference use cases in the Linked.Archi documentation. While the specific implementations are ArchiMEO-specific, the patterns are transferable. The supply-risk and contract management patterns are particularly relevant for Linked.Archi's governance and impact analysis use cases.

7.2.3 Ontology-Based Principle Validation (2026 Paper)

The most recent ArchiMEO paper (Hinkelmann et al., 2026) describes a systematic approach to validating EA principles against EA models using SHACL and SPARQL. This directly aligns with Linked.Archi's SHACL-first approach.

Recommendation: This pattern has been adopted in Linked.Archi. The archimate3.2-principle-shapes.ttl file implements 20 SHACL shapes for architecture governance principles including redundancy avoidance, single source of truth, stewardship, separation of concerns, service orientation, completeness, and motivation alignment. Inspired by Montecchiari & Hinkelmann (2026).

7.3 Lower Priority — Domain Extensions

7.3.1 Enterprise Domain Vocabulary (Selective)

ArchiMEO's EO module contains useful enterprise domain concepts that could be offered as an optional extension:

  • Organizational roles — A SKOS concept scheme for common organizational roles (CEO, CFO, COO, ProjectLead, SoftwareArchitect, etc.) would be useful for stakeholder classification
  • Document types — ContractDocument, Specification, Tender, Bid as subclasses of a Document concept
  • Business event types — FinancialBusinessEvent, LegalBusinessEvent for event-driven architecture modeling
  • SWOT concepts — Strength, Weakness, Opportunity, Threat as a classification scheme

Recommendation: Create an optional extensions/enterprise-vocabulary/ module with SKOS concept schemes for organizational roles, document types, and business event types. Keep these as SKOS individuals (not OWL classes) to maintain the Linked.Archi design principle of separating classification from formal semantics.

7.3.2 Model-Type-to-Element Mapping (EMO Pattern)

ArchiMEO's EMO module provides explicit mappings between model types and their constituent elements. While verbose, this pattern enables useful queries.

Recommendation: Rather than replicating the EMO pattern directly, leverage SHACL shapes to define what elements are valid in each model type. This achieves the same queryability while maintaining the SHACL-first approach. For example, a SHACL shape for "ArchiMate Application Cooperation View" would constrain which element types can appear.

7.3.3 Process Control Constructs

ArchiMEO's UTIL module includes process control constructs (Sequence, Split, Join, Switch) from the OntoGov project. These are useful for formal process modeling beyond BPMN's graphical notation.

Recommendation: Consider adding process control constructs to the BPMN alignment module or as a separate process-patterns extension, particularly if Linked.Archi aims to support process analysis and optimization use cases.

7.4 Approach-Level Recommendations

7.4.1 Publish Competency Questions and Evaluation Results

ArchiMEO's academic validation provides credibility. Linked.Archi should: - Define and publish competency questions for each module - Create SPARQL query tests that validate these questions against example data - Document evaluation results from real-world usage

7.4.2 Formalize the Extension Methodology

ArchiMEO's four-layer structure (Top-Level → Enterprise Upper → ArchiMEO → Application-Specific) provides a clear extension methodology. Linked.Archi should document a similar methodology: 1. Core ontology (fixed foundation) 2. Modeling language ontologies (standard mappings) 3. Framework ontologies (framework-specific extensions) 4. Organization-specific ontologies (custom extensions)

With clear guidelines for which layer new concepts belong to.

7.4.3 Cross-Notation Reasoning Patterns

ArchiMEO demonstrates that cross-notation reasoning (e.g., linking BPMN processes to ArchiMate business processes) is one of the highest-value capabilities of an enterprise ontology. Linked.Archi should: - Strengthen alignment modules between all modeling languages - Provide example SPARQL queries that demonstrate cross-notation analysis - Document the alignment patterns in the usage guide

8. Summary Comparison Matrix

Dimension ArchiMEO Linked.Archi
Origin FHNW, Switzerland (2010–present) Independent (2019–present)
License CC BY-SA 3.0 CC BY 4.0
ArchiMate version 2.1 3.2
Namespace http://ikm-group.ch/archiMEO/ https://meta.linked.archi/
Upper ontology Custom (TOP) None (uses standard vocabs)
Enterprise objects Rich (EO, ~2,769 lines) Minimal (core only)
ISO 42010 Dedicated module (complete) Integrated in core (partial)
BMM Dedicated module Not covered
BPMN Core constructs Full XMI mapping + DI
ArchiMate elements 2.1 subset Full 3.2 and 4.0
Relationship modeling Class + property dual Three-part qualified (PROV-O)
Validation OWL reasoning (later SHACL) SHACL from the start (relationship, element, principle, viewpoint shapes)
Taxonomy OWL class hierarchy OWL class hierarchy + SKOS (altLabels, scopeNotes, changeNotes, editorialNotes)
Provenance Not modeled PROV-O
Visual notation Not modeled SVG references
Architecture decisions Not covered Rich ontology
Quality attributes Not covered Dedicated module
Reference architecture Not covered Dedicated module
Modeling languages ArchiMate, BPMN, BMM ArchiMate, BPMN, C4, Backstage, LeanIX, BMC
Frameworks None TOGAF, DoDAF, Zachman, ADMIT, TIME, Platform Design
Tooling Protégé-based Converters, generators, MCP server
Academic validation 5+ published papers, PhD thesis Design decisions document
Active development Yes (2026 paper) Yes

9. References

  1. Hinkelmann, K., Laurenzi, E., Martin, A., Montecchiari, D., Spahic, M. and Thönssen, B. (2020). ArchiMEO: A Standardized Enterprise Ontology based on the ArchiMate Conceptual Model. In Proceedings of MODELSWARD 2020, pp. 417–424. DOI: 10.5220/0009000204170424. Available at: https://www.scitepress.org/Papers/2020/90002/pdf/index.html

  2. Hinkelmann, K., Gerber, A., Karagiannis, D., Thoenssen, B., Van der Merwe, A., and Woitsch, R. (2016a). A new paradigm for the continuous alignment of business and IT: Combining enterprise architecture modelling and enterprise ontology. Computers in Industry, 79:77–86.

  3. Hinkelmann, K., Laurenzi, E., Martin, A., and Thönssen, B. (2018). Ontology-based metamodeling. In Business Information Systems and Technology 4.0, pp. 177–194. Springer.

  4. Martin, A. (2016). A combined Case-Based Reasoning and Process Execution Approach for Knowledge-Intensive Work. PhD thesis, University of South Africa.

  5. Hinkelmann, K. et al. (2026). Ontology-Based Validation of Enterprise Architecture Principles. Applied Sciences, 16(7):3352. Available at: https://www.mdpi.com/2076-3417/16/7/3352

  6. Thönssen, B. (2013). Automatic, Format-independent Generation of Metadata for Documents Based on Semantically Enriched Context Information. Dissertation, Università degli Studi di Camerino.

  7. Noy, N. F., McGuinness, D. L., et al. (2001). Ontology development 101: A guide to creating your first ontology.

  8. Grüninger, M. and Fox, M. S. (1995). Methodology for the design and evaluation of ontologies.

  9. The Open Group (2023). ArchiMate 3.2 Specification. Available at: https://pubs.opengroup.org/architecture/archimate3-doc/