Linked.Archi

Linked.Archi ArchiMate 3.2 Metamodel Definition

Metamodel Manifest

https://meta.linked.archi/archimate/metamodel#

v3.2.0 draft ammm: Kalin Maldzhanski Linked.Archi Modified: 2026-04-16 License

Metamodel manifest for ArchiMate 3.2. This file ties together all the ArchiMate semantic resources — the element/relationship ontology, SKOS taxonomy, SHACL shapes, derivation rules, viewpoints, deliverable templates, reference data, reference models, and presentation contexts — into a single arch:Metamodel instance. This is the entry point for tools that need to discover all resources that make up the ArchiMate modeling language definition.

The complete ArchiMate 3.2 metamodel definition, aggregating the element/relationship ontology, SKOS taxonomy, SHACL shapes, derivation rules, viewpoints, deliverable templates, reference data, reference models, and presentation contexts into a single discoverable resource.

Based on Framework

ArchiMate 3.2

The ArchiMate enterprise architecture modeling language, version 3.2, published by The Open Group. Provides a uniform representation for diagrams that describe enterprise architectures across business, application, and technology domains.

Constituent Resources

Model Concepts (OWL Ontology)

onto

Linked.Archi ArchiMate ontology aligned to the ArchiMate 3.2 specification, modernized to conform to Linked.Archi core ontology conventions, the qualified relationship pattern, and RDF 1.2. This is not an official Open Group document.
https://meta.linked.archi/archimate/onto#
Formal Rules (SHACL Shapes)

shapes

SHACL shapes for validating ArchiMate model data. Generated from the ArchiMate relationship validity matrix (Archi tool, MIT license). Validates both qualified relationship instances and unqualified direct triples. Pure SHACL core — no SPARQL.
https://meta.linked.archi/archimate/shapes#
Formal Rules (SHACL Shapes)

element-shapes

SHACL shapes for validating ArchiMate element instances and metamodel patterns. Covers structural integrity, assignment/access/serving direction, cross-layer constraints, specialization rules, junction homogeneity, motivation realization direction, strategy realization targets, and deep specialization warnings. Based on ArchiMate 3.2 spec Figures 5, 34, 45, 46, 51, 52, 70, 82, 99, 104-106. For relationship pair validation, see archimate3.2-relationship-shapes.ttl.
https://meta.linked.archi/archimate/element-shapes#
Formal Rules (SHACL Shapes)

principle-shapes

SHACL shapes encoding common enterprise architecture principles and best practices as executable constraints. These shapes validate architecture models against governance patterns such as redundancy avoidance, single authoritative source, separation of concerns, stewardship, and technology standardization. Inspired by the ontology-based EA principle validation approach described in: Montecchiari, D.; Hinkelmann, K. (2026) "Ontology-Based Validation of Enterprise Architecture Principles", Applied Sciences, 16(7):3352. These shapes are designed to be loaded alongside the standard ArchiMate element and relationship shapes. They operate on instance data (architecture models) and detect violations of common governance principles. All shapes use sh:severity sh:Warning by default — organizations should promote specific shapes to sh:Violation based on their governance policies. Usage: ./validate.sh --shacl archimate-principles Or load manually alongside other shapes: core-shapes.ttl + archimate3.2-principle-shapes.ttl + your-model-data.ttl
https://meta.linked.archi/archimate/principle-shapes#
Viewpoint Conformance Rules (SHACL)

viewpoint-shapes

SHACL shapes for validating that architecture Views conform to their declared Viewpoints. These shapes enforce: 1. Element conformance — elements exposed in a View must be instances of types listed in the viewpoint's arch:includesConcept. 2. View type conformance — a View's rdf:type must match one of the viewpoint's arch:viewType values (Diagram, Catalog, Matrix). 3. Viewpoint declaration — every View must declare which viewpoint it conforms to via arch:viewConformsToViewpoint. These shapes are data-driven: they read the viewpoint definitions from the loaded graph (arch:includesConcept, arch:viewType) rather than hardcoding per-viewpoint rules. This means they work for any viewpoint — ArchiMate example viewpoints, custom viewpoints, or viewpoints from other frameworks — as long as the viewpoint data is loaded. Shapes use sh:severity sh:Warning by default. Organizations may promote specific shapes to sh:Violation based on governance policies. Usage: .scripts/validate.sh --shacl archimate-viewpoints Or load manually: core-shapes.ttl + archimate3.2-viewpoint-shapes.ttl + archimate3.2-viewpoints.ttl + your-model-data.ttl
https://meta.linked.archi/archimate/viewpoint-shapes#
Derivation Rules

derivation

SHACL Rules (sh:SPARQLRule) implementing ArchiMate derivation rules DR1-DR8 (valid) and PDR1-PDR12 (potential) from the ArchiMate 3.2 specification Appendix B. Derived relationships are annotated with confidence level and provenance via RDF 1.2 reification.
https://meta.linked.archi/archimate/derivation#
Concept Classification (SKOS)

ArchiMate 3.2 Concept Scheme

Classification of ArchiMate elements by layer and aspect, and relationship types by category.
https://meta.linked.archi/archimate/tax#ArchiMateConceptScheme
Architecture Viewpoints

viewpoints

ArchiMate 3.2 example viewpoints as arch:Viewpoint individuals. Each viewpoint specifies allowed element types (arch:includesConcept), target stakeholders (arch:targetsStakeholder), and framed concerns (arch:viewpointFramesConcern). Organizations may define additional custom viewpoints.
https://meta.linked.archi/archimate/viewpoints#
Viewpoint Library (SKOS)

ArchiMate 3.2 Viewpoint Catalog

Classification of ArchiMate example viewpoints by category, following the ArchiMate specification's own grouping from Chapter 14 and Appendix C. The four top-level categories correspond to the ArchiMate framework dimensions. The sub-categories under Basic Viewpoints (Composition, Support, Cooperation, Realization) correspond to the ArchiMate viewpoint classification matrix.
https://meta.linked.archi/archimate/viewpoints#ViewpointCatalog
Deliverable Templates

Architecture Definition Document

The primary ArchiMate deliverable documenting the target architecture across business, application, and technology layers. Covers organizational structure, application landscape, technology infrastructure, and cross-layer dependencies. Aligned with TOGAF Architecture Definition Document.
https://meta.linked.archi/archimate/deliverable-templates#ArchitectureDefinitionDocument
Deliverable Templates

Architecture Requirements Specification

Documents the architecture requirements derived from stakeholder concerns, goals, and constraints. Traces requirements to the architecture elements that realize them.
https://meta.linked.archi/archimate/deliverable-templates#ArchitectureRequirementsSpec
Deliverable Templates

Architecture Principles Document

Documents the architecture principles that guide design decisions. Includes principle validation results from the principle shapes.
https://meta.linked.archi/archimate/deliverable-templates#ArchitecturePrinciplesDocument
Reference Data

ArchiMate Reference Data

Controlled vocabularies commonly used in ArchiMate models for classifying and annotating architecture elements.
https://meta.linked.archi/archimate/reference-data#ArchiMateReferenceData
Reference Models

ArchiMate Reference Models

Catalog of reference architectures, patterns, and building blocks that can be used as starting points for ArchiMate models.
https://meta.linked.archi/archimate/reference-models#ArchiMateReferenceModels
Presentation Contexts

ArchiMate Presentation Contexts

Stakeholder-specific presentation themes for ArchiMate views. Each context defines the appropriate level of detail, visual notation style, and terminology for a target audience.
https://meta.linked.archi/archimate/presentation-contexts#ArchiMatePresentationContexts

Stakeholders

ApplicationArchitect

BusinessArchitect

BusinessManager

CEO

CIO

DataArchitect

EnterpriseArchitect

InfrastructureArchitect

OperationsManager

ProcessOwner

ProductManager

ProjectManager

SecurityArchitect

SoftwareDeveloper

SolutionArchitect

Concerns

ApplicationIntegration

ApplicationSupport

ArchitectureMigration

ArchitectureOverview

CapabilityLandscape

ChangeManagement

CostOptimization

DeploymentStructure

GoalDecomposition

ImpactOfChange

InformationStructure

InfrastructureStability

MotivationLandscape

OrganizationalStructure

OutcomeDelivery

PhysicalEnvironment

ProcessCooperation

ProductOffering

ProjectDelivery

RequirementsTraceability

ResourceAllocation

ServiceRealization

StakeholderAlignment

StrategicDirection

TechnologySupport