language en

Core Linked.Archi Ontology

Release: 2019-03-17

Modified on: 2026-09-07
This version:: https://meta.linked.archi/core#
Previous version:: https://meta.linked.archi/core/0.3.2#
Revision:: 0.4.0
Issued on:: 2019-03-17
Authors:: https://linked.zone#me; Kalin Maldzhanski
Publisher:: Linked.Archi
See also:: http://www.iso-architecture.org/ieee-1471/index.html; https://en.wikipedia.org/wiki/ISO/IEC_42010; https://www.wikidata.org/wiki/Q5974096
Download serialization:
License:
Visualization:
Cite as:: Core Linked.Archi Ontology

Provenance of this page

draft

Core Linked.Archi Ontology: Overview back to ToC

This ontology has the following classes and properties.

Classes

Named Individuals

Core Linked.Archi Ontology: Description back to ToC

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.

Cross-reference for Core Linked.Archi Ontology classes, object properties and data properties back to ToC

This section provides details for each class and property defined by Core Linked.Archi Ontology.

Classes

Approval State^c back to ToC or Class ToC

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

The governance standing of a model concept — whether it has been reviewed and endorsed by the accountable authority.

is in range of: approval state ^op
has members: Approved ⁿⁱ, Proposed ⁿⁱ

Architecture^c back to ToC or Class ToC

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

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.

is in range of: modelExpressesArchitecture ^op, stakeholderHasInterestIn ^op, systemHasArchitecture ^op

Architecture State^c back to ToC or Class ToC

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

The temporal context of an architecture description — whether it represents the current state (baseline), a desired future state (target), or an intermediate state on the migration path (transitional).

is in range of: architecture state ^op
has members: Baseline ⁿⁱ, Target ⁿⁱ, Transitional ⁿⁱ

Aspect^c back to ToC or Class ToC

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

Architecture Aspect example: data, activity, function, location, people, time, motivation, taxonomy, structure, connectivity, behaviour, information, parameters, constraints, roadmaps, traceability, requirements

has super-classes: Consideration ^c
is in range of: refinedByAspect ^op, viewpoint covers aspect ^op

Catalog^c back to ToC or Class ToC

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

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.

has super-classes: View ^c

Concern^c back to ToC or Class ToC

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

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

has super-classes: Consideration ^c
is in domain of: refinedByAspect ^op
is in range of: resultsIn ^op, stakeholderHasConcern ^op

Consideration^c back to ToC or Class ToC

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

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

has sub-classes: Aspect ^c, Concern ^c, Perspective ^c
is in range of: metamodelIdentifiesConsideration ^op, modelAddressesConsideration ^op, questionAddressesConcern ^op, sectionAddressesConcern ^op, viewpointFramesConcern ^op

DatasetScope^c back to ToC or Class ToC

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

What a question reads: model data alone, or model data with the metamodel beside it.

is in range of: requiresDataset ^op
has members: Model and metamodel ⁿⁱ, Model data ⁿⁱ

DeliverableTemplate^c back to ToC or Class ToC

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

A template of an architecture document produced from a model: its sections in order, each presenting a viewpoint and answering concerns by asking model questions; the values the document is produced for (arch:templateParameter); and the presentation formats it can be rendered in. A generator produces the document from the model, so it states what the model holds, what it lacks and what could not be checked, and does not drift from the model.

has super-classes: Creative Work ^c
is in domain of: templateHasFormat ^op, templateHasSection ^op, templateParameter ^op, templateRequiresViewpoint ^op, templateTargetsPurpose ^op
is in range of: deliverableTemplateUsed ^op, hasDeliverableTemplate ^op

Diagram^c back to ToC or Class ToC

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

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.

has super-classes: View ^c

Element^c back to ToC or Class ToC

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

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.

has super-classes: ModelConcept ^c
has sub-classes: Stakeholder ^c
is in domain of: hasQualityMeasure ^op, isAbstract ^dp
is in range of: measuredEntity ^op

Environment^c back to ToC or Class ToC

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

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.

is in range of: environment ^op

Folder^c back to ToC or Class ToC

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

UI/navigation container used to preserve tool-native organization (containment + stable display order). Not a domain/architecture semantic construct.

has super-classes: Item List ^c

Framework^c back to ToC or Class ToC

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

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

has super-classes: Creative Work ^c
is in range of: definedByFramework ^op

Matrix^c back to ToC or Class ToC

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

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

has super-classes: View ^c

Metamodel^c back to ToC or Class ToC

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

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.

is in domain of: architectureViewpoints ^op, architectureViewpointsRestrictions ^op, conceptClassification ^op, crossLanguageMappings ^op, definedByFramework ^op, derivationRules ^op, formalRules ^op, hasDeliverableTemplate ^op, hasQuestionSet ^op, metamodelIdentifiesConsideration ^op, metamodelIdentifiesStakeholder ^op, modelConcepts ^op, notationSet ^op, presentationContextScheme ^op, referenceData ^op, referenceModels ^op, standardsInformationBase ^op, viewpointLibrary ^op
is in range of: modelConformsToMetamodel ^op

Model^c back to ToC or Class ToC

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

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 <b>Architecture Description</b> 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...

is in domain of: contains ^op, deliverableTemplateUsed ^op, modelAddressesConsideration ^op, modelConformsToMetamodel ^op, modelExpressesArchitecture ^op, modelHasPurpose ^op, modelRepresentsSystem ^op
is in range of: inModel ^op, partOfModel ^op, stakeholderHasInterestIn ^op

ModelConcept^c back to ToC or Class ToC

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

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.

has sub-classes: Element ^c, QualifiedRelationship ^c, View ^c
is in domain of: Concept Owner ^op, Master Data Source ^op, alternative Visual Notation ^op, associatedStandard ^op, exposedInView ^op, hasPart ^op, hasQualifiedRelationship ^op, inModel ^op, inView ^op, partOf ^op, partOfModel ^op, preferred Visual Notation ^op, refinedInto ^op, refines ^op
is in range of: hasPart ^op, includesConcept ^op, partOf ^op, refinedInto ^op, refines ^op, source ^op, target ^op

ModelQuestion^c back to ToC or Class ToC

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

A question an architecture model answers — "What is affected if this element changes?" — together with the executable SPARQL that answers it. Where a Concern is an interest a stakeholder holds in the system, such as the impact of change, a model question asks one thing the architecture description can answer, and informs the concerns it addresses (arch:questionAddressesConcern): a concern is informed by many questions and views, and no single answer settles it. The question is the unit of reuse: a modelling tool offers it beside the views it fits, a deliverable section asks it for the concerns it answers, and an analysis agent selects it by those concerns.

Example

ex:orphans a arch:ModelQuestion, sh:SPARQLSelectExecutable ;
    skos:prefLabel "Which elements take part in no relationship?"@en ;
    arch:questionStage arch:QualityStage ;
    arch:resultIsFinding true ; arch:findingSeverity sh:Info ; arch:findingFocus "element" ;
    sh:parameter [ sh:path arch:model ; sh:optional true ] ;
    sh:prefixes <https://example.org/questions#> ;
    sh:select """
        SELECT ?element ?label WHERE {
          ?element arch:inModel ?model .
          FILTER NOT EXISTS { ?element arch:source ?anySource }
          FILTER NOT EXISTS { ?anyRelationship arch:source|arch:target ?element }
          OPTIONAL { ?element skos:prefLabel ?label }
        }""" .

has super-classes: S P A R Q L Executable ^c
is in domain of: answers ^dp, defaultLimit ^dp, doesNotProve ^dp, findingFocus ^dp, findingSeverity ^op, questionAddressesConcern ^op, questionFitsViewpoint ^op, questionHasPurpose ^op, questionStage ^op, questionTargetsStakeholder ^op, requiresDataset ^op, requiresMetamodel ^op, resultIsFinding ^dp, resultKey ^dp

Perspective^c back to ToC or Class ToC

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

Stakeholder Perspective. Example: * strategic * capability * operations * services * physical

Example

* strategic
* capability
* operations
* services
* physical

has super-classes: Consideration ^c
is in domain of: resultsIn ^op
is in range of: stakeholderHasPerspective ^op, viewpoint addresses perspective ^op

PresentationFormat^c back to ToC or Class ToC

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

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

is in domain of: generatorCommand ^dp
is in range of: templateHasFormat ^op

Purpose^c back to ToC or Class ToC

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

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

is in domain of: :purposeRequiresViewpoints ^op, :purposeRequiresViewpoints ^op
is in range of: modelHasPurpose ^op, questionHasPurpose ^op, templateTargetsPurpose ^op, viewpointHasPurpose ^op

QualifiedRelationship^c back to ToC or Class ToC

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

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:qualifiedServing relationshipNode` — to navigate to the full resource; named after the class it leads to, as PROV-O names `prov:qualifiedUsage` after `prov:Usage` 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) The relationship resource is the canonical form: converters and modelling tools write one for every relationship, whether or not it carries metadata yet, and the questions a model is asked about its relationships read it. A graph trimmed to the direct triples, for fast traversal, is a projection of the model: it answers which elements are connected, not what is recorded about a connection, nor the questions that read relationship resources. A relationship resource whose triple is not asserted is a proposition, not a relationship of the model: rdf:reifies names a triple without asserting it. A potential derivation is one, until the modeller confirms it: asserting the triple, with its qualified predicate, confirms a proposition, and its resource then records that it was derived. A valid derivation is a statement: a rule asserts its triple, with its qualified predicate, and its resource records how. What a modeller stated is told from what a rule derived by the graph, in a store, and by the resource. 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:qualifiedServing
    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:qualifiedServing 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 .

has super-classes: ModelConcept ^c
is in domain of: source ^op, target ^op
is in range of: hasQualifiedRelationship ^op

QuestionSet^c back to ToC or Class ToC

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

The ModelQuestions a language publishes, as one document: the core set, or a metamodel's set for its own vocabulary. A unit of publication, not a grouping by concern — the questions that inform a concern are found through arch:questionAddressesConcern. Its root resource carries the document's metadata (title, licence, vann:preferredNamespaceUri and vann:preferredNamespacePrefix) and declares, with sh:declare, the prefixes its questions' SPARQL uses; each question names it with sh:prefixes.

is in range of: hasQuestionSet ^op

Relationship Proposal Order^c back to ToC or Class ToC

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

Relationship types in the order a modelling tool proposes them when two elements are connected.

has super-classes: Ordered Collection ^c

Stakeholder^c back to ToC or Class ToC

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

: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

has super-classes: Element ^c
is in domain of: stakeholderHasConcern ^op, stakeholderHasInterestIn ^op, stakeholderHasPerspective ^op
is in range of: Concept Owner ^op, metamodelIdentifiesStakeholder ^op, questionTargetsStakeholder ^op, sectionTargetsStakeholder ^op, viewpointTargetsStakeholder ^op

System^c back to ToC or Class ToC

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

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.

is in domain of: environment ^op, meetsPurpose ^op, systemHasArchitecture ^op
is in range of: modelRepresentsSystem ^op, stakeholderHasInterestIn ^op

TemplateSection^c back to ToC or Class ToC

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

An ordered section of a DeliverableTemplate: the Viewpoint it presents (arch:sectionViewpoint), the concerns it answers (arch:sectionAddressesConcern) and the model questions it asks to answer them (arch:sectionAsks), or a single inline query (arch:sectionQuery). Produced from a model, the section shows the answers and the model's views that follow its viewpoint.

Example

am4dt:ADD-S2 a arch:TemplateSection ;
    arch:sectionOrder 2 ;
    skos:prefLabel "2. Process Cooperation"@en ;
    skos:definition "How do processes cooperate, is each performed by someone, and is every service delivered?"@en ;
    arch:sectionViewpoint am4vp:ProcessCooperationViewpoint ;
    arch:sectionAddressesConcern am4vp:ProcessDependencies, am4vp:Responsibilities, am4vp:Completeness ;
    arch:sectionAsks ( am4q:viewpoint-scope am4q:unassigned-behaviour am4q:unrealised-services ) ;
    arch:sectionResultKey "processCooperation" .

is in domain of: sectionAddressesConcern ^op, sectionAsks ^op, sectionOrder ^dp, sectionQuery ^dp, sectionResultKey ^dp, sectionTargetsStakeholder ^op, sectionViewpoint ^op
is in range of: templateHasSection ^op

View^c back to ToC or Class ToC

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

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

has super-classes: ModelConcept ^c
has sub-classes: Catalog ^c, Diagram ^c, Matrix ^c
is in domain of: viewConformsToViewpoint ^op
is in range of: contains ^op, exposedInView ^op, inView ^op

Viewpoint^c back to ToC or Class ToC

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

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

is in domain of: includesConcept ^op, view type ^op, viewpoint addresses perspective ^op, viewpoint covers aspect ^op, viewpointFramesConcern ^op, viewpointHasPurpose ^op, viewpointTargetsStakeholder ^op
is in range of: :purposeRequiresViewpoints ^op, :purposeRequiresViewpoints ^op, questionFitsViewpoint ^op, sectionViewpoint ^op, templateRequiresViewpoint ^op, viewConformsToViewpoint ^op

Object Properties

:purposeRequiresViewpoints
:purposeRequiresViewpoints
alternative Visual Notation
approval state
architecture state
architectureViewpoints
architectureViewpointsRestrictions
associatedStandard
Concept Owner
conceptClassification
conceptType
contains
crossLanguageMappings
definedByFramework
deliverableTemplateUsed
derivationRules
environment
exposedInView
findingSeverity
focus
formalRules
from
hasDeliverableTemplate
hasPart
hasQualifiedRelationship
hasQualityMeasure
hasQuestionSet
includesConcept
inModel
inView
Master Data Source
measuredEntity
measuredQualityAttribute
meetsPurpose
mentionedIn
metamodelIdentifiesConsideration
metamodelIdentifiesStakeholder
model
modelAddressesConsideration
modelConcepts
modelConformsToMetamodel
modelExpressesArchitecture
modelHasPurpose
modelRepresentsSystem
notationSet
partOf
partOfModel
preferred Visual Notation
presentationContextScheme
questionAddressesConcern
questionFitsViewpoint
questionHasPurpose
questionStage
questionTargetsStakeholder
referenceData
referenceModels
refinedByAspect
refinedInto
refines
requiresDataset
requiresMetamodel
resultsIn
sectionAddressesConcern
sectionAsks
sectionTargetsStakeholder
sectionViewpoint
source
stakeholderHasConcern
stakeholderHasInterestIn
stakeholderHasPerspective
standardsInformationBase
systemHasArchitecture
target
templateHasFormat
templateHasSection
templateParameter
templateRequiresViewpoint
templateTargetsPurpose
to
usesNotationSet
view
view type
viewConformsToViewpoint
viewpoint
viewpoint addresses perspective
viewpoint covers aspect
viewpointFramesConcern
viewpointHasPurpose
viewpointLibrary
viewpointTargetsStakeholder

:purposeRequiresViewpoints^op back to ToC or Object Property ToC

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

:purposeRequiresViewpoint is used to model the relevant or recommended Viewpoints when performing an architecture work with the specific :Purpose

has domain: Purpose ^c
has range: Viewpoint ^c

:purposeRequiresViewpoints^op back to ToC or Object Property ToC

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

:purposeRequiresViewpoint is used to model the required Viewpoints when performing an architecture work with the specific :Purpose

has domain: Purpose ^c
has range: Viewpoint ^c

alternative Visual Notation^op back to ToC or Object Property ToC

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

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.

has super-properties: image ^op
has domain: Concept ^c
domain includes: ModelConcept ^c
has range: Image Object ^c

approval state^op back to ToC or Object Property ToC

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

Links a ModelConcept or Model to its governance standing.

Example

ex:PaymentGateway a am4:ApplicationComponent ;
    arch:approvalState arch:Approved ;
    ap:atLifecycleStage ap:Active .

has range: Approval State ^c

architecture state^op back to ToC or Object Property ToC

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

Links a Model or Element to the temporal state it represents — baseline (as-is), target (to-be), or transitional.

Example

ex:CurrentPaymentArch a arch:Model ;
    arch:architectureState arch:Baseline ;
    arch:modelRepresentsSystem ex:PaymentPlatform .

ex:TargetPaymentArch a arch:Model ;
    arch:architectureState arch:Target ;
    arch:modelRepresentsSystem ex:PaymentPlatform .

has range: Architecture State ^c

architectureViewpoints^op back to ToC or Object Property ToC

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

architectureViewpoints property specifies the ontology that defines the architecture viewpoints including Concerns and Stakeholders and also restriction on the viewpoints.

has domain: Metamodel ^c
has range: Ontology ^c

architectureViewpointsRestrictions^op back to ToC or Object Property ToC

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

architectureViewpoints property specifies the ontology that defines restriction on the viewpoints using SHACL or other method. This can also be used for SHACL processors.

has super-properties: shapes Graph ^op
has domain: Metamodel ^c
has range: Ontology ^c

associatedStandard^op back to ToC or Object Property ToC

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

has domain: ModelConcept ^c
has range: Creative Work ^c
is also defined as: named individual

Concept Owner^op back to ToC or Object Property ToC

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

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.

has domain: ModelConcept ^c
has range: Stakeholder ^c

conceptClassification^op back to ToC or Object Property ToC

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

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.

has domain: Metamodel ^c
has range: Concept Scheme ^c

conceptType^op back to ToC or Object Property ToC

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

Model question parameter: a class of concepts a question is restricted to, such as one element type. Binds ?conceptType, which a question keeps apart from the ?type it may report for each concept.

contains^op back to ToC or Object Property ToC

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

Superseded by arch:inModel, read in the other direction: what was `ex:Doc arch:contains ex:OrgChart` is now `ex:OrgChart arch:inModel ex:Doc`.

Is deprecated: true

has domain: Model ^c
has range: View ^c

crossLanguageMappings^op back to ToC or Object Property ToC

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

Links a Metamodel to a document that maps its concepts onto the concepts of other modeling languages or frameworks, enabling queries and reports to span notations. The mapping document is an owl:Ontology whose content is SKOS mapping assertions — skos:exactMatch, skos:closeMatch, skos:relatedMatch, skos:broadMatch and skos:narrowMatch — between this metamodel's classes and those of another.

Example

togaf:TOGAFMetamodel
    arch:crossLanguageMappings <https://meta.linked.archi/togaf/crossmappings#> .

## in togaf-crossmappings.ttl
togaf:ApplicationComponent skos:closeMatch am4:ApplicationComponent .
togaf:Capability           skos:relatedMatch am4:Capability .

has domain: Metamodel ^c
has range: Ontology ^c

definedByFramework^op back to ToC or Object Property ToC

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

The :Framework that is used as a foundation for the :MetaModel

has super-properties: had Primary Source ^op
has domain: Metamodel ^c
has range: Framework ^c

deliverableTemplateUsed^op back to ToC or Object Property ToC

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

Links a Model to a DeliverableTemplate its deliverables are produced with. This lets a tool offer the document for the model, and check that the model has a View following each viewpoint the template presents (arch:templateRequiresViewpoint).

has domain: Model ^c
has range: DeliverableTemplate ^c

derivationRules^op back to ToC or Object Property ToC

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

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.

has super-properties: shapes Graph ^op
has domain: Metamodel ^c
has range: Ontology ^c

environment^op back to ToC or Object Property ToC

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

System Situated In Environment which System and Environment interact some way or another.

has domain: System ^c
has range: Environment ^c

exposedInView^op back to ToC or Object Property ToC

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

Superseded by arch:inView, which states the same relationship under a name that does not imply a picture.

Is deprecated: true

has super-properties: inView ^op
has domain: ModelConcept ^c
has range: View ^c

findingSeverity^op back to ToC or Object Property ToC

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

How serious a finding ModelQuestion's rows are, on SHACL's scale (sh:Info, sh:Warning, sh:Violation), so findings and validation results read alike.

has domain: ModelQuestion ^c
has range: Severity ^c

focus^op back to ToC or Object Property ToC

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

Model question parameter: the concept a question is about — in a modelling tool, the selected element; in a deliverable, the element it is produced for. Binds ?focus.

formalRules^op back to ToC or Object Property ToC

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

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.

has super-properties: shapes Graph ^op
has domain: Metamodel ^c
has range: Ontology ^c

from^op back to ToC or Object Property ToC

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

Model question parameter: the earlier of two states a question compares, such as a baseline plateau. Binds ?from.

hasDeliverableTemplate^op back to ToC or Object Property ToC

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

Links a Metamodel to the DeliverableTemplates it defines. DeliverableTemplates are part of the metamodel alongside elements, relationships, viewpoints, and rules.

has domain: Metamodel ^c
has range: DeliverableTemplate ^c

hasPart^op back to ToC or Object Property ToC

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

hasPart

has characteristics: transitive

has domain: ModelConcept ^c
has range: ModelConcept ^c
is inverse of: partOf ^op

hasQualifiedRelationship^op back to ToC or Object Property ToC

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

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.

has domain: ModelConcept ^c
has range: QualifiedRelationship ^c

hasQualityMeasure^op back to ToC or Object Property ToC

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

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.

has domain: Element ^c
has range: QualityMeasure ^c
is inverse of: measuredEntity ^op

hasQuestionSet^op back to ToC or Object Property ToC

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

Links a Metamodel to the QuestionSets published for its vocabulary: the questions its stakeholders ask of a model, bound to the concerns its viewpoints frame. A modelling tool that loads the metamodel offers them. The core question set applies to every metamodel and is not linked.

has domain: Metamodel ^c
has range: QuestionSet ^c

includesConcept^op back to ToC or Object Property ToC

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

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

has domain: Viewpoint ^c
has range: ModelConcept ^c

inModel^op back to ToC or Object Property ToC

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

Links a ModelConcept to the Model it belongs to. Applies to Elements, QualifiedRelationships and Views alike, so a View's membership in its Model is stated with the same property as an Element's rather than needing a container-first term of its own.

has sub-properties: partOfModel ^op
has domain: ModelConcept ^c
has range: Model ^c

inView^op back to ToC or Object Property ToC

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

Links a ModelConcept to a View that presents it. Applies to Elements, QualifiedRelationships and nested Views alike — anything that is a ModelConcept — and to every kind of View: a Diagram that draws the concept, a Catalog that lists it, a Matrix that indexes it.

has sub-properties: exposedInView ^op
has domain: ModelConcept ^c
has range: View ^c

Master Data Source^op back to ToC or Object Property ToC

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

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.

has domain: ModelConcept ^c
has range: Dataset ^c

measuredEntity^op back to ToC or Object Property ToC

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

Links a QualityMeasure to the Element it measures.

has domain: QualityMeasure ^c
has range: Element ^c
is inverse of: hasQualityMeasure ^op

measuredQualityAttribute^op back to ToC or Object Property ToC

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

Links a QualityMeasure to the QualityAttribute it quantifies.

has domain: QualityMeasure ^c
has range: QualityAttribute ^c

meetsPurpose^op back to ToC or Object Property ToC

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

The purpose of the System. This is a generic property and can be anything.

has domain: System ^c
has range: Thing ^c

mentionedIn^op back to ToC or Object Property ToC

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

is inverse of: mentions ^op
is also defined as: annotation property

metamodelIdentifiesConsideration^op back to ToC or Object Property ToC

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

Links a Metamodel to the Considerations it identifies as relevant for architecture descriptions using this language.

has domain: Metamodel ^c
has range: Consideration ^c

metamodelIdentifiesStakeholder^op back to ToC or Object Property ToC

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

Links a Metamodel to the Stakeholders it identifies as relevant. Derived from ISO/IEC/IEEE 42010.

has domain: Metamodel ^c
has range: Stakeholder ^c

model^op back to ToC or Object Property ToC

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

Model question parameter: the Model a question is restricted to — in a modelling tool, the open model; in a deliverable, the model it is produced from. Binds ?model.

modelAddressesConsideration^op back to ToC or Object Property ToC

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

Links a Model to the Considerations (concerns, aspects, perspectives) it addresses. Derived from ISO/IEC/IEEE 42010.

has domain: Model ^c
has range: Consideration ^c

modelConcepts^op back to ToC or Object Property ToC

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

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.

has domain: Metamodel ^c
has range: Ontology ^c

modelConformsToMetamodel^op back to ToC or Object Property ToC

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

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

has domain: Model ^c
has range: Metamodel ^c

modelExpressesArchitecture^op back to ToC or Object Property ToC

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

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.

has domain: Model ^c
has range: Architecture ^c

modelHasPurpose^op back to ToC or Object Property ToC

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

Links a Model to its Purpose — the reason the architecture work is undertaken.

has domain: Model ^c
has range: Purpose ^c

modelRepresentsSystem^op back to ToC or Object Property ToC

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

Links a Model to the System it represents. In ISO/IEC/IEEE 42010, an architecture description identifies a system of interest.

has domain: Model ^c
has range: System ^c

notationSet^op back to ToC or Object Property ToC

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

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.

has domain: Metamodel ^c
has range: Notation Set ^c

partOf^op back to ToC or Object Property ToC

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

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.

has characteristics: transitive

has domain: ModelConcept ^c
has range: ModelConcept ^c
is inverse of: hasPart ^op

partOfModel^op back to ToC or Object Property ToC

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

Superseded by arch:inModel, which states the same relationship without borrowing the partOf stem.

Is deprecated: true

has super-properties: inModel ^op
has domain: ModelConcept ^c
has range: Model ^c

preferred Visual Notation^op back to ToC or Object Property ToC

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

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.

has characteristics: functional

has super-properties: image ^op
has domain: Concept ^c
domain includes: ModelConcept ^c
has range: Image Object ^c

presentationContextScheme^op back to ToC or Object Property ToC

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

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

has domain: Metamodel ^c
has range: Concept Scheme ^c

questionAddressesConcern^op back to ToC or Object Property ToC

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

Links a ModelQuestion to the Considerations its answer informs. What makes a question selectable by concern, as arch:viewpointFramesConcern makes a viewpoint; a stakeholder's questions follow from arch:stakeholderHasConcern.

has domain: ModelQuestion ^c
has range: Consideration ^c

questionFitsViewpoint^op back to ToC or Object Property ToC

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

Links a ModelQuestion to a Viewpoint whose views it is asked about: a modelling tool offers it while such a view is open, and a view built from its result conforms to that viewpoint.

has domain: ModelQuestion ^c
has range: Viewpoint ^c

questionHasPurpose^op back to ToC or Object Property ToC

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

Links a ModelQuestion to the Purposes it serves — deciding, informing, designing — as arch:viewpointHasPurpose does a viewpoint and arch:templateTargetsPurpose a deliverable template.

has domain: ModelQuestion ^c
has range: Purpose ^c

questionStage^op back to ToC or Object Property ToC

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

The stage of an investigation a ModelQuestion belongs to, from arch:QuestionStageScheme.

has domain: ModelQuestion ^c
has range: Concept ^c

questionTargetsStakeholder^op back to ToC or Object Property ToC

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

Links a ModelQuestion to a Stakeholder who asks it, stated where the concerns it addresses do not already say so.

has domain: ModelQuestion ^c
has range: Stakeholder ^c

referenceData^op back to ToC or Object Property ToC

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

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)

has domain: Metamodel ^c
has range: Concept Scheme ^c

referenceModels^op back to ToC or Object Property ToC

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

Concept scheme that contains any relevant reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations

has domain: Metamodel ^c
has range: Concept Scheme ^c

refinedByAspect^op back to ToC or Object Property ToC

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

refined by

has domain: Concern ^c
has range: Aspect ^c

refinedInto^op back to ToC or Object Property ToC

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

refinedInto

has domain: ModelConcept ^c
has range: ModelConcept ^c
is inverse of: refines ^op

refines^op back to ToC or Object Property ToC

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

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.

has domain: ModelConcept ^c
has range: ModelConcept ^c
is inverse of: refinedInto ^op

requiresDataset^op back to ToC or Object Property ToC

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

What a ModelQuestion must be able to read: model data alone, or the metamodel beside it.

has domain: ModelQuestion ^c
has range: DatasetScope ^c

requiresMetamodel^op back to ToC or Object Property ToC

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

An ontology whose terms a ModelQuestion uses. A tool offers the question only while that ontology is loaded.

has domain: ModelQuestion ^c
has range: Ontology ^c

resultsIn^op back to ToC or Object Property ToC

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

results in

has domain: Perspective ^c
has range: Concern ^c

sectionAddressesConcern^op back to ToC or Object Property ToC

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

A Consideration a TemplateSection answers for its readers. By default the concerns its arch:sectionViewpoint frames; stated where the section is narrower or wider.

has domain: TemplateSection ^c
has range: Consideration ^c

sectionAsks^op back to ToC or Object Property ToC

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

The ModelQuestions a TemplateSection asks, in reading order, as an rdf:List of arch:ModelQuestion: each defined once, asked by any number of sections and offered by any tool. arch:sectionQuery is the inline form for a single query.

has domain: TemplateSection ^c
has range: List ^c

sectionTargetsStakeholder^op back to ToC or Object Property ToC

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

A Stakeholder a TemplateSection is written for, where it differs from its viewpoint's.

has domain: TemplateSection ^c
has range: Stakeholder ^c

sectionViewpoint^op back to ToC or Object Property ToC

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

Links a TemplateSection to the Viewpoint it presents. Produced from a model, the section shows the model's Views that follow this viewpoint, and the questions it asks are pre-bound with it as ?viewpoint.

has domain: TemplateSection ^c
has range: Viewpoint ^c

source^op back to ToC or Object Property ToC

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

the source element of a qualified relationship

has domain: QualifiedRelationship ^c
has range: ModelConcept ^c

stakeholderHasConcern^op back to ToC or Object Property ToC

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

Links a Stakeholder to their Concerns — the interests they have in the system and its architecture. Derived from ISO/IEC/IEEE 42010.

has domain: Stakeholder ^c
has range: Concern ^c

stakeholderHasInterestIn^op back to ToC or Object Property ToC

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

Links a Stakeholder to the System, Architecture, or Model they have an interest in. Derived from ISO/IEC/IEEE 42010.

has domain: Stakeholder ^c
has range: Architecture ^c; Model ^c; System ^c

stakeholderHasPerspective^op back to ToC or Object Property ToC

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

Links a Stakeholder to their Perspective — the viewpoint from which they consider the architecture (e.g., strategic, operational, technical).

has domain: Stakeholder ^c
has range: Perspective ^c

standardsInformationBase^op back to ToC or Object Property ToC

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

has domain: Metamodel ^c
has range: Concept Scheme ^c
is also defined as: named individual

systemHasArchitecture^op back to ToC or Object Property ToC

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

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.

has domain: System ^c
has range: Architecture ^c

target^op back to ToC or Object Property ToC

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

the target element of a qualified relationship

has domain: QualifiedRelationship ^c
has range: ModelConcept ^c

templateHasFormat^op back to ToC or Object Property ToC

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

Links a DeliverableTemplate to the PresentationFormat(s) it supports. Specifies how the deliverable can be rendered — e.g., Markdown, HTML, PDF, slides.

has domain: DeliverableTemplate ^c
has range: PresentationFormat ^c

templateHasSection^op back to ToC or Object Property ToC

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

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.

has domain: DeliverableTemplate ^c
has range: TemplateSection ^c

templateParameter^op back to ToC or Object Property ToC

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

A value a deliverable is produced for — the model, the element under change, two plateaus to compare — declared as an sh:Parameter and pre-bound into every question its sections ask.

has super-properties: parameter ^op
has domain: DeliverableTemplate ^c
has range: Parameter ^c

templateRequiresViewpoint^op back to ToC or Object Property ToC

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

Links a DeliverableTemplate to the Viewpoints it presents: the model a deliverable is produced from needs a View following each of them for the document to show it. The sections say in which order and for which concerns (arch:templateHasSection); this flat list lets a tool see at a glance which views a model lacks for the document.

has domain: DeliverableTemplate ^c
has range: Viewpoint ^c

templateTargetsPurpose^op back to ToC or Object Property ToC

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

Links a DeliverableTemplate to the Purpose(s) it supports. Indicates what kind of architecture activity the deliverable is designed for.

has domain: DeliverableTemplate ^c
has range: Purpose ^c

to^op back to ToC or Object Property ToC

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

Model question parameter: the later of two states a question compares, such as a target plateau. Binds ?to.

usesNotationSet^op back to ToC or Object Property ToC

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

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 .

has domain: Concept ^c
has range: Notation Set ^c

view^op back to ToC or Object Property ToC

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

Model question parameter: a View — in a modelling tool, the open view. Binds ?view.

view type^op back to ToC or Object Property ToC

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

Specifies the type(s) of view a viewpoint typically produces. Values are arch:View subclasses (arch:Diagram, arch:Catalog, arch:Matrix).

has domain: Viewpoint ^c

viewConformsToViewpoint^op back to ToC or Object Property ToC

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

viewpoint property specifies the Viewpoint individual of a particular View instance

has domain: View ^c
has range: Viewpoint ^c

viewpoint^op back to ToC or Object Property ToC

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

Model question parameter: a Viewpoint, as the statement of what is in scope — in a modelling tool, the open view's viewpoint; in a deliverable, the section's arch:sectionViewpoint. Binds ?viewpoint.

viewpoint addresses perspective^op back to ToC or Object Property ToC

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

Which stakeholder perspective(s) the viewpoint is designed for — e.g., Strategic, Operational, Application, Infrastructure, Governance. Values are instances of arch:Perspective.

has super-properties: viewpointFramesConcern ^op
has domain: Viewpoint ^c
has range: Perspective ^c

viewpoint covers aspect^op back to ToC or Object Property ToC

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

Which structural aspect(s) the viewpoint covers — e.g., Active Structure, Behavior, Passive Structure, Motivation, Composite. Values are instances of arch:Aspect.

has super-properties: viewpointFramesConcern ^op
has domain: Viewpoint ^c
has range: Aspect ^c

viewpointFramesConcern^op back to ToC or Object Property ToC

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

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.

has sub-properties: viewpoint addresses perspective ^op, viewpoint covers aspect ^op
has domain: Viewpoint ^c
has range: Consideration ^c

viewpointHasPurpose^op back to ToC or Object Property ToC

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

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

has domain: Viewpoint ^c
has range: Purpose ^c

viewpointLibrary^op back to ToC or Object Property ToC

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

viewpointLibrary property specifies a Concept scheme that classifies available Viewpoints

has domain: Metamodel ^c
has range: Concept Scheme ^c

viewpointTargetsStakeholder^op back to ToC or Object Property ToC

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

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

has domain: Viewpoint ^c
has range: Stakeholder ^c

answers^dp back to ToC or Data Property ToC

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

What one row of a ModelQuestion's result means.

has domain: ModelQuestion ^c
has range: lang String

defaultLimit^dp back to ToC or Data Property ToC

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

The number of rows a browsing tool shows of a ModelQuestion's result. Not part of the query text: a document generator reads every row.

has domain: ModelQuestion ^c
has range: integer

doesNotProve^dp back to ToC or Data Property ToC

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

The conclusion a reader will be tempted to draw from a ModelQuestion's answer and should not — that a modelled relationship is a runtime dependency, that an absent value means none exists.

has domain: ModelQuestion ^c
has range: lang String

findingFocus^dp back to ToC or Data Property ToC

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

The result variable, without its "?", whose value is the concept each row of a finding ModelQuestion is about — the focus node of the finding, as in a SHACL validation result.

Example

"element", "service", "requirement"

has domain: ModelQuestion ^c
has range: string

generatorCommand^dp back to ToC or Data Property ToC

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

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"

has domain: PresentationFormat ^c
has range: string

isAbstract^dp back to ToC or Data Property ToC

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

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

has domain: Element ^c
has range: boolean

resultIsFinding^dp back to ToC or Data Property ToC

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

True when every row of a ModelQuestion's result is a finding against the concerns it addresses, so that an empty result means they are satisfied. A deliverable states an empty finding as "none found" rather than leaving it out.

has domain: ModelQuestion ^c
has range: boolean

resultKey^dp back to ToC or Data Property ToC

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

The key a ModelQuestion's rows are stored under in a document generator's context, within the arch:sectionResultKey of the section that asks it.

has domain: ModelQuestion ^c
has range: string

sectionOrder^dp back to ToC or Data Property ToC

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

The ordinal position of a TemplateSection within its DeliverableTemplate. Sections are ordered by ascending sectionOrder value.

has domain: TemplateSection ^c
has range: integer

sectionQuery^dp back to ToC or Data Property ToC

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

A SPARQL SELECT 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 .

has domain: TemplateSection ^c
has range: string

sectionResultKey^dp back to ToC or Data Property ToC

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

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"

has domain: TemplateSection ^c
has range: string

templateResource^dp back to ToC or Data Property ToC

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

Points to the template file, URL, or resource a deliverable is rendered with: on a DeliverableTemplate, the layout of the document; on a PresentationFormat, the layout for that 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://example.org/templates/slides/default.pptx" — remote PPTX template

has range: any U R I

Annotation Properties

alt Label^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#altLabel

broader^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#broader

citation^ap back to ToC or Annotation Property ToC

IRI: http://schema.org/citation

close Match^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#closeMatch

created^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/created

creator^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/creator

definition^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#definition

description^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/description

domain Includes^ap back to ToC or Annotation Property ToC

IRI: http://schema.org/domainIncludes

domainIncludes^ap back to ToC or Annotation Property ToC

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

defines classes for the subject of a Relationship. It is not to be used for validation

editorial Note^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#editorialNote

example^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#example

history Note^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#historyNote

in Scheme^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#inScheme

Introduction Section^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/net/SMARTprotocol#IntroductionSection

is Replaced By^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/isReplacedBy

isAbstractClass^ap back to ToC or Annotation Property ToC

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

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.

has range: boolean

issued^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/issued

la K B^ap back to ToC or Annotation Property ToC

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

A reference to the Linked.Archi Knowledge base section that describes this concept.

has super-properties: see Also

license^ap back to ToC or Annotation Property ToC

IRI: http://creativecommons.org/ns#license

logo^ap back to ToC or Annotation Property ToC

IRI: http://schema.org/logo

mentionedIn^ap back to ToC or Annotation Property ToC

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

has super-properties: see Also
is inverse of: mentions ^op
is also defined as: object property

modified^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/modified

notation^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#notation

note^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#note

has sub-properties: rationale ^ap

pref Label^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#prefLabel

preferred Namespace Prefix^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/vocab/vann/preferredNamespacePrefix

preferred Namespace Uri^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/vocab/vann/preferredNamespaceUri

publisher^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/publisher

qualified Attribution^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/ns/prov#qualifiedAttribution

rangeIncludes^ap back to ToC or Annotation Property ToC

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

defines classes for the object of a Relationship. It is not to be used for validation

rationale^ap back to ToC or Annotation Property ToC

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

A description of a justification of the existence of the term in that form or some other assertion or value

has super-properties: note ^ap

scope Note^ap back to ToC or Annotation Property ToC

IRI: http://www.w3.org/2004/02/skos/core#scopeNote

status^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/ontology/bibo/status

title^ap back to ToC or Annotation Property ToC

IRI: http://purl.org/dc/terms/title

unqualifiedForm^ap back to ToC or Annotation Property ToC

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

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:qualifiedServing arch:unqualifiedForm am:serves . am:Serving arch:unqualifiedForm am:serves .

Named Individuals

:ⁿⁱ back to ToC or Named Individual ToC

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

has facts: image ^op favicon.svg ⁿⁱ

Analysisⁿⁱ back to ToC or Named Individual ToC

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

Dependencies, traceability, realisation and the impact of change.

belongs to: Concept ^c
has facts: definition ^ap "Dependencies, traceability, realisation and the impact of change."@en; in Scheme ^ap Question stages ⁿⁱ; notation ^ap "analysis"; pref Label ^ap "Analysis"@en

Approvedⁿⁱ back to ToC or Named Individual ToC

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

Reviewed and endorsed by the accountable authority. The concept is binding for the scope it governs.

belongs to: Approval State ^c
has facts: alt Label ^ap "Endorsed"@en; definition ^ap "Reviewed and endorsed by the accountable authority. The concept is binding for the scope it governs."@en; pref Label ^ap "Approved"@en

associatedStandardⁿⁱ back to ToC or Named Individual ToC

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

has facts: mentionedIn ^op chap06.html ⁿⁱ
is also defined as: object property

Baselineⁿⁱ back to ToC or Named Individual ToC

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

The current state of the architecture — how the system exists today. A baseline architecture describes the implemented, operational reality.

belongs to: Architecture State ^c
has facts: alt Label ^ap "As-Is"@en; alt Label ^ap "Current State"@en; definition ^ap "The current state of the architecture — how the system exists today. A baseline architecture describes the implemented, operational reality."@en; pref Label ^ap "Baseline"@en

Discoveryⁿⁱ back to ToC or Named Individual ToC

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

Which vocabulary and shapes the data actually uses.

belongs to: Concept ^c
has facts: definition ^ap "Which vocabulary and shapes the data actually uses."@en; in Scheme ^ap Question stages ⁿⁱ; notation ^ap "discovery"; pref Label ^ap "Discovery"@en

Enrichmentⁿⁱ back to ToC or Named Individual ToC

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

Lifecycle, ownership and the other facts recorded about concepts.

belongs to: Concept ^c
has facts: definition ^ap "Lifecycle, ownership and the other facts recorded about concepts."@en; in Scheme ^ap Question stages ⁿⁱ; notation ^ap "enrichment"; pref Label ^ap "Enrichment"@en

MetamodelingCategoryⁿⁱ back to ToC or Named Individual ToC

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

Category for concepts that define the modeling language itself — metamodels, viewpoints, and rules.

belongs to: Concept ^c
has facts: definition ^ap "Category for concepts that define the modeling language itself — metamodels, viewpoints, and rules."@en; pref Label ^ap "MetamodelingCategory"@en

Model and metamodelⁿⁱ back to ToC or Named Individual ToC

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

Model data together with the loaded metamodel documents — class hierarchy, viewpoint definitions, unqualified forms — in the default graph or in named graphs.

belongs to: DatasetScope ^c
has facts: definition ^ap "Model data together with the loaded metamodel documents — class hierarchy, viewpoint definitions, unqualified forms — in the default graph or in named graphs."@en; pref Label ^ap "Model and metamodel"@en

Model dataⁿⁱ back to ToC or Named Individual ToC

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

Model data only, in the default graph.

belongs to: DatasetScope ^c
has facts: definition ^ap "Model data only, in the default graph."@en; pref Label ^ap "Model data"@en

ModelingCategoryⁿⁱ back to ToC or Named Individual ToC

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

Category for concepts used in the modeling process — elements, relationships, and views.

belongs to: Concept ^c
has facts: definition ^ap "Category for concepts used in the modeling process — elements, relationships, and views."@en; pref Label ^ap "ModelingCategory"@en

NavigationCategoryⁿⁱ back to ToC or Named Individual ToC

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

Category for concepts used in navigation and organization — folders, catalogs, and groupings.

belongs to: Concept ^c
has facts: definition ^ap "Category for concepts used in navigation and organization — folders, catalogs, and groupings."@en; pref Label ^ap "NavigationCategory"@en

Orientationⁿⁱ back to ToC or Named Individual ToC

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

What is in the model, in outline.

belongs to: Concept ^c
has facts: definition ^ap "What is in the model, in outline."@en; in Scheme ^ap Question stages ⁿⁱ; notation ^ap "orientation"; pref Label ^ap "Orientation"@en

PresentationCategoryⁿⁱ back to ToC or Named Individual ToC

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

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)

belongs to: Concept ^c
has facts: definition ^ap "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)"@en; pref Label ^ap "PresentationCategory"@en

Proposedⁿⁱ back to ToC or Named Individual ToC

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

Put forward for governance review but not yet endorsed. The concept carries no authority and may be changed or withdrawn.

belongs to: Approval State ^c
has facts: alt Label ^ap "Submitted"@en; definition ^ap "Put forward for governance review but not yet endorsed. The concept carries no authority and may be changed or withdrawn."@en; pref Label ^ap "Proposed"@en

Qualityⁿⁱ back to ToC or Named Individual ToC

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

Gaps, inconsistencies and the integrity of the description itself.

belongs to: Concept ^c
has facts: definition ^ap "Gaps, inconsistencies and the integrity of the description itself."@en; in Scheme ^ap Question stages ⁿⁱ; notation ^ap "quality"; pref Label ^ap "Quality"@en

QualityAttributeⁿⁱ back to ToC or Named Individual ToC

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

has facts: mentionedIn ^op Quality Attributes ⁿⁱ
is also defined as: class

QualityMeasureⁿⁱ back to ToC or Named Individual ToC

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

has facts: mentionedIn ^op Quality Attributes ⁿⁱ
is also defined as: class

Question stagesⁿⁱ back to ToC or Named Individual ToC

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

The stages an investigation of a model moves through, in order: what is there, what a name refers to, which vocabulary the data uses, how things depend on each other, what is recorded about them, how sound the description is, and what its views show.

belongs to: Concept Scheme ^c
has facts: definition ^ap "The stages an investigation of a model moves through, in order: what is there, what a name refers to, which vocabulary the data uses, how things depend on each other, what is recorded about them, how sound the description is, and what its views show."@en; pref Label ^ap "Question stages"@en

Resolutionⁿⁱ back to ToC or Named Individual ToC

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

Which concept a name refers to, and what it is.

belongs to: Concept ^c
has facts: definition ^ap "Which concept a name refers to, and what it is."@en; in Scheme ^ap Question stages ⁿⁱ; notation ^ap "resolution"; pref Label ^ap "Resolution"@en

standardsInformationBaseⁿⁱ back to ToC or Named Individual ToC

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

has facts: mentionedIn ^op chap06.html ⁿⁱ
is also defined as: object property

Targetⁿⁱ back to ToC or Named Individual ToC

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

The desired future state of the architecture — how the system should exist after planned changes are realised.

belongs to: Architecture State ^c
has facts: alt Label ^ap "Future State"@en; alt Label ^ap "To-Be"@en; definition ^ap "The desired future state of the architecture — how the system should exist after planned changes are realised."@en; pref Label ^ap "Target"@en

Transitionalⁿⁱ back to ToC or Named Individual ToC

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

An intermediate state between baseline and target — a stable plateau that exists for a defined period during migration. Multiple transitional states may exist on the path from baseline to target.

belongs to: Architecture State ^c
has facts: alt Label ^ap "Intermediate State"@en; definition ^ap "An intermediate state between baseline and target — a stable plateau that exists for a defined period during migration. Multiple transitional states may exist on the path from baseline to target."@en; pref Label ^ap "Transitional"@en

Viewsⁿⁱ back to ToC or Named Individual ToC

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

What views present, and how they conform to their viewpoints.

belongs to: Concept ^c
has facts: definition ^ap "What views present, and how they conform to their viewpoints."@en; in Scheme ^ap Question stages ⁿⁱ; notation ^ap "views"; pref Label ^ap "Views"@en

Legend back to ToC

^c: Classes
^op: Object Properties
^dp: Data Properties
ⁿⁱ: Named Individuals

Changes from last version

Classes

Modified classes

https://meta.linked.archi/core#QualifiedRelationship
- Added: " 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:qualifiedServing relationshipNode` — to navigate to the full resource; named after the class it leads to, as PROV-O names `prov:qualifiedUsage` after `prov:Usage` 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) The relationship resource is the canonical form: converters and modelling tools write one for every relationship, whether or not it carries metadata yet, and the questions a model is asked about its relationships read it. A graph trimmed to the direct triples, for fast traversal, is a projection of the model: it answers which elements are connected, not what is recorded about a connection, nor the questions that read relationship resources. A relationship resource whose triple is not asserted is a proposition, not a relationship of the model: rdf:reifies names a triple without asserting it. A potential derivation is one, until the modeller confirms it: asserting the triple, with its qualified predicate, confirms a proposition, and its resource then records that it was derived. A valid derivation is a statement: a rule asserts its triple, with its qualified predicate, and its resource records how. What a modeller stated is told from what a rule derived by the graph, in a store, and by the resource. 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. "^^xsd:string
- Deleted: " 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:qualifiedServing relationshipNode` — to navigate to the full resource; named after the class it leads to, as PROV-O names `prov:qualifiedUsage` after `prov:Usage` 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) The relationship resource is the canonical form: converters and modelling tools write one for every relationship, whether or not it carries metadata yet, and the questions a model is asked about its relationships read it. A graph trimmed to the direct triples, for fast traversal, is a projection of the model: it answers which elements are connected, not what is recorded about a connection, nor the questions that read relationship resources. 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. "^^xsd:string

Acknowledgments back to ToC

The authors would like to thank Silvio Peroni for developing LODE, a Live OWL Documentation Environment, which is used for representing the Cross Referencing Section of this document and Daniel Garijo for developing Widoco, the program used to create the template used in this documentation.

Core Linked.Archi Ontology

Release: 2019-03-17

Core Linked.Archi Ontology: Overview back to ToC

Classes

Object Properties

Data Properties

Annotation Properties

Named Individuals

Core Linked.Archi Ontology: Description back to ToC

Cross-reference for Core Linked.Archi Ontology classes, object properties and data properties back to ToC

Classes

Approval Statec back to ToC or Class ToC

Architecturec back to ToC or Class ToC

Architecture Statec back to ToC or Class ToC

Aspectc back to ToC or Class ToC

Catalogc back to ToC or Class ToC

Concernc back to ToC or Class ToC

Considerationc back to ToC or Class ToC

DatasetScopec back to ToC or Class ToC

DeliverableTemplatec back to ToC or Class ToC

Diagramc back to ToC or Class ToC

Elementc back to ToC or Class ToC

Environmentc back to ToC or Class ToC

Folderc back to ToC or Class ToC

Frameworkc back to ToC or Class ToC

Matrixc back to ToC or Class ToC

Metamodelc back to ToC or Class ToC

Modelc back to ToC or Class ToC

ModelConceptc back to ToC or Class ToC

ModelQuestionc back to ToC or Class ToC

Perspectivec back to ToC or Class ToC

PresentationFormatc back to ToC or Class ToC

Purposec back to ToC or Class ToC

QualifiedRelationshipc back to ToC or Class ToC

QuestionSetc back to ToC or Class ToC

Relationship Proposal Orderc back to ToC or Class ToC

Stakeholderc back to ToC or Class ToC

Systemc back to ToC or Class ToC

TemplateSectionc back to ToC or Class ToC

Viewc back to ToC or Class ToC

Viewpointc back to ToC or Class ToC

Object Properties

:purposeRequiresViewpointsop back to ToC or Object Property ToC

:purposeRequiresViewpointsop back to ToC or Object Property ToC

alternative Visual Notationop back to ToC or Object Property ToC

approval stateop back to ToC or Object Property ToC

architecture stateop back to ToC or Object Property ToC

architectureViewpointsop back to ToC or Object Property ToC

architectureViewpointsRestrictionsop back to ToC or Object Property ToC

associatedStandardop back to ToC or Object Property ToC

Concept Ownerop back to ToC or Object Property ToC

conceptClassificationop back to ToC or Object Property ToC

conceptTypeop back to ToC or Object Property ToC

containsop back to ToC or Object Property ToC

crossLanguageMappingsop back to ToC or Object Property ToC

definedByFrameworkop back to ToC or Object Property ToC

deliverableTemplateUsedop back to ToC or Object Property ToC

derivationRulesop back to ToC or Object Property ToC

environmentop back to ToC or Object Property ToC

exposedInViewop back to ToC or Object Property ToC

findingSeverityop back to ToC or Object Property ToC

focusop back to ToC or Object Property ToC

formalRulesop back to ToC or Object Property ToC

fromop back to ToC or Object Property ToC

hasDeliverableTemplateop back to ToC or Object Property ToC

hasPartop back to ToC or Object Property ToC

hasQualifiedRelationshipop back to ToC or Object Property ToC

hasQualityMeasureop back to ToC or Object Property ToC

hasQuestionSetop back to ToC or Object Property ToC

includesConceptop back to ToC or Object Property ToC

inModelop back to ToC or Object Property ToC

inViewop back to ToC or Object Property ToC

Master Data Sourceop back to ToC or Object Property ToC

measuredEntityop back to ToC or Object Property ToC

measuredQualityAttributeop back to ToC or Object Property ToC

meetsPurposeop back to ToC or Object Property ToC

mentionedInop back to ToC or Object Property ToC

metamodelIdentifiesConsiderationop back to ToC or Object Property ToC

metamodelIdentifiesStakeholderop back to ToC or Object Property ToC

modelop back to ToC or Object Property ToC

Approval State^c back to ToC or Class ToC

Architecture^c back to ToC or Class ToC

Architecture State^c back to ToC or Class ToC

Aspect^c back to ToC or Class ToC

Catalog^c back to ToC or Class ToC

Concern^c back to ToC or Class ToC

Consideration^c back to ToC or Class ToC

DatasetScope^c back to ToC or Class ToC

DeliverableTemplate^c back to ToC or Class ToC

Diagram^c back to ToC or Class ToC

Element^c back to ToC or Class ToC

Environment^c back to ToC or Class ToC

Folder^c back to ToC or Class ToC

Framework^c back to ToC or Class ToC

Matrix^c back to ToC or Class ToC

Metamodel^c back to ToC or Class ToC

Model^c back to ToC or Class ToC

ModelConcept^c back to ToC or Class ToC

ModelQuestion^c back to ToC or Class ToC

Perspective^c back to ToC or Class ToC

PresentationFormat^c back to ToC or Class ToC

Purpose^c back to ToC or Class ToC

QualifiedRelationship^c back to ToC or Class ToC

QuestionSet^c back to ToC or Class ToC

Relationship Proposal Order^c back to ToC or Class ToC

Stakeholder^c back to ToC or Class ToC

System^c back to ToC or Class ToC

TemplateSection^c back to ToC or Class ToC

View^c back to ToC or Class ToC

Viewpoint^c back to ToC or Class ToC

:purposeRequiresViewpoints^op back to ToC or Object Property ToC

:purposeRequiresViewpoints^op back to ToC or Object Property ToC

alternative Visual Notation^op back to ToC or Object Property ToC

approval state^op back to ToC or Object Property ToC

architecture state^op back to ToC or Object Property ToC

architectureViewpoints^op back to ToC or Object Property ToC

architectureViewpointsRestrictions^op back to ToC or Object Property ToC

associatedStandard^op back to ToC or Object Property ToC

Concept Owner^op back to ToC or Object Property ToC

conceptClassification^op back to ToC or Object Property ToC

conceptType^op back to ToC or Object Property ToC

contains^op back to ToC or Object Property ToC

crossLanguageMappings^op back to ToC or Object Property ToC

definedByFramework^op back to ToC or Object Property ToC

deliverableTemplateUsed^op back to ToC or Object Property ToC

derivationRules^op back to ToC or Object Property ToC

environment^op back to ToC or Object Property ToC

exposedInView^op back to ToC or Object Property ToC

findingSeverity^op back to ToC or Object Property ToC

focus^op back to ToC or Object Property ToC

formalRules^op back to ToC or Object Property ToC

from^op back to ToC or Object Property ToC

hasDeliverableTemplate^op back to ToC or Object Property ToC

hasPart^op back to ToC or Object Property ToC

hasQualifiedRelationship^op back to ToC or Object Property ToC

hasQualityMeasure^op back to ToC or Object Property ToC

hasQuestionSet^op back to ToC or Object Property ToC

includesConcept^op back to ToC or Object Property ToC

inModel^op back to ToC or Object Property ToC

inView^op back to ToC or Object Property ToC

Master Data Source^op back to ToC or Object Property ToC

measuredEntity^op back to ToC or Object Property ToC

measuredQualityAttribute^op back to ToC or Object Property ToC

meetsPurpose^op back to ToC or Object Property ToC

mentionedIn^op back to ToC or Object Property ToC

metamodelIdentifiesConsideration^op back to ToC or Object Property ToC

metamodelIdentifiesStakeholder^op back to ToC or Object Property ToC

model^op back to ToC or Object Property ToC

modelAddressesConsideration^op back to ToC or Object Property ToC

modelConcepts^op back to ToC or Object Property ToC

modelConformsToMetamodel^op back to ToC or Object Property ToC

modelExpressesArchitecture^op back to ToC or Object Property ToC

modelHasPurpose^op back to ToC or Object Property ToC

modelRepresentsSystem^op back to ToC or Object Property ToC

notationSet^op back to ToC or Object Property ToC

partOf^op back to ToC or Object Property ToC

partOfModel^op back to ToC or Object Property ToC

preferred Visual Notation^op back to ToC or Object Property ToC

presentationContextScheme^op back to ToC or Object Property ToC

questionAddressesConcern^op back to ToC or Object Property ToC