Core Class and Property

h:Holon

The class of all holons. A holon is a resource that has a content graph CG(H) — the set of triples filed in it (formalized in ). The holon is the whole whose internal structure is its content graph, and which may itself appear as a node — a part — in other holons' content graphs. Class membership is entailed by the rdfs:range axiom on h:inHolon: ?h is inferred to be an h:Holon whenever ?r h:inHolon ?h appears in the graph (see ). No axiom requires a holon to be non-empty or to be a part of anything: a holon MAY have an empty content graph or be top-level.

h:inHolon

An object property that links an RDF 1.2 reifier — an IRI or blank node related to a triple term via rdf:reifies — to the holon that contains the corresponding triple-occurrence. The subject of h:inHolon is therefore the reifier (which identifies one occurrence of an asserted triple); the object is the containing holon. Its rdfs:range is h:Holon. No rdfs:domain is declared, because RDF 1.2 places no class restriction on reifiers [[RDF12-CONCEPTS]]. This property does not use the older rdf:Statement reification vocabulary, which is independent of the RDF 1.2 reifies / triple-term machinery. In Turtle 1.2 [[RDF12-TURTLE]] the bare-brace syntax << :s :p :o >> (a reified triple) expands to a fresh blank-node reifier _:b rdf:reifies <<( :s :p :o )>>; RDF-H reuses this reifier sugar so that h:inHolon is always asserted on an IRI or blank node.

h:contentGraph

A functional object property used in the named-graph profile () to relate a holon to the named graph that materializes its content graph CG(H). The default convention is that the content-graph name equals the holon IRI, so this property is usually omitted; declare it only to decouple a holon's identity from its content-graph name. It has no role in the reifier profile, where CG(H) is defined by the h:inHolon pattern rather than by a named graph. Its rdfs:domain is h:Holon.

h:CompleteHolon

A subclass of h:Holon whose content graph is complete: no triple-occurrence beyond those filed in H belongs to CG(H). A consumer MAY therefore rely on CG(H) being exhaustive — for example, treating the absence of a matching triple in CG(H) as "there is none" for the purpose of integrity checks scoped to the holon. This is a local completeness contract, not a global closed-world assumption: it adds no entailment and is honoured only by SHACL and opting-in consumers (see ), not by an OWL/RDFS reasoner. The boundary it provides is what lets a holon act as a genuine whole. Typing a holon h:CompleteHolon is optional.

Empty content graphs require explicit typing. The rdfs:range axiom on h:inHolon only types resources that are objects of at least one h:inHolon triple — i.e. holons with a non-empty content graph. A holon with an empty content graph exists only via an explicit rdf:type h:Holon assertion. With the content-graph model the empty case is well-defined (an empty CG(H)) rather than degenerate; see Open Issue 4.

OWL DL note. The owl:ObjectProperty declaration commits every reifier in subject position of h:inHolon to being an individual under OWL 2 DL semantics [[OWL2-DIRECT-SEMANTICS]] — strictly stronger than RDF 1.2, which leaves reifiers untyped. In practice, useful reifiers are individuals anyway.

Holon and reifier roles are independent. A resource MAY simultaneously be both a holon (object of h:inHolon) and a reifier (subject of rdf:reifies), and a reifier MAY be the object of h:inHolon — placing one triple-occurrence inside the context of another. RDF-H imposes no disjointness, inheriting the permissive stance of RDF 1.2 [[RDF12-CONCEPTS]]. In most domains a holon is nonetheless best modeled as a domain-level whole (building, system, process) rather than as a reifier itself.

The Part-Of Hierarchy

RDF-H defines a hierarchy of part-whole relationships using rdfs:subPropertyOf and owl:inverseOf, letting modelers be specific while keeping queries general [[OEP-PARTWHOLE]]. A single transitive top-level property, h:partOf, anchors the hierarchy and provides the closure used for "is somewhere in the part hierarchy of" queries. Four sub-properties refine it along orthogonal dimensions: h:componentOf and h:memberOf for structural parthood and aggregate membership respectively (both asymmetric and irreflexive), and h:substanceOf and h:portionOf for material composition and continuous-whole segmentation respectively (both transitive).

h:partOf / h:hasPart

The top-level super-property for all part-whole relations. Use it to query the transitive closure of the part hierarchy. h:hasPart is the inverse of h:partOf.
Characteristics: Transitive. (Acyclicity enforced by SHACL.)

h:componentOf / h:hasComponent

A sub-property of h:partOf for functional or structural parts (e.g., an engine is a component of a car). This relationship is essential for preserving the distinct levels of a holarchy. h:hasComponent is the inverse of h:componentOf.
Characteristics: Non-transitive, asymmetric, irreflexive.

h:memberOf / h:hasMember

A sub-property of h:partOf for elements in a collection or group where the whole is an aggregate of its members (e.g., a player is a member of a team). h:hasMember is the inverse of h:memberOf.
Characteristics: Non-transitive, asymmetric, irreflexive.

h:substanceOf / h:hasSubstance

A sub-property of h:partOf for material composition (e.g., clay is a substance of a brick). A part of the substance is also a part of the whole. h:hasSubstance is the inverse of h:substanceOf.
Characteristics: Transitive. (Acyclicity enforced by SHACL.)

h:portionOf / h:hasPortion

A sub-property of h:partOf for segments of a continuous whole (e.g., a slice is a portion of a pie). A part of the portion is also a part of the whole. h:hasPortion is the inverse of h:portionOf.
Characteristics: Transitive. (Acyclicity enforced by SHACL.)

@prefix h: <https://w3id.org/rdf-h#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

# Top-level transitive part-of (closure for queries; acyclic via SHACL)
h:partOf a owl:ObjectProperty, owl:TransitiveProperty .
h:hasPart a owl:ObjectProperty, owl:TransitiveProperty ;
    owl:inverseOf h:partOf .

# Non-transitive, asymmetric, irreflexive sub-properties of h:partOf
# (immediate structural parthood and aggregate membership)
h:componentOf a owl:ObjectProperty,
        owl:AsymmetricProperty,
        owl:IrreflexiveProperty ;
    rdfs:subPropertyOf h:partOf .
h:hasComponent a owl:ObjectProperty,
        owl:AsymmetricProperty,
        owl:IrreflexiveProperty ;
    rdfs:subPropertyOf h:hasPart ;
    owl:inverseOf h:componentOf .

h:memberOf a owl:ObjectProperty,
        owl:AsymmetricProperty,
        owl:IrreflexiveProperty ;
    rdfs:subPropertyOf h:partOf .
h:hasMember a owl:ObjectProperty,
        owl:AsymmetricProperty,
        owl:IrreflexiveProperty ;
    rdfs:subPropertyOf h:hasPart ;
    owl:inverseOf h:memberOf .

# Transitive sub-properties of h:partOf (acyclic via SHACL, like h:partOf)
h:substanceOf a owl:ObjectProperty, owl:TransitiveProperty ;
    rdfs:subPropertyOf h:partOf .
h:hasSubstance a owl:ObjectProperty, owl:TransitiveProperty ;
    rdfs:subPropertyOf h:hasPart ;
    owl:inverseOf h:substanceOf .

h:portionOf a owl:ObjectProperty, owl:TransitiveProperty ;
    rdfs:subPropertyOf h:partOf .
h:hasPortion a owl:ObjectProperty, owl:TransitiveProperty ;
    rdfs:subPropertyOf h:hasPart ;
    owl:inverseOf h:portionOf .

Acyclicity. No resource may stand in h:partOf+ with itself; this is criterion 2 of the normative MUST-level requirements on a conformant RDF-H graph (see ), pinned to RDFS entailment so that cycles introduced through custom sub-properties of h:partOf are caught automatically. In a finite RDF graph (the only kind this specification considers), acyclicity coincides with well-foundedness of the part-of relation. The SHACL-level enforcement is described in .

OWL 2 DL note. OWL 2 DL (the Description Logic profile of [[OWL2-SYNTAX]]) forbids combining owl:TransitiveProperty with owl:AsymmetricProperty or owl:IrreflexiveProperty on the same role, and does not propagate property characteristics across rdfs:subPropertyOf. Each property in the hierarchy therefore declares its own characteristics explicitly. h:componentOf and h:memberOf remain OWL 2 DL simple roles because neither is itself transitive nor has a transitive sub-property; their transitive super-property h:partOf does not violate the simple-role restriction, which is downward, not upward. See Open Issue 3 for the design history.

Extension constraint. A conformant RDF-H ontology extension MUST NOT introduce transitive sub-properties of h:componentOf, h:memberOf, h:hasComponent, or h:hasMember; doing so would make those properties non-simple (§11 of [[OWL2-SYNTAX]]) and invalidate their owl:AsymmetricProperty and owl:IrreflexiveProperty axioms under OWL 2 DL. More generally, an extension SHOULD classify each custom part-property it introduces as either a closure relation or an immediate relation:

• A closure relation (like h:partOf itself, or h:substanceOf / h:portionOf) ranges over the transitive closure of parthood. It SHOULD be declared owl:TransitiveProperty and a sub-property of h:partOf.
• An immediate relation (like h:componentOf / h:memberOf) holds only one level deep. It SHOULD be declared a sub-property of h:componentOf or h:memberOf (not of h:partOf directly), and — if it is to carry owl:AsymmetricProperty / owl:IrreflexiveProperty — it MUST NOT be transitive nor have a transitive sub-property, so that it remains an OWL 2 DL simple role.

The built-in vocabulary is exactly this split: h:partOf, h:substanceOf, h:portionOf are transitive closure relations, while h:componentOf and h:memberOf are non-transitive immediate relations — which is why a blanket "custom sub-properties should be transitive" rule would be wrong.

Future direction. This mereology is logically separable from the holon machinery and is a candidate for extraction into a sibling vocabulary; the IRIs and semantics defined here are intended to remain stable across such an extraction. See Open Issue 1.

Exclusion of Other Relationship Types

It is a deliberate design choice for the RDF-H vocabulary to focus exclusively on composition (h:inHolon) and mereology (the h:partOf hierarchy). Other important relationship types, such as peer-to-peer, dependency, or hierarchical supervision, are considered domain-specific and are intentionally excluded from this core vocabulary.

This design follows the principle of minimality. RDF-H provides the universal, structural primitives for building holarchies. Modelers are encouraged to define their own domain-specific properties (e.g., ex:isPeerOf, ex:dependsOn) in their own ontologies. The RDF-H pattern is then used to place these custom relationships within the context of a holon. This approach promotes a more flexible and composable ecosystem, where the core RDF-H pattern can be applied to any relationship, without the RDF-H vocabulary itself becoming an exhaustive and overly prescriptive ontology.

@prefix ex:  <https://example.org/network#> .
@prefix h:   <https://w3id.org/rdf-h#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

# A domain-specific property defined in an external ontology
ex:isPeerOf a owl:ObjectProperty, owl:SymmetricProperty .

# The holon resource. Explicit typing is RECOMMENDED for portability,
# even though h:inHolon's range axiom would entail it under RDFS.
ex:SystemCluster a h:Holon .

# Applying the RDF-H pattern to the domain-specific property
@holon ex:SystemCluster {
    ex:ServiceA ex:isPeerOf ex:ServiceB .
}

The content graph and the additive invariant

Let G be the asserted graph: in the reifier profile, the single RDF graph; in the named-graph profile, the union of the dataset's graphs (its default graph together with all of its named graphs). This last point is an RDF-H-defined interpretation, not default RDF behaviour: RDF 1.1/1.2 datasets deliberately fix no required relationship between the default graph and the named graphs, and SPARQL does not query their union by default [[RDF11-DATASETS]]. RDF-H stipulates that, for a dataset using the named-graph profile, the asserted content is the union of its graphs. For a holon H, its content graph CG(H) is the set of triples filed in H. RDF-H imposes one normative constraint relating every content graph to G:

Additive invariant. For every holon H, CG(H) ⊆ G: every triple filed in a holon is also in the asserted graph G. A content graph is therefore a view that carves up one true graph, not a separate or hypothetical theory. This is the defining commitment of RDF-H's additive semantics, and it is the general form of conformance criterion 3. In the reifier profile it is a genuine constraint (the base triple must be asserted alongside the reifier); in the named-graph profile it holds by construction, since each CG(H) is one of the graphs whose union is G. (A contextual reading, in which a holon's triples would be true only "within" the holon and not globally, would drop this invariant; that is deliberately out of scope — see Open Issue 8.)

Because content graphs are views over G, part-whole entailments need no special treatment: if ex:Engine h:componentOf ex:Car is in any CG(H) it is (by the invariant) also in G, so ex:Engine h:partOf ex:Car follows by the ordinary mereology of regardless of which holon it was filed in. What the content graph adds is where the relationship lives, not whether it holds.

Reifier profile (single graph, RDF 1.2)

In the reifier profile, membership is recorded with the RDF 1.2 reifier model and the h:inHolon property:

CG(H) = { (s,p,o) : ∃ r. (r, rdf:reifies, <<( s p o )>>) ∈ G ∧ (r, h:inHolon, H) ∈ G }.

Everything stays in a single graph, and because each occurrence has its own reifier the profile supports per-occurrence metadata (the same relationship can be filed in two holons with distinct provenance on each occurrence — see the multi-holon pattern). The additive invariant is operationalized here by h:AssertedBaseTripleShape (). Turtle-H () is surface syntax for this profile.

Named-graph profile (dataset, RDF 1.1/1.2)

In the named-graph profile, a holon's content graph is a named graph in an RDF dataset [[RDF11-DATASETS]]:

CG(H) = the graph named N in the dataset, where (H, h:contentGraph, N) is asserted in the default graph; by default N = H, so the holon IRI doubles as its content-graph name and h:contentGraph may be omitted.

The holon IRI remains an ordinary, describable resource in the default graph (e.g. ex:Floor_3 a h:Holon ; bldg:floorNumber 3), while its internal structure is the graph it names. Under the RDF-H interpretation that the asserted graph G is the union of the dataset's graphs (an RDF-H stipulation, not default dataset semantics — see asserted graph), each named graph CG(H) is a subset of G by construction: the additive invariant holds with no duplication and needs no separate check — a filed triple is asserted simply by being in its named graph. This profile therefore costs one quad per filed triple (no reifiers), is queryable with GRAPH on current SPARQL engines, and gets a cheap boundary for free (a named graph is exactly its quads).

Profile content-equivalence

The two profiles are content-equivalent under a projection: they realize the same CG(H) for every holon and the same set of asserted base triples, but they are not equivalent as full RDF graphs/datasets — occurrence identity, per-occurrence metadata, and the multiplicity of a triple filed more than once in the same holon are visible in the reifier profile and projected away in the named-graph profile. A conformant processor MAY translate between them:

• reifier → named-graph: for each r h:inHolon H with r rdf:reifies <<( s p o )>>, place (s,p,o) in the graph named N (the content-graph name of H, by default H itself).
• named-graph → reifier: for each (s,p,o) in the graph named N for holon H, mint a fresh reifier r and emit r rdf:reifies <<( s p o )>> . r h:inHolon H . in the single graph.

These translations preserve CG(H) for every holon and the asserted base triples, and are mutually inverse up to renaming of blank-node reifiers and the choice of content-graph name N. They do not preserve the literal triple set: the rdf:reifies/h:inHolon bookkeeping of the reifier profile and the quad structure of the named-graph profile are profile-specific. The reifier profile carries strictly more information only when distinct occurrences of one relationship must be distinguished (per-occurrence metadata); when they need not be, the round trip is lossless.

One profile per holon. A holon SHOULD be serialized in a single profile. Because h:contentGraph is functional, a holon has at most one named content graph; if a holon nonetheless carries both reifier-profile memberships (h:inHolon) and a named content graph, its content graph CG(H) is the union of the two, and processors MAY normalize such mixed data by converting to a single profile first.

Deep content and holon nesting

The deep content of a holon rolls its parts' content graphs up into it, following the part-of hierarchy:

CG*(H) = ∪ { CG(K) : K h:partOf* H } — the union of the content graphs of H and of every holon that is a part of H.

Roll-up follows parthood, not Turtle-H lexical nesting: a nested @holon block () contributes to a holon's deep content only when a part-of edge actually relates the two holons. Lexical nesting on its own is purely a layout convenience and carries no containment. This keeps the two channels — holonic context and parthood — explicit rather than implied by indentation. gives the CG* query.

Entailment posture. Deep content is defined with h:partOf*, so the CG* query traverses the part hierarchy's sub-properties only under RDFS entailment — unlike h:AcyclicPartShape, which is deliberately entailment-independent (it enumerates the sub-properties and their inverses). On an engine without RDFS entailment, substitute the same alternation (( h:partOf | h:componentOf | … | ^h:hasPortion )*) for h:partOf* in the CG* query. CG* is an informative convenience, not a conformance requirement.

Coherence between content and holon

The additive invariant guarantees a content graph is sound (its triples really hold) but not that it is about its holon: nothing in the abstract definition stops a triple whose subject and object are unrelated to H from being filed in H. RDF-H therefore SHOULD-recommends two coherence conditions, surfaced as advisory SHACL shapes ():

• Mereological coherence. A part-of relation filed in H SHOULD have H (or a part of H) as its whole — so a holon's content describes the holon's own composition. This rules out filing ex:Wheel h:componentOf ex:Car inside an unrelated @holon ex:Engine.
• Contextual coherence. Any relation filed in H SHOULD have at least one endpoint that is H or a part of H, so the content graph stays about the holon. Domain relations with one external endpoint (e.g. ex:TempSensor_F3 bldg:monitors ex:HVAC_F3, filed in ex:HVAC_F3) satisfy this.

These are advisory, not conformance requirements: deliberate cross-context placements remain valid RDF-H, but they are the exception rather than the rule. This is a deliberate reversal of earlier drafts, which presented the independence of context and parthood as a headline feature; under the content-graph model it is a permitted edge case.

The @holon Directive

A holon and its constituent relationships are defined by the @holon directive, followed by the holon's identifier (IRI or blank node) and a block of Turtle statements enclosed in curly braces:

@holon <holon-iri> {
    # Turtle statements that are constituents of this holon
}

Why a directive (not a bare IRI { ... } block)? The bare-brace form denotes a named graph in TriG [[TRIG]]; reusing it would clash with that vocabulary. The @holon keyword makes Turtle-H grammatically distinct from TriG and unambiguous to a single parser pass. Turtle-H is not part of Turtle 1.2 [[RDF12-TURTLE]] — it is a proposed sugar that lets developers write a holonic relationship once and have a Turtle-H-aware parser generate both the asserted triple and the h:inHolon annotation.

Content membership is not, by itself, part membership. Filing a triple :s :p :o in @holon :H { ... } places that relationship in the content graph of :H. It does not on its own assert that :s or :o is a part of :H; part-whole relations are carried by the h:partOf hierarchy (). The two channels remain distinct, but they are not meant to be used arbitrarily: recommends that a holon's content graph be about the holon — a part-of relation filed in :H should describe :H's own composition, and any relation filed in :H should touch :H or one of its parts. A typical holon block therefore contains a h:componentOf / h:memberOf / h:substanceOf / h:portionOf triple that says what the parts are, plus domain relations among those parts. Filing a triple that has nothing to do with :H is permitted but is the documented exception, not the intended pattern (and is flagged by the advisory coherence shapes).

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

ex:Car_123 a h:Holon .
ex:Engine_456 a h:Holon .

@holon ex:Car_123 {
    ex:Engine_456 h:componentOf ex:Car_123 .

    @holon ex:Engine_456 {
        ex:Piston_789 h:componentOf ex:Engine_456 .
    }
}

This concise syntax is syntactic sugar for the standard RDF 1.2 representation. A Turtle-H parser MUST translate the block syntax into the equivalent set of standard triples.

The block @holon :H { :s :p :o . } desugars per Turtle-H into:

1. The Base Fact: The relationship itself is asserted.
   :s :p :o .
2. The Context Fact: The relationship's reifier is linked to its containing holon.
   << :s :p :o >> h:inHolon :H .

The reified-triple form << :s :p :o >> is itself sugar in Turtle 1.2 [[RDF12-TURTLE]] — it allocates a fresh blank-node reifier related to the triple term <<( :s :p :o )>> via rdf:reifies. The fully-expanded RDF 1.2 form is therefore three triples per @holon-enclosed statement, as shown below.

# Reified-triple sugar
ex:Engine_456 h:componentOf ex:Car_123 .
<< ex:Engine_456 h:componentOf ex:Car_123 >>
    h:inHolon ex:Car_123 .

# Fully expanded (no syntactic sugar)
ex:Engine_456 h:componentOf ex:Car_123 .
_:r1 rdf:reifies
    <<( ex:Engine_456 h:componentOf ex:Car_123 )>> .
_:r1 h:inHolon ex:Car_123 .

Asserting the Base Triple

RDF 1.2 distinguishes three things that are easy to conflate [[RDF12-CONCEPTS]]:

• An asserted triple :s :p :o . claims that the relationship holds in the graph's interpretation.
• A triple term <<( :s :p :o )>> denotes the triple (:s, :p, :o) as an RDF term. A triple term may appear only as the object of another triple, never as a subject, and asserting a triple that contains a triple term in object position does not assert the inner triple.
• A reifier is an IRI or blank node related to a triple term via rdf:reifies. It identifies a particular occurrence of the underlying triple and is itself an ordinary RDF resource that may appear as either subject or object.

Three verbs therefore have distinct meanings in this specification: a triple is asserted when it appears in the graph as a normal claim; a triple term denotes a triple-as-RDF-term without claiming it; a reifier reifies a triple term, attaching identity to one of its occurrences without claiming it. RDF-H's annotation verb (?r h:inHolon ?H) attaches the reifier to a holon — it neither asserts the underlying triple on its own nor denotes it as an RDF term. Criterion 4 of ties annotation to assertion explicitly.

In Turtle 1.2 [[RDF12-TURTLE]] the bare-brace form << ?s ?p ?o >> is syntactic sugar for a fresh blank-node reifier together with the rdf:reifies triple that ties it to the underlying triple term. Concretely, << ?s ?p ?o >> h:inHolon ?H . expands to _:b rdf:reifies <<( ?s ?p ?o )>> . _:b h:inHolon ?H . Asserting this does not by itself assert ?s ?p ?o — it only asserts that a reifier of that triple is in holon ?H.

RDF-H therefore imposes the following normative requirement:

• For every reifier ?r with ?r h:inHolon ?H in a conformant RDF-H graph, if ?r rdf:reifies <<( ?s ?p ?o )>> holds, then the base triple ?s ?p ?o MUST also be asserted in the same graph.
• The @holon directive of Turtle-H satisfies this requirement automatically by emitting both the asserted triple and the reifier-with-h:inHolon on desugaring (see the desugaring rules).

"Being in a holon" is therefore an annotation on a relationship that is already claimed to hold; it never substitutes for the assertion itself.

The asserted-base-triple requirement is necessary because RDF 1.2 Semantics [[RDF12-SEMANTICS]] places no truth-preserving constraint on rdf:reifies: asserting that a reifier reifies a triple term carries no model-theoretic commitment to the truth of the underlying triple. Without the explicit RDF-H rule above, an RDF-H graph could legitimately contain ?r h:inHolon ?H for a reifier of a triple that is not itself asserted, which would make holons unsound containers for the relationships they purport to gather. RDF 1.2 Semantics likewise places no identity constraint on reifiers of the same triple term, which is what enables the multiple-holons-per-triple pattern shown below.

The Turtle 1.2 annotation syntax {| h:inHolon ?H |} is equivalent to the reified-triple sugar (forms (b) and (c) shown in ) and idiomatic when the holon context is attached to a single triple. The multi-holon pattern below uses it directly.

The same triple in multiple holons

A single base triple MAY appear in more than one holon. Each additional containing holon is recorded by an additional reifier carrying its own h:inHolon. There is no implicit relationship between the holons that share a triple.

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

ex:Engine_456 h:componentOf ex:Car_123
    {| h:inHolon ex:Car_123 |}
    {| h:inHolon ex:DriveTrain_789 |} .

Each {| ... |} block allocates a fresh blank-node reifier for the surrounding triple [[RDF12-TURTLE]]. The two annotation blocks above therefore produce two distinct reifiers of the same base triple, each carrying its own h:inHolon annotation — placing the single relationship into both ex:Car_123 and ex:DriveTrain_789 without identifying the two holons or their respective triple-occurrences. A reader who naturally assumes "one reifier per asserted triple" should note that RDF 1.2 imposes no such constraint: distinct reifiers MAY reify the same triple term, and RDF-H relies on this freedom for the multi-holon pattern.

In the named-graph profile the same pattern is even more direct: the triple simply appears in both content graphs — GRAPH ex:Car_123 { ex:Engine_456 h:componentOf ex:Car_123 } and GRAPH ex:DriveTrain_789 { ex:Engine_456 h:componentOf ex:Car_123 } — with no reifiers involved.

Turtle-H is not TriG

Turtle-H is surface syntax for the reifier profile: a Turtle-H processor MUST NOT treat an @holon block as a TriG [[TRIG]] named graph, and desugars it to h:inHolon annotations within a single graph. This is distinct from the named-graph profile (), where a holon's content graph is a named graph realized in a dataset and authored with ordinary TriG / GRAPH syntax. Both encode the same content graph (); the prohibition here is only that the @holon directive is not itself TriG. The converse is a grammar property (see ), not a normative requirement on TriG processors.

Extracting a content graph

A holon's content graph CG(H) is recovered by a one-line query. In the reifier profile:

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

SELECT ?s ?p ?o WHERE {
    << ?s ?p ?o >> h:inHolon ex:Floor_3 .
}

In the named-graph profile the same content graph is the named graph itself:

SELECT ?s ?p ?o WHERE {
    GRAPH ex:Floor_3 { ?s ?p ?o }
}

Deep content CG*(H) rolls the content graphs of H and all its parts together (reifier profile; h:partOf* binds ?w to ex:Building_A and every part of it, under RDFS entailment):

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

SELECT ?s ?p ?o WHERE {
    ?w h:partOf* ex:Building_A .
    << ?s ?p ?o >> h:inHolon ?w .
}

The named-graph form replaces the reified-triple pattern with GRAPH ?w { ?s ?p ?o }.

Normative Validators

Advisory Validators

These three shapes are declared sh:severity sh:Warning; they surface portability and coherence recommendations and never report a conformance-level sh:Violation.

Validating complete holons

A complete holon asserts that its content graph is complete, which licenses a closed-world reading within the holon. Completeness is necessarily domain-specific (what counts as "complete" depends on the kind of holon), so RDF-H does not ship a single closure validator; instead, model the expected content with an ordinary SHACL shape and target it at the complete holons. For example, requiring that every closed bldg:Floor holon contain exactly one HVAC component:

ex:CompleteFloorShape
    a sh:NodeShape ;
    sh:targetClass h:CompleteHolon ;
    sh:sparql [
        a sh:SPARQLConstraint ;
        sh:message "A closed floor holon must contain exactly one HVAC component." ;
        sh:select """
            PREFIX h:    <https://w3id.org/rdf-h#>
            PREFIX bldg: <https://example.org/bldg#>
            SELECT $this WHERE {
                $this a bldg:Floor .
                {
                    # Ungrouped COUNT — yields 0 (not an empty result) when the
                    # closed floor has no HVAC component, so the zero case is caught.
                    SELECT (COUNT(?hvac) AS ?n) WHERE {
                        << ?hvac h:componentOf $this >> h:inHolon $this .
                        ?hvac a bldg:HVAC .
                    }
                }
                FILTER (?n != 1)
            }
        """ ;
    ] .

The closed-world reading is sound precisely because h:CompleteHolon promises that CG(H) is complete: the absence of a second HVAC occurrence in the content graph can be read as "there is no second HVAC component," which an open-world holon could not guarantee.

Closure is an advisory contract, not an entailment. h:CompleteHolon carries no RDFS or OWL semantics: an OWL or RDFS reasoner does not derive negative facts from it, and merging a complete holon's graph with new triples does not automatically re-validate it. The closed-world reading is honoured only by SHACL shapes (which are closed-world by construction) and by consumers that opt in. Implementers MUST NOT assume a reasoner enforces closure; treat it as a signal that the closed-world checks above are intended to apply.

Implementation profiles

Because the two serialization profiles () have very different tooling demands, conformance is stated against one of two named implementation profiles; an implementation MUST declare which it supports (it MAY support both):

RDF-H Reifier Profile

The single-graph, RDF 1.2 reifier encoding (rdf:reifies + h:inHolon), including Turtle-H. It requires RDF 1.2 triple terms and, for the shipped SHACL shapes, a SHACL engine whose embedded SPARQL supports triple terms (SPARQL 1.2). This support is still maturing across implementations, so a conformant processor MAY use the component-extraction fallback noted in .

RDF-H Dataset Profile

The named-graph encoding over an RDF dataset. It runs on today's RDF 1.1 + SPARQL 1.1 + standard SHACL stacks (membership and content-graph extraction use the GRAPH clause), and depends on the RDF-H asserted-graph interpretation (asserted graph).

The two profiles are content-equivalent under a projection (), so a graph authored for one can be consumed in the other by a processor that supports both.