Alberto D. Mendoza

This is the fifth issue in the series and the second part on shaping the graph, basically how the ArchiMate metamodel becomes enforceable. How I used SHACL to turn the RDF graph into a model aligned with the ArchiMate specification.

The Other Three Validation Files

On post 3 I covered the first SHACL file in the Validation folder archimate_derivation_ rules.ttl which basically implements ArchiMate derivation rules and tells the engine how to imply from what was never explicitly stated. On this post we cover the other 3 files in the Validation folder.

In broad strokes, SHACL operates under the closed-world assumption, and because we want our RDF models to conform to ArchiMate’s rules, we need to ensure our graph has 1) all required values, and 2) all relationship does conform with ArchiMate relationship matrix. With that in mind, the process is then to load the model into your preferred RDF datastore (I use GraphDB in my case), the SHACL processor will read the model as it stands, finds the shapes, and if any of them don’t conform with the standard, it will report them. Crucially, SHACL never adds a triple to make a violation go away. RDF, faced with a fact that doesn’t fit, will try to infer additional facts (based on the derivation rules) that would make it fit. SHACL, faced with the same fact, reports the ones that don’t. OWL infers. SHACL rejects. That single difference is why constraint enforcement lives entirely in the Validation folder and not in Ontology folder.

Conformance Is Not All-Or-Nothing

The constraints are stratified into three files. Why three files? why not one single validation file? Despite what the file names imply, the split is not by topic, it is by abstraction. This structure lets a team adopt the rules in stages instead of facing a single pass/fail gate on day one, pass Level 1 in the first week, defer Level 3 until the model matures.

Level 1 — Core (archimate_validation_core.ttl). Graph integrity, before ArchiMate semantics enter the room. Does every concept have exactly one identifier and one name? Are identifiers unique? Do specialization relationships connect same-typed elements? Are composition and aggregation chains free of cycles? A model that fails Level 1 is broken as a graph — the kind of error that has nothing to do with whether you understand ArchiMate and everything to do with whether the data is sound.

Level 2 — Metamodel (archimate_validation_metamodel.ttl). ArchiMate’s architectural grammar, written against abstract classes. Assignment runs from active structure to behavior. Triggering and flow connect behavior to behavior. Serving flows upward through the layers. These rules hold regardless of whether the element is a BusinessActor, an ApplicationComponent, or a Node — so they are written once, against the aspect-and-layer hierarchy, and OWL’s classification carries them to every concrete type. This is the level that absorbs most of the 3,844 cells without enumerating them.

Level 3 — Relationships (archimate_validation_relationships.ttl). The residue: the type-specific combinations that cannot be derived from aspect and layer alone. A BusinessActor composing a BusinessInterface is valid; a BusinessActor composing a DataObject is not — and both targets are business-layer elements, so nothing short of the exact element type settles it. Level 3 encodes that exhaustively, one shape per element type, 58 in all, not one per cell.

The three files help validate your graph in order. A graph model that passes all three validations is conformant with ArchiMate by construction.

Level 1: Core Validation

Level 1 is where the model is held to the constraints implied by ArchiMate’s Model Exchange File Format, the serialization that lets models move between tools without loss. Level 1 is the SHACL mirror of what the XSD enforces: identifier well-formedness, cardinality, uniqueness, referential integrity. Pass Level 1 and you can produce a schema-valid exchange file.

The point of formalizing ArchiMate in RDF was to serialize it faithfully. The Open Group publishes ArchiMate as a standard, and the standard includes an XML-based exchange format whose entire purpose is to move models between tools without loss. A model that cannot round-trip back into that XML format is not, in any practical sense, an ArchiMate model. It is a graph that happens to use ArchiMate vocabulary. Level 1 is the rung that keeps the serialization honest to the standard it claims to implement.

The three universal attributes — identifier, name, and documentation — are declared in the ontology against archimate:Concept, the shared superclass of both Element and Relationship. The XML schema is built the same way: the identifier attribute lives on ReferenceableType, which ConceptType extends, and ConceptType is the abstract parent of both ElementType and RelationshipType — the XSD annotation calls it “an abstract class for Concepts (Elements, Relationships, Composites, and RelationConnectors).” A relationship gets a required identifier and a required name because it is a concept. This is the validation-side counterpart to the argument from Post 2: an ArchiMate relationship is a first-class fact, not a bare edge, and Level 1 holds it to the same standard of identity that it holds an element to.

The first SHACL Constraints:

<#RealizedConceptShape> rdf:type sh:NodeShape ;
    sh:targetClass owl:NamedIndividual ;
    sh:or (
        [ sh:not [ sh:class archimate:Concept ] ]
        [ sh:and (
                [ sh:property [
                    sh:path archimate:identifier ;
                    sh:minCount 1 ;
                    sh:maxCount 1 ;
                    sh:datatype xsd:string ;
                    sh:pattern "^[a-zA-Z_][a-zA-Z0-9_-]*$" ;
                    sh:message "All realized concepts must have exactly one valid identifier"
                ] ]
                [ sh:property [
                    sh:path archimate:name ;
                    sh:minCount 1 ;
                    sh:maxCount 1 ;
                    sh:datatype xsd:string ;
                ] ]
                [ sh:property [
                    sh:path archimate:documentation ;
                    sh:maxCount 1 ;
                    sh:datatype xsd:string ;
                ] ]
            )
        ]
    ) .

The identifier shape is the most important to highlight. Every realized concept — element or relationship — must carry exactly one identifier, of type string, and that identifier is constrained by a pattern.

The sh:pattern is an important rule that matters. ^[a-zA-Z_][a-zA-Z0-9_-]*$ is not an arbitrary string rule that I picked for tidiness. It is a limitation not from ArchiMate’s exchange schema, but of the underlying XML serialization. In the ArchiMate Model Exchange File Format XSD, every concept carries an attribute named identifier. The exchange format types every identifier as xs:ID — and an xs:ID follows XML’s name rules: it can’t start with a digit, and it can’t contain spaces or most punctuation. The SHACL pattern re-encodes exactly that. Give an element the identifier “123-server” and the RDF graph will accept it, but the moment you serialize to exchange XML you’ve produced a document the schema rejects. Level 1 catches it in the graph, before the broken export happens.

Another point on note: SHACL’s sh:pattern doesn’t use generic regex — the SHACL spec ties it specifically to the XML Schema regular expression flavor (the same dialect xsd:pattern uses). It’s regex, but of the XSD variety, which differs slightly from PCRE or JavaScript regex.

You can thank the W3C for that wormhole… The Semantic Web stack inherited a lot of XML-era W3C machinery. Even though RDF long since stopped being tied to XML syntax (and why we much prefer Turtle), the SHACL standard reaches back and reuses a regex dialect specified for a 2001 standard (XML Schema). It works fine, but it’s a bit of a fossil layer, so this SHACL regex is the one place the post brushes up against XML-isms that still survive purely for continuity.

The rest of the section traces back to the same XSD just as directly. The identifier attribute is declared use="required", which is the sh:minCount 1; an XML attribute can appear at most once on an element, which is the sh:maxCount 1. The schema declares an xs:key over every concept’s @identifier, meaning identifiers must be unique within the document — that is exactly what the UniqueConceptIdentifier shape enforces in the graph. None of these rules require knowing what a BusinessActor is. They require knowing what a valid exchange file is — and that is precisely the standard this serialization commits to.

One place the ontology is deliberately stricter than the exchange format is also worth noting. The XSD declares documentation with maxOccurs="unbounded", which means a concept may carry several documentation entries. The reason: multilingual content. documentation is typed PreservedLangStringType, a string that carries an optional xml:lang attribute, and the format mirrors here exactly what it does for name, which is likewise repeatable. The exchange file expresses an element documented in English and in Spanish as two documentation elements distinguished by their language tag. XML has no native notion of a language-tagged value, so the format repeats the element to carry the languages.

The SHACL shape, by contrast, constrains documentation to sh:maxCount 1. That is an intentional tightening, and it is coherent because RDF does have a native notion of a language-tagged value: "Manages enrollment."@en and "Gestiona la inscripción."@es are two values of one property, each tagged, no repetition of the property required. Multilingual content does not disappear, it moves from “many documentation properties” to “one property, many language-tagged literals,” which is the RDF-native shape, and the same shape the SKOS layer (Post 2) already uses for multilingual labels.

This does leave one concrete obligation. A serializer that converts the RDF model back to an exchange XML file — an RDF-to-XML tool — has to bridge the two representations: it must take the single language-tagged documentation property and emit one documentation XML element per language tag. The cardinality mismatch is not a contradiction between the two formats; it is a transformation the export tool is responsible for performing. Naming it here matters, because round-trip fidelity is the whole promise of conforming to the exchange standard, and that promise only holds if the tooling closes this gap.

Two structural details in this shape are worth pausing on, because they recur everywhere in the validation files.

The first is sh:targetClass owl:NamedIndividual. The shape targets realized concepts, actual model elements, and not the ontology’s own class definitions. The ArchiMate ontology uses class punning (covered in Post 2), which means archimate:BusinessActor is itself, in a sense, an instance. Targeting owl:NamedIndividual instead of archimate:Concept is how the shape says “validate the model, not the metamodel.” A rule that fired on the ontology’s own definitions would report thousands of meaningless violations.

The second is the sh:or wrapping the whole thing. Read literally: a node passes if it is not an archimate:Concept, or if it satisfies all three property constraints. That is SHACL’s idiom for a conditional: “if this is an ArchiMate concept, then it must have these attributes.” SHACL has no if/then; sh:or with a negated guard is how you write one. It is a pattern worth recognizing now, because Level 3 is built almost entirely out of it.

Level 1 Extra – Structural Integrity

Beyond the core concept rules, Level 1 also enforces structural integrity on the relationships that build hierarchy — composition, aggregation, and specialization. These are the relationships that, if allowed to form a cycle, would make the model logically incoherent regardless of which tool reads it. The shape for circular composition is pretty short but it is doing important work:

<#NoCircularComposition> rdf:type sh:NodeShape ;
    sh:targetClass archimate:Element ;
    sh:sparql [
        sh:prefixes <#> ;
        sh:message "Circular composition relationships are not allowed (A composes B, B composes C, C composes A)" ;
        sh:select """
            SELECT $this WHERE {
                $this archimate:composition+ $this
            }
        """
    ] .

One triple pattern carries the entire check. The + after archimate:composition is a SPARQL property path: it means “one or more composition steps.” So $this archimate:composition+ $this reads as “this element reaches itself by following composition one or more times” — which is the definition of a cycle. A composes B, B composes C, C composes A: every element on that loop reaches itself, every one is reported. A direct self-loop, A composes A, is caught too, which is why NoSelfComposition exists mainly as a clearer, more specific error message rather than a logically separate check.

This is also the moment to notice that Level 1 already uses both of SHACL’s registers. The identifier shape is pure declarative SHACL — sh:property, sh:path, sh:pattern, sh:minCount — constraints expressed as data, no query language involved. The cycle shape drops into sh:sparql, because “reachable from itself in any number of hops” is a recursive, path-shaped question that declarative SHACL simply cannot phrase. That division — declarative for shape-of-a-node checks, SPARQL for path-and-graph checks — is not a Level 1 quirk. It is the grain of the whole system, and Level 2 leans almost entirely on the SPARQL side.

Level 2: Validating the Metamodel

Appendix B of the ArchiMate 3.2 specification lists all permitted relationships in a matrix: sixty-two element types on each axis, a 3,844-cell grid, 3,841 of them populated (the three Junction/Relationship intersections are empty). Count every letter in every cell and the specification asserts 11,569 permitted (element, relationship, element) combinations, and, by omission, 30,715 prohibited ones.

However, different from Level 1, where the objective is to conform with the Exchange File format, the exchange format does not validate the metamodel, it is up to the tools that implement the ArchiMate model (and for which The Open Group will grant the seal of approval for the tool to be ArchiMate certified). The objective of Level 2 and 3 is to ensure relationships conform with the normative nature of Appendix B in the specification.

The natural way to make all 11,569 triples enforceable is to encode them directly in SHACL, perhaps in 3,841 rules, one per cell. It would work. It would also be 3,841 rules to maintain, unreadable as a system, and —most importantly— it would hide the fact that the matrix is not random. It has structure. And that structure is described through the specification.

The Business Layer Metamodel for example, gives an overview of the Business Layer elements and their relationships. “Business Internal Active Structure Element”, “Business Internal Behavior Element”, and “Business Passive Structure Element” are abstract classes. We take the same approach on Layer 2. I’ve instantiated every metamodel using the abstract classes.

## 3.2 Service should not realize InternalBehavior (same layer)
# Per Figures 52/70/82: realization flows from internal/collective behavior
# toward external behavior (service), not the reverse.
<#CoreServiceRealizesInternalBehavior> rdf:type sh:NodeShape ;
    sh:targetSubjectsOf archimate:realization ;
    rdfs:label "Core Service Realization Direction" ;
    sh:severity sh:Info ;
    rdfs:comment "Within a core layer, realization should flow from internal/collective behavior to service, not the reverse." ;
    sh:sparql [
        sh:prefixes <#> ;
        sh:message "Service should not realize internal behavior elements — realization flows from process/function/interaction toward service" ;
        sh:select """
            SELECT $this ?target WHERE {
                $this archimate:realization ?target .
                # Source is ExternalBehavior in a core layer
                $this rdf:type/rdfs:subClassOf* archimate:ExternalBehavior .
                VALUES ?layer {
                    archimate:BusinessLayer
                    archimate:ApplicationLayer
                    archimate:TechnologyLayer
                }
                $this rdf:type/rdfs:subClassOf* ?layer .
                # Target is non-external BehaviorAspect in the same layer
                ?target rdf:type/rdfs:subClassOf* archimate:BehaviorAspect .
                ?target rdf:type/rdfs:subClassOf* ?layer .
                FILTER NOT EXISTS {
                    ?target rdf:type/rdfs:subClassOf* archimate:ExternalBehavior
                }
            }
        """
    ] .

So the design decision behind Level 2 validation file is to validate the metamodel. Group the rules by what kind of thing they check, and the metamodel collapses into thirty-four small, readable, independently runnable SHACL rules using the abstract classes. Most of the metamodel turns out to be derivable from a model’s structure. Only the genuinely type-specific residue needs the exhaustive treatment, and even that becomes one shape per element type, not one per cell.

The last validation file is the layer that enforces ArchiMate’s architectural grammar, the patterns from Chapter 4 and the layer figures. Assignment runs from active structure to behavior. Access runs from behavior to passive structure. Realization points from the concrete to the abstract. These are the rules that make a model ArchiMate rather than just a well-formed graph.

The economy of Level 2 is that these rules are written once, against abstract classes, and OWL’s class hierarchy carries them to every concrete element type beneath. The assignment-source shape is the whole pattern in miniature:

Two details carry the whole level. The shape targets sh:targetSubjectsOf archimate:assignment — every node that is the source of an assignment, whatever its type. And the test, rdf:type/rdfs:subClassOf* archimate:ActiveStructure, is a property path that walks from an instance up its entire class chain: take the node’s type, then follow subClassOf zero or more times, and ask whether ActiveStructure is anywhere on that path. A BusinessProcess fails it — its chain leads to BehaviorAspect, not ActiveStructure — so a BusinessProcess on the source end of an assignment is reported. The shape never names BusinessProcess, or BusinessActor, or any concrete type at all. It names one abstract class and lets the hierarchy do the rest. That is the leverage the stack section promised: write the rule against the aspect, and OWL’s classification delivers it to every concrete type beneath.

Level 2 also reaches into the RDF-Star metadata. The attribute shapes — access type, influence sign and strength, flow type — validate the annotations on a relationship, querying the quoted triple <<$this archimate:access ?target>> to check that, say, an accessType is one of read, write, readwrite, unspecified. The first-class relationship facts from Post 2 are not exempt from validation; Level 2 checks their properties too.

Level 3: The Matrix as Shapes

Level 2 gets us most of the way there. What it cannot reach is the residue this post opened with — the combinations that aspect and layer alone do not settle.

A BusinessActor may compose a BusinessInterface but not a DataObject. Both targets are perfectly good elements; the difference is not aspect, not layer, just type. No abstract rule decides it. This is what Level 3 is for, and it is the layer that consumes the relationship matrix directly — the file’s own header notes it is derived from relationships.xml, the same source as the interactive grid above.

Level 3 trades cleverness for exhaustiveness. One shape per element type, each spelling out its permitted targets:

<#BusinessActorRelationships> rdf:type sh:NodeShape ;
    sh:targetClass archimate:BusinessActor ;
    sh:property [
        sh:path archimate:composition ;
        sh:or ( [ sh:class archimate:BusinessActor ]
                [ sh:class archimate:BusinessInterface ]
                [ sh:class archimate:Grouping ] ) ;
        sh:message "BusinessActor: composition is only valid to BusinessActor, BusinessInterface, Grouping."
    ] ;
    # ... aggregation, access, realization follow the same shape
    .

The idiom is the sh:or of sh:class options — the same conditional pattern Level 1 introduced, now used as a whitelist. For BusinessActor‘s composition path, the permitted target is one of exactly three types; anything else is a violation. It is not elegant, and it is not meant to be. It is one BusinessActor row of Appendix B, transcribed.

Notice what Level 3 does not re-litigate. Its header is explicit: flow, triggering, and serving belong to Level 2’s generic metamodel; association is universally permissive and needs no shape; specialization is Level 1’s same-type rule; assignment and influence are already handled upstream. Level 3 only encodes the four structural relationships — composition, aggregation, access, realization — whose legality genuinely turns on element type. Level 3 skips Grouping/Location as unrestricted and Junction/Relationship as connectors. The stratification is doing exactly what it was designed to do: by the time enforcement reaches Level 3, most of the 11,569 combinations have already been settled abstractly, and only the irreducibly type-specific ones remain to be written out.

<#AssignmentSourceConstraint> rdf:type sh:NodeShape ;
    sh:targetSubjectsOf archimate:assignment ;
    sh:sparql [
        sh:message "In core layers, assignment can only originate from active structure elements" ;
        sh:select """
            SELECT $this WHERE {
                $this archimate:assignment ?target .
                $this rdf:type/rdfs:subClassOf* archimate:CoreLayer .
                FILTER NOT EXISTS {
                    $this rdf:type/rdfs:subClassOf* archimate:ActiveStructure
                }
            }
        """
    ] .

What This Looks Like in GraphDB

The three files can run today on your favorite triple store. GraphDB is a concrete place to see the contract enforce itself, and how it works there sharpens what “enforcement” actually means.

The first thing to know is that SHACL is not a button you press after the fact. SHACL support in a given repository must be enabled when that repository is created — you cannot modify an existing repository by enabling validation afterwards. On the Create repository screen there is an Enable SHACL validation checkbox, and that decision is permanent for the repository’s life. This is not a quirk; it is the point. A repository created for conformant ArchiMate is constitutionally conformant — validation is part of what the repository is, not a report you remember to run.

The second thing follows from it. Shape graphs are stored separately from data, in a reserved graph — <http://rdf4j.org/schema/rdf4j#SHACLShapeGraph>. So loading the system happens in two distinct acts. First you import the shapes: the contents of archimate_validation_core.ttl, archimate_validation_metamodel.ttl, and archimate_validation_relationships.ttl go into that reserved shapes graph. Then, separately, you import data — the ArchiMate ontology itself and your model.

And here is where enforcement stops being a metaphor. In GraphDB, validation is not a step you invoke; it runs on every transaction that writes data. When you import a model that violates a shape, the import fails, returning a detailed error message that lists all validation violations in both the Workbench and the command line. The bad data does not land and then get flagged. The transaction is rejected. The graph never enters an invalid state at all.

Take the running example — a model where a BusinessActor is given a composition edge to a DataObject:

myModel:CustomerServiceTeam rdf:type archimate:BusinessActor ;
    archimate:identifier "actor-001" ;
    archimate:name "Customer Service Team" ;
    archimate:composition myModel:CustomerRecord .
myModel:CustomerRecord rdf:type archimate:DataObject ;
    archimate:identifier "data-001" ;
    archimate:name "Customer Record" .

Nothing here is wrong as a graph. The identifiers are well-formed, the names are present — Level 1 is satisfied. The relationship is structural, between two real elements — Level 2’s generic patterns are satisfied. It fails at Level 3, against BusinessActorRelationships, because DataObject is not one of the three types a BusinessActor may compose. Attempt to import this model into the repository, and the transaction is refused. The report comes back as a SHACL validation report — itself an RDF graph — and the offending result reads, in substance:

• sh:focusNode → myModel:CustomerServiceTeam — the element at fault
• sh:resultPath → archimate:composition — the relationship at fault
• sh:value → myModel:CustomerRecord — the value that broke the rule
• sh:resultMessage → “BusinessActor: composition is only valid to BusinessActor, BusinessInterface, Grouping.”
• sh:resultSeverity → sh:Violation

That message is not generic. It is the exact sh:message string written into the Level 3 shape — which is why the effort of writing specific, human-readable messages into every shape pays back here: the report tells whoever hit it precisely what ArchiMate rule they broke and what the legal targets were.

Two honest notes for anyone actually deploying this. First, GraphDB’s validation rests on RDF4J’s ShaclSail, and the official guidance is that SHACL-SPARQL must be written judiciously, because a SPARQL-based constraint is executed for each target — relevant here because Levels 1 and 2 lean heavily on sh:sparql. Keeping targets narrow (sh:targetSubjectsOf rather than a broad class) is a performance decision, not only a modeling one. Second, the validation files use RDF-Star quoted triples for the relationship-attribute checks; RDF-Star support and its interaction with ShaclSail is engine- and version-specific, and is worth confirming against the GraphDB version in front of you rather than assumed.

Post 6

SPARQL examples, impact analysis, federation.

The ontology is independent and is not an official publication of The Open Group. ArchiMate® is a registered trademark of The Open Group.