DCAT Catalog

https://model.example.com/acme-ea#

Worked example demonstrating the EA-as-a-Service extension. Models a 4-person EA team operating as an internal consultancy at a mid-size financial services company. Shows service catalog, engagements, outcomes, satisfaction tracking, capability portfolio, and maturity assessment.

https://meta.linked.archi/simple-example#

Simplest possible Linked.Archi metamodel example demonstrating a minimal element type and relationship definition.

https://meta.linked.archi/examples/cloudplatform/viewpoints#

Architecture viewpoint definitions for Custom Metamodel.

https://meta.linked.archi/examples/cloudplatform/reference-data#

Controlled vocabularies and reference data for Custom Metamodel architecture models.

https://meta.linked.archi/examples/cloudplatform/shapes#

Validation rules for the Cloud Platform Architecture metamodel.

https://meta.linked.archi/examples/cloudplatform/tax#

SKOS taxonomy providing a hierarchical classification of Custom Metamodel concepts.

https://meta.linked.archi/examples/cloudplatform/onto#

Example custom metamodel extending ArchiMate 4.0 with cloud platform concepts — microservices, containers, message brokers, API gateways, and observability components. Demonstrates how to build an organization-specific modeling language on top of the Linked.Archi foundation.

https://meta.linked.archi/examples/cloudplatform/deliverable-templates#

Deliverable template definitions for generating architecture documents from Custom Metamodel models.

https://meta.linked.archi/examples/cloudplatform/metamodel#

Metamodel manifest for the Cloud Platform Architecture example.

https://meta.linked.archi/CnC#

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

https://meta.linked.archi/basic

Minimal Metamodel demonstrating simple element types, relationships, and qualified relationship patterns in Linked.Archi.

https://model.example.com/fraud-detection#

Example architecture model for a real-time fraud detection system that demonstrates the ML-Enabled Systems extension. Shows how ML components (models, pipelines, feature stores) integrate with traditional software components (payment service, transaction database, notification service).

https://meta.linked.archi/bpmn-lite/shapes#

SHACL validation shapes for the BPMN Lite ontology.

https://meta.linked.archi/bpmn-lite/metamodel#

Metamodel manifest for BPMN Lite — a simplified BPMN profile for enterprise architecture reasoning. Covers the EA-relevant subset of BPMN 2.0.2: processes, tasks, events, gateways, participants, data objects, and message flows. Choose BPMN Lite when: • The goal is cross-model reasoning (BPMN ↔ ArchiMate ↔ C4), not BPMN execution. • You want a "thin lift" — only constructs with EA-level semantic value. • Layout and notation detail stays in the original .bpmn file, referenced by URI. Choose the full BPMN 2.0.2 suite (modelingLanguages/bpmn/) when: • You need full spec fidelity (144 classes, diagram interchange, correlation). • You are building BPMN tooling, round-tripping, or execution engines. • You need SHACL validation against the complete BPMN metamodel.

https://meta.linked.archi/bpmn-lite/onto#

A simplified BPMN ontology for enterprise architecture use cases. Covers only the BPMN constructs that carry semantic value at the EA level — processes, tasks, events, gateways, participants, data objects, and message flows. Omits execution-level detail (diagram interchange geometry, waypoints, marker styles, I/O specifications, correlation, loop characteristics) that adds triple density without supporting cross-model reasoning. Use this ontology when the goal is to query, validate, or reason across BPMN and other models (ArchiMate, C4, TOGAF). For full BPMN 2.0.2 fidelity — including diagram interchange and all 144 metamodel classes — use the complete BPMN suite (modelingLanguages/bpmn/). Design rationale: 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. The value of RDF over native XML materializes only when you intend to query, validate, or reason across BPMN and other models.

https://meta.linked.archi/c4/deliverable-templates#

https://meta.linked.archi/c4/reference-data#

Controlled vocabularies and reference data for annotating C4 architecture model elements.

https://meta.linked.archi/c4/viewpoints#

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.

https://meta.linked.archi/c4/structurizr#

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.

https://meta.linked.archi/c4/notation#

Visual notation descriptors for C4 model elements and relationships. Defines the standard C4 visual appearance — colored boxes with technology labels, person shapes, and dashed dependency arrows. Follows the conventions from c4model.com and Structurizr rendering defaults.

https://meta.linked.archi/c4/presentation-contexts#

Stakeholder-specific rendering themes for C4 diagrams. Each context links to a NotationSet via arch:usesNotationSet to drive context-aware palette generation and diagram rendering.

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

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.

https://meta.linked.archi/c4/structurizr-shapes#

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

https://meta.linked.archi/c4/onto#

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. This is not an official c4model.com document.

https://meta.linked.archi/c4/shapes#

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

https://meta.linked.archi/c4/tax#

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

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

Metamodel manifest for UML 2.5.1. Ties together the UML element/relationship ontology, SHACL shapes, alignment axioms, SKOS taxonomy, viewpoints, and reference data into a single discoverable resource. This metamodel formalizes the OMG Unified Modeling Language as a Linked.Archi modeling language, enabling UML model data to participate in the unified architecture knowledge graph alongside ArchiMate, C4, BPMN, and Backstage. The mapping from the MOF-based UML metamodel to OWL/RDF is informed by the OMG Ontology Definition Metamodel (ODM, formal/2014-09-02) Annex D mapping rules, with Linked.Archi conventions (three-declaration qualified relationships, SHACL validation, SKOS classification) applied on top. ODM maps UML model instances (M1) to OWL for dataset use; this metamodel represents the UML metamodel itself (M2) in OWL for architecture knowledge graph use.

https://meta.linked.archi/uml/reference-data#

Controlled vocabularies for UML model annotations — visibility kinds, aggregation kinds, parameter direction kinds, message sorts, pseudostate kinds, transition kinds, interaction operator kinds, and connector kinds. Modeled as SKOS concept schemes following Linked.Archi convention DD-5. These correspond to UML 2.5.1 enumerations that the ODM specification (Annex D.3.9) maps to either owl:oneOf or SKOS concept schemes. Linked.Archi uses SKOS for all enumerated value sets (see DD-5).

https://meta.linked.archi/uml/tax#

SKOS taxonomy classifying UML 2.5.1 metaclasses by diagram type and by metaclass category (structural vs behavioral, classifier vs relationship). Provides navigation aids for modeling tool palettes and knowledge graph exploration.

https://meta.linked.archi/uml/shapes#

SHACL shapes for validating UML model data in the Linked.Archi knowledge graph. Covers relationship domain/range constraints, required properties, and structural integrity rules derived from the UML 2.5.1 specification.

https://meta.linked.archi/uml/viewpoints#

UML 2.5.1 diagram types formalized as Linked.Archi viewpoints. Each of the 14 UML diagram types is represented as an arch:Viewpoint instance with its included concepts, purpose, and framed concerns.

https://meta.linked.archi/uml/onto#

RDF/OWL formalization of the OMG Unified Modeling Language (UML) 2.5.1 metamodel for use in the Linked.Archi architecture knowledge graph. Covers structural classifiers (Class, Interface, Component, Package), behavioral elements (Activity, StateMachine, Interaction), deployment concepts (Node, Artifact), and use cases (Actor, UseCase). Relationship types follow the Linked.Archi three-declaration qualified relationship pattern. This ontology is INFORMED BY the OMG Ontology Definition Metamodel (ODM, formal/2014-09-02) but does NOT apply ODM directly. ODM Annex D maps UML model instances (M1) to OWL; this ontology represents the UML metamodel itself (M2) as OWL classes so that UML model data can be typed in a knowledge graph. We adopt ODM principles (Class→owl:Class, Generalization→rdfs:subClassOf, Package→owl:Ontology) but depart from ODM for associations (three-declaration pattern), enumerations (SKOS), constraints (SHACL), and domain/range (arch:domainIncludes). See the skos:scopeNote for the full comparison. This is not an official OMG document. It is a Linked.Archi interpretation of the UML specification for semantic architecture modeling.

https://meta.linked.archi/archimate3/notation#

Visual notation descriptors for ArchiMate 3.2 elements and relationships. Defines the standard visual appearance (shape, color, icon, line style) for each model concept, enabling palette generation and diagram rendering from structured metadata.

https://meta.linked.archi/archimate3/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 via a custom property and provenance via PROV-O (prov:wasGeneratedBy, prov:wasDerivedFrom), using RDF 1.2 reification.

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

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.

https://meta.linked.archi/archimate3/deliverable-templates#

https://meta.linked.archi/archimate3/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. Contexts link to NotationSets via arch:usesNotationSet to drive context-aware palette generation.

https://meta.linked.archi/archimate3/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/archimate3/tax#

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.

https://meta.linked.archi/archimate3/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/archimate3/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/archimate3/shapes#

SHACL shapes for validating ArchiMate 3.2 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/archimate3/reference-models#

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

https://meta.linked.archi/archimate3/reference-data#

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

https://meta.linked.archi/archimate3/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/archimate3/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/archimate3/onto/3.0#

OWL ontology defining ArchiMate 3.0 element types and relationships for Linked.Archi.

https://meta.linked.archi/archimate3/tax/3.0#

SKOS taxonomy classifying ArchiMate 3.0 elements by layer and aspect, and relationship types by category.

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

Metamodel manifest for ArchiMate 4.0. This file ties together all the ArchiMate 4.0 semantic resources — the element/relationship ontology, SKOS taxonomy, viewpoints, and future SHACL shapes — into a single arch:Metamodel instance. This is the entry point for tools that need to discover all resources that make up the ArchiMate 4.0 modeling language definition.

https://meta.linked.archi/archimate4/derivation#

SHACL Rules (sh:SPARQLRule) implementing ArchiMate 4.0 derivation rules. Derived relationships are annotated with confidence level via a custom property and provenance via PROV-O (prov:wasGeneratedBy, prov:wasDerivedFrom). Draft — the full derivation matrix needs validation against the ArchiMate 4.0 spec.

https://meta.linked.archi/archimate4/reference-models#

Catalog of reference architectures and patterns for ArchiMate 4.0 models.

https://meta.linked.archi/archimate4/shapes#

SHACL shapes for validating ArchiMate 4.0 model data. Generated from the ArchiMate 4.0 relationship validity matrix (Appendix B). Validates qualified relationship instances and unqualified direct triples. Pure SHACL core.

https://meta.linked.archi/archimate4/principle-shapes#

SHACL shapes encoding common enterprise architecture principles as executable constraints. Adapted from 3.2 principle shapes for ArchiMate 4.0 domain-based structure.

https://meta.linked.archi/archimate4/element-shapes#

SHACL shapes for validating ArchiMate 4.0 element instances and metamodel patterns. Adapted from 3.2 shapes for the domain-based structure of 4.0. Draft — needs validation against the ArchiMate 4.0 relationship validity matrix.

https://meta.linked.archi/archimate4/onto#

Linked.Archi ArchiMate ontology aligned to the ArchiMate 4.0 specification (the "Hexagonion"). ArchiMate 4.0 replaces the layer-based structure of 3.x with a domain-based organization (Common, Business, Application, Technology, Strategy, Motivation, Implementation & Migration). Behavior elements that were previously duplicated per layer (e.g., BusinessProcess, ApplicationProcess, TechnologyProcess) are merged into single cross-domain elements (Process, Function, Event, Service). New Common Domain elements (Role, Collaboration, Path) are introduced as generic, domain-independent concepts. This is not an official Open Group document.

https://meta.linked.archi/archimate4/notation#

Visual notation descriptors for ArchiMate 4.0 elements and relationships. Defines the standard visual appearance (shape, color, icon, line style) for each model concept, enabling palette generation and diagram rendering from structured metadata.

https://meta.linked.archi/archimate4/viewpoint-shapes#

SHACL shapes for validating that architecture Views conform to their declared Viewpoints. Data-driven — reads viewpoint definitions from the loaded graph.

https://meta.linked.archi/archimate4/tax#

Pure SKOS taxonomy classifying ArchiMate 4.0 elements by domain and by aspect. ArchiMate 4.0 replaces the layer-based structure of 3.x with a domain-based organization (Common, Business, Application, Technology, Strategy, Motivation, Implementation & Migration). For OWL abstract classes used in SHACL constraint checking, see archimate4-onto.ttl.

https://meta.linked.archi/archimate4/presentation-contexts#

Stakeholder-specific presentation themes for ArchiMate 4.0 views.

https://meta.linked.archi/archimate4/reference-data#

Controlled vocabularies commonly used in ArchiMate 4.0 models.

https://meta.linked.archi/archimate4/deliverable-templates#

https://meta.linked.archi/archimate4/viewpoints#

ArchiMate 4.0 viewpoints as arch:Viewpoint individuals. Each viewpoint specifies allowed element types (arch:includesConcept), target stakeholders (arch:targetsStakeholder), and framed concerns (arch:viewpointFramesConcern). ArchiMate 4.0 uses domain-based organization; viewpoints reference the merged cross-domain elements (Process, Function, Event, Service) from the Common Domain. Organizations may define additional custom viewpoints.

https://meta.linked.archi/archimate3/tax/3.1#

SKOS taxonomy classifying ArchiMate 3.1 elements by layer and aspect, and relationship types by category. Adds ValueStream to the Strategy layer (introduced in 3.1).

https://meta.linked.archi/archimate3/onto/3.1#

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

https://meta.linked.archi/backstage/shapes#

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

https://meta.linked.archi/backstage/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.

https://meta.linked.archi/backstage/onto#

An RDF/OWL ontology for Backstage catalog entities and their relationships, extending the Linked.Archi core ontology. This is not an official Spotify document.

https://meta.linked.archi/backstage/reference-data#

Controlled vocabularies for Backstage catalog entity annotations.

https://meta.linked.archi/backstage/tax#

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

https://meta.linked.archi/backstage/presentation-contexts#

Stakeholder-specific rendering themes for Backstage catalog views.

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

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.

https://meta.linked.archi/backstage/deliverable-templates#

https://meta.linked.archi/bpmn/onto#shacl

SHACL shapes validating BPMN 2.0.2 core semantic classes — activities, events, gateways, flows, data objects, and their structural constraints. Derived from the OMG BPMN 2.0.2 specification.

https://meta.linked.archi/bpmn/di#shacl

SHACL shapes validating BPMN 2.0.2 Diagram Interchange classes — BPMNDiagram, BPMNPlane, BPMNShape, BPMNEdge, and BPMNLabel.

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

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.

https://meta.linked.archi/bpmn/di-core#shacl

SHACL shapes validating OMG Diagram Interchange (DI) abstract classes — Diagram, DiagramElement, Shape, Edge, Label, and Style.

https://meta.linked.archi/bpmn/suite#shapes

Shape aggregator that pulls together all SHACL shape modules for the BPMN suite (Core, Infrastructure, BPMNDI, DI, DC) into a single importable unit.

https://meta.linked.archi/bpmn/di#

https://meta.linked.archi/bpmn/viewpoints#

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

https://meta.linked.archi/bpmn/suite#

Import aggregator that pulls together all five BPMN ontology packages (Core, Infrastructure, BPMNDI, DI, DC) and the alignment axioms into a single importable unit.

https://meta.linked.archi/bpmn/onto#

https://meta.linked.archi/bpmn/di-core#

https://meta.linked.archi/bpmn/infra#

https://meta.linked.archi/bpmn/deliverable-templates#

https://meta.linked.archi/bpmn/dc#

https://meta.linked.archi/bpmn/dc#shacl

SHACL shapes validating OMG Diagram Common (DC) datatypes — Bounds, Point, and Font.

https://meta.linked.archi/bpmn/infra#shacl

SHACL shapes validating BPMN 2.0.2 infrastructure classes — Definitions container and Import elements.

https://meta.linked.archi/bpmn/suite#alignment

Alignment axioms mapping BPMN semantic classes to Linked.Archi core types. Maps bpmn:BaseElement to arch:Element and BPMN relationship classes (SequenceFlow, MessageFlow, Association, etc.) to arch:QualifiedRelationship.

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

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.

https://meta.linked.archi/bmc/onto#

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

https://meta.linked.archi/edgy/shapes#

SHACL validation shapes for EDGY 23 enterprise design models. Enforces element labeling requirements, relationship source/target constraints, and core link domain/range validity.

https://meta.linked.archi/edgy/onto#

OWL ontology for the EDGY 23 Enterprise Design language by Intersection Group. Defines the four base elements (People, Outcome, Activity, Object), twelve facet and intersection elements, three relationship types (Link, Flow, Tree), and two label types (Tagging, Metrics). EDGY content is available under CC BY-SA 4.0 license.

https://meta.linked.archi/edgy/notation#

Visual notation descriptors for EDGY 23 enterprise design elements and relationships. Follows the canonical EDGY visual language: all elements are drawn as circles. Base elements use a neutral grey palette. Facet elements are coloured by facet — yellow for Identity (Purpose, Story, Content), blue for Architecture (Capability, Process, Asset), red for Experience (Task, Journey, Channel). Intersection elements use the colour produced by mixing their two parent facets — green for Organisation (Identity ∩ Architecture), orange for Brand (Identity ∩ Experience), and purple for Product (Architecture ∩ Experience). Every element notation references both a composed icon (arch:prefVisNotation) and a glyph (arch-vis:iconSymbol) so it can be rendered either as a preview or as a shape-with-badge.

https://meta.linked.archi/edgy/viewpoints#

Viewpoint definitions for EDGY 23 enterprise design models. Defines viewpoints aligned with the three EDGY facets (Identity, Architecture, Experience), their intersections, and cross-cutting enterprise-wide perspectives.

https://meta.linked.archi/edgy/reference-data#

Reference data for EDGY 23 enterprise design models — pre-defined tag types for asset classification, metric categories, capability maturity levels, and other enumerated values commonly used in EDGY maps.

https://meta.linked.archi/edgy/deliverable-templates#

Deliverable template definitions for EDGY 23 enterprise design. Defines document templates for enterprise design outputs — capability maps, journey maps, service blueprints, enterprise overviews, and identity documents.

https://meta.linked.archi/edgy/tax#

Pure SKOS taxonomy classifying EDGY 23 enterprise elements. Top concepts are Base Elements, Facet Elements (subdivided by facet category), Intersection Elements, Relationships, and Labels. EDGY organizes enterprise design through three facets (Identity, Architecture, Experience) with three intersections (Organisation, Product, Brand) that bridge pairs of facets.

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

Metamodel manifest for EDGY 23 — the Enterprise Design language by Intersection Group. This file ties together all the EDGY semantic resources — the element/relationship ontology and SKOS taxonomy — into a single arch:Metamodel instance. EDGY is an open-source tool for collaborative Enterprise Design that provides a simple but rich visual language of base elements, facet elements, relationships, and labels to describe what an enterprise consists of and how its parts form a whole. This is the entry point for tools that need to discover all resources that make up the EDGY 23 modeling language definition.

https://meta.linked.archi/leanix/v3-onto#

Ontology representation of SAP LeanIX Meta Model v3 fact sheets and relations. This is not an official SAP document.

https://meta.linked.archi/leanix/viewpoints#

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

https://meta.linked.archi/leanix/deliverable-templates#

https://meta.linked.archi/leanix/onto#

OWL ontology representing the SAP LeanIX Meta Model v4 — the fact sheet types and relationships used by SAP LeanIX for enterprise architecture management. Models 12 default fact sheet types (Objective, Initiative, Business Capability, Organization, Business Context, Application, Interface, Data Object, IT Component, Tech Category, Platform, Provider) plus one optional type (System), organized across Strategy & Transformation, Business, Application & Data, and Technical architecture layers. Relationships follow the Linked.Archi qualified relationship pattern. This is not an official SAP document.

https://meta.linked.archi/leanix/tax#

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

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

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.

https://meta.linked.archi/eaonapage/tax#

SKOS taxonomy of the 24 EA artifacts identified by Kotusev across 27+ organizations, classified by the CSVLOD types and usage frequency. Also includes the EA Maturity Model (Stage Zero through Stage Three) and the EA Governance classification (architecture tiers, governance bodies, governance activities).

https://meta.linked.archi/eaonapage/onto#

Ontology for the Enterprise Architecture on a Page framework by Svyatoslav Kotusev. Models the CSVLOD artifact taxonomy (Considerations, Standards, Visions, Landscapes, Outlines, Designs), the three core EA processes (Strategic Planning, Initiative Delivery, Technology Optimization), process phases and governance activities, EA practice participants, governance bodies and tiers, maturity stages, and the 24 empirically validated EA artifacts. Based on peer-reviewed research across 27+ organizations, this framework describes how EA practices actually work rather than prescribing how they should work. This is not an official IASA document.

https://meta.linked.archi/eaonapage/shapes#

SHACL validation shapes for the EA on a Page framework. Validates artifact instances, process-artifact mappings, governance arrangements, and maturity stage consistency. These shapes encode the structural rules implicit in the EA on a Page framework.

https://meta.linked.archi/eaonapage/deliverable-templates#

Deliverable templates for the EA on a Page framework. Each template defines the structure and required viewpoints for a common EA deliverable. Based on the artifact types and typical structures described by Kotusev. EA on a Page explicitly says templates should be adapted rather than copied. These templates capture the typical structure observed across organizations and should be customized to local context.

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

Metamodel manifest for EA on a Page. Ties together the CSVLOD ontology, artifact taxonomy, maturity model, governance classification, viewpoints, deliverable templates, and SHACL validation shapes into a single discoverable resource.

https://meta.linked.archi/eaonapage/viewpoints#

Viewpoints for the EA on a Page framework. Each viewpoint specifies the artifact types it includes, the stakeholders it targets, and the purpose it serves. Derived from the CSVLOD artifact taxonomy and the three core EA processes described by Kotusev. EA on a Page does not formally define viewpoints, but its artifact types and processes imply a natural set of viewpoints that practitioners use in practice. These viewpoints formalize those implicit conventions.

https://meta.linked.archi/time-framework/shapes#

SHACL shapes for validating TIME framework model data. Ensures applications have required metadata, fit assessments are complete, and controlled vocabulary values are valid. This is the SHACL layer of the TIME framework. Use together with: * time-onto.ttl (OWL) — defines classes, properties, and OWL reasoning rules * time-tax.ttl (SKOS) — organizes controlled vocabularies for navigation

https://meta.linked.archi/time-framework/onto#

Ontology for representing application portfolio fit assessments and Gartner TIME dispositions (Tolerate, Invest, Migrate, Eliminate), including functional fit, technical fit, and cost fitness dimensions. Provides classes for applications, fit assessments, criteria scoring, evidence tracking, and OWL enumeration types with automatic quadrant classification. This is the OWL layer of the TIME framework. Use together with: * time-shapes.ttl (SHACL) — validates completeness and value constraints * time-tax.ttl (SKOS) — organizes controlled vocabularies for navigation This is not an official Gartner document.

https://meta.linked.archi/time-framework/tax#

SKOS concept scheme for the TIME framework controlled vocabularies, classifying TIME dispositions, fit ratings, fit dimensions, assessment statuses, evidence types, and lifecycle states under a single scheme with multiple top concepts. Individuals are defined in the companion ontology (time-onto.ttl) and referenced here via skos:narrower. This is the SKOS layer of the TIME framework. Use together with: * time-onto.ttl (OWL) — defines classes, properties, and enumeration individuals * time-shapes.ttl (SHACL) — validates completeness and value constraints

https://meta.linked.archi/time-framework/metamodel#

Metamodel manifest for the TIME (Tolerate, Invest, Migrate, Eliminate) framework. Ties together the TIME ontology and controlled vocabularies into a single discoverable resource for application portfolio rationalization.

https://meta.linked.archi/togaf/deliverable-templates#

https://meta.linked.archi/togaf/tax#

SKOS taxonomy classifying TOGAF 10 Enterprise Metamodel entities by architecture domain.

https://meta.linked.archi/togaf/onto#

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

https://meta.linked.archi/togaf9/tax#

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

https://meta.linked.archi/togaf9/onto#

Linked.Archi ontology aligned to the TOGAF Content Metamodel as defined in TOGAF 9.2 (Chapter 30). 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.

https://meta.linked.archi/togaf/crossmappings#

Cross-language SKOS mappings between TOGAF Content Metamodel concepts and ArchiMate modeling language concepts. TOGAF ↔ ArchiMate mappings are derived from: The Open Group, "Mapping of the TOGAF Content Metamodel to ArchiMate" https://pubs.opengroup.org/architecture/archimate3-doc/ch-Mapping-TOGAF-Content-Metamodel.html This appendix in the ArchiMate 3.x specification provides an official mapping between TOGAF Content Metamodel entity types and ArchiMate elements. The ArchiMate 4.0 mappings extend this with the updated element names from the 4.0 "Hexagonion" restructuring.

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

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

https://meta.linked.archi/togaf/viewpoints#

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).

https://meta.linked.archi/platform-design#

SKOS taxonomy for platform design concepts based on the Platform Design Toolkit methodology. Covers stakeholders (consumer, producer, enabler, keystone), assets, capabilities, stories, needs, solutions, touchpoints, value exchange, compensation, and channels.

https://meta.linked.archi/atam/onto#

Ontology for the Architecture Tradeoff Analysis Method (ATAM) from the Software Engineering Institute (SEI) at Carnegie Mellon University. Models the evaluation-specific concepts that ATAM adds beyond the core decision and quality attribute vocabulary: utility trees, sensitivity points, tradeoff points, risks, non-risks, and risk themes. ATAM is a method for evaluating software architectures relative to quality attribute goals. It exposes architectural risks that potentially inhibit the achievement of business goals by systematically analyzing quality attribute scenarios against architectural approaches. Use together with: * ad:arch-decision — for decisions, forces, options, and QA scenarios * refa:ref-arch — for patterns and tactics (architectural approaches) * iso25010 — for quality attribute definitions This is not an official SEI/Carnegie Mellon document.

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

Metamodel manifest for ATAM. Ties together the ATAM evaluation ontology into a single discoverable resource.

https://meta.linked.archi/zachman#

SKOS taxonomy of the Zachman Framework for Enterprise Architecture. Models the six communication interrogatives (columns), six reification transformations (rows), the stakeholder perspective labels associated with each row, the column abstraction names, and the 36 cells formed by their intersection. The Zachman Framework is not a methodology — it is a classification schema for organizing architectural descriptions based on the intersection of primitive interrogatives and reification transformations. This is not an official Zachman International product. "Zachman Framework" is a registered trademark of Zachman International, Inc.

https://meta.linked.archi/zachman/deliverable-templates#

Deliverable templates for the Zachman Framework. Provides an EA Artifact Coverage Report that queries the knowledge graph for artifacts classified by Zachman perspective and interrogative (or directly by cell), identifies gaps, and generates a coverage matrix.

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

Metamodel manifest for the Zachman Framework. Aggregates the taxonomy (interrogatives, reification transformations, perspectives, column abstractions, and 36 cells), SHACL validation shapes, and deliverable templates into a single entry point. The Zachman Framework is a classification schema — it does not define element types or viewpoints. It provides a 6x6 grid for classifying descriptive representations produced by other modeling languages.

https://meta.linked.archi/zachman/shapes#

SHACL validation shapes for artifacts classified using the Zachman Framework taxonomy. Validates that artifacts using Zachman classification have at least one perspective (row) and one interrogative (column), and warns about potential inconsistencies between cell-level and axis-level classification.

https://meta.linked.archi/4plus1/viewpoints#

Viewpoint definitions for the 4+1 Architectural View Model. These are language-agnostic viewpoints — they specify concerns and stakeholders but do not prescribe which modeling language to use. A custom metamodel attaches concrete element types via arch:includesConcept.

https://meta.linked.archi/4plus1#

SKOS taxonomy of the 4+1 Architectural View Model (Kruchten, 1995). Defines five viewpoint categories that can be used to classify viewpoints in any custom metamodel. The 4+1 model is language-agnostic — it describes what concerns each view addresses, not which notation to use.

https://meta.linked.archi/4plus1/deliverable-templates#

Deliverable templates for the 4+1 Architectural View Model. Defines a Software Architecture Document (SAD) structured around the five views, following the template pattern from Kruchten's original paper and the RUP SAD template.

https://meta.linked.archi/4plus1/metamodel#

Metamodel manifest for the 4+1 Architectural View Model. Aggregates the taxonomy, viewpoints, and deliverable templates into a single entry point. The 4+1 model is a viewpoint framework — it does not define its own element types. Custom metamodels reference it for viewpoint structure and document templates.

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

Metamodel manifest for DoDAF 2.02. Ties together the DoDAF entity ontology, viewpoint taxonomy, and viewpoint definitions into a single discoverable resource. DoDAF 2.0 shifted from rigid "products" to a data-centric approach with "Fit-for-Purpose" presentation. This metamodel captures the underlying data model that the 8 viewpoints and 52 DoDAF-described Models present.

https://meta.linked.archi/dodaf/viewpoints#

DoDAF 2.02 viewpoints modeled as arch:Viewpoint individuals. Each viewpoint corresponds to a DoDAF-described Model (AV, CV, DIV, OV, PV, SvcV, StdV, SV). DoDAF 2.0 uses "Fit-for-Purpose" presentation — these viewpoints define the data content, not rigid visual templates.

https://meta.linked.archi/dodaf/onto#

Linked.Archi ontology aligned to the U.S. Department of Defense Architecture Framework (DoDAF) version 2.02. Models the core entity types used across DoDAF viewpoints as OWL classes extending arch:Element, and the key relationships as owl:ObjectProperty. DoDAF 2.0 shifted focus from static products to architectural data — this ontology captures the underlying data model that the viewpoints present. This is not an official U.S. Department of Defense document.

https://meta.linked.archi/dodaf/tax#

SKOS taxonomy classifying DoDAF 2.02 entities by viewpoint.

https://meta.linked.archi/admit/tax#

SKOS taxonomy of ADMIT framework concepts — architecture levels, domains, resource dimensions, design forces classification, and the architecture development lifecycle (ADLC) with its phases and processes.

https://meta.linked.archi/admit/onto#

The ADMIT Design Forces Ontology contains the 20 ADMIT architecture design forces as OWL classes extending ad:Force. This is not an official IASA document.

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

Metamodel manifest for ADMIT. Ties together the ADMIT ontology and concept taxonomy into a single discoverable resource.

https://meta.linked.archi/uaf/crossmappings#

Cross-language SKOS mappings between UAF 1.2 concepts and other modeling languages in the Linked.Archi knowledge graph. UAF ↔ DoDAF mappings are derived from the OMG UAF 1.2 Specification, Appendix A — Traceability (https://www.omg.org/spec/UAF/1.2/). UAF ↔ ArchiMate mappings are editorial — no official OMG or Open Group document formally maps UAF to ArchiMate. These express semantic proximity based on concept definitions. Mappings are provided for both ArchiMate 3.2 and ArchiMate 4.0.

https://meta.linked.archi/uaf/tax#

SKOS taxonomy classifying UAF 1.2 metaclasses by two dimensions: viewpoint (10 viewpoints) and aspect (11 aspects). This dual classification reflects the UAF grid structure where each cell represents a specific combination of viewpoint and aspect. This is not an official OMG document.

https://meta.linked.archi/uaf/viewpoints#

UAF 1.2 viewpoints modeled as arch:Viewpoint individuals. UAF defines 10 viewpoints that organize architectural concerns. Each viewpoint specifies the concepts it includes, its purpose, and the concerns it frames. This is not an official OMG document.

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

Metamodel manifest for the Unified Architecture Framework (UAF) 1.2. Ties together the UAF entity ontology, SHACL shapes, SKOS taxonomy, viewpoint definitions, and alignment axioms into a single discoverable resource. UAF supersedes DoDAF, MODAF, and NAF, providing a unified framework that organizes architectural data across 10 viewpoints and 11 aspects. This is not an official OMG document.

https://meta.linked.archi/uaf/shapes#

SHACL shapes for validating UAF 1.2 model data. Imports core-shapes for base QualifiedRelationship validation. Adds UAF-specific domain/range constraints per relationship type. This is not an official OMG document.

https://meta.linked.archi/uaf/onto#

Linked.Archi ontology aligned to the Unified Architecture Framework (UAF) version 1.2, an OMG standard (formal/2025-10-01 through formal/2025-10-07). UAF provides a unified architecture framework superseding DoDAF, MODAF, and NAF. It organizes architectural data across 10 viewpoints and 11 aspects, defining approximately 288 metaclasses across multiple domains. This ontology models the core entity types used across UAF viewpoints as OWL classes extending arch:Element, and the key relationships using the three-declaration pattern (unqualified predicate, qualified class, qualified property). This is not an official OMG document.

https://meta.linked.archi/iso25010#

Ontology of software product quality characteristics from ISO/IEC 25010:2023. Top-level characteristics (Functional Suitability, Reliability, etc.) are owl:Class categories. Leaf sub-characteristics (Functional Completeness, Time Behaviour, etc.) are owl:NamedIndividual instances of their parent class — vocabulary terms referenced by arch:QualityMeasure and ad:QualityAttributeRequirement.

https://meta.linked.archi/iso15288#

SKOS taxonomy and OWL classes for system lifecycle processes from ISO/IEC/IEEE 15288:2023. Establishes a common framework of process descriptions for the life cycle of systems created by humans, covering agreement, organizational project-enabling, technical management, and technical processes.

https://meta.linked.archi/iso12207#

SKOS taxonomy and OWL classes for software lifecycle processes from ISO/IEC/IEEE 12207:2017. Covers the framework of processes for the software life cycle, including agreement, organizational project-enabling, technical management, and technical processes applicable to software systems.

https://meta.linked.archi/iso25012#

Ontology of data quality characteristics from ISO/IEC 25012. DataQuality is the root owl:Class (subClassOf arch:QualityAttribute). The fifteen data quality characteristics are owl:NamedIndividual instances of DataQuality — vocabulary terms referenced by arch:QualityMeasure and ad:QualityAttributeRequirement. Grouped into inherent, system-dependent, and inherent/system-dependent categories via skos:note.

https://meta.linked.archi/iso42010#

SKOS taxonomy of architecture description concepts from ISO/IEC/IEEE 42010:2022. This is the architecture description standard that the Linked.Archi core ontology aligns to. Covers the key concepts of system, architecture, architecture description, stakeholder, concern, architecture viewpoint, architecture view, architecture model, architecture decision, architecture rationale, correspondence, and correspondence rule.

https://meta.linked.archi/iso25011#

Ontology of IT service quality characteristics from ISO/IEC 25011. ITServiceQuality is the root owl:Class (subClassOf arch:QualityAttribute). The nine service quality characteristics are owl:NamedIndividual instances of ITServiceQuality — vocabulary terms referenced by arch:QualityMeasure and ad:QualityAttributeRequirement.

https://meta.linked.archi/iso42020#

SKOS taxonomy and OWL classes for architecture governance processes from ISO/IEC/IEEE 42020:2019. Covers the processes for governing and managing the architecture of systems and software, including architecture conceptualization, evaluation, elaboration, and transition under an overarching architecture governance framework.

https://meta.linked.archi/ea-service/metamodel#

Metamodel manifest for the EA-as-a-Service extension. Ties together the EA service ontology, SKOS taxonomy, SHACL shapes, and reference data into a single discoverable resource. Designed to compose with the Architecture Decisions extension (tracing engagements to decisions) and the Financial Architecture extension (cost-aware service delivery).

https://meta.linked.archi/ea-service/shapes#

SHACL shapes for validating EA-as-a-Service models. Enforces governance rules: every service must declare required capabilities, every engagement must have an assigned architect and status, and every EA service must have a label.

https://meta.linked.archi/ea-service/onto#

Extension ontology for modeling the EA function as an internal management consultancy. Provides vocabulary for EA service catalogs, service engagements, stakeholder satisfaction, EA capability portfolios, and maturity assessment. Addresses the Gartner 2025 prediction that by 2028, half of EA teams will rebrand themselves to emphasize their strategic role as business partners. Formalizes the shift from "architecture practice" to "architecture services" by making service offerings, engagements, outcomes, and satisfaction into queryable elements in the knowledge graph. Designed to be lightweight and adaptable — organizations customize the service catalog and maturity model to their operating model. Trademarked names referenced herein are property of their respective owners.

https://meta.linked.archi/ea-service/tax#

SKOS taxonomy classifying EA-as-a-Service concepts by service type, engagement duration, stakeholder type, and maturity level.

https://meta.linked.archi/ea-service/reference-data#

Reference data for EA-as-a-Service — service types, engagement statuses, and maturity levels.

https://meta.linked.archi/ai-governance/reference-data#

Reference data for AI governance — EU AI Act risk levels, OECD AI Principles, human oversight modes, and assessment statuses.

https://meta.linked.archi/ai-governance/metamodel#

Metamodel manifest for the AI Ethics & Governance extension. Ties together the AI governance ontology, SKOS taxonomy, SHACL shapes, and reference data into a single discoverable resource. This is the entry point for tools that need to discover all resources that make up the AI Ethics & Governance modeling vocabulary. Designed to compose with the ML-Enabled Systems extension — the ML extension provides the technical layer (models, pipelines, serving), while this extension provides the governance layer (risk classification, conformity assessment, bias assessment, human oversight).

https://meta.linked.archi/ai-governance/shapes#

SHACL shapes for validating AI governance models. Enforces governance rules: every AI system must have a risk classification, high-risk systems must have conformity assessments and human oversight plans, and all AI systems must have explainability documentation.

https://meta.linked.archi/ai-governance/onto#

Extension ontology for AI ethics and governance. Provides element types, properties, and reference data for managing AI system risk classification, conformity assessment, bias assessment, explainability documentation, human oversight plans, and governance policies. Builds on the ML-Enabled Systems extension (mlsys:) by adding the governance layer that connects ML components to regulatory frameworks (EU AI Act), ethical principles (OECD AI Principles), and organizational AI governance policies. Motivated by Gartner 2025 Leadership Vision identifying AI ethics and governance as a critical gap in EA teams, and by the EU AI Act (Regulation 2024/1689) requiring formal risk classification and conformity assessment for high-risk AI systems. Trademarked names referenced herein are property of their respective owners.

https://meta.linked.archi/ai-governance/tax#

SKOS taxonomy classifying AI governance concepts by risk level, principle, lifecycle phase, and assessment type.

https://meta.linked.archi/ref-arch#

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.

https://meta.linked.archi/arch-decision#

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.

https://meta.linked.archi/quality-attributes#

Extension providing named quality-attribute individuals (beyond ISO 25010) for use in architecture decision evaluation, tactic mapping, and quality-attribute scenario modeling. Use this extension to reference resilience-oriented quality attributes such as Safety, Survivability, Longevity, and Adaptability that complement the ISO 25010 taxonomy.

https://meta.linked.archi/tactics#

Extension ontology providing a taxonomy of architectural tactics organized by quality attribute (availability, interoperability, modifiability, performance, security). Use this extension to classify concrete design techniques that architects employ to achieve specific quality-attribute responses, and to relate them to patterns and decisions.

https://meta.linked.archi/financial-architecture/shapes#

SHACL shapes for validating financial architecture models. Enforces governance rules: every cost model must have a currency and at least one cost item, every investment case must have a type and projected ROI, and every cost-benefit analysis must have cost, benefit, and NPV.

https://meta.linked.archi/financial-architecture/tax#

SKOS taxonomy classifying financial architecture concepts by cost type, investment type, and analysis type.

https://meta.linked.archi/financial-architecture/reference-data#

Reference data for financial architecture — cost categories, investment types, and cost periods.

https://meta.linked.archi/financial-architecture/metamodel#

Metamodel manifest for the Financial Architecture extension. Ties together the financial architecture ontology, SKOS taxonomy, SHACL shapes, and reference data into a single discoverable resource. This is the entry point for tools that need to discover all resources that make up the Financial Architecture modeling vocabulary. Designed to compose with the TIME framework for cost-aware portfolio rationalization, and with the Architecture Decisions extension for cost-informed decision making.

https://meta.linked.archi/financial-architecture/onto#

Extension ontology for financial aspects of enterprise architecture. Provides vocabulary for Total Cost of Ownership (TCO) models, cost allocation to business capabilities and value streams, investment case tracking (Run/Grow/Transform), cost-benefit analysis for architecture decision options, and FinOps cloud cost management. Not intended to replace financial planning tools — the goal is to make cost a queryable dimension of the architecture knowledge graph, enabling questions like "What is the annual run cost of all applications supporting this capability?" or "Which decision option has the best NPV?" Motivated by Gartner 2025 Leadership Vision identifying lack of financial acumen as one of the five mistakes EA teams make. Trademarked names referenced herein are property of their respective owners.

https://meta.linked.archi/arch-processes#

Extension ontology for modeling architecture governance processes, activities, tasks, and their inputs and outputs within architecture models. This extension enables architects to capture process-oriented aspects of architecture work — governance workflows, lifecycle activities, and the artifacts they consume and produce — as first-class elements in architecture models alongside structural and behavioral elements. Use this extension when you need to: * Model architecture governance processes and their decomposition * Capture process inputs (forces, models, information items) and outputs (decisions, deliverables, models) * Trace how architecture activities relate to decisions and deliverables * Integrate process views into architecture descriptions The classes in this extension are practical model elements (subClassOf arch:Element) that can be used in architecture views and governed by metamodels, just like elements from the decisions or reference architecture extensions. The process concepts are aligned with ISO/IEC/IEEE 42020 (architecture governance), ISO/IEC/IEEE 12207 (software lifecycle), and ISO/IEC/IEEE 15288 (system lifecycle). For the normative standard definitions themselves, see the corresponding standard vocabularies under standards/.

https://meta.linked.archi/ml-systems/shapes#

SHACL shapes for validating ML-enabled system architecture models. Enforces governance rules: every ML model must have versioning, monitoring, and dataset lineage; every serving infrastructure must have latency SLAs.

https://meta.linked.archi/ml-systems/quality-attributes#

Quality attribute individuals specific to ML-enabled systems. Extends the base quality-attributes extension with ML-specific concerns identified by Moin et al. (2023) and Lewis et al. (2021).

https://meta.linked.archi/ml-systems/metamodel#

Metamodel manifest for the ML-Enabled Systems extension. Ties together the ML element/relationship ontology, SKOS taxonomy, and SHACL shapes into a single discoverable resource. This is the entry point for tools that need to discover all resources that make up the ML-Enabled Systems modeling vocabulary.

https://meta.linked.archi/ml-systems/tax#

SKOS taxonomy classifying ML-enabled system concepts by lifecycle phase and component role.

https://meta.linked.archi/ml-systems/onto#

Extension ontology for modeling ML-enabled system architectures. Provides element types, relationship types, stakeholders, concerns, and viewpoints for describing the ML aspects of software systems — training pipelines, model serving, feature engineering, data lineage, and the integration boundary between ML and non-ML components. Motivated by the gap identified in Moin et al. (2023): existing architecture frameworks lack stakeholders, viewpoints, and model kinds for data scientists, data engineers, and ML engineers. This extension addresses that gap within the Linked.Archi ecosystem. Trademarked names referenced herein are property of their respective owners.

https://meta.linked.archi/core-viewpoints#

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.

https://meta.linked.archi/core#

Core Linked.Archi Ontology for Enterprise and IT Architecture modeling. Trademarked names (UML, BPMN, ArchiMate, TOGAF, etc.) referenced herein are property of their respective owners.

https://meta.linked.archi/core-vis#

Core Linked.Archi Ontology for Diagrams and Visual Notation. Provides vocabulary for diagram interchange (nodes, links, bounds) and visual styling (colors, fonts, shapes, icons). Used both at the instance level (diagram elements) and at the type level (default notation for model concepts via NotationSet).

https://meta.linked.archi/core-tax#

SKOS taxonomy providing a hierarchical classification of Linked.Archi concepts.

https://meta.linked.archi/core-deliverable-templates#

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.

https://meta.linked.archi/core-shapes#

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.