What is Linked.Archi?¶

Linked.Archi is an open ecosystem for building architectural knowledge graphs — a shared, queryable, machine-readable representation of your organization's architecture that connects strategy to implementation.

The ecosystem consists of shared ontologies (OWL), validation rules (SHACL), taxonomies (SKOS), converters, generators, and AI enablement tooling. Together, they let you represent architecture models from different tools and notations — ArchiMate, C4, BPMN, UML, Backstage, LeanIX — as RDF, so they become queryable, validatable, and connectable in a single knowledge graph.

This repository (meta.linked.archi) is the semantic foundation. A separate toolbox repository provides converters, generators, a graph navigator, and an MCP server for AI agents.

The problem it addresses¶

Architecture knowledge is scattered across tools that don't talk to each other. The ArchiMate model lives in Archi or Sparx EA. Architecture decisions live in Confluence or Markdown ADRs. The service catalog lives in Backstage. API specs live in Swagger. Deployment topology lives in Terraform. Quality requirements live in someone's head.

Each tool is good at what it does. The problem is the connections between them. When someone asks "which business capabilities are at risk if we decommission this platform?" — answering that requires traversing from technology components through application services through business services to capabilities, cross-referencing with portfolio assessments and architecture decisions. No single tool holds all of that.

Linked.Archi provides the shared vocabulary that makes these connections explicit and queryable.

What's in this repository¶

Core ontology¶

core/core-onto.ttl — the shared foundation. Defines the concepts that all modeling languages share: Element, QualifiedRelationship, View, Viewpoint, Model, Metamodel, System, Architecture, Stakeholder, Concern, QualityAttribute. Aligned with ISO/IEC/IEEE 42010.

Modeling languages¶

Linked.Archi formalizes seven modeling notations as OWL ontologies. These notations span the full spectrum of architecture work — from enterprise-wide strategy and governance down to code-level software design. Each serves a different community of practitioners and operates at a different level of abstraction and expressiveness:

ArchiMate (https://meta.linked.archi/archimate3/onto#) is the most expressive for enterprise architecture. It covers seven layers (Strategy, Business, Application, Technology, Physical, Motivation, Implementation & Migration) with 62 element types and 11 formally typed relationships. It's the only notation here that traces from business capability through application service to deployment node in a single model. Its strength is cross-layer governance; its weakness is adoption outside the EA team.
BPMN (https://meta.linked.archi/bpmn/onto#) is the standard for behavioral modeling — how work actually flows. Where ArchiMate abstracts a process to a single element, BPMN decomposes it into activities, gateways, events, lanes, and message flows with precise execution semantics. Process analysts and business architects use it when "what happens in what order, with what exceptions" matters.
UML (https://meta.linked.archi/uml/onto#) (1997) is the oldest and broadest notation here — 14 diagram types covering structure (class, component, deployment, package), behavior (activity, state machine, sequence, use case), and interaction. It's the lingua franca of software engineering education and the formal foundation that C4 simplified away from. Most teams use a subset (class + sequence + component), but the full language can express anything from domain models to protocol state machines.
C4 (https://meta.linked.archi/c4/onto#) is a deliberate reaction to UML's complexity. Four zoom levels, five element types, one relationship type (labeled arrow). Its power is adoption: developers learn it in hours, maintain it in Git as DSL files, and review it in pull requests. Its limitation is semantic thinness — no typed relationships, no cross-layer traceability, no formal validation.
Backstage (https://meta.linked.archi/backstage/onto#) isn't a modeling notation in the traditional sense — it's a service catalog schema (Component, System, API, Resource, Group). But it captures what no EA tool does: who owns what, what's the lifecycle state, what APIs does it expose. For platform engineering teams, it's the source of truth for the running estate.
LeanIX (https://meta.linked.archi/leanix/onto#) is a portfolio management tool's data model — applications, IT components, business capabilities, and their relationships. It serves enterprise architects and portfolio managers who need to rationalize application landscapes, track technology lifecycle, and connect business capabilities to IT.
BMC (https://meta.linked.archi/bmc/onto#) (Business Model Canvas) is a lightweight strategy vocabulary — nine building blocks for describing how an organization creates and delivers value. It operates at a level above architecture proper, but connects to it when you need to trace from value proposition to capability to system.

Each language is formalized as an OWL ontology importing arch:core. This means elements from different notations can coexist in the same graph, participate in the same SPARQL queries, and be validated by the same SHACL shapes. An ArchiMate Application Component and a Backstage Component representing the same system can be linked. A BPMN Process and an ArchiMate Business Process modeling the same workflow can be connected.

Note: Not all ontology implementations are at the same level of completeness. ArchiMate 3.2 is the reference implementation that exercises every metamodel pattern. Others vary. See the individual README files in each modelingLanguages/ subdirectory for current status.

Frameworks¶

Governance and assessment frameworks that provide structure for how architecture work is organized, evaluated, and classified:

TOGAF (https://meta.linked.archi/togaf/onto#) — the most widely adopted EA framework. Content metamodel (36 entity types), ADM phase taxonomy, 60 viewpoints organized by phase, 8 stakeholder roles, and 5 deliverable templates with SPARQL queries.
DoDAF (https://meta.linked.archi/dodaf/onto#) — U.S. Department of Defense Architecture Framework. Data-centric approach with 8 viewpoints containing 52 models. 22 entity classes, 10 relationship types. Mandated for defense architecture descriptions.
UAF (https://meta.linked.archi/uaf/onto#) — Unified Architecture Framework. OMG standard that unifies DoDAF, MODAF, and NAF concepts into a single framework for defense and systems engineering.
ADMIT (https://meta.linked.archi/admit/onto#) — 20 design forces organized as a systematic checklist for architecture decision-making. Forces cover business, operations, security, cost, integration, simplicity, and more. Modeled as owl:Class rdfs:subClassOf ad:Force for direct use with the decisions extension.
TIME (https://meta.linked.archi/time-framework/onto#) — Gartner's application portfolio rationalization model. Classifies applications into Tolerate/Invest/Migrate/Eliminate based on functional and technical fit. Includes OWL equivalent classes for automatic quadrant classification, SHACL validation, and evidence tracking.
Zachman (https://meta.linked.archi/zachman#) — 6×6 classification schema for architecture artifacts. Six interrogatives (What, How, Where, Who, When, Why) × six perspectives (Planner through Worker). Useful as a completeness check — "which cells have no artifacts?"
EA on a Page (https://meta.linked.archi/eaonapage/onto#) — evidence-based framework from Kotusev's research across 27+ organizations. CSVLOD artifact taxonomy (Considerations, Standards, Visions, Landscapes, Outlines, Designs), three EA processes, governance model, and maturity stages.
ATAM (https://meta.linked.archi/atam/onto#) — Architecture Tradeoff Analysis Method from SEI/CMU. Utility trees, sensitivity points, tradeoff points, risks, and non-risks. For formal architecture evaluation with stakeholder-driven quality attribute prioritization.
Platform Design (https://meta.linked.archi/platform-design#) — vocabulary for platform business design. Stakeholder roles (consumer, producer, enabler, keystone), value exchange, channels, and touchpoints.

Extensions¶

Cross-cutting concerns that compose with any modeling language. Each extension imports arch:core and defines classes that subclass arch:Element, making them usable in architecture views alongside elements from any notation:

Architecture Decisions (https://meta.linked.archi/arch-decision#) — decisions, issues, forces (requirements, constraints, trends, principles), options with trade-offs, quality attribute scenarios (full QAS structure). The most-used extension — connects "why" to "what."
Architecture Processes (https://meta.linked.archi/arch-processes#) — governance workflows as model elements. Processes, activities, tasks, roles, milestones, inputs/outputs. Aligned with ISO 42020/12207/15288.
Reference Architecture (https://meta.linked.archi/ref-arch#) — patterns, tactics, building blocks (ABB/SBB), reference models. Patterns contain tactics; tactics address quality attributes. Connects to decisions when an architect selects a pattern as part of an option.
Quality Attributes (https://meta.linked.archi/quality-attributes#) — ISO 25010-aligned quality attribute individuals (Availability, Performance, Security, Maintainability, etc.). Used by decisions, tactics, and ATAM evaluations.
Tactics (https://meta.linked.archi/tactics#) — architectural tactics organized by quality attribute. Each tactic specifies which quality attributes it addresses and which it impacts as a side effect.
AI Governance (https://meta.linked.archi/ai-governance/onto#) — EU AI Act risk classification, conformity assessments, bias assessments, explainability reports, human oversight plans. Wraps ML system components with governance metadata.
Financial Architecture (https://meta.linked.archi/financial-architecture/onto#) — TCO models, cost-benefit analyses, investment cases, technical debt costs, cloud cost allocation. Attaches financial data to architecture elements so recommendations come with business cases.
EA-as-a-Service (https://meta.linked.archi/ea-service/onto#) — models the EA practice itself as a service catalog. Named services with SLEs, engagement tracking, stakeholder satisfaction, capability portfolios, maturity assessments.
ML-Enabled Systems (https://meta.linked.archi/ml-systems/onto#) — ML models, datasets, training pipelines, serving infrastructure, feature stores, monitoring. The technical layer that AI Governance wraps with regulatory metadata.

Standards¶

Reference vocabularies for ISO standards — not model elements, but definitions you can reference via rdfs:seeAlso:

ISO 42010, 42020, 12207, 15288, 25010, 25011, 25012

Validation¶

SHACL shapes for each modeling language enforce relationship validity, required properties, and governance rules. The validate.sh script runs syntax checks and SHACL validation.

How the pieces connect¶

All ontologies import arch:core. This means an ArchiMate Application Component, a Backstage Component, and a C4 Container are all arch:Element instances. They can participate in the same views, be governed by the same SHACL shapes, and be traversed in the same SPARQL queries.

Extensions compose freely with modeling languages. You can attach ad:Decision instances to ArchiMate elements, link timefw:FitAssessment to applications, or connect aigov:AISystem governance wrappers to mlsys:MLModel instances. The shared arch:core foundation makes this work without custom integration code.

Cross-language mappings (*-crossmappings.ttl files) provide formal equivalence axioms between frameworks — for example, mapping TOGAF content metamodel entities to ArchiMate elements, or UAF concepts to DoDAF equivalents.

What you can do with it¶

Query across sources. Once architecture artifacts from different tools are converted to RDF against these ontologies, SPARQL queries can traverse the entire landscape. "Which applications support capability X, are classified as Migrate in TIME, and have no architecture decision documenting why?" — one query, four concerns.

Validate automatically. SHACL shapes encode governance rules as executable constraints. Run them in CI/CD. Catch missing owners, invalid relationships, incomplete decisions, and governance gaps before they reach production.

Generate documents. Deliverable templates define SPARQL-driven document structures. The toolbox generators produce Markdown, HTML, and interactive visualizations from the graph.

Enable AI agents. The MCP server exposes the graph to Claude, Amazon Q, or any MCP-compatible agent. Architects ask natural language questions; the agent translates to SPARQL and returns grounded answers.

Build custom metamodels. Extend the core ontology with organization-specific elements, relationships, and validation rules. The ArchiMate implementation (13 files, 17,000+ lines) serves as a reference for what a complete metamodel looks like.

Design principles¶

These are the non-obvious choices that shape the ontologies. Each has a rationale documented in Design Decisions.

OWL for meaning, SHACL for validation, SKOS for navigation. OWL defines vocabulary semantics. SHACL enforces closed-world constraints. SKOS provides classification hierarchies for tool palettes and navigation. They don't overlap.
Minimal OWL profile. Only class declarations, simple hierarchies, property typing, imports, and documentation metadata. No complex restrictions (except TIME, where OWL equivalent classes enable automatic quadrant classification). Everything else goes in SHACL.
No punning. The same IRI is never used as both an OWL class and a SKOS concept. Taxonomies reference OWL classes via skos:narrower or rdfs:seeAlso, but don't declare them as concepts.
domainIncludes/rangeIncludes instead of rdfs:domain/rdfs:range. Domain and range in RDFS are inference axioms, not constraints. Using them causes unintended type inference. Annotation properties provide tooling hints without polluting the type graph. See the Domain & Range Guide for the full explanation.
Qualified relationships. Every relationship has three representations: a direct predicate for graph traversal (am:serves), a qualified relationship resource for metadata and provenance (am:Serving instance), and an rdf:reifies bridge (RDF 1.2). This supports both simple SPARQL queries and rich architecture management.
Standards are reference vocabularies, extensions are model elements. ISO standard concepts don't subclass arch:Element — they're definitions you reference. Extension concepts do subclass arch:Element — they appear in models and views.

Getting started¶

If you want to...	Start here
Understand the architecture approach	Architecture & Approach
Build a metamodel from scratch	Quick Start Guide
See what modeling languages are available	Modeling Languages Guide
Add decision tracking, processes, or other extensions	Extensions Guide
Integrate TOGAF, DoDAF, or other frameworks	Frameworks Guide
Write SHACL validation rules	Validation Guide
Understand the design rationale	Design Decisions
See working examples	`examples/` directory

Limitations¶

This is the semantic layer, not a complete platform. The ontologies define vocabulary and validation rules. You still need converters to get data in, generators to get views out, and a SPARQL engine to query it. The toolbox (separate repository) provides these, but it's not a turnkey product.
Semantic web skills required. Working with these ontologies requires familiarity with RDF/Turtle syntax, basic OWL concepts, and SPARQL for queries. SHACL for validation. This is a real barrier for teams without semantic web experience.
The ontologies model the language, not the enterprise. Linked.Archi defines what an Application Component is and how it relates to other concepts. It doesn't contain your organization's actual applications. You populate the graph with your own instance data (or convert it from existing tools).
Not all modeling languages are equally mature. The ontology implementations vary in completeness. ArchiMate 3.2 is the reference implementation. See individual module READMEs for current status.