Linked.Archi Documentation

Metamodel manifest for the C4 model. Ties together the C4 element/relationship ontology, SHACL shapes, SKOS taxonomy, viewpoints, deliverable templates, and reference data into a single discoverable resource.

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.

Metamodel manifest for the Backstage Software Catalog. Ties together the Backstage element/relationship ontology, SHACL shapes, SKOS taxonomy, viewpoints, deliverable templates, reference data, and presentation contexts into a single discoverable resource.

Metamodel manifest for BPMN 2.0.2. Ties together the BPMN element/relationship ontologies, SHACL shapes, alignment axioms, and diagram interchange modules into a single discoverable resource. Derived from the OMG BPMN 2.0.2 specification XMI.

Metamodel manifest for the Business Model Canvas. The BMC is a pure SKOS vocabulary (no OWL elements or relationships) representing the nine building blocks defined by Alexander Osterwalder.

Metamodel manifest for the SAP LeanIX Meta Model v4. Ties together the LeanIX fact sheet ontology, viewpoints, and taxonomy into a single discoverable resource. Shapes, deliverable templates, reference data, and presentation contexts can be added later.

Metamodel manifest for TOGAF. Ties together the Content Metamodel ontology, ADM taxonomy, viewpoints, deliverable templates, and SHACL shapes into a single discoverable resource.

Minimal representation of the Zachman Framework as an architecture metamodel.

Simplest possible Linked.Archi metamodel example.

Component and Connector Example Ontology based on Linked.Archi Core Ontology.

Minimal Metamodel.

Component and Connector Example Ontology based on Linked.Archi Core Ontology.

Structurizr-specific extensions to the C4 model ontology. Adds deployment modeling concepts (deployment nodes, infrastructure nodes, deployment environments, container instances) that are part of the Structurizr tooling but not part of the abstract C4 model. Imports the C4 model ontology (c4-onto.ttl) — all C4 core concepts are available via the c4: namespace.

An RDF/OWL ontology for the C4 model — the abstract, notation-independent software architecture visualization model created by Simon Brown. Defines the four core abstraction levels (Person, Software System, Container, Component) and their relationships. This ontology covers the C4 model itself, not any specific tooling implementation. For Structurizr-specific concepts (deployment nodes, infrastructure nodes, deployment environments), see the Structurizr extension ontology (structurizr-onto.ttl) which imports this ontology.

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.

Linked.Archi ArchiMate 3.0 Ontology.

Linked.Archi ArchiMate 3.1 Ontology. based on ArchiMate 3.1 specification

Linked.Archi ArchiMate 3.1 Ontology. based on ArchiMate 3.1 specification

Linked.Archi ArchiMate 3.1 Ontology. based on ArchiMate 3.1 specification

An RDF/OWL ontology for Backstage catalog entities and their relationships, extending the Linked.Archi core ontology.

OWL mapping of the OMG BPMN 2.0.2 Diagram Interchange (BPMNDI) package.

OWL mapping of the OMG BPMN 2.0.2 semantic model.

OWL mapping of the OMG DD Diagram Interchange (DI) abstract classes.

OWL mapping of the BPMN 2.0.2 infrastructure package (Definitions, Import).

OWL mapping of the OMG DD Diagram Common (DC) datatypes.

Ontology representation of SAP LeanIX Meta Model v3 fact sheets and relations.

Ontology representation of SAP LeanIX Meta Model v4 fact sheets and relations.

Linked.Archi ontology aligned to the TOGAF Content Metamodel as defined in TOGAF 9.2 Chapter 30 and TOGAF 10 Architecture Content Chapter 3. Models the entity types and relationships of the Content Metamodel as OWL classes and properties, conforming to Linked.Archi core ontology conventions. This is not an official Open Group document.

TOGAF 9.2 Content Metamodel

System Lifecycle Processes Reference Model based on ISO/IEC/IEEE 15288.

Linked.Archi Architecture Processes Ontology.

Linked.Archi Architecture Processes Ontology.

Extension ontology for modeling reference architectures, reference models, architectural patterns, tactics, and building blocks (ABB/SBB). Use this extension to capture reusable architectural knowledge, classify patterns by type (module, integration, deployment), relate tactics to quality attributes, and trace how patterns and tactics interact.

Extension ontology for modeling architecture decisions, the issues that trigger them, candidate options, influencing forces (requirements, constraints, trends), and the rationale linking forces to chosen options. Use this extension when you need to capture decision records, trace forces to options, or integrate with ADD-style iterative decision processes.

Linked.Archi Architecture Processes Ontology.

A minimal metamodel demonstrating the Linked.Archi pattern: two element types and one relationship type with all three declarations.

Core Linked.Archi Ontology for Enterprise and IT Architecture modeling.

Base Ontology EA modeling.

SHACL shapes for validating Structurizr deployment model data. Imports c4-shapes for base C4 model validation.

SHACL shapes for validating C4 model data. Covers the abstract C4 model relationships (Using, ContainerContainment, ComponentContainment). For Structurizr deployment shapes, see structurizr-shapes.ttl.

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.

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

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.

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.

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

Linked.Archi ArchiMate 3.0 Ontology.

SHACL shapes for validating Backstage catalog data. Imports core-shapes for base QualifiedRelationship validation. Adds Backstage-specific domain/range constraints per relationship type.

Base SHACL shapes for the Linked.Archi core ontology. These shapes apply to all metamodels that extend the core. Metamodel-specific shapes (e.g., ArchiMate, C4, Backstage) import this file and add type-specific constraints.

Controlled vocabularies for C4 model annotations.

Stakeholder-specific rendering themes for C4 diagrams.

SKOS taxonomy classifying C4 model elements by abstraction level and relationship types by category.

Stakeholder-specific presentation themes for ArchiMate views. Each context defines the appropriate level of detail, visual notation style, and terminology for a target audience.

Pure SKOS taxonomy classifying ArchiMate elements by layer and by aspect, and relationship types by category. For OWL abstract classes used in SHACL constraint checking, see archimate3.2-onto.ttl.

Catalog of reference architectures, patterns, and building blocks that can be used as starting points for ArchiMate models.

Controlled vocabularies commonly used in ArchiMate models for classifying and annotating architecture elements.

Controlled vocabularies for Backstage catalog entity annotations.

SKOS taxonomy classifying Backstage Software Catalog entities by category (software entities, organizational entities) and relationship types.

Stakeholder-specific rendering themes for Backstage catalog views.

SKOS vocabulary representing the nine building blocks of the Business Model Canvas by Alexander Osterwalder.

SKOS taxonomy classifying LeanIX Meta Model v4 fact sheet types by architecture layer and relationship types by category.

This ontology is designed to align with the Linked.Archi meta repository style and can be published with versioned IRIs and Widoco documentation.

SKOS taxonomy classifying TOGAF Content Metamodel entities by architecture domain and ADM phase.

SKOS taxonomy for platform design concepts.

Linked.Archi admit extension Ontology for Architecture Decision and Architecture evaluation.

C4 model viewpoints corresponding to the four abstraction levels defined by Simon Brown. Each level zooms into the previous one, providing progressively more detail. The Deployment diagram is an additional cross-cutting viewpoint.

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.

Backstage Software Catalog viewpoints for visualizing service ownership, system dependencies, API landscapes, and domain organization. Each viewpoint maps to a common Backstage use case.

BPMN 2.0.2 viewpoints corresponding to the four diagram types defined by the OMG specification: Process, Collaboration, Choreography, and Conversation.

Viewpoints for the SAP LeanIX Meta Model v4, covering application portfolio management, technology landscape, interface mapping, capability mapping, and transformation roadmaps.

TOGAF architecture viewpoints organized by ADM phase. Each viewpoint corresponds to a catalog, matrix, or diagram defined in the TOGAF Architecture Content Framework. Consistent across TOGAF 9.2 (Chapter 31) and TOGAF 10 (Architecture Content, Chapter 3).

Framework-agnostic architecture viewpoints derived from ISO/IEC/IEEE 42010 and common architecture practice. These are universal viewpoints that any modeling language can use — ArchiMate, TOGAF, C4, Backstage, or custom metamodels can specialize or reference them.

Framework-agnostic deliverable templates that define the content structure of common architecture documents. Each template specifies which viewpoints are required — the actual views are created when someone instantiates the template into a concrete deliverable (arch:Model). These templates reference core viewpoints. Framework-specific templates (e.g., TOGAF Architecture Definition Document) should be defined in the respective framework's file, referencing framework-specific viewpoints.