RDF-H: Holon Extensions for RDF

This specification defines the abstract syntax, formal semantics, and concrete syntaxes for a proposed holonic extension to the Resource Description Framework 1.2, referred to here as RDF-H. This proposal introduces the holon as a first-class primitive within the RDF data model. A holon is a resource that is simultaneously a whole in itself and a part of a larger whole, capable of structurally containing other RDF resources, including other holons. This mechanism provides a semantically precise and structurally native method for representing nested, contextual, and compositional knowledge. It is designed to overcome the limitations of existing RDF paradigms—such as the verbosity of standard reification, the statement-level focus of RDF-star, and the dataset-level partitioning of named graphs—for modeling complex systems. By grounding containment in formal mereology and ensuring full backward compatibility with RDF 1.2, this specification enables the robust modeling of digital twins, cyber-physical systems, fine-grained access control policies, and other domains requiring a native understanding of "wholes-within-wholes."

Introduction and Motivation

The Resource Description Framework (RDF) provides a powerful, graph-based data model for representing information about resources and the relationships between them. Its core structure, a set of subject-predicate-object triples, creates a directed, labeled graph that is flexible, extensible, and web-scalable. However, the "flat" nature of this graph, where all triples exist at the same structural level, presents significant challenges when modeling systems that possess inherent compositional or contextual hierarchies.

The key words MUST, MUST NOT, SHOULD, and MAY in this document are to be interpreted as described in [[RFC2119]].

The Need for Native Structural Containment

Many real-world and conceptual domains are fundamentally compositional. A car is a whole composed of parts like an engine and wheels; the engine, in turn, is a whole composed of its own parts. A digital twin of a factory floor is a whole that contains digital twins of individual assembly lines, which in turn contain twins of robotic arms. In systems biology, a cell contains organelles, which contain molecular complexes. In all these cases, the identity, boundary, and integrity of a subsystem (the "part") are as crucial as the relationships that exist within it.

While RDF can describe these part-whole relations using predicates (e.g., ex:engine ex:partOf ex:car), it lacks a primitive mechanism to structurally represent this containment within the data model itself. Existing approaches require developers to adopt specific modeling conventions or use mechanisms that were designed for related but distinct purposes. This leads to semantic ambiguity, complex queries, and a disconnect between the intuitive structure of the domain and its representation in the graph. This specification for RDF-H introduces the holon primitive to address this gap, providing a native, semantically grounded way to model structural containment directly within the graph.

Limitations of Existing Approaches: A Comparative Analysis

The need for a new primitive is best understood by examining the limitations of current RDF mechanisms for grouping, contextualizing, and annotating data.

Standard Reification

The original RDF specification provided a vocabulary for reification, allowing a statement to be treated as a resource. To annotate the triple :man :hasSpouse :woman, one must create a new resource of type rdf:Statement and link it to the subject, predicate, and object via rdf:subject, rdf:predicate, and rdf:object properties. This approach has several well-documented drawbacks:

Verbosity: It requires four additional triples to make a single assertion about another triple, leading to significant data bloat and unwieldy queries.
Semantic Weakness: Asserting the four reification triples does not, by itself, assert the original triple. It merely describes it.
Identity Crisis: Each reification creates a new, distinct rdf:Statement resource. This models a particular instance or token of a statement (e.g., its appearance in a specific document), not the abstract proposition itself. This is useful for provenance but is not suitable for grouping resources under a conceptual whole.

RDF-star (RDF 1.2)

RDF-star, now integrated into RDF 1.2, was a major breakthrough that addressed the verbosity of reification by introducing quoted (or embedded) triples as a new type of RDF term [[RDF12-CONCEPTS]]. A triple can be used directly as the subject or object of another triple (e.g., <<:man :hasSpouse :woman>> :confidence 0.95.). While immensely useful, RDF-star's purpose is statement-level annotation. It is designed to attach metadata to individual edges in the graph. It answers the question, "What can be said about this specific relationship?" It does not, however, provide a mechanism for grouping a set of resources (both nodes and edges) into a containing whole. It cannot answer the question, "What statements hold true inside the boundary of this system?"

Named Graphs (RDF Datasets)

Named graphs are the most common mechanism in RDF for grouping triples [[RDF11-DATASETS]]. An RDF dataset consists of a default graph and zero or more named graphs, where each named graph is a pair of an IRI (the graph name) and an RDF graph. This mechanism, often serialized as quads (subject, predicate, object, graph name), appears to offer a form of containment. However, a deeper analysis reveals that it is fundamentally a data management feature, not a resource modeling primitive, with critical limitations for representing holonic structures:

Dataset-Level Partitioning, Not Resource-Level Containment: Named graphs partition the entire triple store into distinct, named sets of triples. This is a mechanism for managing collections of graphs, often used for provenance, access control, or versioning at the level of a whole document or dataset. In contrast, a holon establishes a containment relationship between resources within a single, unified graph. A holon is an RDF term that can be the subject or object of other triples, while a named graph's name is an identifier for a graph, not typically a node within it.
Ambiguous Semantics: The semantics of a graph name are notoriously underspecified in the W3C recommendations. A graph name could denote the graph itself, the document it came from, a context, or an unconstrained resource. This ambiguity makes named graphs unsuitable for precise, model-theoretic representation of part-whole relations.
Exclusive Membership: In most quad-store implementations, a triple belongs to exactly one graph. This makes it difficult to model a resource that is simultaneously a part of multiple, overlapping systems—a common requirement in complex systems modeling.
Querying Paradigm: Querying across named graphs in SPARQL requires the GRAPH clause, which changes the active graph against which a sub-query is evaluated. This is a meta-level operation on the dataset, not a traversal of a relationship within the graph. It does not naturally compose with property paths, which are designed for in-graph traversal.

Holons, as proposed in this specification, offer a solution that is semantically precise, operates at the resource level, allows for overlapping containment, and is designed for native traversal-based querying.

Feature	Standard Reification	RDF-star (RDF 1.2)	Named Graphs (RDF 1.1)	Holonic Graphs (RDF-H)
Granularity	Single Statement	Single Statement	Set of Statements (Graph)	Set of Resources (Subgraph)
Semantic Precision	Weak (describes a statement token)	Strong (annotates a proposition)	Ambiguous (multiple interpretations of graph name)	Strong (formal mereological relation)
Syntactic Verbosity	High (4 extra triples)	Low (`<<...>>`)	Moderate (quads)	Low (`@holon {...}`)
Querying Paradigm	Complex Joins	SPARQL-star Patterns	`GRAPH` Clause (Scope Change)	Property Path Traversal (`CONTAINS`)
Core Use Case	Provenance of a statement token	Metadata on a statement	Dataset management, provenance	Modeling structural containment

A Mereological Foundation for Holons

To ensure conceptual rigor, the holon primitive is grounded in mereology, the formal theory of parts and wholes. While ontology design patterns have been developed to represent various part-whole relations in OWL (e.g., componentOf, memberOf, contains) [[OEP-PARTWHOLE]], these are vocabulary-level conventions. RDF-H elevates containment to a structural primitive of the data model itself.

The containment relation introduced in this specification, denoted by the symbol ⊂, is defined as a strict partial order, corresponding to the notion of a proper part. It adheres to the following core axioms:

Irreflexivity: No object is a proper part of itself.
Asymmetry: If A is a proper part of B, then B cannot be a proper part of A.
Transitivity: If A is a proper part of B, and B is a proper part of C, then A is a proper part of C.

By building these properties into the data model and its semantics, RDF-H provides a robust and predictable foundation for representing and reasoning about compositional systems. The most critical property derived from these axioms is acyclicity, which ensures the model is well-founded and free from logical paradoxes.

Design Principles and Requirements

The design of RDF-H is guided by the following principles:

Backward Compatibility: Any valid RDF 1.2 graph or dataset MUST be a valid RDF-H graph or dataset. All existing RDF 1.2 semantics and entailment rules remain in effect.
Semantic Coherence: The introduction of holons and the containment relation MUST be a conservative extension of the RDF 1.2 model-theoretic semantics [[RDF12-SEMANTICS]]. It must not introduce logical contradictions or invalidate existing entailments.
Syntactic Integration: Concrete syntaxes for holons (e.g., Turtle-H) MUST integrate cleanly with existing syntaxes, particularly the quoted triple syntax (<<...>>) of RDF-star. The two mechanisms are designed to be orthogonal and compositional.
Native Queryability: The containment relation MUST be a first-class, traversable path within the graph. Querying holonic structures SHOULD feel like natural graph traversal, not like a meta-level operation on datasets.

The Semantic Holonic Graph (SHG) Abstract Data Model

This section defines the formal abstract syntax for RDF-H, extending the [[RDF12-CONCEPTS]]. The core extension is the introduction of a primitive containment relation, giving rise to Holonic Graphs.

Terminology

The terminology of [[RDF12-CONCEPTS]] applies unless overridden here. A new vocabulary namespace, http://www.w3.org/rdfh#, is introduced and is bound by convention to the prefix h:.

Holon: An RDF term (an IRI or a blank node) that is an instance of the class h:Holon. A holon is a resource that can structurally contain other RDF terms, establishing a boundary within an RDF graph.
Containment Relation (⊂): A primitive, directed, binary relation between a contained RDF term (the part or member) and a containing holon (the whole). This relation is a fundamental part of the RDF-H data model and is not represented by a specific IRI predicate in the graph's triple set.
Containment Edge: An instance of the containment relation, denoted t ⊂ H, where t is any RDF term and H is a holon. It represents the assertion that t is a direct part of the whole H.
Holonic Graph: An RDF graph that may contain zero or more holons and containment edges. It is formally defined as a pair of a set of triples and a set of containment edges.
Boundary Graph: An RDF graph that provides metadata about a specific containment edge. It is attached to the containment relationship itself, not to the part or the whole. It can be used to express constraints or context (e.g., temporal, modal, security) on the membership of the part within the whole.
Holarchy: A set of resources organized by the transitive closure of the containment relation (⊂*), forming a forest of directed acyclic graphs (DAGs).

Namespace

The permanent namespace URI for terms defined in this specification is https://w3id.org/rdf-h#. This specification uses the prefix h: to refer to terms in this namespace. Until this namespace is configured to resolve directly, the formal vocabulary definition in Turtle format can be found at its development location: rdfh.ttl.

Formal Definition of Holonic Graphs and Datasets

The abstract data model of RDF 1.2 is extended as follows:

An RDF-H Term is an IRI, a literal, a blank node, or a quoted triple, as defined in [[RDF12-CONCEPTS]].
A Holon is an RDF-H Term that is an IRI or a blank node.
A Containment Edge is an ordered pair (t, H) where t is an RDF-H Term and H is a Holon. This is written notationally as t ⊂ H.
An RDF-H Triple is an RDF triple as defined in [[RDF12-CONCEPTS]].
An RDF-H Graph (or Holonic Graph) is a pair $G_h = (T, C)$ , where:
- $T$ is a set of RDF-H Triples.
- $C$ is a set of Containment Edges.
An RDF-H Dataset is a collection of RDF-H Graphs, comprising exactly one default graph and zero or more named graphs. Each named graph is a pair of an IRI or blank node (the graph name) and an RDF-H Graph. This structure is consistent with the RDF 1.1 Dataset definition.

The Holon Primitive

Any resource identified by an IRI or a blank node MAY be designated as a holon. This designation is made by asserting a triple of the form:

<H> rdf:type h:Holon.

where <H> is the IRI or blank node identifier for the holon. The class h:Holon is a new primitive class defined in the h: vocabulary. It is a subclass of rdfs:Resource. A resource can have multiple types; being a holon does not preclude it from being an instance of other classes. For example, a resource ex:Car1 can be both a h:Holon (if it contains parts) and an ex:Vehicle.

The act of designating a resource as a holon indicates that it may serve as the whole (the right-hand side) in a containment edge. Any RDF term may be the part (the left-hand side).

The Containment Relation (⊂) and its Formal Properties

The containment relation ⊂ is a primitive part of the data model. It is not an RDF property and does not have an IRI. Its semantics are built directly into RDF-H processors. The relation defines a strict partial order over the terms in a graph, and MUST adhere to the following formal properties:

Property	Formal Definition	Implication
Transitivity	If `a ⊂ b` and `b ⊂ c`, then `a ⊂ c`.	Containment hierarchies can be traversed to arbitrary depth. A part of a part is also a part of the whole.
Irreflexivity	For any term `a`, it is not the case that `a ⊂ a`.	Prevents simple self-containment loops. An object cannot be a proper part of itself.
Asymmetry	If `a ⊂ b`, then it is not the case that `b ⊂ a`.	Prevents direct cyclic containment between two objects.
Acyclicity	There is no sequence of terms $t_1, t_2,..., t_n$ such that $t_1 ⊂ t_2 ⊂... ⊂ t_n ⊂ t_1$ .	This is the general well-foundedness condition. It prevents all cycles of any length, ensuring the holarchy is a Directed Acyclic Graph (DAG) and preventing logical paradoxes. This is the single most important constraint for a conformant processor to enforce.

Boundary Graphs: Scoping and Semantics

A simple statement ex:sensor1 ⊂ ex:engine1 asserts a structural relationship. However, it is often necessary to qualify this relationship. For example, the sensor might only be part of the engine during a specific time interval, or the containment might only be valid under certain security contexts. This metadata pertains to the act of containment itself, i.e., to the containment edge.

To model this, the containment edge is treated as a reifiable statement. While the containment relation ⊂ is primitive, it can be expressed for the purpose of annotation using the RDF-star-compatible vocabulary property h:containedIn. A containment edge r ⊂ H can be reified as the triple r h:containedIn H. This triple can then be used as the subject of other triples to attach a boundary graph.

A Boundary Graph is an RDF graph that describes a containment edge. It is attached using a pattern analogous to RDF-star annotation.

Example: To state that ex:sensor1 is contained in ex:engine1 and to attach a boundary specifying its active period, one would assert:

@prefix ex: <http://example.org/>.
@prefix h: <https://w3id.org/rdf-h#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

# This reified triple represents the containment edge
<< ex:sensor1 h:containedIn ex:engine1 >>
    h:validFrom "2025-01-01T00:00:00Z"^^xsd:dateTime ;
    h:validUntil "2026-01-01T00:00:00Z"^^xsd:dateTime.

Here, the two triples with subject << ex:sensor1 h:containedIn ex:engine1 >> form the boundary graph for that specific containment edge. The semantics of the properties within the boundary graph (e.g., h:validFrom) are not defined by this specification and are left to application-specific vocabularies and entailment regimes (e.g., temporal reasoners, access control systems).

This approach has two key advantages:

It reuses the well-understood and powerful RDF-star mechanism for statement annotation.
It correctly associates metadata with the relationship, not with either of the participants.

Interaction with RDF-star Quoted Triples

The holon containment mechanism is orthogonal to and fully compatible with the quoted triple mechanism of RDF-star. They operate at different levels of granularity and can be composed freely.

A quoted triple can be contained in a holon: A statement itself can be considered a member of a containing context.
- << :s :p :o >> ⊂ :H1.
- This means the proposition expressed by <:s :p :o> is considered to hold within the scope of holon :H1.
A containment relationship can be annotated: As shown in the previous section, the reified form of a containment edge can be the subject of an annotation.
- << :r h:containedIn :H1 >> :confidence 0.9.
A holon can contain triples, including RDF-star triples:
- @holon :H1 { :a :b :c. << :x :y :z >> :annotates :x. }
- This asserts that both the triple :a :b :c and the RDF-star triple << :x :y :z >> :annotates :x are contained within :H1.

This compositional power allows for rich, multi-level modeling, where holons provide macro-level structural grouping, and RDF-star provides micro-level annotation of the statements within or about those groups.

Formal Semantics and Entailment

This section provides a formal model-theoretic semantics for RDF-H, defining the precise meaning of holonic graphs and the conditions under which entailments hold. The semantics is a conservative extension of the [[RDF12-SEMANTICS]].

H-Interpretations: Extending the RDF 1.2 Semantics

The model theory for RDF-H extends the notion of an interpretation from the [[RDF12-SEMANTICS]].

A simple H-interpretation I is an RDF 1.2 simple interpretation I_rdf = (IR, IP, IEXT, IS, IL, RE) defined in [[RDF12-SEMANTICS]], augmented with two additional components:

A distinguished subset $IH ⊆ IR$ , which is the extension of the class h:Holon.
A binary relation $CEXT ⊆ IR × IH$ , which is the extension of the primitive containment relation ⊂.

IR is a non-empty set of resources (the universe).
IP is a set of properties.
IEXT: IP → 2^(IR × IR) maps properties to sets of pairs of resources.
IS: IRIs → (IR ∪ IP) maps IRIs to resources or properties.
IL: Literals → IR is a partial mapping from literals to resources.
RE: (IR ∪ B) × IP × (IR ∪ L ∪ B) → IR maps triple terms to resources.

An RDFS H-interpretation extends an RDFS-interpretation from [[RDF12-SEMANTICS]] in the same manner, and similarly for other entailment regimes like OWL.

Semantic Conditions for Holons, Containment, and Boundaries

An H-interpretation I satisfies a holonic graph $G_h = (T, C)$ if and only if all of the following conditions hold:

Triple Satisfaction: I satisfies the set of triples T according to the underlying entailment regime (e.g., RDFS entailment as defined in [[RDF12-SEMANTICS]]). This includes the condition that for any triple H rdf:type h:Holon in T, it must be that $I(H) ∈ IH$ .
Containment Edge Satisfaction: For every containment edge (t, H) in the set C, the pair (I(t), I(H)) MUST be a member of the containment extension relation $CEXT$ .
Containment Relation Axioms: The relation $CEXT$ MUST satisfy the axioms of a strict partial order:
- Irreflexivity: For all $x ∈ IR$ , $(x, x) ∉ CEXT$ .
- Asymmetry: For all $x, y ∈ IR$ , if $(x, y) ∈ CEXT$ , then $(y, x) ∉ CEXT$ .
- Transitivity: For all $x, y, z ∈ IR$ , if $(x, y) ∈ CEXT$ and $(y, z) ∈ CEXT$ , then $(x, z) ∈ CEXT$ .

The acyclicity constraint is a direct consequence of these axioms, ensuring the model is well-founded.

The semantics of triples within a Boundary Graph are subject to the same satisfaction conditions as any other triples in the dataset. This specification does not define additional semantic conditions for boundary graph vocabularies (e.g., h:validFrom), as their interpretation is application-dependent.

The H-Entailment Regime

The H-entailment regime builds upon a standard RDF 1.2 entailment regime [[SPARQL11-ENTAILMENT]], such as RDFS-entailment or OWL 2 DL-entailment.

A holonic graph $G_1$ H-entails a holonic graph $G_2$ (written $G_1 \models_H G_2$ ) under a base entailment regime E (e.g., RDFS) if every E-conformant H-interpretation that satisfies $G_1$ also satisfies $G_2$ .

This definition gives rise to a set of formal entailment rules that can be implemented by reasoners. For clarity, we use the predicate h:containedIn to represent the ⊂ relation within rule syntax. The key entailment patterns for the containment relation itself are:

h-trans: The transitivity rule.

IF:  ?a h:containedIn ?b.
     ?b h:containedIn ?c.
THEN:?a h:containedIn ?c.

h-type: A resource on the right-hand side of a containment relation must be a holon.
```
IF:  ?a h:containedIn ?b.
THEN:?b rdf:type h:Holon.
```

A full, formal list of entailment rules, including interactions with RDFS, is provided in Appendix C.

Acyclicity, Well-Foundedness, and the Prevention of Paradoxes

The requirement that the containment relation ⊂ be acyclic is not merely a practical constraint for simplifying traversal algorithms; it is a fundamental guarantee of the logical soundness of the RDF-H data model. Its importance is analogous to the Axiom of Foundation in Zermelo-Fraenkel set theory.

Self-referential structures are the source of many well-known logical paradoxes. For example, Russell's Paradox arises from considering the set of all sets that do not contain themselves, $R = \{x | x \notin x\}$ [[SEP-SELFREF]]. Asking whether $R \in R$ leads to a contradiction. This paradox demonstrated that naive set theory, which allowed any definable property to form a set, was inconsistent. The solution in modern set theory is to build the universe of sets in a cumulative hierarchy, which explicitly forbids a set from containing itself.

In the context of RDF-H, a cyclic containment such as H1 ⊂ H2 and H2 ⊂ H1 would be a structural paradox. A more complex cycle, H1 ⊂ H2 ⊂... ⊂ Hn ⊂ H1, presents the same logical problem. If such structures were permitted, the very notion of "containment" would become incoherent, and the transitive closure of the ⊂ relation would be ill-defined for cyclic members.

By mandating that the containment relation ⊂ be irreflexive and acyclic (i.e., that the holarchy be a well-founded directed acyclic graph), this specification ensures that the holonic extension to RDF is free from such self-referential paradoxes. This is the core reason why a conformant RDF-H processor MUST detect and reject graphs containing containment cycles. Such a graph is not merely "malformed"; it is logically inconsistent with the foundational axioms of the data model. This guarantee of well-foundedness is a cornerstone of the robustness of the Semantic Holonic Graph model.

Concrete Syntaxes for Holonic Graphs

This section defines concrete syntaxes for writing and exchanging RDF-H Holonic Graphs. The primary syntax is Turtle-H, an extension of Turtle-star. Guidance for a JSON-LD representation is also provided.

Turtle-H: A Holonic Extension to Turtle-star

Turtle-H extends the Turtle 1.2 (RDF-star) syntax [[RDF12-TURTLE]] with a dedicated block structure for defining holons and their contents, and an annotation-like syntax for describing containment boundaries.

The `@holon` Block

A holon and its directly contained resources are defined using the @holon directive followed by an IRI or blank node identifier for the holon, and a block of Turtle statements enclosed in curly braces {...}.

@prefix ex: <http://example.org/>.
@prefix h: <https://w3id.org/rdf-h#>.

@holon ex:BuildingA {
    # ex:BuildingA is implicitly typed as h:Holon.
    # All resources defined here are contained in ex:BuildingA.

    ex:Device1 a ex:Sensor ;
               ex:location "First Floor".

    @holon ex:Device2 {
        # This defines a nested holon, ex:Device2.
        # ex:Device2 is contained in ex:BuildingA.
        ex:SubComponent1 a ex:Processor. # Contained in ex:Device2
    }
}

The @holon <H> { G_turtle } syntax is formally defined as the following set of assertions:

The triple <H> rdf:type h:Holon. is added to the graph.
All triples defined within the G_turtle block are added to the graph.
For every resource r that is the subject of a triple or a holon defined directly within the G_turtle block, a containment edge r ⊂ <H> is added to the graph.
Nested @holon blocks are processed recursively. In the example above, ex:Device1 ⊂ ex:BuildingA, ex:Device2 ⊂ ex:BuildingA, and ex:SubComponent1 ⊂ ex:Device2. By transitivity, ex:SubComponent1 ⊂ ex:BuildingA is also entailed.

The full EBNF grammar for Turtle-H, extending the Turtle-star grammar, is provided in Appendix A.

Containment and Boundary Syntax

While the @holon block provides a convenient way to define contents, an explicit syntax for asserting containment and describing its boundary is also necessary. This is achieved by reifying the containment edge using the h:containedIn property and annotating it with a syntax inspired by Turtle-star's annotation syntax ({|...|}).

@prefix ex: <http://example.org/>.
@prefix h: <https://w3id.org/rdf-h#>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>.

# Assert that ex:SensorData is contained in ex:SecureEnclave
ex:SensorData h:containedIn ex:SecureEnclave
    # The following block is the Boundary Graph for this containment edge
    {|
        acl:accessTo <#graph> ;
        acl:mode acl:Read ;
        acl:agentClass <http://xmlns.com/foaf/0.1/Person>.
    |}.

This syntax is syntactic sugar for the following RDF-star triples:

ex:SensorData h:containedIn ex:SecureEnclave.

<< ex:SensorData h:containedIn ex:SecureEnclave >>
    acl:accessTo <#graph> ;
    acl:mode acl:Read ;
    acl:agentClass <http://xmlns.com/foaf/0.1/Person>.

This approach provides a clean, expressive, and semantically precise way to attach metadata to the act of containment itself, reusing existing and familiar syntactic constructs.

JSON-LD-H: Representing Holons and Boundaries in JSON-LD

Representing holonic structures in JSON-LD 1.1 [[JSON-LD11]] can be achieved by extending the standard JSON-LD processing model. A future companion note will fully specify this, but the recommended approach is as follows.

Holon Containment via `@contains`

A new keyword, @contains, can be introduced into the JSON-LD context. A holon's contents can be represented as a JSON array or object that is the value of this key within the holon's node object.

{
  "@context": {
    "h": "https://w3id.org/rdf-h#",
    "ex": "http://example.org/",
    "@version": 1.1,
    "Holon": "h:Holon",
    "@contains": {
      "@id": "h:contains",
      "@type": "@id",
      "@container": "@graph"
    }
  },
  "@id": "ex:BuildingA",
  "@type": "Holon",
  "@contains": [
    {
      "@id": "ex:Device1",
      "ex:location": "First Floor"
    }
  ]
}

A JSON-LD-H processor would interpret the @contains key as generating h:containedIn relationships from the objects in its array to the parent node object.

Boundaries via JSON-LD-star Annotation

Boundaries on containment edges can be represented using the annotation mechanism proposed for JSON-LD-star [[JSON-LD-STAR]]. This involves annotating the h:containedIn property.

{
  "@context": {
    "h": "https://w3id.org/rdf-h#",
    "ex": "http://example.org/",
    "acl": "http://www.w3.org/ns/auth/acl#",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "hasMember": { "@reverse": "h:containedIn" }
  },
  "@id": "ex:SecureEnclave",
  "@type": "h:Holon",
  "hasMember": {
    "@id": "ex:SensorData",
    "@annotation": {
      "acl:mode": "acl:Read",
      "acl:agentClass": { "@id": "foaf:Person" }
    }
  }
}

Here, the hasMember term would be defined in the context as the reverse of h:containedIn. The @annotation object provides the boundary graph metadata for the containment edge. An example @context is provided in Appendix B.

Quad-based Serializations (N-Quads-H, TriG-H)

To support interoperability with existing quad-based infrastructure, a mapping from the holonic data model to a quad representation is defined. This mapping must distinguish between triples asserted in a named graph and statements about containment.

A containment edge t ⊂ H is serialized as a quad using a dedicated, well-known graph IRI, h:ContainmentGraph. The predicate h:containedIn is used to represent the relation.

t h:containedIn H h:ContainmentGraph.

A conformant RDF-H processor, when consuming quads, MUST interpret any quad in the h:ContainmentGraph not as a triple within a named graph, but as a direct assertion of a containment edge in the holonic data model. This allows the holarchy structure to be preserved during serialization and exchange, while clearly separating it from the named graph mechanism for dataset partitioning.

Querying Holonic Graphs: SPARQL-H

SPARQL 1.1 [[SPARQL11-QUERY]] is extended to support native traversal and querying of holonic structures. The extension, SPARQL-H, introduces a new primitive property path for containment and leverages existing SPARQL-star capabilities for boundary filtering.

The `CONTAINS` Property Path Operator

To enable natural traversal of the holarchy, a new primitive property path is introduced. This path corresponds directly to the primitive ⊂ relation and its inverse.

The IRI h:contains represents a single, direct step down the holarchy (from whole to part). This is the inverse of the h:containedIn property used for reification.
The IRI h:containedIn represents a single, direct step up the holarchy (from part to whole).

These can be used with SPARQL's standard property path operators (*, +, ?, !, ^, /, |) to express complex traversals. For example:

h:containedIn+: Finds all containing holons, transitively.
h:contains*: Finds all contained parts, transitively and reflexively (including the starting holon itself).

For improved readability, SPARQL-H also introduces several case-insensitive keywords as syntactic sugar for common path expressions.

SPARQL-H Syntax	Equivalent Path Expression	Formal Meaning
`?whole CONTAINS ?part`	`?whole h:contains ?part`	Direct containment (one level)
`?whole CONTAINS+ ?part`	`?whole h:contains+ ?part`	Transitive containment (one or more levels)
`?whole CONTAINS* ?part`	`?whole h:contains* ?part`	Transitive, reflexive containment (zero or more levels)
`?part IS_CONTAINED_IN ?whole`	`?part h:containedIn ?whole`	Direct containment (inverse direction)

An implementation MUST recognize and treat these keywords as identical to their corresponding h: path expressions during query parsing and evaluation.

Example Query: Find all devices contained anywhere within ex:BuildingA.

# ASCII-friendly form
PREFIX ex: <http://example.org/>
SELECT ?device WHERE {
  ex:BuildingA CONTAINS+ ?device.
  ?device a ex:Device.
}

# Equivalent path expression form
PREFIX ex: <http://example.org/>
PREFIX h: <https://w3id.org/rdf-h#>
SELECT ?device WHERE {
  ex:BuildingA h:contains+ ?device.
  ?device a ex:Device.
}

Boundary Filtering with SPARQL-star Patterns

The initial draft of this specification proposed a new BOUNDARY clause. However, based on the revised data model (Section 4.5) where boundaries are annotations on reified containment edges, a new clause is unnecessary and undesirable. Instead, boundary filtering is accomplished using standard SPARQL 1.2 (RDF-star) query patterns.

This is a significant simplification and improvement, as it relies on an existing, well-understood W3C Recommendation rather than introducing new, proprietary syntax.

Example Query: Find all parts contained in ex:BuildingA where the containment relationship is marked with h:mode "active".

PREFIX ex: <http://example.org/>
PREFIX h: <https://w3id.org/rdf-h#>

SELECT ?part
WHERE {
  ?part h:containedIn ex:BuildingA.
  << ?part h:containedIn ex:BuildingA >> h:mode "active".
}

This query first finds all potential parts using the h:containedIn property path, and then filters them by checking for the required annotation on the corresponding quoted triple.

Formal Algebra and Evaluation Semantics

The SPARQL algebra is extended with evaluation rules for the new primitive property paths. The evaluation of a path expression is defined with respect to an H-interpretation I and its containment extension relation $CEXT$ .

Let eval(P, G) be the function that evaluates a property path P against a graph G. The semantics for h:containedIn are defined as:

eval(Path(h:containedIn), G) = { (I(a), I(b)) | (a, b) ∈ CEXT }

where CEXT is the extension of the containment relation in the H-interpretation of G. The semantics for h:contains are defined via the inverse path operator: h:contains is equivalent to ^h:containedIn. The evaluation of complex paths involving these primitives follows the standard SPARQL 1.1 property path semantics.

Advanced Query Patterns and Examples

The combination of holonic traversal and standard SPARQL features enables powerful queries.

Example: Find the root holon(s) for a given component.

This query finds the top-level container(s) for ex:SubComponentX.

PREFIX ex: <http://example.org/>
PREFIX h: <https://w3id.org/rdf-h#>

SELECT ?root
WHERE {
  ex:SubComponentX h:containedIn+ ?root.
  FILTER NOT EXISTS { ?root h:containedIn ?superRoot. }
}

Example: Aggregate properties from all parts.

This query calculates the total weight of a composite object by summing the weights of all its direct parts.

PREFIX ex: <http://example.org/>
PREFIX h: <https://w3id.org/rdf-h#>

SELECT (SUM(?partWeight) AS ?totalWeight)
WHERE {
  ex:Assembly123 h:contains ?part.
  ?part ex:weight ?partWeight.
}

These examples demonstrate that SPARQL-H provides an expressive and intuitive language for querying hierarchical and compositional data structures represented as holonic graphs.

Validation with SHACL-H

The Shapes Constraint Language (SHACL) is a W3C Recommendation for validating RDF graphs against a set of conditions, called shapes [[SHACL]]. To support the validation of Holonic Graphs, this specification defines SHACL-H, an extension that introduces new constraint components specific to holonic structures. A processor that claims SHACL-H conformance MUST support these new components in addition to the full SHACL Core and SHACL-SPARQL specifications.

Core Holon Constraint Components

SHACL-H introduces a small set of new, built-in constraint components to validate the unique structural properties of holons.

`h:AcyclicContainmentConstraintComponent`

This is the most critical validation component. It enforces the fundamental acyclicity constraint of the holonic data model.

IRI: h:AcyclicContainmentConstraintComponent
Parameters: None.
Constraint: A focus node f violates this constraint if there exists a non-empty property path of h:containedIn from f back to f. That is, if the SPARQL query ASK { ?f h:containedIn+ ?f } returns true when ?f is bound to the focus node.

ex:HolonShape a sh:NodeShape ;
    sh:targetClass h:Holon ;
    sh:constraint h:AcyclicContainmentConstraintComponent.

This shape targets all resources of type h:Holon and ensures none of them participate in a containment cycle.

`h:HolonConstraintComponent`

This component can be used to validate that nodes acting as containers are explicitly declared as holons.

IRI: h:HolonConstraintComponent
Parameters: None.
Constraint: A focus node f that is the object of an h:containedIn triple violates this constraint if f does not have rdf:type h:Holon.

ex:ContainedResourceShape a sh:NodeShape ;
    sh:targetObjectsOf h:containedIn ;
    sh:constraint h:HolonConstraintComponent.

Defining Shape Constraints for Holon Boundaries and Emergent Properties

Beyond the new components, standard SHACL is perfectly suited for defining constraints on the contents of holons and their boundaries.

Constraining Boundary Graphs

Since boundary graphs are attached using standard RDF-star patterns, they can be validated with standard SHACL shapes. A shape can target the reified containment statement and define constraints on its properties.

Example: A shape to ensure that any active containment boundary specifies a valid temporal range.

ex:BoundaryShape a sh:NodeShape ;
    sh:targetSubjectsOf h:mode ; # Target reified containment statements with a mode
    sh:filterShape [ sh:hasValue "active" ] ; # Only for active ones
    sh:property [
        sh:path h:validFrom ;
        sh:datatype xsd:dateTime ;
        sh:maxCount 1 ;
        sh:minCount 1 ;
    ] ;
    sh:property [
        sh:path h:validUntil ;
        sh:datatype xsd:dateTime ;
        sh:maxCount 1 ;
    ].

Constraining Holon Contents and Emergent Properties

SHACL can be used to define what types of resources are allowed within a holon, or to validate properties that emerge from the composition of parts.

Example: A shape stating that any ex:Engine holon must contain at least one ex:Cylinder.

ex:EngineShape a sh:NodeShape ;
    sh:targetClass ex:Engine ;
    sh:property [
        sh:path h:contains ; # Path from whole to part
        sh:class ex:Cylinder ;
        sh:qualifiedMinCount 1 ;
        sh:qualifiedValueShape [ sh:class ex:Cylinder ]
    ].

Validation of complex emergent properties (e.g., that the total weight of a whole equals the sum of its parts' weights) can be achieved using SHACL-SPARQL constraints, which allow for arbitrary SPARQL queries to be used for validation. This combination of new holon-specific components and existing SHACL features provides a comprehensive framework for ensuring the quality and integrity of RDF-H Holonic Graphs.

Use Cases and Non-Normative Guidance

This section provides non-normative examples and guidance on how the holon primitive can be applied to solve common modeling problems.

Modeling Pattern: Fine-Grained Access Control

Holons and their boundary graphs provide a powerful mechanism for implementing fine-grained access control (FGAC) directly within the RDF graph. Traditional RDF access control often operates at the model or named-graph level. Holons allow for resource-centric policies.

Consider a multi-tenant system where data for different projects must be segregated. Each project can be represented as a holon.

@holon ex:ProjectA {
    ex:SpecDoc1 a ex:Document.
    ex:Task3 a ex:Task.
}
@holon ex:ProjectB {
    ex:SpecDoc2 a ex:Document.
}

An access control policy can be attached to the containment edge between a user and a project holon.

ex:UserAlice h:containedIn ex:ProjectA {| acl:mode acl:Read, acl:Write |}.
ex:UserBob h:containedIn ex:ProjectA {| acl:mode acl:Read |}.
ex:UserBob h:containedIn ex:ProjectB {| acl:mode acl:Read, acl:Write |}.

A query processor or middleware layer can then enforce access by inspecting these boundaries. A query from UserAlice for documents would be rewritten to only search within holons she has at least acl:Read access to. This can be implemented by modifying the query to traverse the containment hierarchy:

# Original query from Alice
SELECT ?doc WHERE { ?doc a ex:Document }

# Rewritten query by the access control layer
SELECT ?doc WHERE {
  ex:UserAlice h:containedIn ?project.
  << ex:UserAlice h:containedIn ?project >> acl:mode acl:Read.
  ?project CONTAINS* ?doc.
  ?doc a ex:Document.
}

This pattern provides a flexible, graph-native way to define and enforce complex access policies that are co-located with the data they protect.

Modeling Pattern: Temporal, Modal, and Provenance Contexts

Boundary graphs are ideal for representing various forms of context that qualify a part-whole relationship.

Temporal Context: A component may only be part of a larger assembly for a specific period. RDF-star annotations on the h:containedIn edge can capture validFrom and validUntil timestamps, modeling the temporal dynamics of the system's composition. This is more precise than associating timestamps with the part or whole, as it correctly qualifies the relationship itself.
Modal Context: In engineering or planning, one might need to distinguish between components that are part of an assembly versus those that could potentially be part of it. A boundary graph can hold a property like h:modality "actual" or h:modality "potential", allowing for the representation of different possible configurations within the same graph. This is a form of modal logic representation within the graph.
Provenance Context: The assertion that one resource is contained within another may come from a specific source or have a certain confidence level. The boundary graph can store this provenance information (e.g., using the PROV-O ontology), stating who asserted the containment relationship and when.

In all these cases, the holon/boundary model provides a more granular and semantically precise alternative to using named graphs, where the entire graph is placed in a single, coarse-grained context.

A Comparative Look: Holonic Graphs vs. Labeled Property Graphs (LPGs)

Practitioners familiar with Labeled Property Graphs (LPGs), such as those used by Neo4j, will recognize similarities between holonic modeling and common patterns in LPGs. LPGs naturally support hierarchical data by creating relationships between nodes representing wholes and parts. Query languages like Cypher excel at traversing these hierarchies with variable-length path expressions.

RDF-H can be seen as introducing a key structural capability of LPGs into the RDF data model, but with the distinct advantages of the Semantic Web stack:

Formal Semantics: RDF-H, including holons, is defined by a formal, model-theoretic semantics [[RDF12-SEMANTICS]]. This provides a rigorous foundation for data interpretation and logical inference that is often lacking in the LPG world, where semantics can be implementation-dependent.
Global Uniqueness: Resources in RDF are identified by IRIs, providing a global, web-scalable namespace. This facilitates data integration and federation in a way that is more challenging with the local identifiers used in many LPGs.
Standardization: RDF, SPARQL, and SHACL are W3C standards, promoting interoperability between different tools and vendors. SPARQL-H and SHACL-H extend this standardized ecosystem. In contrast, while efforts like the GQL standard are underway, the LPG space remains more fragmented.
Rich Entailment: Holonic graphs can be used in conjunction with RDFS and OWL entailment regimes [[SPARQL11-ENTAILMENT]]. This allows for rich semantic reasoning (e.g., class subsumption, property characteristics) to be combined with structural containment, a feature not native to LPGs.

In essence, RDF-H Holonic Graphs offer a "best of both worlds" approach: the intuitive, traversal-friendly modeling of hierarchies found in property graphs, combined with the formal rigor, global interoperability, and reasoning capabilities of RDF.

Security and Privacy Considerations

The introduction of holons and, particularly, the transitivity of the containment relation, has significant implications for security and privacy that implementers and data modelers MUST consider.

Transitive Access and Data Aggregation: A naive access control model might grant a user access to a holon H. Due to transitivity, this could imply access to all resources contained within H, and all resources contained within its sub-holons, to any depth. This can lead to unintentional data exposure if a sub-holon contains sensitive information. Access control systems built on RDF-H SHOULD NOT assume that access to a whole implies access to all its parts. Policies should be explicit about the propagation of access rights down the holarchy. The boundary graph mechanism provides a means to specify such policies on a per-edge basis.
Inference and Data Leakage: The combination of H-entailment with other regimes like RDFS or OWL can lead to new inferences. For example, if a policy states that only members of the ex:Admin class can be contained in the ex:AdminHolon, and a user observes that ex:Bob ⊂ ex:AdminHolon, they can infer that ex:Bob is an ex:Admin, even if that triple is not directly visible. Implementers of secure systems must analyze the potential for such information leakage through inference.
Boundary Graph Security: Boundary graphs themselves contain policy or context metadata. Access to the boundary graphs must be controlled as carefully as access to the data they describe. An attacker who can modify a boundary graph could potentially escalate their own privileges. For example, changing acl:mode acl:Read to acl:mode acl:Write on a containment edge's boundary. Systems SHOULD treat boundary graph data as highly sensitive.
Denial of Service: The requirement for processors to validate acyclicity is a potential vector for denial-of-service attacks. A malicious user could submit a graph with a very large, complex, but ultimately cyclic containment structure. Implementations SHOULD use efficient cycle detection algorithms and may impose limits on traversal depth during validation to mitigate this risk.