Linked.Archi Relationship Modeling Guide¶

How relationships are represented in Linked.Archi ontologies: the qualified relationship pattern, RDF 1.2 integration, PROV-O lineage, and practical guidance for metamodel designers.

1. The Problem¶

Architecture models need two views of every relationship:

A direct triple for graph traversal — ex:AppSvc1 am:serves ex:BizProc1 — enabling SPARQL property paths, reasoning, impact analysis, and simple queries.
A first-class resource for architecture management — a managed object with identity, lifecycle, provenance, governance state, view context, and the ability to be the source or target of other relationships.

Neither view alone is sufficient. A pure triple is direct but cannot carry metadata or be referenced by other relationships. A pure resource preserves identity but leaves the binary fact implicit, forcing consumers to reconstruct it.

2. The Linked.Archi Solution¶

Linked.Archi emits both representations for every relationship and bridges them with RDF 1.2 rdf:reifies.

2.1 The Four Representations¶

For a "serves" relationship between an application service and a business process:

# 1. Direct triple — for traversal and analytics
ex:AppSvc1 am:serves ex:BizProc1 .

# 2. Qualified predicate — navigates from source to the relationship resource
ex:AppSvc1 am:qualifiedServes ex:qr-005 .

# 3. Qualified relationship resource — the first-class architectural object
ex:qr-005 a am:Serving ;
    arch:source ex:AppSvc1 ;
    arch:target ex:BizProc1 ;
    rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> ;  # 4. RDF 1.2 bridge
    prov:wasDerivedFrom ex:diagramEdge-81 ;
    dcterms:description "Shown on Viewpoint A"@en ;
    arch:conceptOwner ex:teamAlpha .

#	Representation	Purpose	Consumer
1	Direct triple	Graph traversal, SPARQL, reasoning	Analytics, impact analysis
2	Qualified predicate	Navigate from source to relationship resource	Modeling tools, UIs
3	Qualified relationship resource	Metadata, lifecycle, governance, higher-order links	Architecture management
4	`rdf:reifies`	Bridges the direct triple to the resource	RDF 1.2 consumers

2.2 Why This Matters for Enterprise Architecture¶

The same logical relation often appears in different contexts:

Current-state vs target-state — two relationship occurrences, same proposition, different lifecycle
Observed vs inferred — CMDB-discovered flow vs design-documented flow
Different viewpoints — the same "serves" relationship shown in an application landscape view and a business capability view, with different visual context

RDF 1.2 explicitly supports multiple distinct reifiers for the same proposition. Each reifier is a separate QualifiedRelationship instance with its own metadata.

Higher-order modeling is also supported — a risk assessment can target a specific relationship occurrence:

ex:risk42 a am:RiskAssessment ;
    arch:source ex:securityReview2026Q1 ;
    arch:target ex:qr-005 ;
    ex:riskLevel ex:high .

This is only possible because ex:qr-005 is a first-class resource, not just a triple.

3. Core Ontology Constructs¶

The core ontology (arch:) provides three constructs for relationship modeling:

3.1 `arch:QualifiedRelationship` (class)¶

The base class for all relationship occurrence types. Subclasses are defined in metamodels for each specific relationship type (e.g., am:Serving, am:Accessing).

QualifiedRelationship is a subclass of arch:ModelConcept, making relationship types symmetric with element types in the modeling palette:

Elements → subclasses of arch:Element → palette shows element types
Relationships → subclasses of arch:QualifiedRelationship → palette shows relationship types

Both carry visual notations (arch:prefVisNotation), taxonomy classifications, and domain/range guidance.

3.2 `arch:source` and `arch:target` (properties)¶

Properties on QualifiedRelationship instances pointing to the source and target elements:

arch:source
    a           owl:ObjectProperty ;
    rdfs:domain arch:QualifiedRelationship ;
    rdfs:range  arch:ModelConcept .

arch:target
    a           owl:ObjectProperty ;
    rdfs:domain arch:QualifiedRelationship ;
    rdfs:range  arch:ModelConcept .

Note that rdfs:range is arch:ModelConcept, not just arch:Element — a relationship can target another relationship (higher-order modeling).

3.3 `arch:unqualifiedForm` (annotation property)¶

Schema-level mapping declaring which unqualified predicate a qualified form corresponds to:

arch:unqualifiedForm
    a               owl:AnnotationProperty ;
    skos:closeMatch prov:unqualifiedForm .

Used on QualifiedRelationship subclasses and qualified properties in the metamodel — never on instance data:

am:Serving        arch:unqualifiedForm am:serves .
am:qualifiedServes arch:unqualifiedForm am:serves .

3.4 `arch:hasQualifiedRelationship` (property)¶

Generic fallback qualified predicate used when no type-specific qualified predicate is mapped:

arch:hasQualifiedRelationship
    a           owl:ObjectProperty ;
    rdfs:domain arch:ModelConcept ;
    rdfs:range  arch:QualifiedRelationship .

In well-designed metamodels, type-specific qualified predicates (e.g., am:qualifiedServes) should be preferred.

4. Defining a Relationship Type in a Metamodel¶

A complete relationship type definition in a Linked.Archi metamodel consists of three declarations:

4.1 The Unqualified Predicate¶

A standard owl:ObjectProperty used in direct triples:

am:serves
    a                    owl:ObjectProperty ;
    skos:prefLabel       "Serves"@en ;
    skos:definition      "..."@en ;
    arch:domainIncludes  am:ApplicationService ;
    arch:rangeIncludes   am:BusinessProcess ;
.

arch:domainIncludes / arch:rangeIncludes provide guidance for modeling tools (relationship wizards) without triggering OWL inference. Actual constraints belong in SHACL.

4.2 The Qualified Relationship Class¶

A subclass of arch:QualifiedRelationship representing the relationship type in the palette:

am:Serving
    a                    owl:Class ;
    rdfs:subClassOf      arch:QualifiedRelationship ;
    arch:unqualifiedForm am:serves ;
    skos:prefLabel       "Serving"@en ;
    skos:definition      "..."@en ;
    arch:prefVisNotation "https://meta.linked.archi/archimate3/v3/img/rel_serving.svg" ;
    arch:domainIncludes  am:ApplicationService ;
    arch:rangeIncludes   am:BusinessProcess ;
.

4.3 The Qualified Property¶

An owl:ObjectProperty connecting the source element to the relationship resource:

am:qualifiedServes
    a                    owl:ObjectProperty ;
    rdfs:domain          am:Element ;
    rdfs:range           am:Serving ;
    arch:unqualifiedForm am:serves ;
.

4.4 Summary: Three Declarations per Relationship Type¶

Declaration	Type	Purpose
`am:serves`	`owl:ObjectProperty`	Direct triple predicate
`am:Serving`	`owl:Class` (⊂ `arch:QualifiedRelationship`)	Palette concept, visual notation, classification
`am:qualifiedServes`	`owl:ObjectProperty`	Navigates source → relationship resource

5. Emitting Relationship Data¶

When producing model data (e.g., from an ETL converter), emit all representations:

# Always: the direct triple
ex:AppSvc1 am:serves ex:BizProc1 .

# When metadata/governance is needed: the qualified resource
ex:AppSvc1 am:qualifiedServes ex:qr-005 .

ex:qr-005 a am:Serving ;
    arch:source ex:AppSvc1 ;
    arch:target ex:BizProc1 ;
    rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> ;
    skos:prefLabel "AppSvc1 serves BizProc1" ;
    prov:wasDerivedFrom ex:diagramEdge-81 ;
    ex:status ex:approved ;
    ex:validFrom "2026-01-15"^^xsd:date .

5.1 When to Emit Only the Direct Triple¶

If a relationship has no metadata, no governance requirements, and no multiplicity (only one edge of this type between the pair), the direct triple alone is sufficient:

ex:AppSvc1 am:serves ex:BizProc1 .

5.2 When to Emit the Qualified Resource¶

Emit the qualified resource when any of these apply:

The relationship has metadata (provenance, confidence, status, dates)
Multiple distinct edges of the same type exist between the same pair
The relationship needs lifecycle management (proposed → approved → deprecated)
The relationship appears in specific viewpoints with view-specific context
Other relationships target this relationship (higher-order modeling)

6. PROV-O Lineage¶

The Linked.Archi qualified relationship pattern adopts and extends the PROV-O qualified relation pattern:

PROV-O	Linked.Archi	Role
`prov:EntityInfluence`	`arch:QualifiedRelationship`	Base class for qualified nodes
`prov:influencer` / `prov:entity`	`arch:source` / `arch:target`	Source and target elements
`prov:unqualifiedForm`	`arch:unqualifiedForm`	Schema-level mapping to unqualified predicate
`prov:qualifiedInfluence`	Type-specific qualified property (e.g., `am:qualifiedServes`)	Navigates source → qualified node
(no equivalent)	`rdf:reifies` (RDF 1.2)	Bridges direct triple to resource

The key extension beyond PROV-O is rdf:reifies — PROV-O predates RDF 1.2 and has no standardized bridge between the qualified node and the direct triple. Linked.Archi uses rdf:reifies for this, which also enables multiple distinct reifiers for the same proposition.

References: - PROV-O Qualified Forms - Qualified Relation Pattern

7. RDF 1.2 Integration¶

RDF 1.2 introduces rdf:reifies and triple terms, replacing the legacy rdf:Statement / rdf:subject / rdf:predicate / rdf:object vocabulary.

7.1 How `rdf:reifies` Works¶

A triple term denotes a proposition. A resource linked to that proposition via rdf:reifies is the reifier:

ex:qr-005 rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> .

The reifier (ex:qr-005) is the thing we further describe — with metadata, provenance, lifecycle, etc.

7.2 Multiple Reifiers¶

RDF 1.2 explicitly allows multiple distinct reifiers for the same proposition:

# Current-state observation (from CMDB)
ex:qr-005 a am:Serving ;
    arch:source ex:AppSvc1 ;
    arch:target ex:BizProc1 ;
    rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> ;
    ex:status ex:current ;
    ex:sourceSystem ex:cmdb .

# Target-state design (from architecture review)
ex:qr-006 a am:Serving ;
    arch:source ex:AppSvc1 ;
    arch:target ex:BizProc1 ;
    rdf:reifies <<( ex:AppSvc1 am:serves ex:BizProc1 )>> ;
    ex:status ex:target ;
    ex:sourceSystem ex:archReview .

Same proposition, different reifiers, different metadata. This is exactly what enterprise architecture needs.

7.3 Turtle 1.2 Compact Syntax¶

Turtle 1.2 provides annotation syntax for concise serialization:

ex:AppSvc1 am:serves ex:BizProc1 ~ ex:qr-005 {|
    a am:Serving ;
    arch:source ex:AppSvc1 ;
    arch:target ex:BizProc1 ;
    ex:status ex:approved
|} .

7.4 Relationship to RDF-Star¶

RDF-Star was a community extension (2019–2022) that introduced quoted triples (<<s p o>>) as a way to annotate triples with metadata without full reification. Several implementations adopted it (Jena, RDF4J, Stardog, GraphDB), and some ArchiMate-as-OWL projects (e.g., Mendoza's ontology) use it for relationship metadata:

# RDF-Star approach (pre-RDF 1.2)
:Process1 archimate:access :CustomerData .
<<:Process1 archimate:access :CustomerData>>
    archimate:accessType "read" .

RDF 1.2 standardized and superseded RDF-Star. The key changes:

Quoted triples become triple terms — the <<( s p o )>> syntax in RDF 1.2 denotes a proposition (a triple term), not a quoted triple. The semantics are cleaner: a triple term is a value, not a statement about the graph.
rdf:reifies replaces implicit annotation — in RDF-Star, annotating <<s p o>> directly was ambiguous (does the annotation apply to the triple occurrence or the proposition?). RDF 1.2 makes this explicit: a reifier is a resource that rdf:reifies a triple term, and you annotate the reifier.
Typed reifiers — RDF-Star annotations are untyped. With rdf:reifies, the reifier is a regular RDF resource that can have an rdf:type — in our case, a domain-specific class like am:Serving. This is what enables the qualified relationship pattern to work with RDF 1.2.
Multiple reifiers per proposition — explicitly supported and well-defined in RDF 1.2. In RDF-Star, the semantics of multiple annotations on the same quoted triple were implementation-dependent.

For Linked.Archi, the practical consequence is: we get both the lightweight annotation capability (annotate any triple) and typed, first-class relationship resources — in a single W3C-standardized mechanism. Projects still using RDF-Star syntax will need to migrate as tooling converges on RDF 1.2.

7.5 Status¶

As of early 2026, the RDF 1.2 documents are W3C Working Drafts. Teams should validate syntax and tooling support before freezing serialization choices in production.

References: - RDF 1.2 Concepts - RDF 1.2 Schema - RDF 1.2 Turtle - RDF 1.2 Primer

8. Why Not Punning?¶

Earlier versions of the Linked.Archi core ontology used OWL 2 punning and metaclass patterns for relationships (arch:Relationship rdfs:subClassOf rdf:Property). This has been removed. The reasons:

Punning creates inference gaps. Under OWL 2 Direct Semantics, the class view and property view of a punned IRI are interpreted independently. No logical bridge exists between them. This encodes implicit intent that reasoners will not honor.
Tooling inconsistencies. Protégé, visualization tools, and SPARQL endpoints handle punning inconsistently — duplicate UI entries, broken annotation display, ambiguous query results.
Not needed. The qualified relationship pattern achieves the same goals (palette generation, classification, direct graph traversal) without punning:
Palette → QualifiedRelationship subclasses (symmetric with Element subclasses)
Classification → SKOS taxonomy
Graph traversal → standard owl:ObjectProperty
Metadata → QualifiedRelationship instances
RDF 1.2 makes it unnecessary. rdf:reifies provides the standardized bridge between the direct triple and the relationship resource, eliminating the need for any same-IRI tricks.

For a detailed analysis of punning risks in ArchiMate-aligned knowledge graphs, see DD-6 in Design Decisions.

9. SHACL Validation¶

Two key validation rules for the qualified relationship pattern:

9.1 Every Qualified Relationship Must Have Source and Target¶

arch:QualifiedRelationshipShape
    a sh:NodeShape ;
    sh:targetClass arch:QualifiedRelationship ;
    sh:property [
        sh:path arch:source ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:class arch:ModelConcept ;
    ] ;
    sh:property [
        sh:path arch:target ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:class arch:ModelConcept ;
    ] .

9.2 Materialize the Direct Triple (SHACL Rule)¶

If the direct triple is not already asserted, it can be materialized from the qualified resource:

arch:MaterializeDirectTripleRule
    a sh:NodeShape ;
    sh:targetClass arch:QualifiedRelationship ;
    sh:rule [
        a sh:SPARQLRule ;
        sh:construct """
            PREFIX arch: <https://meta.linked.archi/core#>
            CONSTRUCT { ?s ?p ?o . }
            WHERE {
                $this arch:source ?s ;
                      arch:target ?o .
                $this a ?qrType .
                ?qrType arch:unqualifiedForm ?p .
            }
        """ ;
    ] .

10. Anti-Patterns¶

10.1 Treating Relationship Occurrences as Predicates¶

Do not make QualifiedRelationship instances function as rdf:Property. The relationship type is a predicate (am:serves). The relationship occurrence is a resource (ex:qr-005).

10.2 Using `arch:unqualifiedForm` on Instance Data¶

arch:unqualifiedForm is a schema-level mapping — use it on class and property definitions in the metamodel. At the instance level, the unqualified predicate is available via rdf:reifies on the QualifiedRelationship occurrence.

10.3 Omitting the Direct Triple¶

Always emit the direct triple alongside the qualified resource. Consumers doing analytics, traversal, and impact analysis need the direct predicate. The qualified resource is for governance — the direct triple is for graph work.

11. Checklist for Metamodel Designers¶

For every relationship type, define three things: unqualified predicate (owl:ObjectProperty), qualified class (rdfs:subClassOf arch:QualifiedRelationship), qualified property (owl:ObjectProperty with range = qualified class)
Annotate the qualified class and qualified property with arch:unqualifiedForm pointing to the unqualified predicate
Add arch:domainIncludes / arch:rangeIncludes on the unqualified predicate for modeling tool guidance
Add arch:prefVisNotation on the qualified class for the palette icon
Classify the qualified class in the SKOS taxonomy (by layer, aspect, relationship category)
Define SHACL shapes for valid source/target combinations
In model data, always emit the direct triple; emit the qualified resource when metadata is needed
Use rdf:reifies to bridge the direct triple to the qualified resource (RDF 1.2)

12. SPARQL Query Patterns¶

The following examples demonstrate how the qualified relationship pattern supports real architecture knowledge management queries.

All queries assume:

PREFIX arch:  <https://meta.linked.archi/core#>
PREFIX vocab: <https://custom.linked.archi/ont#>
PREFIX skos:  <http://www.w3.org/2004/02/skos/core#>
PREFIX prov:  <http://www.w3.org/ns/prov#>

12.1 Capability Realization Chain¶

Which application components realize which capabilities, and through which relationships?

SELECT ?capability ?capLabel ?rel ?component ?compLabel WHERE {
    ?component vocab:qualifiedRealizes ?rel .
    ?rel arch:target ?capability ;
         a vocab:Realization .
    ?capability a vocab:Capability .
    OPTIONAL { ?capability skos:prefLabel ?capLabel }
    OPTIONAL { ?component skos:prefLabel ?compLabel }
}
ORDER BY ?capLabel

The qualified form is essential here: the direct vocab:realizes triple tells you what is realized, but the relationship resource carries the provenance and source model reference needed for audit.

12.2 Unrealized Capabilities (Gap Analysis)¶

Which capabilities have no application component realizing them?

SELECT ?capability ?capLabel WHERE {
    ?capability a vocab:Capability .
    OPTIONAL { ?capability skos:prefLabel ?capLabel }
    FILTER NOT EXISTS {
        ?rel a vocab:Realization ;
             arch:target ?capability .
    }
}

12.3 Impact Analysis — Transitive Trigger Chain¶

Starting from a given component, what sequence of components is triggered?

SELECT ?step ?stepLabel WHERE {
    <https://data.linked.archi/.../id-SOURCE> vocab:triggers+ ?step .
    OPTIONAL { ?step skos:prefLabel ?stepLabel }
}

Uses the direct vocab:triggers predicate for SPARQL property paths (which require simple predicates). Switch to the qualified form when you need metadata on each hop.

12.4 Cross-Layer Influence with Weights¶

Which drivers influence which application services, and what is the influence weight?

SELECT ?driver ?driverLabel ?service ?serviceLabel ?weight WHERE {
    ?driver vocab:qualifiedInfluences ?rel .
    ?rel a vocab:Influence ;
         arch:target ?service .
    ?service a vocab:ApplicationService .
    OPTIONAL { ?driver skos:prefLabel ?driverLabel }
    OPTIONAL { ?service skos:prefLabel ?serviceLabel }
    OPTIONAL { ?rel vocab:influenceWeight ?weight }
}

The weight property lives on the relationship resource — only accessible via the qualified form.

12.5 Orphaned Elements¶

Which elements have no incoming or outgoing relationships?

SELECT ?element ?label WHERE {
    ?element a arch:Element .
    OPTIONAL { ?element skos:prefLabel ?label }
    FILTER NOT EXISTS { ?rel arch:source ?element }
    FILTER NOT EXISTS { ?rel arch:target ?element }
}

12.6 Provenance — Stale Conversions¶

Which named graphs were converted before a given date?

SELECT ?graph ?convertedAt WHERE {
    ?graph prov:generatedAtTime ?convertedAt .
    FILTER (?convertedAt < "2025-06-01T00:00:00Z"^^xsd:dateTime)
}
ORDER BY ?convertedAt

13. OWL Property Chain Axiom¶

An OWL reasoner can infer the direct triple from the qualified form using a property chain:

vocab:serves owl:propertyChainAxiom ( vocab:qualifiedServes arch:target ) .

This means: if A vocab:qualifiedServes R and R arch:target B, then infer A vocab:serves B. This makes the direct triple redundant for reasoners, but it is still emitted explicitly for SPARQL engines that do not perform OWL inference.

14. ETL Converter Emission Control¶

Linked.Archi converters (ArchiMate, BPMN, PlantUML) control relationship emission with independent flags:

--emit-direct-rel-triples      Emit direct shortcut triples:
                                 source vocab:serves target

--emit-qualified-rel-triples   Emit qualified triples:
                                 source vocab:qualifiedServes relationshipNode
                               Uses the qualifiedPredicates section of the type-mapping YAML.
                               Falls back to arch:hasQualifiedRelationship if no mapping found.

Both flags are independent — you can enable either or both.

Type-Mapping YAML¶

Qualified predicates are declared explicitly, separate from direct predicates:

predicates:
  Serving:       https://custom.linked.archi/ont#serves
  Composition:   https://custom.linked.archi/ont#composedOf
  Aggregation:   https://custom.linked.archi/ont#aggregates
  Triggering:    https://custom.linked.archi/ont#triggers
  Flow:          https://custom.linked.archi/ont#flowsTo
  Realization:   https://custom.linked.archi/ont#realizes
  Assignment:    https://custom.linked.archi/ont#assignedTo
  Influence:     https://custom.linked.archi/ont#influences
  Specialization: https://custom.linked.archi/ont#specializes
  Access:        https://custom.linked.archi/ont#accesses

qualifiedPredicates:
  Serving:       https://custom.linked.archi/ont#qualifiedServes
  Composition:   https://custom.linked.archi/ont#qualifiedComposedOf
  Aggregation:   https://custom.linked.archi/ont#qualifiedAggregates
  Triggering:    https://custom.linked.archi/ont#qualifiedTriggers
  Flow:          https://custom.linked.archi/ont#qualifiedFlowsTo
  Realization:   https://custom.linked.archi/ont#qualifiedRealizes
  Assignment:    https://custom.linked.archi/ont#qualifiedAssignedTo
  Influence:     https://custom.linked.archi/ont#qualifiedInfluences
  Specialization: https://custom.linked.archi/ont#qualifiedSpecializes
  Access:        https://custom.linked.archi/ont#qualifiedAccesses

If a relationship type has no entry in qualifiedPredicates, the generic fallback arch:hasQualifiedRelationship is used.

Three-Graph Architecture¶

All converters produce three named graphs:

Graph	Content
Semantic	Core elements and relationships (the knowledge)
Views	Diagram layout and visualization data (the presentation)
Provenance	Conversion metadata and lineage (the governance)

This separation allows consumers to load only what they need and maintains clear data lineage.