Alberto D. Mendoza

This is the second issue of a series on why Enterprise Architecture practice could use a different information system model. The first post covered the motivation, the state of EA tooling, an introduction to the ontology’s structure, and the federation vision. This post is about the Ontology files: the design decisions, the tradeoffs, and the honest limitations of formalizing ArchiMate 3.2 in OWL. If you want to understand why the ontology is structured the way it is, and not some other way, this is that post.

The Ontology Files

When I started writing the ontology, I wanted to have one file. archimate.ttl. OWL classes, SKOS labels, relationship declarations, all of it in one place. It made sense at the time. One ontology, one file. But that approach didn’t last. The SKOS vocabulary kept pulling in a different direction from the OWL semantics, and validation logic had no clean home. The file was getting too long. It was doing three jobs and doing none of them well. So I split it. One OWL file for meaning, one SHACL for constraints, one SKOS for vocabulary. Three files, three jobs, no overlap. You can see the history and evolution of the file in the GitHub commits.

Eventually, I discovered that this design principle of separating Semantics/Meaning from Contrains/Structure has a name, the Polikoff Rule. Understanding each file helped clarify why each part of the system works the way it does.

This post is about the files in the Ontology folder, what’s in them, the design decisions behind them, the tradeoffs, and the honest limitations of formalizing ArchiMate 3.2 in OWL. If you want to understand why the Ontology is structured the way it is, and not some other way, this is that post.

The Three Files

When you go to GitHub, you will see a simple folder structure.

ontology/
├── archimate.ttl # Main ontology file (purl.org/archimate/owl)
├── archimate_skos.ttl # Vocabulary (purl.org/archimate/skos)
└── archimate_profile_examples.ttl # Profile examples

The main file is called archimate.ttl and here you will find the core of the ArchiMate Ontology. Elements and Relationships using Class hierarchies, object properties, the semantic relationships between them. What a BusinessActor is. What composition is. What specialization means as a transitive property. How layers and aspects compose into a coherent taxonomy. These are statements about meaning, and OWL is the right language for them. You can find more details about this file on my first post.

archimate_skos.ttl: the SKOS vocabulary. Term definitions, alternative labels, scope notes, broader/narrower relationships between concepts. The browsable structure that makes the ontology legible to architects rather than just to reasoners. SKOS handles what OWL was not designed for: controlled vocabulary management, multilingual labels, navigational collections for onboarding practitioners to a large taxonomy.

archimate_profile_examples.ttl: Examples of Element Specializations and the Profile mechanism. Showcases the extensibility of the ArchiMate language, into narrower and specialized classes. Best example is BusinessActor -> Person.

Each file has one job. A reasoner consuming archimate.ttl does not need to load the SKOS file. The SKOS file can publish independent languages. A governance tool running SHACL validation does not need to load the SKOS hierarchy. An organization that wants to import the class hierarchy and layer their own SHACL shapes on top can do so without inheriting constraints that only apply in one context.

The third example file, is just a practical example of the language extensibility mechanism. A domain team can add a profile namespace with new element subtypes, layer domain-specific Classes, add terminology to the SKOS vocabulary, all without touching any of the three core files. The shared semantics stay intact. That is what the separation was built for.

ArchiMate.ttl – The Main File

The file is organized into three sections. Each has one job.

Section 1 — General ArchiMate Definitions. The ontology declaration, the class hierarchy root, the universal properties, the Aspects, and the Layers. This is the grammar of the language before any element is named. ArchiMate → Model → Concept → Element / Relationship. Every element declared in Section 2 inherits from this chain. The three universal properties — identifier, name, documentation — are declared here against Concept, which means they apply to both elements and relationships without being redeclared. The Aspects (ActiveStructure, PassiveStructure, BehaviorAspect, MotivationAspect) and Layers (BusinessLayer, ApplicationLayer, TechnologyLayer, and the extended layers) are declared here as abstract classes. No element type lives in Section 1. It is the skeleton.

### 1. General ArchiMate Definitions
<#ArchiMate> rdf:type owl:Class ;
    rdfs:label "ArchiMate" ;
    rdfs:comment "ArchiMate Enterprise Architecture modeling language, a visual language with a set of default iconography for describing, analyzing, and communicating many concerns of Enterprise Architectures as they change over time. The standard provides a set of entities and relationships with their corresponding iconography for the representation of Architecture Descriptions." ;
    rdfs:subClassOf owl:Thing ;
    skos:exactMatch archimate-skos:ArchiMate .
<#Model> rdf:type owl:Class ;
    rdfs:label "Model" ;
    rdfs:comment "A model contains elements and relationships within an architecture." ;
    rdfs:subClassOf <#ArchiMate> .
<#Concept> rdf:type owl:Class ;
    rdfs:label "Concept" ;
    rdfs:comment "A conceptual entity within the ArchiMate modeling language." ;
    rdfs:subClassOf <#Model> .
# Aspects
<#Aspect> rdf:type owl:Class ;
    rdfs:label "Aspect" ;
    rdfs:comment "Classification of elements based on layer-independent characteristics related to the concerns of different stakeholders. Used for positioning elements in the ArchiMate metamodel." ;
    rdfs:subClassOf <#Model> .
# Layers
<#Layer> rdf:type owl:Class ;
    rdfs:label "Layer" ;
    rdfs:comment "A major division in the architecture that categorizes elements according to their scope and purpose." ;
    rdfs:subClassOf <#Model> .
# Elements
<#Element> rdf:type owl:Class ;
    rdfs:label "Element" ;
    rdfs:comment "A fundamental building block within an architecture model." ;
    rdfs:subClassOf <#Concept> .

Section 2 — ArchiMate Elements. All 61 element types, organized by layer subsection: Motivation, Strategy, Business, Application, Technology, Physical, Implementation & Migration, and Composite Elements. Each element is three rdfs:subClassOf declarations — element type, layer, and aspect:

### 2. ArchiMate Elements
#### 2.3 Business Layer Elements
##### Active Structure Elements
<#BusinessActor> rdf:type owl:Class ;
    rdfs:label "Business Actor" ;
    rdfs:comment "An organizational entity capable of performing behavior." ;
    rdfs:subClassOf <#InternalActiveStructure> ;
    rdfs:subClassOf <#BusinessLayer> ;
    rdfs:subClassOf <#Element> .

Three lines. That is the entire encoding of a BusinessActor‘s position in the metamodel — what it is, where it lives, and what role it plays — in a form a reasoner propagates automatically to every instance. A SHACL shape written against ActiveStructure fires on BusinessActor instances without modification. A query for all BusinessLayer elements returns it. The subclass chain does the work.

Section 3 — Relationships. The four owl:ObjectProperty hierarchies (structuralRelationship, dependencyRelationship, dynamicRelationship, otherRelationship), the 11 relationship types declared as sub-properties, the Junction class, and the RDF-Star metadata properties. This is where the design decisions get interesting — and where the rest of this post focuses.

### 3. Relationships
#### 3.1 Base Relationship Properties
<#structuralRelationship> rdf:type owl:ObjectProperty ;
    rdfs:label "structural relationship" ;
    rdfs:comment "Base property for structural relationships that define static construction or composition." ;
    rdfs:domain <#Element> ;
    rdfs:range <#Element> .
# Structural Relationships
<#assignment> rdf:type owl:ObjectProperty ;
    rdfs:label "assignment" ;
    rdfs:comment "Links active structure elements with behavior that they perform or roles they fulfill." ;
    rdfs:subPropertyOf <#structuralRelationship> ;
    rdfs:domain <#Element> ;
    rdfs:range <#Element> .

ArchiMate_SKOS – The Human-Readable File

There are two files, a TTL file, and an HTML file. The TTL is the computer readable one, and the HTML is the human readable one. The link to the HTML page is

https://purl.org/archimate#

purl.org is a persistent URL service provided by The Internet Archive, it’s a redirect layer that decouples the identifier from wherever the file actually lives. It will keep resolving even if I move the ontology from one hosting provider to another. As of right now, GitHub htmlpreview is doing the hosting. Purl its the service the semantic web community actually uses. E.g. Dublin Core (purl.org/dc/terms/). The entire OBO Foundry, hundreds of biomedical ontologies, they all use purl as its ontology identity infrastructure.

In the ArchiMate Ontology case, each term in the ontology resolves to a Permanent URL. Point a browser at https://purl.org/archimate#BusinessActor and you land on a html page with human-readable vocabulary. Not a schema dump, not a Turtle file, but a structured definition with a preferred label, an alternative label (if one exists), the definition of that term as drawn on the specification, the aspect and layer the term falls under, and a scope note that goes one step further than the spec definition does.

That last part is worth dwelling on. The ArchiMate specification defines what a BusinessProcess is. The SKOS scope note explains when to use it, that it models sequences of business activities that deliver value to customers or stakeholders, that it is typically implemented by business actors or roles, that it is distinct from a BusinessFunction in that a process is triggered and time-bounded where a function is ongoing. That is the guidance that today lives in training materials and in the heads of experienced practitioners. The SKOS vocabulary is an attempt to put it in the graph, where it is queryable, referencable, and machine-accessible alongside the formal semantics.

The SKOS vocabulary covers the full language — all 61 element types, all 11 relationship types, the framework structure itself. Some other advantages to SKOS worth naming explicitly.

Multilingual labels. The SKOS vocabulary can handle multiple languages, in some examples, it carries Spanish labels alongside English. For skos:prefLabel "Business Process"@en, we also have skos:prefLabel "Proceso de Negocio"@es alongside . This is a stub, not a complete translation. SKOS prefLabel and altLabel are language-tagged by design, and adding a full translation is additive, no changes to the OWL ontology or SHACL shapes required. For a language used globally by EA teams who do not all work in English, this matters.

Cross-references to adjacent vocabularies. skos:closeMatch and skos:related links can connect ArchiMate concepts to analogous concepts in other vocabularies. ApplicationProcess can carry a skos:closeMatch to the BPMN Process concept. These are not precise equivalences, they are navigational hints for practitioners mapping between vocabularies. They are also the seeds of the alignment work that federation at scale will need, shared identifiers, and vocabulary-level cross-references are how you establish those bridges without requiring a centralized registry.

NOTE: This is still a Work in Progress. The structural design decisions described here are stable. The human-readable vocabulary — scope notes, cross-references, and multilingual labels — is incomplete as of this writing, and will be updated as the ontology develops. Translations are welcome. If you’d like to contribute, submit a PR on GitHub.

ArchiMate_Profile_Examples.ttl –
The Extensibility Mechanism

The third file is not part of the core ontology. It is a demonstration of what the separation between the core files makes possible.

ArchiMate’s profile mechanism allows domain teams to define subtypes of standard elements without modifying the specification. A Person is a BusinessActor. A Microservice is an ApplicationComponent. A Container is a Node. These are not new element types, they are specializations of existing ones, with their own properties and constraints layered on top.

In the ontology, a profile class is three declarations:

myModel:Person rdf:type owl:Class ;
    rdfs:subClassOf archimate:BusinessActor ;
    archimate:specialization archimate:BusinessActor ;
    rdfs:label "Person" .

rdfs:subClassOf gives OWL inference — a Person instance is automatically a BusinessActor, which is automatically an InternalActiveStructure, which is automatically an Element. The full class chain propagates without any additional declarations. Profile-specific properties — dateOfBirth, email — are declared against the profile class, not against BusinessActor. They stay in the profile namespace. The core ontology is untouched.

archimate:specialization does a second job alongside rdfs:subClassOf. Because specialization is declared as owl:TransitiveProperty, it enables ArchiMate’s derivation rules, specifically DR1 “Transitivity of Specialization”, which handle the relationships a specialized element potentially inherits from its generalizations. A Person assigned to a BusinessProcess might inherit that assignment from its BusinessActor parent. The derivation engine surfaces that possibility. Whether it holds depends on the model — but the engine knows to ask. More on this on Post 3.

Relationships are Complicated

Now, diving into one key issue that every ArchiMate practitioner who has experienced working with the language knows: the issue with the language is not the Elements, it’s the Relationships that are complicated.

What separates the novice ArchiMate practitioner from the expert, is in the understanding of what the specification actually says about the relationships, and how they work. We know exactly what it means to have a structural vs a dynamic vs a dependent relationship, and how they fit in the larger metamodel.

This idea of formalizing ArchiMate in RDF is not new. When I started looking into it, I found three prior efforts that formalized ArchiMate in RDF, all independent from TOGAF, working from the tools available at the time. In terms of the Terminology, we all had similar approaches, using OWL and instantiating all ArchiMate Elements as classes, however, when looking under the hood, the details around how Relationships are instantiated, tell a different story. Understanding how these efforts got built, and why, is the fastest path to understanding why this ontology is structured differently.

The central claim of this ArchiMate Ontology work is simple: ArchiMate relationships are first-class architectural facts, and RDF-Star is currently the most practical way to represent them faithfully in a semantic architecture repository.

Relationship Taxonomy

ArchiMate’s 11 relationship types are organized into four semantic clusters:

Structural relationships — assignment, aggregation, composition, realization — define ownership, composition, and implementation chains. composition implies a shared lifecycle: if the whole is removed, the parts go with it. aggregation does not carry that implication. realization flows upward through layers, a Technology element realizing an Application element, never the reverse. assignment is the weakest of them all. These are not documentation conventions. They are architectural facts with consequences.

Dependency relationships — serving, access, influence, association — capture how elements use or affect each other without structural coupling. access carries an accessType property: Read, Write, or ReadWrite. influence carries influenceSign (positive, negative) and influenceStrength (weak, moderate, strong). These property are what distinguish a read dependency from a write dependency, a strong influence from a weak one, in the queries and derivation rules that consume them.

Dynamic relationships — triggering, flow — express process causality and transfer. triggering is causal: one behavior initiates another. flow carries information, material, or energy between behaviors. flow carries a flowType property.

Specialization stands alone as otherRelationship, and carries a unique property that is native to OWL, the Transitive declaration (coming up on blogpost 4).

These clusters matter because any inference or derivation rules can be written against the clusters, not individual relationship types. A rule that applies to any structuralRelationship automatically applies to composition, aggregation, realization, and assignment, including any future relationship specialization that can add a new structural relationship type.

Also, the cluster structure shapes a key implementation decision. ArchiMate’s generic metamodel suggests narrow domain and range declarations for each element – relationship – element triple. E.g. ActiveStructure can be assignment to BehaviorAspect, and that BehaviorAspect can access PassiveStructure. In the ArchiMate Ontology case, the ontology declares all relationship properties with domain/range → Element instead. I’ve made it intentionally broad.

The reason is simple: in OWL, rdfs:domain and rdfs:range are not guards. They are inference axioms. If someone’s model incorrectly puts a BusinessObject (a PassiveStructure) as the subject of an assignment (not possible per ArchiMate rules), a narrowly declared ontology wouldn’t catch the error, the engine would infer that the BusinessObject must therefore be an ActiveStructure. No warning. No rejection. Just a new, wrong fact added to the graph without error or warning.

Keeping the declarations broad means OWL stays honest about what it’s for: expressing what things are, not policing what relationships are permitted. The 3,800+ element-relationship-element validity rules from Appendix B, which state what relationships are valid and which ones are not, belong to SHACL, which rejects invalid patterns rather than inferring around them. I will cover SHACL Validation in the next post.

Prior Art: Three Attempts, Three Different Answers

In graph speak, ArchiMate Relationships are not just bare edges. The specification treats them as first-class concepts: Yes, they carry semantics, but also identifiers, names, documentation, and some have specific properties. access relationships have an access type: read, write, read-write. influence relationships carry a Sign and Strength. Most relationships have directionality, others like association are undirected by default but may be directed.

Standard RDF cannot accommodate properties on an edge, it’s just limited and cannot enrich that line between two circles into a full blown fact. A triple is Subject Predicate Object. The predicate carries no metadata. If you want to say something about a relationship, who established it, when, under what authority, whether it was derived. You are immediately in the territory of the n-ary relationship problem: how do you attach properties (a triple) to something that is itself a triple?

This is the question that organizes everything in this post. Every design decision that follows is either a direct answer to it, or a consequence of the answer chosen.

ArchiMEO

The most substantial prior academic formalization. Hinkelmann, Martin, Thönssen, and colleagues at FHNW University of Applied Sciences produced ArchiMEO between 2012 and 2014. It is serious work. A genuine attempt to encode ArchiMate’s class hierarchy and relationship structure in OWL as part of a broader enterprise ontology ecosystem. It remains the most referenced prior effort in the space.

ArchiMEO’s approach to relationships was to model them both as reified OWL Classes (grouped under StructuralRelationships, DynamicRelationships, etc.) and as bare owl:ObjectProperty declarations. The class hierarchy exists but the properties, which are what you would actually traverse in a model, carry no metadata: no names, no documentation, no provenance on the relationship instance. Domains and ranges are almost uniformly typed to eo:EnterpriseObject, providing minimal constraint enforcement. For governance and audit use cases, this is not sufficient.

Two other limitations compound this. ArchiMEO predates SHACL (which reached W3C Recommendation in 2017) and provides no validation capability, which compliance use cases require. And it was last updated against ArchiMate 2.1, before the full Motivation element set, the Strategy layer, the Physical layer, and the relationship derivation rule set were added to the specification. It has not been maintained as a current spec formalization. The repository is at ikm-group/ArchiMEO.

ArchiMate2RDF

The bp4mc2 project took a different approach: a converter that translates ArchiMate exchange format XML to RDF. It deserves credit for something ArchiMEO did not do, naming the problem explicitly. The project documentation states that even in pre-3.0 versions of ArchiMate, the mapping is problematic with regard to the name or documentation of a relationship, and proposes classic RDF reification as the solution.

Reification rdf:Statement was the standard answer to this problem for two decades. It works by minting a new node that represents the relationship as a resource, then attaching four triples to it: rdf:subject, rdf:predicate, rdf:object, and the metadata – names, documentation, properties – attaches as additional triples on the statement node. The original edge is preserved for traversal.

The problem is that the statement node and the actual relationship are now two separate things. A SPARQL query traversing from a BusinessActor through a serving relationship to an ApplicationService has to know to look for the rdf:Statement proxy, then navigate from there to the metadata. Every graph traversal has to pick up extra artifacts. The project documentation says it clearly: it works, it’s ugly. archimate2rdf explicitly called for The Open Group to publish a canonical ArchiMate ontology. That call has not been answered. (in fact, even recently -late 2025- dismissed the whole idea as purely academic). The repo is at bp4mc2/archimate2rdf.

Nicolas Figay’s OWL Work

First of all, we buddies on LinkedIn… so in internet terms, we know each other. He’s a scholar of a caliber I’ve yet to meet anywhere thou. His work is miles ahead of mine, his prose is impeccable, and his wordsmithing is sine qua non. You always know exactly where he stands, and he’ll make sure you understand why.

His work is the most semantically faithful and ambitious that I’ve come across. Figay translates the exchange format to OWL via XSLT, using a hybrid approach: relationships are modeled as classes and as inferred object properties. It is the effort that most directly engages with reasoning and interoperability use cases, and it is the one that gets furthest into the logical modeling before hitting the ceiling of what OWL can express cleanly.

Figay actually pushed back (on my own LinkedIn post nonetheless) on my RDF-Star approach as the right solution to this problem, called it “an imperfect and inaccurate trick when willing to actually define an ontology.” That critique is worth taking seriously, because he is not wrong. RDF-Star does not fully solve the n-ary relationship problem from a higher-order logic perspective. Attaching metadata to a triple is not the same as defining a relationship as a first-class entity with its own type, properties, and participation in class hierarchies. You can find Figay’s repo at nfigay/archimate.owl

In my defense… The tradeoff here is expressiveness for operationalization. For governance, impact analysis, and compliance tracing, the use cases this ontology is designed to serve, RDF-Star is sufficient, practically accessible, and supported in production-grade triple stores today. A theoretically cleaner substrate that requires tooling no EA team can realistically deploy is not a solution. It is a research artifact.

All efforts before the RDF-star community group report which was published in 2021 are a product of their time, and the reason this ontology is structured differently is because of RDF-star. Once RDF 1.2 standard is Accepted, a revision of this solution will be in order.

Four Options, One Decision

With all that said, laid out side by side, the options were these:

Named graphs. Wrap each triple in a named graph and annotate the graph URI. Works cleanly for dataset-level provenance — this set of triples came from this source at this time. Fails for ArchiMate because relationship metadata is per-relationship, not per-dataset. A model with 400 relationships requires 400 named graphs, each containing a single triple plus its annotations. The graph layer, which is supposed to partition data into meaningful datasets, becomes a bookkeeping mechanism for individual edges.

RDF Reification. The rdf:Statement approach. Works. Ugly. The original relationship becomes a described thing rather than a live edge, and querying across the model requires knowing to look for statement proxy nodes. archimate2rdf chose this and named the problem themselves.

OWL 2 Punning. I mentioned Punning on my first post. OWL 2 DL permits a URI to be declared as both an owl:Class and an owl:ObjectProperty simultaneously. The appeal is a single declaration that serves both the metadata inheritance (class) and the traversable edge (property) roles. The failure mode is that punning operates at the type level, not the instance level — a specific relationship instance still has nowhere to carry its name or confidence value. Beyond that, punning support across OWL reasoners is inconsistent enough that building on it introduces tooling risk without commensurate benefit.

RDF-Star. Allows a triple to be the subject of another triple. The original edge remains traversable. Metadata attaches directly to the relationship instance. The quoted triple <<s p o>> is the relationship; the annotations are facts about that relationship. One mechanism, no proxy nodes, no graph explosion.

The diagram below shows the relationship properties in a standard ArchiMate view

Becomes in Turtle

myModel:StudentEnrollmentService rdf:type archimate:BusinessService .
myModel:StudentInformationSystem rdf:type archimate:ApplicationComponent .
<< myModel:StudentInformationSystem archimate:serving myModel:StudentEnrollmentService >>
    archimate:identifier     "rel-20240901-001" ;
    archimate:name           "SIS serves Enrollment" ;
    archimate:confidence     "asserted" ;
    myModel:establishedBy    "Alberto D. Mendoza" ;
    myModel:effectiveDate    "2026-03-01"^^xsd:date .

RDF-Star has production-grade support in Stardog, GraphDB, and Apache Jena, and is being formalized as part of the W3C RDF 1.2 specification, where the arity problem is explicitly named as a motivating use case. The new rdf:reifies primitive in RDF 1.2 goes further, introducing reifiers as named, typed entities that concretize abstract propositions, moving closer to the first-class relationship entities that Figay’s critique demands. The trajectory is clear. This bet is on the right side.

RDF-Star in Practice

Now that metadata properties on a relationship have a place, we can add details to each relationship types.

Here are the properties that are embedded in the Ontology file archimate.ttl

#### 3.4 RDF-Star Relationship Metadata Properties
# Derivation Confidence
<#confidence> rdf:type owl:DatatypeProperty ;
    rdfs:label "Confidence" ;
    rdfs:comment "Confidence level in the relationship: 'asserted' (explicitly modeled), 'valid' (derived via DR1-DR8 rules), or 'potential' (derived via PDR1-PDR12 rules). Asserted relationships do not require this property; it is intended primarily for relationships materialized by SHACL-AF sh:construct derivation rules." ;
    rdfs:range [
        owl:oneOf ( "asserted" "valid" "potential" )
    ] .
# Access Relationship Specific Properties
<#accessType> rdf:type owl:DatatypeProperty ;
    rdfs:label "Access Type" ;
    rdfs:comment "Type of access: read, write, readwrite, or unspecified." ;
    rdfs:range xsd:string .
# Influence Relationship Specific Properties  
<#influenceSign> rdf:type owl:DatatypeProperty ;
    rdfs:label "Influence Sign" ;
    rdfs:comment "Sign of the influence: positive, negative, or unspecified." ;
    rdfs:range xsd:string .
<#influenceStrength> rdf:type owl:DatatypeProperty ;
    rdfs:label "Influence Strength" ;
    rdfs:comment "Strength of the influence: weak, moderate, strong, or unspecified." ;
    rdfs:range xsd:string .
# Flow Relationship Specific Properties
<#flowType> rdf:type owl:DatatypeProperty ;
    rdfs:label "Flow Type" ;
    rdfs:comment "Type of flow: information, material, energy, or unspecified." ;
    rdfs:range xsd:string .

This SPARQL query retrieves all explicitly asserted serving relationships, with their owners and dates:

SELECT ?component ?service ?establishedBy WHERE {
  << ?component archimate:serving ?service >>
      myModel:establishedBy  ?establishedBy ;
      myModel:effectiveDate  ?date ;
      archimate:confidence "asserted" .
  FILTER(?date >= "2024-01-01"^^xsd:date)
}

Current, explicitly asserted, owned, dated. Every connection that fails any of those filters surfaces as a gap rather than being silently omitted. That is what the open-world assumption buys in practice — an honest answer about what is known, what is uncertain, and what is missing.

Next post: Knowledge Engineering. Where OWL inference carries real weight, where it hands off to SHACL, and why getting that boundary wrong is the mistake most prior formalizations made.

ArchiMate Class Hierarchy

Property Hierarchy · Object Properties (Relationships)