Core Linked.Archi Ontology
type: NamedIndividual
license: http://creativecommons.org/licenses/by/4.0/
created: 2019-03-17
creator: me
creator: Kalin Maldzhanski
description: 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.
issued: 2019-03-17
modified: 2026-04-12
publisher: linked.archi
publisher: Linked.Archi
introduction section: Core Linked.Archi Ontology for EA modeling.
status: draft
preferred namespace prefix: arch
citation: Core Linked.Archi Ontology
type: Ontology
prior version: 0.3.1#
version info: 0.3.2

Architecture
type: Class
definition: fundamental concepts or properties related to a :System in its environment embodied in its elements, relationships, and in the principles of its design and evolution. Architecture is different form Architecture description as Specified in ISO/IEC/IEEE 42010 Standard. Architecture is an abstract Concept that maps directly to a System of in other words Entity of Interest. Any System has an Architecture whether intentional or accidental, known or unknown, documented or contained as tacit knowledge. Architecture Description (see ISO/IEC/IEEE 42010) is a work product that expresses the architecture. In Linked .Archi context :Model is a more formal specialization of Architecture Description.
scope note: Derived from ISO/IEC/IEEE 42010: "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution." The standard distinguishes Architecture (inherent to a system) from Architecture Description (a work product).

Aspect
type: Class
subclass of: Consideration
definition: Architecture Aspect example: data, activity, function, location, people, time, motivation, taxonomy, structure, connectivity, behaviour, information, parameters, constraints, roadmaps, traceability, requirements

Catalog
type: Class
subclass of: View
definition: Catalog is a list of building blocks of a specific type, or of related types, that are used for governance or reference purposes (for example, an organization chart, showing locations and actors). As with building blocks, catalogs carry metadata according to the metamodel, which supports query and analysis.
scope note: Aligned with TOGAF Architecture Content Framework: "a list of building blocks of a specific type, or of related types, that are used for governance or reference purposes." See TOGAF 10 Architecture Content, Chapter 3.

Concern
type: Class
subclass of: Consideration
definition: Example concerns: — The purpose or missions of the system — The appropriateness of the system for use in fulfilling its missions — The feasibility of constructing the system — The risks of system development and operation to users, acquirers, and developers of the system — Maintainability, deployability, and evolvability of the system
scope note: Derived from ISO/IEC/IEEE 42010: "any interest in the system." The term derives from "separation of concerns" (Dijkstra). Examples include purpose, functionality, structure, behavior, cost, supportability, safety, interoperability.

Consideration
type: Class
definition: Abstract base class for concerns, aspects, and perspectives — the interests that shape how architecture is described and communicated. Subclasses: Concern, Aspect, Perspective.

DeliverableTemplate
type: Class
subclass of: CreativeWork
definition: A template that defines the content structure of an architecture deliverable by specifying which viewpoints it requires and which presentation formats it supports. Each required viewpoint acts as a placeholder — the actual views are created when someone uses the template to produce a concrete deliverable. A concrete deliverable (arch:Model) is produced by instantiating a DeliverableTemplate: for each required viewpoint, a View conforming to that viewpoint is created and added to the Model via arch:contains.
scope note: Aligned with TOGAF Architecture Content Framework where deliverables (e.g., Architecture Definition Document, Architecture Requirements Specification) are defined as aggregations of specific catalogs, matrices, and diagrams. Also aligned with ISO/IEC/IEEE 42010 where an Architecture Description is comprised of Architecture Views, each governed by a Viewpoint. DeliverableTemplates are defined at the Metamodel level via arch:hasDeliverableTemplate, alongside other metamodel components (elements, relationships, viewpoints, rules). Models instantiate them via arch:deliverableTemplateUsed. Example: archvp:ArchitectureDefinitionDocument a arch:DeliverableTemplate ; arch:templateRequiresViewpoint amvp:Organization, amvp:ApplicationCooperation, amvp:ImplementationDeployment ; arch:templateHasFormat archdt:MarkdownFormat, archdt:PDFFormat ; arch:templateTargetsPurpose archvp:Designing . When instantiated: ex:MyADD a arch:Model ; arch:deliverableTemplateUsed archvp:ArchitectureDefinitionDocument ; arch:contains ex:OrgView, ex:AppCoopView, ex:DeployView . ex:OrgView a arch:Diagram ; arch:viewConformsToViewpoint amvp:Organization .

Diagram
type: Class
subclass of: View
definition: Diagrams are renderings of architectural content in a graphical format to allow stakeholders to retrieve the required information. Diagrams can also be used as a technique for graphically populating architecture content or for checking the completeness of information that has been collected. The TOGAF content framework defines a set of architecture diagrams to be created (e.g., organization chart). Each of these diagrams may be created several times for an architecture with different style or content coverage to suit stakeholder concerns.
scope note: Aligned with TOGAF Architecture Content Framework: "renderings of architectural content in a graphical format to allow stakeholders to retrieve the required information." See TOGAF 10 Architecture Content, Chapter 3.

Element
type: Class
subclass of: ModelConcept
definition: Element is the class for Elements or Nodes used in models. Element sub-classes are to be defined in more specific Architecture Meta Models Element instances are to be used in the actual Architecture Models. In general an Architecture Element represents any significant component of the architecture that needs to be addressed.

Environment
type: Class
definition: The context in which a system exists, including external entities, conditions, and influences that interact with or affect the system. Derived from ISO/IEC/IEEE 42010.

Folder
type: Class
subclass of: ItemList
definition: UI/navigation container used to preserve tool-native organization (containment + stable display order). Not a domain/architecture semantic construct.

Framework
type: Class
subclass of: CreativeWork
definition: Framework in Linked.Archi context is used to represent any type of Architecture framework. A Metamodel could be defined within a framework and thus part of it example Togaf Content Metamodel or OAF which is mostly a MetaModel or Zachman Framework even an Ontology. Frameworks may define other concepts like Processes, which is the case with Togaf ADM. Framework is characterized with ... check is standard...
scope note: Maps to ISO/IEC/IEEE 42010 "Architecture Framework" — conventions, principles, and practices for architecture description established within a specific domain or community. Examples: TOGAF, Zachman, ADMIT.

Matrix
type: Class
subclass of: View
definition: Matrix is a grid that shows relationships between two or more model entities. Matrices are used to represent relationships that are list-based rather than graphical in their usage (for example, a CRUD matrix showing which applications Create, Read, Update, and Delete a particular type of data is difficult to represent visually).
scope note: Aligned with TOGAF Architecture Content Framework: "a grid that shows relationships between two or more model entities." See TOGAF 10 Architecture Content, Chapter 3.

Metamodel
type: Class
definition: A Metamodel in Linked.Archi context is the definition (Model) of a Modeling Language, so that models can be expressed in a way that communicates information about a system among involved stakeholders and can be correctly interpreted by those stakeholders and supporting technologies. The Modeling Language formalizes the structure, terms, notations, syntax, semantics, integrity rules, inference/derivation rules, and also a set of standard Viewpoints. Well-known modeling languages that can be formalized as Linked.Archi metamodels include UML, BPMN, ArchiMate, C4, E/R, and SQL Schema. These are domain-level languages whose concepts become arch:Element and arch:QualifiedRelationship subclasses in the knowledge graph. Note: RDF/OWL/SHACL/SKOS is the representation framework in which all the above modeling languages are expressed — it operates at the meta-meta level, not as a peer of UML or BPMN. Listing OWL alongside UML as a "modeling language" is technically defensible (OWL can model domains), but in the Linked.Archi context OWL is the substrate, not a sibling. The OMG Ontology Definition Metamodel (ODM, formal/2014-09-02) explicitly defines the mapping between MOF/UML and OWL/RDF, confirming that RDF/OWL is the layer below MOF-based languages that enables their semantic integration. A model is said to conform to a modeling language. ISO/IEC/IEEE 42010 Architecture Description can be based on a specific metamodel, which can be a simple metamodel or an aggregate of multiple metamodels from different domains. A Metamodel is a manifest that ties together all constituent resources: the model concepts ontology, SHACL shapes, derivation rules, viewpoints, taxonomy, deliverable templates, and other artifacts. It is the entry point for tools that need to discover everything that makes up a modeling language.
scope note: Maps to ISO/IEC/IEEE 42010 "Architecture Description Language" — a language for use in architecture descriptions. In Linked.Archi, a Metamodel aggregates OWL ontologies, SHACL shapes, SKOS schemes, and other resources that together define the vocabulary and rules for a modeling language. In Linked.Archi, RDFS/OWL is the foundational layer (analogous to M3 in the OMG four-layer architecture). Modeling languages like UML, BPMN, and ArchiMate are expressed as OWL ontologies (M2), and model instances are RDF individuals typed with those ontology classes (M1). The OMG four-layer framing is used here for didactic continuity with OMG-trained colleagues, not because MOF is structurally necessary — RDFS is reflective and self-describing without a separate meta-meta tier.

MetamodelingCategory
type: NamedIndividual
type: Concept
definition: Category for concepts that define the modeling language itself — metamodels, viewpoints, and rules.

Model
type: Class
definition: A model is a selective representation of some system whose form and content are chosen based on a specific set of concerns. The model is related to the system by an explicit or implicit mapping. ISO/IEC/IEEE 42010 Architecture Description is an example of a Model, which can be a simple model or an aggregate of multiple models from different domains. The scope and context of a Model is established by analysing the domain subject area and defined by the Metamodel. High-level domains may include: * Telecommunications * Healthcare * Retail * Manufacturing * Transportation * Defense * Government More precise domains within a particular organization may be related to the different organizational bodies and depertments such as * Enterprose Architecture * Solution Architecture * Security Architecture, * Software Engineering * Operational Services * Business Departments...
scope note: Maps to ISO/IEC/IEEE 42010 "Architecture Description" — a work product used to express the architecture of some entity of interest. In Linked.Archi, Model is a more general term that encompasses architecture descriptions and other selective representations.

ModelConcept
type: Class
definition: ModelConcept is the base Class for all Concepts used in an Architecture [Model](#Model), namely: * [Element](#Element) * [QualifiedRelationship](#QualifiedRelationship) * [View](#View) More specific type of construct can be defined by extending this Class. Usually one will not need to use this Class directly, but mostly each of the subclasses. Custom Model Concepts are defined in the [Metamodel](#Metamodel). The palette of available concepts for a modeling tool is built from subclasses of Element (for nodes) and subclasses of QualifiedRelationship (for edges). Both carry visual notations, taxonomy classifications, and domain/range guidance.
rationale: To understand why we have ModelConcepts base Class and why not use directly Concepts or Classes, we first need to understand what does Architecture Model mean in our context. That it is something mainly used to address stakeholder concerns also used to help in and possibly record the decision processes. This means that all those Model Concepts needs to be presented in different context, have specific visual notation according to that context and understood correctly by stakeholders. This involves lots of visual communication and contextual data. Model concepts are also used in the architecture modelling processes and this requires that there is a repository of predefined Concepts that an Architect can use in the Model. There are also certain restrictions that applies to those modelConcepts which are specified in the Architecture framework used and modelled in the :Metamodel(#Metamodel).

ModelingCategory
type: NamedIndividual
type: Concept
definition: Category for concepts used in the modeling process — elements, relationships, and views.

NavigationCategory
type: NamedIndividual
type: Concept
definition: Category for concepts used in navigation and organization — folders, catalogs, and groupings.

Perspective
type: Class
subclass of: Consideration
definition: Stakeholder Perspective. Example: * strategic * capability * operations * services * physical
example: * strategic * capability * operations * services * physical

PresentationCategory
type: NamedIndividual
type: Concept
definition: Category for concepts related to visual presentation — notations, templates, rendering, and context-aware palette generation. Includes: - NotationSet / VisualNotation (type-level visual recipes) - prefVisNotation / altVisNotation (rendered images) - PresentationContext → usesNotationSet (audience-driven selection) - DeliverableTemplate / PresentationFormat (output structure)

PresentationFormat
type: Class
definition: Defines the output format for rendering a deliverable — e.g., Markdown, HTML, PDF, slides, dashboard. A DeliverableTemplate specifies which formats it supports via arch:templateHasFormat.
example: * Markdown * HTML * PDF * Slide Deck (PPT) * Interactive Dashboard
history note: Replaces the earlier arch:PresentationTemplate class, which conflated content structure (what viewpoints to include) with rendering format (how to present). The content structure role is now handled by arch:DeliverableTemplate. The rendering format role is handled by this class.

Purpose
type: Class
definition: As a work product, an AD is devised for the specific purpose for which the architecting effort is undertaken. This purpose shapes the AD and also act as force in the architecting effort. This is the same as "Design Objectives" mentioned in ADD 3.0.
example: For a presales proposal architecture work involves rapid design. Here the main viewpoint would be high level structure and behaviour as well as cost estimations. The design work will not go in details
scope note: Related to ISO/IEC/IEEE 42010 concept of the purpose for which an architecture description is devised. Also related to ADD 3.0 "Design Objectives."

QualifiedRelationship
type: Class
subclass of: ModelConcept
definition: A first-class architectural resource that represents a named, addressable relationship occurrence between two [ModelConcept](#ModelConcept) resources. QualifiedRelationship instances are genuine architectural objects — they have identity, lifecycle, provenance, governance state, and can themselves be the source or target of other relationships (higher-order modeling). Each QualifiedRelationship carries: * [source](#source) — the source element * [target](#target) — the target element The unqualified predicate is determined from: * the class definition via [unqualifiedForm](#unqualifiedForm) (schema-level) * the reified triple via rdf:reifies (instance-level, RDF 1.2) Three complementary representations are emitted for every relationship: 1. **Direct triple** — `source vocab:serves target` — for SPARQL traversal 2. **Qualified predicate** — `source vocab:qualifiedServes relationshipNode` — to navigate to the full resource 3. **Qualified relationship resource** (this class) — carries all metadata: labels, provenance, lifecycle, etc. 4. **rdf:reifies** — bridges the direct triple to this resource (RDF 1.2) With RDF 1.2, `rdf:reifies` bridges the direct triple to this resource, replacing the older rdf:Statement approach. Multiple distinct reifiers for the same proposition are supported — essential when the same logical relation appears in different contexts (current vs target state, observed vs inferred, CMDB-discovered vs design-reviewed). Subclasses of QualifiedRelationship are defined in the metamodel for each specific relationship type. The schema-level mapping to the unqualified predicate is declared using [unqualifiedForm](#unqualifiedForm). The generic fallback predicate [hasQualifiedRelationship](#hasQualifiedRelationship) is used when no type-specific qualified predicate is mapped.
example: # Metamodel: define the relationship type am:serves a owl:ObjectProperty ; skos:prefLabel "Serves"@en ; arch:domainIncludes am:ApplicationService ; arch:rangeIncludes am:BusinessProcess ; . am:Serving a owl:Class ; rdfs:subClassOf arch:QualifiedRelationship ; arch:unqualifiedForm am:serves ; skos:prefLabel "Serving"@en ; arch:prefVisNotation "https://ex.com/serves.svg" ; . am:qualifiedServes a owl:ObjectProperty ; rdfs:range am:Serving ; arch:unqualifiedForm am:serves ; . # Model data: emit both representations ex:AppSvc1 am:serves ex:BizProc1 . ex:AppSvc1 am:qualifiedServes ex:qr-005 . ex:qr-005 a am:Serving ; arch:source ex:AppSvc1 ; arch:target ex:BizProc1 ; rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> ; prov:wasDerivedFrom ex:diagramEdge-81 .
history note: Earlier versions of this ontology had a separate :Relationship class (rdfs:subClassOf :ModelConcept, rdf:Property) using a metaclass pattern where instances were automatically rdf:Property. That class has been removed. Relationship types are now standard owl:ObjectProperty. QualifiedRelationship subclasses serve as the palette concepts for relationship types (symmetric with Element subclasses for element types). The earlier design also based QualifiedRelationship on rdf:Statement with relSource/relTarget/relPredicate as subproperties of rdf:subject/rdf:object/rdf:predicate. That dependency on old-style reification has been removed. RDF 1.2 rdf:reifies is the intended bridge between the direct triple and the relationship resource.
scope note: This class adopts the PROV-O qualified relation pattern (prov:qualifiedInfluence / prov:EntityInfluence) and extends it for architecture modeling. The mapping is: PROV-O Linked.Archi ───── ─────────── prov:EntityInfluence arch:QualifiedRelationship prov:influencer / prov:entity arch:source / arch:target prov:unqualifiedForm arch:unqualifiedForm (schema-level) prov:qualifiedInfluence type-specific qualified property (e.g. am:qualifiedServes) (no equivalent) rdf:reifies (RDF 1.2 — bridges direct triple to resource) With RDF 1.2, rdf:reifies provides the standardized bridge between the direct triple and this resource, replacing the older rdf:Statement approach. Instances of QualifiedRelationship are not reification workarounds — they are managed architectural objects that support lifecycle (proposed → approved → deprecated), governance (ownership, approval), and higher-order links (a risk assessment targeting a data flow).

QualityAttribute
type: Class
type: NamedIndividual
definition: Quality attributes are characteristics of a Software Product Quality, Software in Use Quality, Data Quality, Service Quality, Enterprise Quality, or any other System Quality. An instance of QualityAttribute class represent inherent property or characteristic of an Element or QualityAttributeRequirement so that it can be distinguished quantitatively or qualitatively. Quality Attribute is quantified by [QualityMeasure](#QualityMeasure) that can be related to an Element or QualityAttributeRequirement. Element in that case can be a work product or behavior of a system, software, or stakeholders such as users, operators, developers, testers, or maintainers.
scope note: Aligned with ISO/IEC 25010 (Systems and software quality models) and the SEI/CMU quality attribute characterization. Quality attributes are key architectural forces in the ADD (Attribute-Driven Design) method.
mentionedIn: Quality Attributes

QualityMeasure
type: Class
type: NamedIndividual
definition: Used to quantify QualityAttributes
mentionedIn: Quality Attributes

Stakeholder
type: Class
subclass of: Element
definition: :Stakeholder is the class for Stakeholders used in describing high level architecture interest. Stakeholder is a first-class element and represented in the Code ontology as it affects directly the way the architecture and architecture description will be organized and thus impact the MetaModel. Stakeholder can be used also as a :ModelConcept and for that :Element can be extended. Same instance of :Stakeholder and :element can be used and this also recommended as will benefit the analysis and inference. Example Types of stakeholders: a) Users of the system b) Acquirers of the system c) Developers of the system d) Maintainers of the system
scope note: Derived from ISO/IEC/IEEE 42010: "individual, team, or organization holding concerns for the system of interest." Also aligned with ArchiMate Stakeholder element and TOGAF stakeholder management.

System
type: Class
definition: The subject of interest of a Model that is a combination of interrelated and interdependent parts organized to achieve one or more stated purposes. As such a system is defined by its structure and purpose. A system is influenced by its environment and may be bounded by space and time. This is inclusive of designs at all levels such as an entire enterprise, a process, information structures or I.T. systems.
scope note: Maps to ISO/IEC/IEEE 42010 "Entity of Interest" (2022 edition) or "System of Interest" (2011 edition). The standard uses "system" as a placeholder that can refer to an enterprise, system of systems, product line, service, subsystem, or software.

TemplateSection
type: Class
definition: An ordered section within a DeliverableTemplate that references a Viewpoint. When the template is instantiated, each TemplateSection becomes a placeholder for a View conforming to the referenced viewpoint. Sections carry an order index for sequencing and optional guidance text.
example: archvp:ADDSection1 a arch:TemplateSection ; arch:sectionOrder 1 ; arch:sectionViewpoint amvp:Organization ; skos:prefLabel "1. Organizational Structure"@en ; skos:definition "Document the organizational structure using the Organization Viewpoint."@en .

View
type: Class
subclass of: ModelConcept
definition: Architecture View is a representation of a system from the perspective of a related set of concerns. It consists of one or more architecture models of the system
scope note: Maps to ISO/IEC/IEEE 42010 "Architecture View" — a representation of a system from the perspective of a related set of concerns. A view is governed by its viewpoint. Subtypes Catalog, Matrix, and Diagram align with TOGAF artifact classification.

Viewpoint
type: Class
definition: An architecture Viewpoint is a specification of the conventions for a particular kind of architecture view. It can also be called the definition or schema for that kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern (or set of concerns) about a system-of-interest. A viewpoint can be seen as a diferent perspective of the subject area that shapes the Metamodel, which defines the Model. Viewpoints may look quite different so as to be meaningful to different stakeholders
scope note: Derived from ISO/IEC/IEEE 42010: "a work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns." Also aligned with ArchiMate Chapter 14 and TOGAF viewpoint definitions.
qualified attribution: dd

alternative Visual Notation
type: ObjectProperty
domain includes: ModelConcept
domain: Concept
range: ImageObject
sub property of: image
broader: PresentationCategory
definition: An alternative rendered visual notation image for a resource. A resource can have multiple altVisNotation values — one per alternative PresentationContext or NotationSet. For example, a BusinessActor might have: - prefVisNotation → standard ArchiMate icon (for architects) - altVisNotation → simplified flat box (for executives) - altVisNotation → monochrome version (for printing) When multiple notation sets exist, each VisualNotation in a non-default set produces an altVisNotation on the concept it describes.

architectureViewpoints
type: ObjectProperty
domain: Metamodel
range: Ontology
broader: MetamodelingCategory
definition: architectureViewpoints property specifies the ontology that defines the architecture viewpoints including Concerns and Stakeholders and also restriction on the viewpoints.

architectureViewpointsRestrictions
type: ObjectProperty
domain: Metamodel
range: Ontology
sub property of: shapesGraph
broader: MetamodelingCategory
definition: architectureViewpoints property specifies the ontology that defines restriction on the viewpoints using SHACL or other method. This can also be used for SHACL processors.

associatedStandard
type: ObjectProperty
type: NamedIndividual
domain: ModelConcept
range: CreativeWork
broader: MetamodelingCategory
definition: any reference to as standard that is relevant to the subject and can or should be referenced. Any associated standard should be part of the [standardsInformationBase](#standardsInformationBase). This sometimes require validation in that case standrad may be present in the Model but not in the Metamodel stands information base, however, should be put in the next version of the Metamodel.
mentionedIn: chap06.html

definedByFramework
type: ObjectProperty
domain: Metamodel
range: Framework
sub property of: hadPrimarySource
definition: The :Framework that is used as a foundation for the :MetaModel

conceptClassification
type: ObjectProperty
domain: Metamodel
range: ConceptScheme
broader: NavigationCategory
definition: ConceptClassification resource is a Scheme that defines the classification of the Elements, Relationships and Viewpoints or other Model Concepts defined within a Metamodel or ontology for example: `rdf:type skos:ConceptScheme , owl:Ontology` is a consistent statement This classification could be used for visual aid and modelling. More than one classifications can exist. Classifications can be embedded within the Metamodel ontology. SKOS concept scheme(s) needs to be supplied.

Concept Owner
type: ObjectProperty
domain: ModelConcept
range: Stakeholder
definition: Indicates the stakeholder or governance body responsible for the maintenance and governance of an architecture concept within the architecture repository.
editorial note: Use this property to explicitly document ownership to avoid ambiguity in governance responsibilities across various organisational units or roles.
scope note: This property helps to clearly identify accountability and stewardship, facilitating effective governance and lifecycle management of architecture elements.

contains
type: ObjectProperty
domain: Model
range: View
definition: Links a Model to the Views it contains. A Model (architecture description) is a deliverable that aggregates multiple Views, each conforming to a Viewpoint.
scope note: In ISO/IEC/IEEE 42010, an Architecture Description is comprised of one or more Architecture Views. In TOGAF, a deliverable (e.g., Architecture Definition Document) contains multiple catalogs, matrices, and diagrams. In Linked.Archi, arch:Model serves as both the ISO 42010 Architecture Description and the TOGAF deliverable concept. A Model can be instantiated from a DeliverableTemplate, which specifies which viewpoints are required. Each required viewpoint becomes a placeholder for a View: Example: ex:ArchDefinitionDoc a arch:Model ; arch:deliverableTemplateUsed archvp:ArchitectureOverviewDocument ; arch:contains ex:OrgChart, ex:AppLandscape, ex:TechDeployment ; arch:modelHasPurpose ex:CloudMigration . ex:OrgChart a arch:Diagram ; arch:viewConformsToViewpoint amvp:Organization .

deliverableTemplateUsed
type: ObjectProperty
domain: Model
range: DeliverableTemplate
definition: Links a Model (concrete deliverable) to the DeliverableTemplate it was instantiated from. This enables traceability from a deliverable back to its template and validation that all required viewpoints have corresponding views.

derivationRules
type: ObjectProperty
domain: Metamodel
range: Ontology
sub property of: shapesGraph
broader: MetamodelingCategory
definition: DerivationRules property specifies the document that defines the possible derivation rules. A way to express those rules could be N3 notation. This can also be used for SHACL processors.

domainIncludes
type: AnnotationProperty
definition: defines classes for the subject of a Relationship. It is not to be used for validation
scope note: Values of this property define the type of the source Element; in simple relationships, this would be the subject. This property is used for guiding modelling but not restricting relationships. Relationship restrictions, like other types of restrictions, should be implemented using SHACL.

environment
type: ObjectProperty
domain: System
range: Environment
definition: System Situated In Environment which System and Environment interact some way or another.

exposedInView
type: ObjectProperty
domain: ModelConcept
range: View
definition: Concepts property that specifies the individual Views that exposes that Concept such as Elements, Relationships or other Views. In the case of a relationshipRDF* or statement can be used to link the triple with the View.

formalRules
type: ObjectProperty
domain: Metamodel
range: Ontology
sub property of: shapesGraph
broader: MetamodelingCategory
definition: FormalRules property specifies all the rules that a Model needs to conform to. This include Element structure, relationships, properties even naming conventions. A way to represent those rules can be SHACL. This can also be used for SHACL processors.

generatorCommand
type: DatatypeProperty
domain: PresentationFormat
range: string
definition: The shell command or pipeline used to produce the deliverable output from the knowledge graph and the template resource. The command receives the SPARQL endpoint or data file as input and produces the rendered output.
example: "handlebars render --template aod.md.hbs --data sparql://localhost:7200" "python generate.py --format pdf --template governance.tex" "mkdocs build --config-file mkdocs-deliverable.yml"

hasDeliverableTemplate
type: ObjectProperty
domain: Metamodel
range: DeliverableTemplate
broader: PresentationCategory
definition: Links a Metamodel to the DeliverableTemplates it defines. DeliverableTemplates are part of the metamodel alongside elements, relationships, viewpoints, and rules.
history note: Replaces arch:hasPresentationTemplate which pointed to the now-removed arch:PresentationTemplate class.

hasPart
type: ObjectProperty
type: TransitiveProperty
domain: ModelConcept
range: ModelConcept
definition: hasPart

hasQualifiedRelationship
type: ObjectProperty
domain: ModelConcept
range: QualifiedRelationship
definition: Generic fallback qualified predicate used when no type-specific qualified predicate is mapped for a relationship type. Points from a source element to a QualifiedRelationship node.

hasQualityMeasure
type: ObjectProperty
domain: Element
range: QualityMeasure
definition: Whether an element has a quality attribute measure associated to it. A domain can be an Element such as work product or behavior of a system, software, or stakeholders such as users, operators, developers, testers, or maintainers.

includesConcept
type: ObjectProperty
domain: Viewpoint
range: ModelConcept
definition: Defines the Concepts that may be used in this Viewpoint. These are not considered as restrictions, but can be used to define a palette of available Model Concepts. Note that more formal and rigid SHACL rules can be defined in a [shapes graph](https://w3c.github .io/data-shapes/shacl/#dfn-shapes-graphs) using property [architectureViewpointsRestrictions](#architectureViewpointsRestrictions).

isAbstract
type: DatatypeProperty
domain: Element
range: boolean
definition: Denotes if an element is abstract or concrete. These can be respectively Architecture Building Block (ABB) or Solution Building Block (SBB). SBBs are used for concrete architecture solutions and are normaly part of a catalogue and exists in CMDB ot ITSM solutions as well as architecture landscape repository. ABBs are more abstract and used for modellig patterns, reference architectures or hight level (superior) architectures

isAbstractClass
type: AnnotationProperty
range: boolean
definition: Denotes that an OWL class is abstract at the metamodel level — used for classification, validation, and inference via inheritance but not intended to be instantiated directly in architecture models. Concrete (palette-ready) classes do not carry this annotation.

laKB
type: AnnotationProperty
sub property of: seeAlso
definition: A reference to the Linked.Archi Knowledge base section that describes this concept.

Master Data Source
type: ObjectProperty
domain: ModelConcept
range: Dataset
definition: Specifies the authoritative data source or primary repository from which the architecture element's data is maintained, exported, or synchronised.
editorial note: Maintain clarity in source identification to enhance data reliability and simplify maintenance and integration workflows within the architecture repository.
scope note: This annotation is particularly crucial for scenarios involving data aggregation, ensuring traceability and consistency across diverse architecture modelling and management tools.

measuredEntity
type: ObjectProperty
domain: QualityMeasure
range: Element
inverse of: hasQualityMeasure
definition: Links a QualityMeasure to the Element it measures.

measuredQualityAttribute
type: ObjectProperty
domain: QualityMeasure
range: QualityAttribute
definition: Links a QualityMeasure to the QualityAttribute it quantifies.

meetsPurpose
type: ObjectProperty
domain: System
range: Thing
definition: The purpose of the System. This is a generic property and can be anything.

mentionedIn
type: AnnotationProperty
type: ObjectProperty
sub property of: seeAlso
inverse of: mentions
definition: Indicates that the concept is referred in, but is not necessarily the main topic.

metamodelIdentifiesConsideration
type: ObjectProperty
domain: Metamodel
range: Consideration
definition: Links a Metamodel to the Considerations it identifies as relevant for architecture descriptions using this language.

metamodelIdentifiesStakeholder
type: ObjectProperty
domain: Metamodel
range: Stakeholder
definition: Links a Metamodel to the Stakeholders it identifies as relevant. Derived from ISO/IEC/IEEE 42010.

modelAddressesConsideration
type: ObjectProperty
domain: Model
range: Consideration
definition: Links a Model to the Considerations (concerns, aspects, perspectives) it addresses. Derived from ISO/IEC/IEEE 42010.

modelConcepts
type: ObjectProperty
domain: Metamodel
range: Ontology
broader: ModelingCategory
definition: ModelConcepts property specifies the Ontology that defines the structure, terms, notations, semantics and basic syntax of the modeling language. This includes Elements and Relationships subtypes. Viewpoints are defined using [architectureViewpoints](#architectureViewpoints) property and classified using [viewpointLibrary](#viewpointLibrary) property. Note actual individulas Elements, Relationships, Views are defined in the actual Architecture Model.

modelConformsToMetamodel
type: ObjectProperty
domain: Model
range: Metamodel
definition: Links a Model to the Metamodel (modeling language) it conforms to. A model is expressed using the vocabulary and rules defined by its metamodel. Derived from ISO/IEC/IEEE 42010 "architecture description language".

modelExpressesArchitecture
type: ObjectProperty
domain: Model
range: Architecture
definition: Links a Model (architecture description) to the Architecture it expresses. An architecture description is a work product that expresses an architecture. Derived from ISO/IEC/IEEE 42010.

modelHasPurpose
type: ObjectProperty
domain: Model
range: Purpose
definition: Links a Model to its Purpose — the reason the architecture work is undertaken.

modelRepresentsSystem
type: ObjectProperty
domain: Model
range: System
definition: Links a Model to the System it represents. In ISO/IEC/IEEE 42010, an architecture description identifies a system of interest.

notationSet
type: ObjectProperty
domain: Metamodel
range: NotationSet
broader: PresentationCategory
definition: Links a Metamodel to its available NotationSet(s). A NotationSet is a named collection of VisualNotation descriptors — one per ModelConcept — that defines the default visual appearance for palette generation and diagram rendering. Multiple notation sets allow alternative visual representations for the same metamodel: standard (full spec notation), simplified (flat rectangles, no icons), monochrome (grayscale for printing), or custom (organization-specific branding). A palette generator reads the active NotationSet to determine shape, color, icon, and dimensions for each element and relationship type.

partOf
type: ObjectProperty
type: TransitiveProperty
domain: ModelConcept
range: ModelConcept
inverse of: hasPart
definition: partOf is a generic property that is mainly intended for traceability and composability relations across models. While it can be used for composition relationships within a model, in many cases more specific semantics would be needed and for that new more specific relationship should be used.

partOfModel
type: ObjectProperty
domain: ModelConcept
range: Model
definition: Concepts property that specifies the Model that contains that Concept such as Elements, Relationships or other Views. In the case of a relationship RDF-star or statement can be used to link the triple with the View. Note that Model propery of a concept can be expressed via quads.

preferred Visual Notation
type: ObjectProperty
type: FunctionalProperty
domain includes: ModelConcept
domain: Concept
range: ImageObject
sub property of: image
broader: PresentationCategory
definition: The preferred (default) rendered visual notation image for a resource. This is the "finished product" — a pre-rendered composite image (typically SVG) showing how the concept looks in its standard visual form. Used by documentation generators, static catalogs, and tools that need a quick icon without constructing from primitives. For the structured construction recipe (shape + color + icon + dimensions), see the VisualNotation class and its defaultStyle property in core-vis-onto.ttl. The relationship between the three visual layers: - arch:prefVisNotation → rendered image (for docs, catalogs, LLM context) - arch-vis:VisualNotation + defaultStyle → construction recipe (for diagram editors) - arch:usesNotationSet on PresentationContext → context-aware selection A VisualNotation instance typically carries both: the defaultStyle (recipe) and arch:prefVisNotation (rendered output). A tool can generate the prefVisNotation SVG from the VisualNotation descriptor.

presentationContextScheme
type: ObjectProperty
domain: Metamodel
range: ConceptScheme
broader: PresentationCategory
definition: Links a Metamodel to its PresentationContext classification scheme. A PresentationContext is a stakeholder-specific theme that determines how architecture is visualized and communicated. Each context in the scheme can link to a NotationSet (via arch:usesNotationSet) to specify the visual appearance appropriate for that audience. The scheme groups contexts such as Executive, Architect, Developer, Operations, and Governance — each representing a different audience with different information needs and visual preferences. Example flow for palette generation: 1. User selects a PresentationContext (e.g., "Executive") 2. Tool follows arch:usesNotationSet → gets the appropriate NotationSet 3. Tool reads VisualNotation instances from that set 4. Palette is rendered with context-appropriate shapes, colors, and detail level
example: * C-Level * Business * DevOps * Architects * Infra * Security * Data Management
rationale: presentationContextScheme categories are used as 'Themes' to group those concepts and generate different visualizations and presentation structure depending on that Context. Each context can reference a specific NotationSet to control the visual rendering.

:purposeRequiresViewpoints
type: ObjectProperty
domain: Purpose
range: Viewpoint
definition: :purposeRequiresViewpoint is used to model the relevant or recommended Viewpoints when performing an architecture work with the specific :Purpose

:purposeRequiresViewpoints
type: ObjectProperty
domain: Purpose
range: Viewpoint
definition: :purposeRequiresViewpoint is used to model the required Viewpoints when performing an architecture work with the specific :Purpose

rangeIncludes
type: AnnotationProperty
definition: defines classes for the object of a Relationship. It is not to be used for validation
scope note: Values of this property define the type of the target Element; in simple relationships, this would be the subject. This property is used for guiding modelling but not restricting relationships. Relationship restrictions, like other types of restrictions, should be implemented using SHACL.

rationale
type: AnnotationProperty
sub property of: note
definition: A description of a justification of the existence of the term in that form or some other assertion or value

referenceData
type: ObjectProperty
domain: Metamodel
range: ConceptScheme
broader: NavigationCategory
definition: any reference data that is relevant to the subject and can or should be referenced by any element or description within the Architecture Model or the Metamodel itself. For Reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations use [referenceModels](#referenceModels)

referenceModels
type: ObjectProperty
domain: Metamodel
range: ConceptScheme
broader: NavigationCategory
definition: Concept scheme that contains any relevant reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations

refinedByAspect
type: ObjectProperty
domain: Concern
range: Aspect
definition: refined by

refinedInto
type: ObjectProperty
domain: ModelConcept
range: ModelConcept
definition: refinedInto

refines
type: ObjectProperty
domain: ModelConcept
range: ModelConcept
inverse of: refinedInto
definition: domain refines range i.e. domain is a more concrete or complete representation of range. This is a traceability property intended to use within a single model or across models. I may be used as well as to related a particular :View that refines a :Element. For example a high level process may be refined by a sequence diagram.

resultsIn
type: ObjectProperty
domain: Perspective
range: Concern
definition: results in

sectionOrder
type: DatatypeProperty
domain: TemplateSection
range: integer
definition: The ordinal position of a TemplateSection within its DeliverableTemplate. Sections are ordered by ascending sectionOrder value.

sectionQuery
type: DatatypeProperty
domain: TemplateSection
range: string
definition: A SPARQL SELECT or CONSTRUCT query that extracts the data needed to populate this template section from the knowledge graph. The query is executed against the architecture model data and its results are passed to the template engine as the data context for this section. Variable names in the SELECT clause become JSON keys in the template context. For example, a query returning ?label and ?description produces objects with "label" and "description" fields that the Handlebars template iterates over. This property makes the deliverable generation pipeline fully declarative: a tool reads the template sections in order, executes each section's query, and renders the template with the results. No hardcoded extraction logic is needed.
example: :ADD-S1 arch:sectionQuery """ PREFIX am: <https://meta.linked.archi/archimate3/onto#> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> SELECT ?label ?description WHERE { ?actor a am:BusinessActor ; skos:prefLabel ?label . OPTIONAL { ?actor skos:definition ?description } FILTER(lang(?label) = "en") } ORDER BY ?label """^^xsd:string .

sectionResultKey
type: DatatypeProperty
domain: TemplateSection
range: string
definition: The JSON key under which the query results for this section are placed in the template context. For example, if sectionResultKey is "businessActors", the Handlebars template accesses the data via {{#each businessActors}}. If not specified, a tool may derive the key from the section's local name or sectionOrder.
example: "businessActors", "crossLayerRelationships", "requirements"

sectionViewpoint
type: ObjectProperty
domain: TemplateSection
range: Viewpoint
definition: Links a TemplateSection to the Viewpoint it references. When the deliverable template is instantiated, a View conforming to this viewpoint is created for this section.

source
type: ObjectProperty
domain: QualifiedRelationship
range: ModelConcept
alternative label: relationship source
definition: the source element of a qualified relationship
scope note: Analogous to the influencer/agent entity in a PROV-O qualified influence. In the PROV-O pattern, a qualified node points back to the entity that caused the influence; here, source points to the element from which the relationship originates.

stakeholderHasConcern
type: ObjectProperty
domain: Stakeholder
range: Concern
definition: Links a Stakeholder to their Concerns — the interests they have in the system and its architecture. Derived from ISO/IEC/IEEE 42010.

stakeholderHasInterestIn
type: ObjectProperty
domain: Stakeholder
range: Architecture
range: Model
range: System
definition: Links a Stakeholder to the System, Architecture, or Model they have an interest in. Derived from ISO/IEC/IEEE 42010.

stakeholderHasPerspective
type: ObjectProperty
domain: Stakeholder
range: Perspective
definition: Links a Stakeholder to their Perspective — the viewpoint from which they consider the architecture (e.g., strategic, operational, technical).

standardsInformationBase
type: ObjectProperty
type: NamedIndividual
domain: Metamodel
range: ConceptScheme
broader: NavigationCategory
definition: standards concept scheme contains classification of standards and references to standards that are relevant to the subject and can or should be used. This scheme may also define Guidelines and Best Practices o toher informal or semi-formal guiding documentation. Formal Patterns, Reference Architectures, Models, Building Blocks and tactics should use [Reference Architecture Ontology](https://meta.linked.archi/ref-arch)
example: * Business Standards: * Standard shared business functions * Standard role and actor definitions * Security and governance standards for business activity * Data Standards: * Standard coding and values for data * Standard structures and formats for data * Standards for origin and ownership of data * Restrictions on replication and access * Applications Standards: * Standard/shared applications supporting specific business functions * Standards for application communication and interoperation * Standards for access, presentation, and style * Technology Standards; * Standard hardware products * Standard software products * Standards for software development
mentionedIn: chap06.html

systemHasArchitecture
type: ObjectProperty
domain: System
range: Architecture
definition: Links a System to its Architecture — the fundamental concepts or properties embodied in its elements, relationships, and design principles. Derived from ISO/IEC/IEEE 42010.

target
type: ObjectProperty
domain: QualifiedRelationship
range: ModelConcept
alternative label: relationship target
definition: the target element of a qualified relationship
scope note: Analogous to the influenced entity in a PROV-O qualified influence. In the PROV-O pattern, the qualified node is reached from the influenced entity; here, target points to the element at which the relationship arrives.

viewpointTargetsStakeholder
type: ObjectProperty
domain: Viewpoint
range: Stakeholder
definition: Viewpoint property that relates targeted stakeholders. While this relationship can be infered from :viewpointFramesConcern and :stakeholderHasConcern it is not always the case when concerns overlap or there are different visual notations and representation preferences form the side of the stakeholders. In other words this is explicitly defined by the designer of the particular viewpoint and can match all or a subsets of the stakeholders. In some case it

templateHasFormat
type: ObjectProperty
domain: DeliverableTemplate
range: PresentationFormat
definition: Links a DeliverableTemplate to the PresentationFormat(s) it supports. Specifies how the deliverable can be rendered — e.g., Markdown, HTML, PDF, slides.

templateHasSection
type: ObjectProperty
domain: DeliverableTemplate
range: TemplateSection
definition: Links a DeliverableTemplate to its ordered TemplateSection instances. Each section references a viewpoint and carries an order index for sequencing. Use this property when section ordering and per-section guidance matter. For a simpler flat list of required viewpoints, use arch:templateRequiresViewpoint.

templateRequiresViewpoint
type: ObjectProperty
domain: DeliverableTemplate
range: Viewpoint
definition: Links a DeliverableTemplate to the Viewpoints it requires. Each referenced viewpoint acts as a placeholder — when the template is instantiated into a concrete deliverable (arch:Model), a View conforming to each required viewpoint must be created. For ordered sections with sequence numbers and guidance text, use arch:templateHasSection with TemplateSection instances instead.

templateResource
type: DatatypeProperty
domain: PresentationFormat
range: anyURI
definition: Points to the actual template file, URL, or resource used to render a deliverable in this format. Can be a local file path, a URL to a template repository, or a reference to a template engine resource (e.g., Handlebars, Jinja2, XSLT).
example: "templates/aod.md.hbs" — Handlebars Markdown template "templates/report.html.j2" — Jinja2 HTML template "templates/governance.tex" — LaTeX PDF template "https://templates.linked.archi/slides/default.pptx" — remote PPTX template

templateTargetsPurpose
type: ObjectProperty
domain: DeliverableTemplate
range: Purpose
definition: Links a DeliverableTemplate to the Purpose(s) it supports. Indicates what kind of architecture activity the deliverable is designed for.

unqualifiedForm
type: AnnotationProperty
definition: Schema-level mapping: declares which unqualified predicate a qualified form (qualified property or QualifiedRelationship subclass) corresponds to. Use on schema definitions only, not on instance data. At the instance level, the unqualified predicate is available via rdf:reifies on the QualifiedRelationship occurrence (RDF 1.2). Example: am:qualifiedServes arch:unqualifiedForm am:serves . am:Serving arch:unqualifiedForm am:serves .

usesNotationSet
type: ObjectProperty
domain: Concept
range: NotationSet
broader: PresentationCategory
definition: Links a PresentationContext (a SKOS concept within a presentationContextScheme) to the NotationSet that should be used when rendering for that audience. This is the key property that connects "who is looking" to "how things look": - A PresentationContext represents a stakeholder audience (Executive, Architect, Developer...) - A NotationSet defines the visual appearance (shapes, colors, icons, line styles) - This property bridges the two, enabling context-aware palette generation When a tool needs to render a palette or diagram: 1. Determine the active PresentationContext (from user role or preference) 2. Follow usesNotationSet to get the appropriate NotationSet 3. Query VisualNotation instances in that set for each ModelConcept 4. Render using the defaultStyle from each VisualNotation If a PresentationContext has no usesNotationSet, tools should fall back to the Metamodel-level arch:notationSet (the default/standard notation).
example: am4pc:ArchitectContext arch:usesNotationSet am4not:ArchiMate40StandardNotation . am4pc:ExecutiveContext arch:usesNotationSet am4not:ArchiMate40SimplifiedNotation .

viewConformsToViewpoint
type: ObjectProperty
domain: View
range: Viewpoint
definition: viewpoint property specifies the Viewpoint individual of a particular View instance

view type
type: ObjectProperty
domain: Viewpoint
definition: Specifies the type(s) of view a viewpoint typically produces. Values are arch:View subclasses (arch:Diagram, arch:Catalog, arch:Matrix).
scope note: Maps to three standard sources: 1. ISO/IEC/IEEE 42010 "Model Kind" — the concept that defines conventions for a type of architecture model. In ISO 42010:2011, a Viewpoint specifies one or more Model Kinds, and each Model Kind governs Architecture Models within a View. 2. TOGAF Architecture Content Framework artifact classification — TOGAF classifies architecture artifacts into three types: Catalogs (lists of building blocks), Matrices (relationships between building blocks), and Diagrams (graphical representations). See TOGAF 10 Architecture Content, Chapter 3. 3. ArchiMate Specification (Chapter 14: Viewpoints) — ArchiMate viewpoints are aligned with ISO 42010. A viewpoint defines conventions for producing a view, which can be a diagram, catalog, matrix, or other representation of a subset of the architecture. In Linked.Archi, arch:Diagram, arch:Catalog, and arch:Matrix serve as both ISO 42010 model kinds and TOGAF/ArchiMate artifact types. This property references OWL classes as values. Under OWL 2 Full (which Linked.Archi effectively uses with its minimal OWL profile and SHACL-based validation), classes can appear as property objects. No IRI is declared as both owl:Class and owl:NamedIndividual.

viewpoint addresses perspective
type: ObjectProperty
domain: Viewpoint
range: Perspective
sub property of: viewpointFramesConcern
definition: Which stakeholder perspective(s) the viewpoint is designed for — e.g., Strategic, Operational, Application, Infrastructure, Governance. Values are instances of arch:Perspective.

viewpoint covers aspect
type: ObjectProperty
domain: Viewpoint
range: Aspect
sub property of: viewpointFramesConcern
definition: Which structural aspect(s) the viewpoint covers — e.g., Active Structure, Behavior, Passive Structure, Motivation, Composite. Values are instances of arch:Aspect.

viewpointFramesConcern
type: ObjectProperty
domain: Viewpoint
range: Consideration
definition: Links a Viewpoint to the Considerations it addresses. This is the generic property — use the sub-properties :viewpointCoversAspect and :viewpointAddressesPerspective for more specific queries on which structural aspect or stakeholder perspective a viewpoint covers.

viewpointHasPurpose
type: ObjectProperty
domain: Viewpoint
range: Purpose
definition: Links a Viewpoint to its purpose — the type of architecture activity it supports. Common purposes include Deciding (evaluating options, portfolio rationalization), Designing (creating or refining architecture), Informing (communicating to stakeholders), and Governing (compliance checking, standards enforcement).
scope note: Distinct from :modelHasPurpose (why the architecture work exists) and :meetsPurpose (what the system is for). This property describes what kind of activity the viewpoint is designed to support.

viewpointLibrary
type: ObjectProperty
domain: Metamodel
range: ConceptScheme
broader: NavigationCategory
definition: viewpointLibrary property specifies a Concept scheme that classifies available Viewpoints