An RDF/OWL ontology for C4 model and Structurizr elements and relationships, extending the core ontology.
defines classes for the subject of a Relationship. It is not to be used for validation
Values of this property define the type of the source Element; in simple relationships, this would be the subject. This property is used for guiding modelling but not restricting relationships. Relationship restrictions, like other types of restrictions, should be implemented using SHACL.
A reference to the Linked.Archi Knowledge base section that describes this concept.
defines classes for the object of a Relationship. It is not to be used for validation
Values of this property define the type of the target Element; in simple relationships, this would be the subject. This property is used for guiding modelling but not restricting relationships. Relationship restrictions, like other types of restrictions, should be implemented using SHACL.
A description of a justification of the existence of the term in that form or some other assertion or value
QualifiedRelationships are annotated with arch:simpleRelationship to indicate the property used to assert an unqualified relation between entities.
A container belongs to a software system.
A container is deployed on a deployment node.
A software system is deployed on deployment nodes.
Indicates that one element uses or interacts with another.
addressesConsideration
A resource can have more than one value of :altVisNotation
An alternative Visual Notation for a resource.
alternative Visual Notation
architectureViewpoints property specifies the ontology that defines the architecture viewpoints including Concerns and Stakeholders and also restriction on the viewpoints.
architectureViewpoints
architectureViewpoints property specifies the ontology that defines restriction on the viewpoints using SHACL or other method. This can also be used for SHACL processors.
architectureViewpointsRestrictions
The :Framework that is used as a foundation for the :MetaModel
ConceptClassification resource is a Scheme that defines the classification of the Elements, Relationships and Viewpoints or other Model Concepts defined within a Metamodel or ontology for example: `rdf:type skos:ConceptScheme , owl:Ontology` is a consistent statement This classification could be used for visual aid and modelling. More than one classifications can exist. Classifications can be embedded within the Metamodel ontology. SKOS concept scheme(s) needs to be supplied.
conceptClassification
Indicates the stakeholder or governance body responsible for the maintenance and governance of an architecture concept within the architecture repository.
Use this property to explicitly document ownership to avoid ambiguity in governance responsibilities across various organisational units or roles.
Concept Owner
This property helps to clearly identify accountability and stewardship, facilitating effective governance and lifecycle management of architecture elements.
conformsToMetamodel
viewpoint property specifies the Viewpoint individual of a particular View instance
conformsToViewpoint
DerivationRules property specifies the document that defines the possible derivation rules. A way to express those rules could be N3 notation. This can also be used for SHACL processors.
derivationRules
System Situated In Environment which System and Environment interact some way or another.
environment
Concepts property that specifies the individual Views that exposes that Concept such as Elements, Relationships or other Views. In the case of a relationshipRDF* or statement can be used to link the triple with the View.
exposedInView
expressesArchitecture
FormalRules property specifies all the rules that a Model needs to conform to. This include Element structure, relationships, properties even naming conventions. A way to represent those rules can be SHACL. This can also be used for SHACL processors.
formalRules
framesConsideration
hasArchitecture
hasConcern
hasInterestIn
hasPart
hasPerspective
:presentationTemplate property defines a template that can be used to visualize part of the Architecture Model
hasPresentationTemplate
:hasPurpose
Whether an element has a quality attribute measure associated to it. A domain can be an Element such as work product or behavior of a system, software, or stakeholders such as users, operators, developers, testers, or maintainers.
hasQualityMeasure
identifiesConsideration
identifiesStakeholder
Defines the Concepts that may be used in this Viewpoint. These are not considered as restrictions, but can be used to define a palette of available Model Concepts. Note that more formal and rigid SHACL rules can be defined in a [shapes graph](https://w3c.github .io/data-shapes/shacl/#dfn-shapes-graphs) using property [architectureViewpointsRestrictions](#architectureViewpointsRestrictions).
includesConcept
Specifies the authoritative data source or primary repository from which the architecture element's data is maintained, exported, or synchronised.
Maintain clarity in source identification to enhance data reliability and simplify maintenance and integration workflows within the architecture repository.
Master Data Source
This annotation is particularly crucial for scenarios involving data aggregation, ensuring traceability and consistency across diverse architecture modelling and management tools.
measuredEntity
measuredQualityAttribute
The purpose of the System. This is a generic property and can be anything.
meetsPurpose
ModelConcepts property specifies the Ontology that defines the structure, terms, notations, semantics and basic syntax of the modeling language. This includes Elements and Relationships subtypes. Viewpoints are defined using [architectureViewpoints](#architectureViewpoints) property and classified using [viewpointLibrary](#viewpointLibrary) property. Note actual individulas Elements, Relationships, Views are defined in the actual Architecture Model.
modelConcepts
partOf is a generic property that is mainly intended for traceability and composability relations across models. While it can be used for composition relationships within a model, in many cases more specific semantics would be needed and for that new more specific relationship should be used.
partOf
Concepts property that specifies the Model that contains that Concept such as Elements, Relationships or other Views. In the case of a relationship RDF-star or statement can be used to link the triple with the View. Note that Model propery of a concept can be expressed via quads.
partOfModel
A resource has no more than one value of :prefVisNotation
The preferred Visual Notation for a resource,.
preferred Visual Notation
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
* C-Level * Business * DevOps * Architects * Infra * Security * Data Management
presentationContextScheme categories are used as 'Themes' to group those concepts and generate different visualizations and presentation structure depending on that Context
any reference data that is relevant to the subject and can or should be referenced by any element or description within the Architecture Model or the Metamodel itself. For Reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations use [referenceModels](#referenceModels)
referenceData
Concept scheme that contains any relevant reference Architectures, Models, Templates, Patterns, Tactics Reference design and implementations
referenceModels
refined by
refinedByAspect
refinedInto
domain refines range i.e. domain is a more concrete or complete representation of range. This is a traceability property intended to use within a single model or across models. I may be used as well as to related a particular :View that refines a :Element. For example a high level process may be refined by a sequence diagram.
refines
:requiredViewpoint is used to model the relevant or recommended Viewpoints when performing an architecture work with the specific :Purpose
:requiredViewpoints
representsSystem
:requiredViewpoint is used to model the required Viewpoints when performing an architecture work with the specific :Purpose
results in
resultsIn
Viewpoint property that relates targeted stakeholders. While this relationship can be infered from :viewpointFramesConcern and :stakeholderHasConcern it is not always the case when concerns overlap or there are different visual notations and representation preferences form the side of the stakeholders. In other words this is explicitly defined by the designer of the particular viewpoint and can match all or a subsets of the stakeholders. In some case it
viewpointTargetsStakeholder
viewpointLibrary property specifies a Concept scheme that classifies available Viewpoints
viewpointLibrary
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
A component (code-level module or class) within a container.
A container (application, service, database, etc.) within a software system.
A physical or virtual infrastructure element (e.g., server, device, VM, cloud instance).
A specific infrastructure node (database server, load balancer, etc.).
A person who uses the software system (user, actor, etc.).
A relationship between C4 elements (interaction, dependency, etc.).
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.
Architecture Aspect example: data, activity, function, location, people, time, motivation, taxonomy, structure, connectivity, behaviour, information, parameters, constraints, roadmaps, traceability, requirements
Catalog is a list of building blocks of a specific type, or of related types, that are used for governance or reference purposes (for example, an organization chart, showing locations and actors). As with building blocks, catalogs carry metadata according to the metamodel, which supports query and analysis.
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
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 is the class for Elements or Nodes used in models. Element sub-classes are to be defined in more specific Architecture Meta Models Element instances are to be used in the actual Architecture Models. In general an Architecture Element represents any significant component of the architecture that needs to be addressed.
Element
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 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).
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.
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 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)
To understand why we have ModelConcepts base Class and why not use directly Concepts or Classes, we first need to understand what does Architecture Model mean in our context. That it is something mainly used to address stakeholder concerns also used to help in and possibly record the decision processes. This means that all those Model Concepts needs to be presented in different context, have specific visual notation according to that context and understood correctly by stakeholders. This involves lots of visual communication and contextual data. Model concepts are also used in the architecture modelling processes and this requires that there is a repository of predefined Concepts that an Architect can use in the Model. There are also certain restrictions that applies to those modelConcepts which are specified in the Architecture framework used and modelled in the :Metamodel(#Metamodel).
Stakeholder Perspective. Example: * strategic * capability * operations * services * physical
* strategic * capability * operations * services * physical
Defines 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.
* Word Doc * Markdown * html * PDF * PPT
As a work product, an AD is devised for the specific purpose for which the architecting effort is undertaken. This purpose shapes the AD and also act as force in the architecting effort. This is the same as "Design Objectives" mentioned in ADD 3.0.
For a presales proposal architecture work involves rapid design. Here the main viewpoint would be high level structure and behaviour as well as cost estimations. The design work will not go in details
**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.
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" ; .
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 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
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.
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
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
MetamodelingCategory
ModelingCategory
NavigationCategory
PresentationCategory
Quality attributes are characteristics of a Software Product Quality, Software in Use Quality, Data Quality, Service Quality, Enterprise Quality, or any other System Quality. An instance of QualityAttribute class represent inherent property or characteristic of an Element or QualityAttributeRequirement so that it can be distinguished quantitatively or qualitatively. Quality Attribute is quantified by [QualityMeasure](#QualityMeasure) that can be related to an Element or QualityAttributeRequirement. Element in that case can be a work product or behavior of a system, software, or stakeholders such as users, operators, developers, testers, or maintainers.
any reference to as standard that is relevant to the subject and can or should be referenced. Any associated standard should be part of the [standardsInformationBase](#standardsInformationBase). This sometimes require validation in that case standrad may be present in the Model but not in the Metamodel stands information base, however, should be put in the next version of the Metamodel.
associatedStandard
Indicates that the concept is referred in, but is not necessarily the main topic.
mentionedIn
standards concept scheme contains classification of standards and references to standards that are relevant to the subject and can or should be used. This scheme may also define Guidelines and Best Practices o toher informal or semi-formal guiding documentation. Formal Patterns, Reference Architectures, Models, Building Blocks and tactics should use [Reference Architecture Ontology](https://meta.linked.archi/ref-arch)
* Business Standards: * Standard shared business functions * Standard role and actor definitions * Security and governance standards for business activity * Data Standards: * Standard coding and values for data * Standard structures and formats for data * Standards for origin and ownership of data * Restrictions on replication and access * Applications Standards: * Standard/shared applications supporting specific business functions * Standards for application communication and interoperation * Standards for access, presentation, and style * Technology Standards; * Standard hardware products * Standard software products * Standards for software development
standardsInformationBase