Architecture Practice from Scratch — Part 5: Formal Metamodel Definition

Parts 3 and 4 produced a conceptual metamodel and governance design — element types, relationships, domains, controlled vocabularies, review cadences. This part translates those into formal RDF that a tool can consume: OWL ontology, SKOS taxonomy, viewpoint definitions, and a metamodel manifest.

This is where the architecture practice becomes machine-readable.

The series:

1. Stakeholder Discovery & Viewpoint Elicitation
2. Structuring Requirements into Viewpoints & Artifact Types
3. Metamodel Conceptualized
4. Governance & Lifecycle Management
5. Formal Metamodel Definition ← you are here
6. Formal Governance & Validation (upcoming)
7. Tool Integration (upcoming)

---

What We're Producing

Four Turtle files that together constitute the ACME Corp metamodel:

File	Content	Linked.Archi Pattern
acme-onto.ttl	Custom element types + relationship properties	arch:modelConcepts
acme-tax.ttl	Controlled vocabularies (adoption levels, data sensitivity, maturity)	arch:conceptClassification
acme-viewpoints.ttl	5 viewpoint definitions with viewpoint catalog	arch:architectureViewpoints
acme-metamodel.ttl	Manifest tying everything together	The entry point

Additionally, the example includes assets produced in Part 6 and for the generation pipeline:

File	Content	Linked.Archi Pattern
acme-shapes.ttl	SHACL validation shapes (Part 6)	arch:formalRules
acme-deliverable-templates.ttl	Catalog page generators with SPARQL sections (Part 7)	arch:hasDeliverableTemplate

These follow the same structure as the ArchiMate 4.0 semantic assets in this repository. See Build Your Own Metamodel for the complete pattern reference and Deliverable Generator Spec for how templates are consumed by tooling.

---

File 1: Ontology (acme-onto.ttl)

The ontology defines custom element types and relationships that extend ArchiMate 4.0.

Design Principle: Reuse + Extend

ArchiMate 4.0 types are imported and used directly — no redeclaration. Custom types subclass arch:Element (not ArchiMate types) to avoid coupling:

@prefix arch: <https://meta.linked.archi/core#> .
@prefix am4:  <https://meta.linked.archi/archimate4/onto#> .
@prefix :     <https://example.com/acme/onto#> .

# Reused directly from ArchiMate 4 (no declaration needed):
#   am4:ApplicationComponent, am4:ApplicationService,
#   am4:TechnologyComponent, am4:TechnologyService,
#   am4:Capability, am4:DataObject, am4:Gap, am4:WorkPackage

# Custom extension — not in ArchiMate:
:IntegrationPoint
    a               owl:Class ;
    rdfs:subClassOf arch:Element ;
    skos:prefLabel  "Integration Point"@en ;
    skos:definition '''A defined interface through which two application components
exchange data or invoke services.'''@en ;
    rdfs:seeAlso    am4:Interface ;
.

What Gets Extended (8 Custom Types)

Type	Domain	Why Not Reuse ArchiMate
IntegrationPoint	Application	ArchiMate Interface is too abstract — we need protocol + direction
AdoptionRecommendation	Technology	Governance concept, not an architecture element
MaturityAssessment	Strategy	Point-in-time evaluation, not a static structure
Team	Organization	Organizational assignment — not in ArchiMate scope
Option	Implementation	Decision modeling — not in ArchiMate scope
DataClassification	Compliance	GDPR-specific, not in ArchiMate scope
ProcessingPurpose	Compliance	GDPR-specific
LegalBasis	Compliance	GDPR-specific

Relationships as Object Properties

Each relationship from Part 3 becomes an owl:ObjectProperty with explicit domain and range:

:ownedBy
    a               owl:ObjectProperty ;
    skos:prefLabel  "owned by"@en ;
    skos:definition "Links an application component to the team responsible for it."@en ;
    rdfs:domain     am4:ApplicationComponent ;
    rdfs:range      :Team ;
.

:hasRecommendation
    a               owl:ObjectProperty ;
    skos:prefLabel  "has recommendation"@en ;
    skos:definition "Links a technology component to its adoption governance recommendation."@en ;
    rdfs:domain     am4:TechnologyComponent ;
    rdfs:range      :AdoptionRecommendation ;
.

ArchiMate relationships (am4:serves, am4:realizes, am4:flowsTo, am4:triggers) are reused without redeclaration.

---

File 2: Taxonomy (acme-tax.ttl)

Controlled vocabularies for governance classifications. Single concept scheme with three top-level groupings:

<https://example.com/acme/tax#>
    a                skos:ConceptScheme ;
    skos:prefLabel   "ACME Corp Architecture Classifications"@en ;
    skos:hasTopConcept :AdoptionLevels, :DataSensitivity, :MaturityLevels ;
.

:AdoptionLevels
    a                 skos:Concept ;
    skos:topConceptOf <https://example.com/acme/tax#> ;
    skos:prefLabel    "Adoption Levels"@en ;
    skos:narrower     :Adopt, :Trial, :Hold, :Retire ;
.

:Adopt
    a               skos:Concept ;
    skos:broader    :AdoptionLevels ;
    skos:prefLabel  "Adopt"@en ;
    skos:definition "Approved for production use. New projects should use this technology."@en ;
.

Why SKOS (Not OWL Enumerations)

Per Design Decision DD-4 (Part 3): these are organization-governed value sets that change slowly. SKOS gives: - Enumerable values with labels and definitions - Hierarchy if needed (e.g., Personal → Special Category) - Versioning via concept scheme metadata - Queryable with standard SPARQL patterns

Part 6 will add SHACL shapes that validate instances reference valid concepts from these schemes.

---

File 3: Viewpoints (acme-viewpoints.ttl)

Each viewpoint from Part 2 becomes an arch:Viewpoint individual:

:TechnologyRadarVP
    a                       arch:Viewpoint ;
    skos:prefLabel          "Technology Radar"@en ;
    skos:definition         '''Shows approved, trialled, held, and retiring technologies.
Used to govern the technology stack.'''@en ;
    arch:includesConcept    am4:TechnologyComponent, acme:AdoptionRecommendation ;
    arch:viewpointHasPurpose :Governing, :Deciding ;
    arch:viewType           arch:Matrix, arch:Catalog ;
.

Viewpoint Properties

Property	Meaning	Source (Part 2)
arch:includesConcept	Element types allowed in this viewpoint	"Concept Types" column
arch:viewpointHasPurpose	Why stakeholders use it	"Purpose" column
arch:targetsStakeholder	Who uses it (omitted here — defined in EAonaPage viewpoints, reusable)
arch:viewType	How it's rendered	"View Types" column

Viewpoint Catalog as SKOS

Viewpoints are grouped by EA process in a SKOS concept scheme for navigation:

:ViewpointCatalog
    a                skos:ConceptScheme ;
    skos:hasTopConcept :StrategicViewpoints, :OptimizationViewpoints, :DeliveryViewpoints ;
.

---

File 4: Metamodel Manifest (acme-metamodel.ttl)

The entry point for tools. One arch:Metamodel individual that references all assets:

:AcmeMetamodel
    a                             arch:Metamodel ;
    skos:prefLabel                "ACME Corp Metamodel"@en ;

    arch:basedOnFramework         :AcmeFramework ;
    arch:modelConcepts            <https://example.com/acme/onto#> ;
    arch:conceptClassification    <https://example.com/acme/tax#> ;
    arch:architectureViewpoints   <https://example.com/acme/viewpoints#> ;
    arch:viewpointLibrary         acmevp:ViewpointCatalog ;
.

A tool reads this manifest, follows the IRIs, and discovers: - What element types exist (from arch:modelConcepts) - What classifications are available (from arch:conceptClassification) - What viewpoints are defined (from arch:architectureViewpoints) - What the framework context is (from arch:basedOnFramework)

---

How the Parts Connect

Part	Produced	Consumed By
Part 3 — Element types	→ acme-onto.ttl classes	SHACL shapes (Part 6), tool palettes (Part 7)
Part 3 — Relationships	→ acme-onto.ttl properties	SHACL shapes (Part 6), diagram rendering (Part 7)
Part 3 — DD-4 Controlled vocabularies	→ acme-tax.ttl	SHACL validation (Part 6), dropdowns in tools (Part 7)
Part 2 — Viewpoint specs	→ acme-viewpoints.ttl	Viewpoint conformance shapes (Part 6), view filtering (Part 7)
Part 4 — Governance cadences	→ Not yet formalized (Part 6)	Staleness queries, review date validation

---

What's NOT in Part 5

These are deferred to Part 6 (Formal Governance & Validation):

• SHACL shapes — completeness rules, relationship constraints, viewpoint conformance
• SPARQL governance queries — staleness detection, coverage analysis
• CI/CD pipeline — validation on commit

And deferred to Part 7 (Tool Integration):

• Deliverable templates — Handlebars/Jinja templates for generating Markdown from SPARQL results
• Notation set — visual appearance definitions for a modeling tool palette
• Generation pipeline — TTL → SPARQL → Markdown → HTML/Confluence/PDF

---

Validating the Files

To check the Turtle files parse correctly:

# Using rapper (Raptor RDF parser)
rapper -c -i turtle examples/acme-corp/acme-onto.ttl
rapper -c -i turtle examples/acme-corp/acme-tax.ttl
rapper -c -i turtle examples/acme-corp/acme-viewpoints.ttl
rapper -c -i turtle examples/acme-corp/acme-metamodel.ttl

Full semantic validation (SHACL) comes in Part 6.

---

Practical Tips

Do

• Start with the manifest. Write acme-metamodel.ttl first — even if the other files are empty. It forces you to commit to namespaces and file organization before getting lost in detail.
• One file per concern. Ontology, taxonomy, viewpoints, shapes in separate files. This matches governance: different review cadences, different owners.
• Use rdfs:seeAlso for soft references. When your type is "like" an ArchiMate type but not formally a subclass, rdfs:seeAlso declares the similarity without creating inheritance coupling.
• Keep definitions practitioner-readable. skos:definition is for architects, not ontology engineers. If a definition requires OWL knowledge to understand, it's too technical.

Don't

• Don't redeclare ArchiMate types. Import the ontology and use the types directly. Redeclaring creates synchronization problems when ArchiMate evolves.
• Don't over-constrain domains/ranges. If a relationship could reasonably apply to a broader type, use arch:Element as the domain. Overly specific constraints break extensibility.
• Don't create deep class hierarchies. Two levels (arch:Element → your type) is enough. Three or more creates coupling that makes evolution painful.
• Don't put instance data in the ontology. The ontology defines types and relationships. Actual architecture instances (the applications, technologies, capabilities) go in a separate model file.

---

What Comes Next

Part 6 takes these formal definitions and adds SHACL shapes that encode the governance rules from Part 4: completeness constraints, relationship validity, viewpoint conformance, and staleness detection queries. The metamodel tells you what's possible. The shapes tell you what's required.

---

References

• Build Your Own Metamodel — the full pattern reference
• ArchiMate 4.0 Primer & Modeling Guide
• Ontology Reference
• Part 3 — Metamodel Conceptualized
• Part 4 — Governance & Lifecycle Management

---

This is Part 5 of the Architecture Practice from Scratch series. Part 6: Formal Governance & Validation continues by adding SHACL shapes and CI/CD validation.