An RDF/OWL ontology for C4 model and Structurizr elements and relationships, extending the core ontology. C4/Structurizr Metamodel Ontology defines classes for the subject of a Relationship. It is not to be used for validation domainIncludes 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 rangeIncludes 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. simpleRelationship A component belongs to a container. belongs to container A container belongs to a software system. belongs to system A container is deployed on a deployment node. deployed on A container contains components. has component A software system contains containers. has container A software system is deployed on deployment nodes. has deployment node Indicates that one element uses or interacts with another. uses 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 definedByFramework 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 conformsToMetamodel 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 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 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 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 :requiredViewpoints results in resultsIn relationshipSource the subject source relationshipTarget the object target 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 description display name Tags or classifications. tags Technology stack used by the container. technology 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 isAbstract A component (code-level module or class) within a container. Component A container (application, service, database, etc.) within a software system. Container A physical or virtual infrastructure element (e.g., server, device, VM, cloud instance). Deployment Node A specific infrastructure node (database server, load balancer, etc.). Infrastructure Node A person who uses the software system (user, actor, etc.). Person A relationship between C4 elements (interaction, dependency, etc.). Relationship A software system in the C4 model. Software System 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 Architecture Aspect example: data, activity, function, location, people, time, motivation, taxonomy, structure, connectivity, behaviour, information, parameters, constraints, roadmaps, traceability, requirements Aspect 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. Catalog 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 Concern Consideration 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. Diagram 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 Environment 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... Framework 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). Matrix 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 <b>Architecture Description</b> can be based on a specific metamodel, which can be a simple meta model or an aggregate of multiple meta models from different domains. Metamodel 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... Model 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) ModelConcept 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 Perspective 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 PresentationTemplate 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 Purpose QualifiedRelationship **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. Relationship :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 Stakeholder 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. System 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 View 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 Viewpoint 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. QualityAttribute Used to quantify QualityAttributes QualityMeasure 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