Backstage Metamodel Ontology
type: Ontology
imports: core#
definition: An RDF/OWL ontology for Backstage catalog entities and their relationships, extending the core ontology.

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

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

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

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

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

simpleRelationship
type: AnnotationProperty
definition: QualifiedRelationships are annotated with arch:simpleRelationship to indicate the property used to assert an unqualified relation between entities.
sub property of: seeAlso
range: Relationship
domain: QualifiedRelationship

belongs to domain
type: ObjectProperty
domain: Element
range: Domain
definition: Element belongs to a domain.

consumes API
type: ObjectProperty
domain: Component
range: API
definition: Component consumes an API.

member of
type: ObjectProperty
domain: User
range: Group
definition: User is a member of a group.

owned by
type: ObjectProperty
domain: Element
range: Group
definition: Element is owned by a group.

part of system
type: ObjectProperty
domain: Component
range: System
definition: Component is part of a system.

provides API
type: ObjectProperty
domain: Component
range: API
definition: Component provides an API.

uses resource
type: ObjectProperty
domain: Component
range: Resource
definition: Component uses a resource.

addressesConsideration
type: ObjectProperty
domain: Model
range: Consideration

alternative Visual Notation
type: ObjectProperty
sub property of: image
domain: Concept
range: ImageObject
domain includes: ModelConcept
broader: PresentationCategory
definition: A resource can have more than one value of :altVisNotation
definition: An alternative Visual Notation for a resource.

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

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

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

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

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

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

conformsToMetamodel
type: ObjectProperty
domain: Model
range: Metamodel

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

conformsToMetamodel
type: ObjectProperty
domain: Model
range: Model

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

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

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

expressesArchitecture
type: ObjectProperty
domain: Model
range: Architecture

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

framesConsideration
type: ObjectProperty
domain: Viewpoint
range: Consideration

hasArchitecture
type: ObjectProperty
domain: System
range: Architecture

hasConcern
type: ObjectProperty
domain: Stakeholder
range: Concern

hasInterestIn
type: ObjectProperty
domain: Stakeholder
range: Architecture
range: Model
range: System

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

hasPerspective
type: ObjectProperty
domain: Stakeholder
range: Perspective

hasPresentationTemplate
type: ObjectProperty
domain: Metamodel
range: PresentationTemplate
broader: PresentationCategory
definition: :presentationTemplate property defines a template that can be used to visualize part of the Architecture Model

:hasPurpose
type: ObjectProperty
domain: Model
range: Purpose

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

identifiesConsideration
type: ObjectProperty
domain: Metamodel
range: Consideration

identifiesStakeholder
type: ObjectProperty
domain: Metamodel
range: Stakeholder

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

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

measuredEntity
type: ObjectProperty
inverse of: hasQualityMeasure
domain: QualityMeasure
range: Element

measuredQualityAttribute
type: ObjectProperty
domain: QualityMeasure
range: QualityAttribute

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

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

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

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

preferred Visual Notation
type: ObjectProperty
sub property of: image
type: FunctionalProperty
domain: Concept
range: ImageObject
domain includes: ModelConcept
broader: PresentationCategory
definition: A resource has no more than one value of :prefVisNotation
definition: The preferred Visual Notation for a resource,.

presentationContextScheme
type: ObjectProperty
domain: Metamodel
range: ConceptScheme
broader: PresentationCategory
definition: presentationContextScheme contains classification of Presentation Context categories associated with presentation related concepts such as [PresentationTemplate](#PresentationTemplate), [altVisNotation](#altVisNotation), [prefVisNotation] (#prefVisNotation) Presentation Context can also be related to [Stakeholder](#Stakeholder) or stakeholder groups. In this way it used a 'Theme' to group those concepts and generate different visualizations and presentation structure depending on that Context
example: * C-Level * Business * DevOps * Architects * Infra * Security * Data Management
rationale: presentationContextScheme categories are used as 'Themes' to group those concepts and generate different visualizations and presentation structure depending on that Context

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

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

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

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

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

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

representsSystem
type: ObjectProperty
domain: Model
range: System

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

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

source
type: ObjectProperty
domain: QualifiedRelationship
range: ModelConcept
alternative label: relationshipSource
definition: the subject

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

target
type: ObjectProperty
domain: QualifiedRelationship
range: ModelConcept
alternative label: relationshipTarget
definition: the object

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

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

description
type: DatatypeProperty
domain: Element
range: string

display name
type: DatatypeProperty
domain: Element
range: string

lifecycle
type: DatatypeProperty
domain: Component
range: string
definition: Component lifecycle (e.g., production, deprecated, experimental).

owner
type: DatatypeProperty
domain: Element
range: string

tags
type: DatatypeProperty
domain: Element
range: string

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

API
type: Class
subclass of: Element
definition: An API that is owned and maintained in the ecosystem.

Component
type: Class
subclass of: Element
definition: A deployable unit, service, library, or application.

Domain
type: Class
subclass of: Element
definition: A high-level grouping (often aligned to business domains).

Group
type: Class
subclass of: Element
definition: A group of users (e.g., team, department, tribe).

Resource
type: Class
subclass of: Element
definition: A resource used by components or systems (e.g., database, bucket, external service).

System
type: Class
subclass of: Element
definition: A set of components and resources that provide business or technical value.

User
type: Class
subclass of: Element
definition: A human user in the Backstage ecosystem.

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

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

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

Concern
type: Class
subclass of: Consideration
definition: Example concerns: — The purpose or missions of the system — The appropriateness of the system for use in fulfilling its missions — The feasibility of constructing the system — The risks of system development and operation to users, acquirers, and developers of the system — Maintainability, deployability, and evolvability of the system

Consideration
type: Class

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

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

Environment
type: Class

Framework
type: Class
subclass of: CreativeWork
definition: Framework in Linked.Archi context is used to represent any type of Architecture framework. A Metamodel could be defined within a framework and thus part of it example Togaf Content Metamodel or OAF which is mostly a MetaModel or Zachman Framework even an Ontology. Frameworks may define other concepts like Processes, which is the case with Togaf ADM. Framework is characterized with ... check is standard...

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

Metamodel
type: Class
subclass of: Ontology
definition: A Metamodel in Linked.Archi context is the definition(Model) of the Modeling Language, so that the Model can be expressed in a way that communicates information about a system among involved stakeholders that can be correctly interpreted by the 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 include UML, SQL Schema, BPMN, E/R, OWL, and XML Schema. 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 meta model or an aggregate of multiple meta models from different domains.

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

ModelConcept
type: Class
definition: ModelConcept is the base Class for all Concepts used in an Architecture [Model](#Model), namely: * [Element](#Element) * [Relationship](#Relationship) * [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)
rationale: To understand why we have ModelConcepts base Class and why not use directly Concepts or Classes, we first need to understand what does Architecture Model mean in our context. That it is something mainly used to address stakeholder concerns also used to help in and possibly record the decision processes. This means that all those Model Concepts needs to be presented in different context, have specific visual notation according to that context and understood correctly by stakeholders. This involves lots of visual communication and contextual data. Model concepts are also used in the architecture modelling processes and this requires that there is a repository of predefined Concepts that an Architect can use in the Model. There are also certain restrictions that applies to those modelConcepts which are specified in the Architecture framework used and modelled in the :Metamodel(#Metamodel).

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

PresentationTemplate
type: Class
subclass of: CreativeWork
definition: Defines template that can be used for different types of presentation i.e. documents, spreadsheets, presentation slides, online presentation is slides or web pages of other forms such as dashboards, PDF, Vega or D3 visualizations.
example: * Word Doc * Markdown * html * PDF * PPT

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

QualifiedRelationship
type: Class
subclass of: Relationship

QualityAttribute
type: Class
type: NamedIndividual
mentionedIn: Quality Attributes
definition: Quality attributes are characteristics of a Software Product Quality, Software in Use Quality, Data Quality, Service Quality, Enterprise Quality, or any other System Quality. An instance of QualityAttribute class represent inherent property or characteristic of an Element or QualityAttributeRequirement so that it can be distinguished quantitatively or qualitatively. Quality Attribute is quantified by [QualityMeasure](#QualityMeasure) that can be related to an Element or QualityAttributeRequirement. Element in that case can be a work product or behavior of a system, software, or stakeholders such as users, operators, developers, testers, or maintainers.

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

Relationship
type: Class
subclass of: Property
subclass of: ModelConcept
definition: **Relationship** is the Class for relationships between Architecture concepts. **Relationship** is an instance of rdf:Class. Intances of **Relationship** should be only owl:ObjectProperties or simply rdf:Property. In other words **Relationship Class** is not a class used for reification of a relationship statement, it is the rdf:property used in the RDF triple as predicate. **Relationship subclasses** are to be defined in specific Architecture Meta Models(Ontologies or Vocabularies) These are to be used in triples and also in statements as predicates when RDF* is not possible or multiple instances of the same type of relationship exists between 2 Elements. Note the Relationship instances are defined in the metamodel compared to Elements that are defined as subclasses of :Element in the metamodel. The reason is that these are instances of rdf:Property and used as predicates and thus represent 'types' of relationships. The actual 'instantiation' happens when used in triples and also when described further using RDF* or rdf:Statement for reification.
example: ex:aggregation a arch:Relationship ; skos:prefLabel "Aggregation"@en ; skos:definition "Relationship between a Node and a composite Node representing that an element combines one or more other elements"@en ; arch:prefVisNotation "https://ex.com/aggregation.svg" ; .
history note: Initially rdf:statement was chosen as a default mechanism to describe relationships, however as RDF-star matured became the preferred way. This is due to the fact that relationship itself is less rarely used as Qualified element compared to when used as to related elements and perform graph traversals. Also very often multiples relationships of the same type are modelled between the same elements, while this is technically possible semantically it does not contribute to the model clarity and should be avoided. If this is strictly required then rdf:Statement approach shall be used. For all the rest reification uses cases rdf-star should be used. Relationship should not have instances whereas QualifiedRelationship can have instances. Reason is that when desiging a metamodel simple Relationships are actually rdf:properties or more speciically owl:ObjectProperty and subclasses of :Relationship as any element in the metamodel is a subclass of one of the arch:Concepts. Instances of the metamodel classes are the actual Architecture models.

Stakeholder
type: Class
subclass of: Element
definition: :Stakeholder is the class for Stakeholders used in describing high level architecture interest. Stakeholder is a first-class element and represented in the Code ontology as it affects directly the way the architecture and architecture description will be organized and thus impact the MetaModel. Stakeholder can be used also as a :ModelConcept and for that :Element can be extended. Same instance of :Stakeholder and :element can be used and this also recommended as will benefit the analysis and inference. Example Types of stakeholders: a) Users of the system b) Acquirers of the system c) Developers of the system d) Maintainers of the system

System
type: Class
definition: The subject of interest of a Model that is a combination of interrelated and interdependent parts organized to achieve one or more stated purposes. As such a system is defined by its structure and purpose. A system is influenced by its environment and may be bounded by space and time. This is inclusive of designs at all levels such as an entire enterprise, a process, information structures or I.T. systems.

View
type: Class
subclass of: ModelConcept
definition: Architecture View is a representation of a system from the perspective of a related set of concerns. It consists of one or more architecture models of the system

Viewpoint
type: Class
definition: An architecture Viewpoint is a specification of the conventions for a particular kind of architecture view. It can also be called the definition or schema for that kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern (or set of concerns) about a system-of-interest. A viewpoint can be seen as a diferent perspective of the subject area that shapes the Metamodel, which defines the Model. Viewpoints may look quite different so as to be meaningful to different stakeholders
qualified attribution: dd

MetamodelingCategory
type: NamedIndividual
type: Concept

ModelingCategory
type: NamedIndividual
type: Concept

NavigationCategory
type: NamedIndividual
type: Concept

PresentationCategory
type: NamedIndividual
type: Concept