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.
Linked.Archi
Core Linked.Archi Ontology
Core Linked.Archi Ontology for EA modeling.
defines classes for the subject of a Relationship. It is not to be used for validation
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.
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.
isAbstractClass
A reference to the Linked.Archi Knowledge base section that describes this concept.
defines classes for the object of a Relationship. It is not to be used for validation
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.
A description of a justification of the existence of the term in that form or some other assertion or value
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 .
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.
alternative Visual Notation
architectureViewpoints property specifies the ontology that defines the architecture viewpoints including Concerns and Stakeholders and also restriction on the viewpoints.
architectureViewpoints
architectureViewpoints property specifies the ontology that defines restriction on the viewpoints using SHACL or other method. This can also be used for SHACL processors.
architectureViewpointsRestrictions
The :Framework that is used as a foundation for the :MetaModel
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.
conceptClassification
Indicates the stakeholder or governance body responsible for the maintenance and governance of an architecture concept within the architecture repository.
Use this property to explicitly document ownership to avoid ambiguity in governance responsibilities across various organisational units or roles.
Concept Owner
This property helps to clearly identify accountability and stewardship, facilitating effective governance and lifecycle management of architecture elements.
Links a Model to the Views it contains. A Model (architecture description) is a deliverable that aggregates multiple Views, each conforming to a Viewpoint.
contains
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 .
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.
deliverableTemplateUsed
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.
derivationRules
System Situated In Environment which System and Environment interact some way or another.
environment
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.
exposedInView
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.
formalRules
Links a Metamodel to the DeliverableTemplates it defines. DeliverableTemplates are part of the metamodel alongside elements, relationships, viewpoints, and rules.
Replaces arch:hasPresentationTemplate which pointed to the now-removed arch:PresentationTemplate class.
hasDeliverableTemplate
hasPart
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.
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.
hasQualityMeasure
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).
includesConcept
Specifies the authoritative data source or primary repository from which the architecture element's data is maintained, exported, or synchronised.
Maintain clarity in source identification to enhance data reliability and simplify maintenance and integration workflows within the architecture repository.
Master Data Source
This annotation is particularly crucial for scenarios involving data aggregation, ensuring traceability and consistency across diverse architecture modelling and management tools.
Links a QualityMeasure to the Element it measures.
measuredEntity
Links a QualityMeasure to the QualityAttribute it quantifies.
measuredQualityAttribute
The purpose of the System. This is a generic property and can be anything.
meetsPurpose
Links a Metamodel to the Considerations it identifies as relevant for architecture descriptions using this language.
metamodelIdentifiesConsideration
Links a Metamodel to the Stakeholders it identifies as relevant. Derived from ISO/IEC/IEEE 42010.
metamodelIdentifiesStakeholder
Links a Model to the Considerations (concerns, aspects, perspectives) it addresses. Derived from ISO/IEC/IEEE 42010.
modelAddressesConsideration
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.
modelConcepts
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".
modelConformsToMetamodel
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.
modelExpressesArchitecture
Links a Model to its Purpose — the reason the architecture work is undertaken.
modelHasPurpose
Links a Model to the System it represents. In ISO/IEC/IEEE 42010, an architecture description identifies a system of interest.
modelRepresentsSystem
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.
notationSet
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.
partOf
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.
partOfModel
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.
preferred Visual Notation
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
* C-Level * Business * DevOps * Architects * Infra * Security * Data Management
presentationContextScheme
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.
:purposeRequiresViewpoint is used to model the relevant or recommended Viewpoints when performing an architecture work with the specific :Purpose
:purposeRequiresViewpoints
:purposeRequiresViewpoint is used to model the required Viewpoints when performing an architecture work with the specific :Purpose
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)
referenceData
Concept scheme that contains any relevant reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations
referenceModels
refined by
refinedByAspect
refinedInto
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.
refines
results in
resultsIn
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.
sectionViewpoint
the source element of a qualified relationship
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.
Links a Stakeholder to their Concerns — the interests they have in the system and its architecture. Derived from ISO/IEC/IEEE 42010.
stakeholderHasConcern
Links a Stakeholder to the System, Architecture, or Model they have an interest in. Derived from ISO/IEC/IEEE 42010.
stakeholderHasInterestIn
Links a Stakeholder to their Perspective — the viewpoint from which they consider the architecture (e.g., strategic, operational, technical).
stakeholderHasPerspective
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.
systemHasArchitecture
the target element of a qualified relationship
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.
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
viewpointTargetsStakeholder
Links a DeliverableTemplate to the PresentationFormat(s) it supports. Specifies how the deliverable can be rendered — e.g., Markdown, HTML, PDF, slides.
templateHasFormat
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.
templateHasSection
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.
templateRequiresViewpoint
Links a DeliverableTemplate to the Purpose(s) it supports. Indicates what kind of architecture activity the deliverable is designed for.
templateTargetsPurpose
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).
am4pc:ArchitectContext arch:usesNotationSet am4not:ArchiMate40StandardNotation . am4pc:ExecutiveContext arch:usesNotationSet am4not:ArchiMate40SimplifiedNotation .
usesNotationSet
viewpoint property specifies the Viewpoint individual of a particular View instance
viewConformsToViewpoint
Specifies the type(s) of view a viewpoint typically produces. Values are arch:View subclasses (arch:Diagram, arch:Catalog, arch:Matrix).
view type
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.
Which stakeholder perspective(s) the viewpoint is designed for — e.g., Strategic, Operational, Application, Infrastructure, Governance. Values are instances of arch:Perspective.
viewpoint addresses perspective
Which structural aspect(s) the viewpoint covers — e.g., Active Structure, Behavior, Passive Structure, Motivation, Composite. Values are instances of arch:Aspect.
viewpoint covers aspect
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.
viewpointFramesConcern
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).
viewpointHasPurpose
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 property specifies a Concept scheme that classifies available Viewpoints
viewpointLibrary
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.
"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"
generatorCommand
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
The ordinal position of a TemplateSection within its DeliverableTemplate. Sections are ordered by ascending sectionOrder value.
sectionOrder
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.
: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 .
sectionQuery
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.
"businessActors", "crossLayerRelationships", "requirements"
sectionResultKey
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).
"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
templateResource
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.
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).
Architecture Aspect example: data, activity, function, location, people, time, motivation, taxonomy, structure, connectivity, behaviour, information, parameters, constraints, roadmaps, traceability, requirements
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.
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.
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
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.
Abstract base class for concerns, aspects, and perspectives — the interests that shape how architecture is described and communicated. Subclasses: Concern, Aspect, Perspective.
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.
DeliverableTemplate
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 .
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.
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 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.
Element
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.
UI/navigation container used to preserve tool-native organization (containment + stable display order). Not a domain/architecture semantic construct.
Folder
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...
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 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).
Aligned with TOGAF Architecture Content Framework: "a grid that shows relationships between two or more model entities." See TOGAF 10 Architecture Content, Chapter 3.
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.
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.
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...
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 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.
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).
Stakeholder Perspective. Example: * strategic * capability * operations * services * physical
* strategic * capability * operations * services * physical
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.
* Markdown * HTML * PDF * Slide Deck (PPT) * Interactive Dashboard
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.
PresentationFormat
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.
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
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."
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.
# 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 .
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.
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).
: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
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.
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.
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.
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.
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 .
TemplateSection
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
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.
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
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.
Category for concepts that define the modeling language itself — metamodels, viewpoints, and rules.
MetamodelingCategory
Category for concepts used in the modeling process — elements, relationships, and views.
ModelingCategory
Category for concepts used in navigation and organization — folders, catalogs, and groupings.
NavigationCategory
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)
PresentationCategory
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.
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.
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.
associatedStandard
Indicates that the concept is referred in, but is not necessarily the main topic.
mentionedIn
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)
* 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
standardsInformationBase