Standards Alignment¶

Linked.Archi aligns its core concepts to international standards from ISO/IEC/IEEE. The standards/ directory contains formal vocabularies that capture the key concepts from these standards, providing traceability from Linked.Archi ontologies back to their normative sources.

How Standards Are Used¶

Standards serve as reference vocabularies — they define the formal terminology that the modeling languages, extensions, and core ontology align to. They are not modeling languages themselves; they provide the conceptual foundation.

Standard	What it provides	Used by
ISO/IEC/IEEE 42010	Architecture description concepts (System, Architecture, Viewpoint, View, Stakeholder, Concern)	Core ontology (`arch:Viewpoint`, `arch:Stakeholder`, `arch:Concern`)
ISO/IEC/IEEE 42020	Architecture governance processes (Conceptualization, Evaluation, Elaboration, Transition)	Architecture processes extension, TOGAF metamodel
ISO/IEC/IEEE 12207	Software lifecycle processes (Agreement, Technical Management, Technical)	Architecture processes extension
ISO/IEC/IEEE 15288	System lifecycle processes (same structure as 12207 but for systems)	Architecture processes extension
ISO/IEC 25010	Software product quality model (8 characteristics, 31 sub-characteristics)	Quality attributes extension, ArchiMate principle shapes
ISO/IEC 25011	IT service quality model (9 characteristics)	Quality attributes extension
ISO/IEC 25012	Data quality model (15 characteristics)	Quality attributes extension

Semantic Modeling Patterns¶

Architecture & Systems Engineering Standards (42010, 42020, 12207, 15288)¶

These standards are modelled as reference vocabularies — they are owl:Class hierarchies that do not subclass arch:Element. They are not model elements; they define the formal terminology that the core ontology and extensions align to. Concepts use rdfs:seeAlso to link to the corresponding core ontology class where applicable.

ISO 42010 concepts are pure owl:Class with SKOS labels and definitions. ISO 42020, 12207, and 15288 define owl:Class types (Process, Activity, Task, etc.) and named individuals of :Process for the specific process areas.

# In standards/iso42010/iso42010.ttl
:ArchitectureViewpoint
    a               owl:Class ;
    skos:prefLabel  "Architecture Viewpoint"@en ;
    skos:definition "A work product establishing the conventions for the construction,
                     interpretation, and use of architecture views..." ;
    rdfs:seeAlso    arch:Viewpoint .   # ← links to the core ontology class

Note: Standards do not subclass arch:Element because they are reference vocabularies, not model elements. The practical model element classes live in the extensions (e.g., ap:ArchitectureProcess rdfs:subClassOf arch:Element in the architecture processes extension).

Quality Models (25010, 25011, 25012)¶

These standards use a class/individual hybrid pattern:

Root classes (e.g., iso25010:SoftwareProductQuality) are owl:Class with rdfs:subClassOf arch:QualityAttribute
Top-level characteristics (e.g., iso25010:Reliability) are owl:Class with rdfs:subClassOf the root — they are categories that group sub-characteristics
Leaf sub-characteristics (e.g., iso25010:Availability) are owl:NamedIndividual typed as their parent class — they are the vocabulary terms you reference in models

This pattern reflects how quality attributes are actually used: the leaf sub-characteristics are named concepts from the standard, not types you instantiate. Per-component quantification is done via arch:QualityMeasure.

Standards root classes do not subclass arch:Element — they are reference vocabulary terms, not model elements. The arch:QualityAttribute superclass provides the semantic bridge to the core ontology.

iso25010:SoftwareProductQuality          ← owl:Class (rdfs:subClassOf arch:QualityAttribute)
  └─ iso25010:Reliability                ← owl:Class (category)
       ├─ iso25010:Availability          ← owl:NamedIndividual (vocabulary term)
       ├─ iso25010:FaultTolerance        ← owl:NamedIndividual
       ├─ iso25010:Recoverability        ← owl:NamedIndividual
       └─ iso25010:Maturity              ← owl:NamedIndividual

Traceability¶

Each standard vocabulary uses rdfs:seeAlso to link its concepts to the corresponding OWL classes in the core ontology. This enables queries like "which ISO 42010 concepts does this ontology implement?":

PREFIX iso42010: <https://meta.linked.archi/iso42010#>
PREFIX arch:     <https://meta.linked.archi/core#>

SELECT ?isoConcept ?isoLabel ?coreClass WHERE {
    ?isoConcept rdfs:seeAlso ?coreClass ;
                skos:prefLabel ?isoLabel .
    ?coreClass a owl:Class .
}

Architecture & Systems Engineering Standards¶

ISO/IEC/IEEE 42010 — Architecture Description¶

The foundational standard for architecture description. Defines the conceptual model that Linked.Archi's core ontology implements: System, Architecture, Architecture Description, Stakeholder, Concern, Architecture Viewpoint, Architecture View, Architecture Model, Architecture Decision, Architecture Rationale, Correspondence, and Correspondence Rule.

Namespace: https://meta.linked.archi/iso42010#

ISO/IEC/IEEE 42020 — Architecture Processes¶

Defines the processes for governing and managing architecture: Architecture Governance, Architecture Conceptualization, Architecture Evaluation, Architecture Elaboration, and Architecture Transition. These align with TOGAF's ADM phases and the architecture processes extension.

Namespace: https://meta.linked.archi/iso42020#

ISO/IEC/IEEE 12207 — Software Lifecycle Processes¶

Framework of processes for the software life cycle: Agreement Processes, Organizational Project-Enabling Processes, Technical Management Processes, and Technical Processes.

Namespace: https://meta.linked.archi/iso12207#

ISO/IEC/IEEE 15288 — System Lifecycle Processes¶

Same structure as 12207 but for systems engineering. Covers the full system life cycle from concept through retirement.

Namespace: https://meta.linked.archi/iso15288#

Quality Models (SQuaRE Family)¶

ISO/IEC 25010 — Product Quality Model¶

The most comprehensive quality model. Defines 8 top-level quality characteristics as owl:Class categories, with 31 leaf sub-characteristics as owl:NamedIndividual vocabulary terms: Functional Suitability (3), Performance Efficiency (3), Compatibility (2), Usability (6), Reliability (4), Security (5), Maintainability (5), and Portability (3). Also defines Quality in Use as a separate root class and three user types (PrimaryUser, SecondaryUser, IndirectUser).

Namespace: https://meta.linked.archi/iso25010#

ISO/IEC 25011 — Service Quality Model¶

Quality characteristics for IT services. ITServiceQuality is the root owl:Class, with 9 characteristics as owl:NamedIndividual instances: Availability, Responsiveness, Integrity, Usability, Portability, Recoverability, Capacity, Continuity, and Security.

Namespace: https://meta.linked.archi/iso25011#

ISO/IEC 25012 — Data Quality Model¶

Quality characteristics for data. DataQuality is the root owl:Class, with 15 characteristics as owl:NamedIndividual instances grouped into inherent (Accuracy, Completeness, Consistency, Credibility, Currentness), inherent/system-dependent (Accessibility, Compliance, Confidentiality, Efficiency, Precision, Traceability, Understandability), and system-dependent (Availability, Portability, Recoverability).

Namespace: https://meta.linked.archi/iso25012#

Using Standards in Your Models¶

Quality Attribute Measurement¶

The core ontology provides arch:QualityMeasure for per-component quantification. A QualityMeasure links a named quality attribute (the owl:NamedIndividual from the standard) to a specific architecture element:

@prefix arch:     <https://meta.linked.archi/core#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix am:       <https://meta.linked.archi/archimate3/onto#> .
@prefix ex:       <https://model.example.com/myarch#> .

# The architecture element
ex:PaymentService a am:ApplicationService ;
    skos:prefLabel "Payment Processing Service"@en ;
    arch:hasQualityMeasure ex:payment-availability, ex:payment-security .

# Quality measures — per-component quantification
ex:payment-availability a arch:QualityMeasure ;
    arch:measuredQualityAttribute iso25010:Availability ;   # ← the NamedIndividual
    arch:measuredEntity           ex:PaymentService ;       # ← the Element
    skos:prefLabel "Payment Service Availability Target"@en .

ex:payment-security a arch:QualityMeasure ;
    arch:measuredQualityAttribute iso25010:Confidentiality ;
    arch:measuredEntity           ex:PaymentService ;
    skos:prefLabel "Payment Service Confidentiality Target"@en .

Quality Attribute Requirements (Decision Records)¶

The architecture decisions extension uses ad:QualityAttributeRequirement with Quality Attribute Scenarios (QAS) to capture quality requirements formally:

@prefix ad:       <https://meta.linked.archi/arch-decision#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .
@prefix ex:       <https://model.example.com/myarch#> .

ex:QAR-001 a ad:QualityAttributeRequirement ;
    skos:prefLabel "Payment Availability Under Peak Load"@en ;
    ad:onQualityAttribute   iso25010:Availability ;         # ← the NamedIndividual
    ad:qasSourceOfStimulus  "External users" ;
    ad:qasStimulus          "Black Friday peak load (10x normal traffic)" ;
    ad:qasEnvironment       "Normal operation, all regions active" ;
    ad:qasArtifact          ex:PaymentService ;
    ad:qasResponse          "Service continues processing transactions" ;
    ad:qasResponseMeasure   "99.95% uptime, p99 latency < 500ms" .

Querying Quality Attributes¶

Find all elements with reliability-related quality measures:

PREFIX arch:     <https://meta.linked.archi/core#>
PREFIX iso25010: <https://meta.linked.archi/iso25010#>

SELECT ?element ?elementLabel ?qa ?qaLabel WHERE {
    ?measure a arch:QualityMeasure ;
             arch:measuredEntity ?element ;
             arch:measuredQualityAttribute ?qa .
    ?element skos:prefLabel ?elementLabel .
    ?qa      skos:prefLabel ?qaLabel .
    ?qa      a iso25010:Reliability .
}

Find all quality attribute requirements that lack a response measure:

PREFIX ad: <https://meta.linked.archi/arch-decision#>

SELECT ?qar ?label WHERE {
    ?qar a ad:QualityAttributeRequirement ;
         skos:prefLabel ?label .
    FILTER NOT EXISTS { ?qar ad:qasResponseMeasure ?_ }
}

Compliance Validation with SHACL¶

Use SHACL shapes to enforce that critical systems have required quality measures:

@prefix sh:       <http://www.w3.org/ns/shacl#> .
@prefix arch:     <https://meta.linked.archi/core#> .
@prefix iso25010: <https://meta.linked.archi/iso25010#> .

ex:CriticalSystemSecurityShape a sh:NodeShape ;
    sh:targetClass ex:CriticalSystem ;
    sh:property [
        sh:path arch:hasQualityMeasure ;
        sh:qualifiedValueShape [
            sh:property [
                sh:path arch:measuredQualityAttribute ;
                sh:hasValue iso25010:Confidentiality ;
            ] ;
        ] ;
        sh:qualifiedMinCount 1 ;
        sh:message "Critical systems must have a Confidentiality quality measure." ;
    ] .