Skip to content

Architecture and Approach

Layered architecture of the Linked.Archi semantic stack — scattered data sources unified through a three-tier module structure of Languages, Frameworks, and Extensions around an ISO 42010 core, projected as queryable model instances

This document explains the technical architecture of the Linked.Archi ontology ecosystem — the core thesis, the standards alignment, how modules compose, and the key modelling patterns.

For what the project is and what's in it, see What is Linked.Archi?. For how the pipeline works end-to-end, see Bridging Architecture Silos.

Core thesis

An architecture metamodel can be expressed as the abstract syntax of a domain-specific modelling language. Representing it in RDF lets us assign each layer of the language to the formalism suited to it: OWL for the core concepts and their logical relationships, SKOS for the controlled vocabularies and taxonomies used to classify and tag architecture elements, and SHACL for structural validation and constraints. The result is a single integrated graph offering machine-interpretable precision, vocabulary-level interoperability, SPARQL queryability, and — using SKOS concept schemes as classification axes — the ability to generate stakeholder-specific views from one source of truth.

This is the foundational idea. An ArchiMate metamodel, a C4 model, a Backstage catalogue schema — these are all domain-specific languages. OWL gives us the formal semantics for the core concepts; together with RDFS it forms the meta-language for defining them. SHACL is the constraint language we use to validate them. SKOS is the classification language we use to organise them. SPARQL is the query language we use to traverse them.

The W3C semantic web stack is not the only way to do this (you could use JSON Schema, or GraphQL, or a custom DSL). We chose it because:

  • Formal semantics eliminate interpretation ambiguity
  • Standard query language (SPARQL) works across all modules
  • Inference capabilities derive new facts from existing ones
  • The ecosystem is mature (Protégé, triplestores, SHACL validators, WIDOCO)
  • Multiple serializations (Turtle, JSON-LD, N-Triples) serve different consumers

We accept the costs that come with this choice — a steeper learning curve, a smaller talent pool, and an open-world default that does not match enterprise validation expectations. The last is precisely why SHACL, not OWL axioms, carries the constraint-checking role in our stack.

ISO/IEC/IEEE 42010 alignment

The core ontology aligns with ISO 42010 (Architecture Description). This gives us a framework-agnostic foundation that any modelling language can plug into:

ISO 42010 Concept Linked.Archi Class Role
System-of-Interest arch:System The subject being architected
Architecture arch:Architecture Fundamental concepts/properties of a system
Architecture Description arch:Model Work product expressing the architecture
Architecture Viewpoint arch:Viewpoint Specification for a kind of view
Architecture View arch:View Representation addressing a set of concerns
Stakeholder arch:Stakeholder Party with interests in the system
Concern arch:Concern Interest in the system
Model Kind arch:Metamodel Manifest aggregating all resources for a modeling language

The distinction between Architecture (abstract, inherent to a system) and Architecture Description (work product) is preserved. Multiple frameworks (TOGAF, DoDAF, Zachman, ADMIT) map to the same foundation because ISO 42010 is framework-agnostic by design.

In Linked.Archi, a Framework represents any community-recognised architecture framework — deliberately heterogeneous, since the community applies the term to artefacts of very different natures. As the core ontology notes, a framework may contain a metamodel (TOGAF's Content Metamodel), may be primarily a classification schema or ontology (the Zachman Framework), and may additionally define processes (TOGAF's ADM). A Metamodel is the formalised definition of a modelling language: a manifest tying together the model-concepts ontology, SHACL shapes, derivation rules, viewpoints, taxonomy, and deliverable templates, and optionally declaring the Framework it is definedByFramework. The tiers therefore preserve each artefact's identity as its community defines it; what a module contributes is read from the typed manifest properties it populates (modelConcepts for vocabulary, viewpointLibrary/architectureViewpoints for viewpoints).

Module composition

Each ontology is independently publishable with versioned IRIs:

Module Import Structure All modules import arch:core. Organisations adopt only what they need — extensions compose freely.

Organisations adopt only the modules they need. A team using ArchiMate + architecture decisions imports two ontologies. A team adding TIME portfolio assessment imports a third. Extensions compose freely because they all share arch:core.

In Linked.Archi a Metamodel is a manifest that ties together a modelling language's constituent resources through typed properties — arch:modelConcepts for the element/relationship ontology, arch:formalRules for SHACL shapes, arch:conceptClassification and arch:viewpointLibrary for SKOS taxonomies, arch:architectureViewpoints for viewpoints, and arch:hasDeliverableTemplate for deliverable templates. What a module contributes is therefore read directly from the manifest properties it populates, with no auxiliary role vocabulary required. ArchiMate 3.2 populates the full manifest — ontology, taxonomy, four sets of SHACL shapes, derivation rules, viewpoints, templates, reference data, and presentation contexts — and is thus a complete modelling language. TOGAF populates a Content Metamodel ontology and an ADM process taxonomy and viewpoints, making it the hybrid the core anticipates when it notes that "a Metamodel could be defined within a framework … [and] Frameworks may define other concepts like Processes, which is the case with TOGAF ADM." Zachman, by contrast, populates only a classification taxonomy (six Aspects, six Perspectives, thirty-six Cells), SHACL shapes, and templates — and explicitly defines neither element types nor viewpoints, being a classification schema realised essentially as a SKOS concept scheme. The frameworks tier is heterogeneous precisely because the architecture community applies the term to artefacts as different as these; Linked.Archi preserves each one's semantics as its originating body defines it rather than forcing a uniform shape.

The architecture is organised as a single shared foundation, arch:core, with three tiers of modules layered on top. Modelling languages (ArchiMate, BPMN, C4, …) supply element and relationship vocabularies — the what of a model. Frameworks (TOGAF, Zachman, TIME, …) supply method, structure, and viewpoints — the how of organising a model. Extensions (architecture decisions, quality attributes, AI governance, …) add cross-cutting concerns that any language or framework may draw on. Every module imports arch:core and, occasionally, other modules they explicitly build on, so each can be adopted in isolation.

arch:core is the framework-agnostic foundation every module builds on. It is deliberately empty of domain vocabulary — it defines no ApplicationComponent, no BusinessProcess, no notation-specific element types; everything domain-specific lives in a module. What it does provide is the structural backbone shared across all tiers: the ISO/IEC/IEEE 42010 classes (arch:System, arch:Architecture, arch:Model, arch:Viewpoint, arch:Stakeholder, arch:Concern), the generic element and relationship machinery on which the qualified-relationship pattern builds, the Consideration hierarchy (Concern / Aspect / Perspective) that frameworks populate differently, the arch:Metamodel manifest vocabulary, and the SKOS scaffolding for classification. The principle is not that core is small, but that core is domain-neutral: it carries the architecture-description framework that every modelling language and framework specialises, and nothing that commits to a particular language or domain. (The ISO 42010 classes and the Consideration hierarchy are detailed in the sections above and below respectively.)

Organisations therefore adopt only the modules they need. A team using ArchiMate plus architecture decisions imports two modules over core; a team adding TIME portfolio assessment imports a third. Because every module grounds its vocabulary in the same domain-neutral foundation, extensions compose freely — an architecture decision can reference an ArchiMate component, and a TIME assessment can score it, without any module needing to know about the others.

The three tiers classify modules by their ontological role in the structure, not by their genre in the architecture literature. A modelling language contributes instantiable element and relationship types — the constructs models are built from (ArchiMate, BPMN, C4; and, because arch:core is domain-neutral, business-design languages such as BMC and EDGY, which contribute element types regardless of whether the domain is business or IT). An extension contributes cross-cutting properties attachable to elements from any language — a decision, a quality attribute, a cost, a governance status.

The frameworks tier is deliberately the most heterogeneous of the three, and intentionally so. "Framework" is the term the architecture community applies to a broad and internally diverse set of artefacts that are, for the most part, not formally related to one another: some are primarily process (ATAM is a set of evaluation processes operating over quality attributes; TOGAF's ADM is a phased method), some are primarily viewpoint classification (Zachman classifies views and viewpoints; 4+1 organises concerns into views), and some bundle several roles at once (TOGAF combines a content metamodel of instantiable elements, the ADM process, and a set of viewpoints). Rather than force these into a single artificial shape, the framework tier preserves each module's semantics as its originating community defines them. The tier is therefore a faithful umbrella over community-recognised frameworks, not a claim that its members share a common structure.

Key modelling patterns

Minimal OWL profile

The metamodel uses a deliberately small subset of OWL and delegates everything else to SHACL. The guiding principle is the separation of description from validation: OWL describes what the vocabulary is — its classes, properties, and hierarchy — while SHACL enforces what a conforming model must satisfy.

This split exists because OWL operates under the Open World Assumption (OWA): the absence of a statement does not make it false. Architecture governance needs the opposite — closed-world validation, where "every application must have an owner" is a checkable rule whose violation is an error, not an invitation to infer a missing owner. SHACL provides exactly this. Mixing OWL constraint axioms with governance rules — expecting owl:cardinality or rdfs:domain to behave like validation — is a frequent and well-documented failure mode in enterprise ontology projects. The profile below avoids it by construction.

What OWL handles

OWL is restricted to constructs that describe the vocabulary without imposing constraint-style inference:

  • class and property declarations
  • a simple taxonomic hierarchy via rdfs:subClassOf
  • property typing (owl:ObjectProperty vs owl:DatatypeProperty)
  • modularisation via owl:imports
  • documentation metadata (labels, definitions, provenance)

What SHACL handles

Everything with constraining force:

  • cardinalities and required properties
  • value constraints and datatype/range enforcement
  • closed shapes
  • conditional rules
  • relationship validity (which element types may connect to which)

The remainder of this section justifies, construct by construct, why each retained piece of OWL is safe to keep given that the profile's whole purpose is to push constraints into SHACL. The test applied throughout is simple: a construct may stay in OWL only if its inference is either absent, or wanted and predictable, and never if it masquerades as validation.

rdfs:subClassOf

We keep rdfs:subClassOf for taxonomic hierarchy. Subclass does carry inference under the OWA — membership propagates upward — but this is precisely the inference we want: an instance of am:ApplicationComponent should be inferable as an arch:Element. The inference is monotonic and predictable, and it never acts as validation. We rely on it for query generalisation (querying for all arch:Element instances returns every subtype) and for palette inheritance in tooling, while keeping cardinality, required properties, and disjointness in SHACL. Subsumption is the one place where OWA inference is an asset rather than a hazard.

owl:ObjectProperty / owl:DatatypeProperty

We declare properties as owl:ObjectProperty or owl:DatatypeProperty solely to distinguish relationships (links between resources) from attributes (literal-valued data). This typing carries no constraining force: it does not restrict which classes a property may apply to, nor how often it may be used; it only fixes whether the value is a resource or a literal. It exists so that tooling can tell an edge from a field when generating palettes, forms, and serializations. Any restriction on where a property may be used lives in SHACL, and looser guidance lives in arch:domainIncludes / arch:rangeIncludes (below).

owl:imports

We use owl:imports for modularisation — the mechanism by which every module pulls in arch:core and, where applicable, the modules it builds on. owl:imports is purely structural: it composes graphs by transitive inclusion and carries no domain-level inference of its own. It is what lets the layered module structure resolve to a single graph for reasoning, validation, and querying without any module restating core's definitions. Import is about assembly, not semantics.

domainIncludes / rangeIncludes

We use annotation properties (arch:domainIncludes, arch:rangeIncludes) instead of rdfs:domain/rdfs:range for relationship guidance. Domain and range in RDFS are inference axioms — they cause unintended type inference. Annotation properties provide tooling hints without polluting the type graph. Actual constraints live in SHACL. See DD-8 and the full Domain & Range Guide.

Retained property characteristics

A small number of OWL property characteristics are kept because their inference is wanted, not as oversights. These are the only OWL axioms in the profile that do inferential work beyond subsumption, and they are bounded deliberately:

  • Transitivity on the compositional properties hasPart / partOf, so that part-of chains resolve automatically across a model.
  • Inverse pairs (e.g. hasPart ⇔ partOf, refines ⇔ refinedInto), so that traversal in either direction is available without asserting both triples.
  • Functionality on arch:prefVisNotation (one preferred visual notation per concept).

Every other characteristic-style constraint — cardinality, uniqueness as validation, disjointness, value restrictions — is expressed in SHACL. The line is explicit: OWL carries subsumption plus this short, fixed list of inferential conveniences; SHACL carries all enforcement.

The same separation of description from inference that governs the rest of the profile governs how we link the same real-world entity across sources. The default is skos:exactMatch: it states that two nodes correspond — are interchangeable for querying — without asserting they are the same individual, and it carries no OWL entailment. This keeps cross-source links in the same inference-free everyday path as the rest of the profile: a plain SPARQL engine traverses the link, no reasoner required, and each node keeps its native type.

owl:sameAs is admitted only as a deliberate exception, for confirmed-identity cases where a full, reasoned property merge is genuinely wanted — analogous to how the profile admits transitivity on hasPart/partOf: a bounded, documented use of OWL inference where its effect is the desired feature, not an accident. The test is substitutability — whether a reasoner could safely treat the two IRIs as one everywhere. Because that test usually fails across notations (which describe systems at different granularities), owl:sameAs stays the exception and skos:exactMatch the rule.

This is the same discipline applied throughout: subsumption and a short, named list of property characteristics are the only inference we rely on by default; everything else — including cross-source identity in the common case — is expressed without invoking a reasoner.

Qualified relationships

Every relationship type has three representations:

  1. Direct predicate — ex:AppSvc1 am:serves ex:BizProc1 — for SPARQL traversal and analytics
  2. Qualified resource — an am:Serving instance with arch:source, arch:target, metadata, lifecycle — for architecture management
  3. RDF 1.2 bridge — rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> — connects the direct triple to the resource

This matters because enterprise architecture needs both simple graph queries ("what serves what?") and rich relationship management (provenance, lifecycle states, multiple distinct edges between the same pair, higher-order modelling).

See Relationship Modelling Guide for the full pattern and DD-10 for the rationale.

Dual classification (OWL + SKOS)

  • OWL class hierarchies provide formal semantics that reasoners and SHACL shapes use ( am:BusinessActor rdfs:subClassOf am:ActiveStructureElement)
  • SKOS concept schemes provide navigation and classification for tools (palette generation, filtering, faceted search)

The two are linked via rdfs:seeAlso but kept separate — no punning. See DD-6 and DD-7.

The Consideration hierarchy (Concerns, Aspects, Perspectives)

ISO 42010 says a Viewpoint frames Concerns. We extend this into a three-level hierarchy under arch:Consideration:

Consideration Hierarchy Three levels of Consideration: Concern (specific interest), Aspect (structural dimension), Perspective (stakeholder level).

Each level serves a different classification purpose, and different frameworks populate them differently:

Concerns are the most specific — they describe what a viewpoint actually shows. ArchiMate viewpoints define concerns like "Structure of the enterprise in terms of roles, departments" or "Dependencies between application components." The 4+1 model's views (Logical, Process, Development, Physical, Scenarios) are also concerns — they describe what set of interests a viewpoint addresses.

Aspects are structural dimensions — orthogonal cuts across the architecture. ArchiMate's core structural aspects are: Active Structure (who/what performs), Behaviour (what is performed), Passive Structure (what is acted upon). Coachman's interrogatives (Inventory/What, Process/How, Distribution/Where, Responsibility/Who, Timing/When, Motivation/Why) serve the same role — they describe which fundamental question an artefact answers.

Note: Some concepts sit between categories. "Motivation" (Why) is an interrogative/aspect in Coachman's world, but could equally be modelled as a Concern or a Perspective depending on the framework. The Consideration hierarchy provides the vocabulary — the designer of the metamodel decides which concepts to use and how to classify them.

Perspectives are stakeholder abstraction levels — who is looking and at what level of detail. ArchiMate defines: Strategic, Operational, Application, Infrastructure, Governance. Coachman's perspectives (Executive, Business Management, Architect, Engineer, Technician, Enterprise) are perspectives — they describe progressive reification from abstract to concrete.

The corresponding properties on arch:Viewpoint:

Property Range Purpose Example
arch:viewpointFramesConcern arch:Consideration Generic — any consideration fourplus1:LogicalView
arch:viewpointCoversAspect arch:Aspect Which structural dimension zach:Inventory, am:ActiveStructureAspect
arch:viewpointAddressesPerspective arch:Perspective Which stakeholder level zach:Architect, am:StrategicPerspective

Example — an ArchiMate viewpoint classified across frameworks:

amvp:OrganizationViewpoint
    a                                  arch:Viewpoint ;
    skos:prefLabel                     "Organization Viewpoint"@en ;
    arch:viewpointFramesConcern        amvp:OrgStructureConcern ;
    arch:viewpointCoversAspect         am:ActiveStructureAspect, zach:Responsibility ;
    arch:viewpointAddressesPerspective am:OperationalPerspective, zach:BusinessManagement ;
    arch:targetsStakeholder            am:EnterpriseArchitect .

This viewpoint is simultaneously classified by ArchiMate's aspects/perspectives and Coachman's interrogatives/perspectives — enabling cross-framework completeness queries without a dedicated classification property.

Metamodel as manifest

A metamodel (arch:Metamodel) is not merely an ontology. It is a manifest that aggregates the constituent resources making up a modelling language: the element and relationship ontology (arch:modelConcepts), SHACL shapes (arch:formalRules), derivation rules, viewpoints (arch:architectureViewpoints), the SKOS classification and viewpoint taxonomies (arch:conceptClassification, arch:viewpointLibrary), deliverable templates, reference data, and presentation contexts. It is also the resource a model declares conformance to — per ISO/IEC/IEEE 42010, an architecture description is based on a metamodel, which may itself be an aggregate of several domain metamodels.

Structure of a Linked.Archi Semantic Set Anatomy of a metamodel manifest — the entry point that aggregates all constituent resources making up a modeling language or framework definition.

A manifest need not aggregate every possible resource; it aggregates those the language actually defines. A minimal language may declare only an ontology, while a mature one accrues shapes, viewpoints, taxonomies, and templates over time.

Two physical arrangements, one logical thing

The manifest is a logical role, not a mandatory separate file. How it is packaged depends on how many constituent resources the language has:

  • Self-typing ontology (simple case). When a language consists of little more than its ontology, the ontology file is the manifest: a single IRI typed as both owl:Ontology and arch:Metamodel. This dual typing is deliberately consistent — no second file is introduced where one would carry no additional resources.
  • Separate manifest file (complex case). Once a language accumulates SHACL shapes, viewpoints, a taxonomy, deliverable templates, and presentation contexts as independent artefacts — as ArchiMate does — a standalone manifest references each of them. This keeps every artefact independently editable, versionable, and reusable, and avoids collapsing the whole language definition into one monolithic file.

The deciding criterion is therefore resource count and separation of concerns: prefer the self-typing form until the language has enough distinct artefacts that referencing them from a dedicated manifest is clearer than inlining them.

Why this matters

Because every constituent resource hangs off a typed manifest property, a module's contribution can be read directly from the manifest — which properties it populates tells you whether it supplies element types (arch:modelConcepts), viewpoints (arch:architectureViewpoints / arch:viewpointLibrary), validation (arch:formalRules), classification (arch:conceptClassification), or only a subset. This is what makes the module catalogue self-describing and queryable, and it is why no separate module-role vocabulary is required: the manifest already carries that information structurally.

See DD-13.

References