Validation failure when Equipment feeds a Loop (e.g. Heat Exchanger → Hot Water Loop)

[LiMingchen159]

Hi @gtfierro , @carlosduarteroa👋

First, thank you both for the great work on the Brick schema — I’ve been using it in my current project and it’s been very helpful.
I’m currently collaborating with @carlosduarteroa and working with a model based on his implementation (thanks, @carlosduarteroa! 🙏).

---

Context

During validation, I found a case that cannot be validated successfully — when a piece of equipment feeds a hot water loop.
Example below:

hhws:building29.heat_exchanger a brick:Heat_Exchanger ;
    rdfs:label "Heat Exchanger - Building 29" ;
    brick:feeds hhws:building29.hws.secondary_loop .

hhws:building29.hws.secondary_loop a brick:Hot_Water_Loop ;
    rdfs:label "Hot Water Loop - Building 29" ;

This modeling seems semantically correct (the heat exchanger provides heat to the secondary loop),
but the SHACL validation fails because brick:Equipment’s feeds property does not currently allow brick:Loop as a valid target class.

---

Proposed Change

To better reflect this common and physically valid relationship (e.g., Heat Exchanger → Loop, Boiler → Hot Water Loop),
I suggest allowing brick:Loop as a valid target for both brick:Equipment and brick:HVAC_Equipment.

---

1️⃣ Updated brick:Equipment

brick:Equipment a owl:Class,
        sh:NodeShape ;
    rdfs:label "Equipment"^^xsd:string ;
    rdfs:subClassOf brick:Class,
        brick:Entity,
        rec:Asset ;
    skos:definition "devices that serve all or part of the building and may include electric power, lighting, transportation, or service water heating, including, but not limited to, furnaces, boilers, air conditioners, heat pumps, chillers, water heaters, lamps, luminaires, ballasts, elevators, escalators, or other devices or installations."@en ;
    sh:not [ sh:class brick:Location ;
            sh:message "Instances of Equipment cannot be Locations." ],
        [ sh:class brick:Substance ;
            sh:message "Instances of Equipment cannot be Substances." ],
        [ sh:class brick:Quantity ;
            sh:message "Instances of Equipment cannot be Quantities." ],
        [ sh:class brick:Collection ;
            sh:message "Instances of Equipment cannot be Collections." ],
        [ sh:class brick:Point ;
            sh:message "Instances of Equipment cannot be Points." ],
        [ sh:class brick:EntityProperty ;
            sh:message "Instances of Equipment cannot be EntityProperties." ] ;
    sh:property [ sh:class brick:Equipment ;
            sh:message "A piece of Equipment's parts should be always other Equipment." ;
            sh:path brick:hasPart ],
        [ sh:class brick:Point ;
            sh:message "A piece of Equipment can have Points." ;
            sh:path brick:hasPoint ],
        [ sh:message "Equipment can be part of a Collection, System or other Equipment." ;
            sh:or ( [ sh:class brick:System ] [ sh:class brick:Equipment ] [ sh:class brick:Collection ] ) ;
            sh:path brick:isPartOf ],
        [ sh:message "A piece of Equipment can be located only at a Location/Space" ;
            sh:or ( [ sh:class brick:Location ] [ sh:class rec:Space ] ) ;
            sh:path brick:hasLocation ],
        [ sh:message "A piece of Equipment can feed a Equipment or Location/Space." ;
-            sh:or ( [ sh:class brick:Equipment ] [ sh:class brick:Location ] [ sh:class rec:Space ] )  ;
+            sh:or ( [ sh:class brick:Equipment ] [ sh:class brick:Location ] [ sh:class rec:Space ] [shc:class brick:Loop ] )  ;
            sh:path brick:feeds ],

---

2️⃣ Updated brick:HVAC_Equipment

brick:HVAC_Equipment a owl:Class,
        sh:NodeShape ;
    rdfs:label "HVAC Equipment"@en ;
    rdfs:subClassOf brick:Equipment ;
    skos:definition "See Heating_Ventilation_Air_Conditioning_System"@en ;\
-     sh:property [ sh:or ( [ sh:class brick:HVAC_Equipment ] [ sh:class brick:Valve ] [ sh:class rec:Space ] ) ;
+    sh:property [ sh:or ( [ sh:class brick:HVAC_Equipment ] [ sh:class brick:Valve ] [ sh:class rec:Space ] [sh:class brick:Loop] ) ;
            sh:path brick:feeds ],
        [ sh:or ( [ sh:class brick:HVAC_Equipment ] [ sh:class brick:Valve ] ) ;
            sh:path brick:hasPart ] ;
    sh:rule [ a sh:TripleRule ;
            sh:object tag:Equipment ;
            sh:predicate brick:hasTag ;
            sh:subject sh:this ],
        [ a sh:TripleRule ;
            sh:object tag:HVAC ;
            sh:predicate brick:hasTag ;
            sh:subject sh:this ] ;
    brick:hasAssociatedTag tag:Equipment,
        tag:HVAC .

---

Summary

• Issue: SHACL validation fails when Equipment feeds a Loop (e.g., Heat Exchanger → Hot Water Loop).

• Proposal: Add brick:Loop as a valid target for the feeds property of both brick:Equipment and brick:HVAC_Equipment.

• Rationale: This reflects common HVAC semantics, aligns with physical reality, and prevents false negatives due to overly strict parent class constraints.

• Impact: Minimal, backward-compatible schema change that improves modeling flexibility and validation consistency.

If this makes sense, I’d be happy to open a PR for review.
Thanks again for your great work on Brick!

[gtfierro]

Hi @LiMingchen159 can you explain how having equipment feed a loop reflects common HVAC semantics? The intent of the Loop construct is to state which equipment/locations exist within a loop. Thus, its awkward to express that something "feeds" the loop, when it should probably just be a member of the loop.

Can you help me understand what you want to model that can't be captured by making the equipment part of the loop?

[LiMingchen159]

Sorry for the late reply! And thanks @gtfierro for the clarification. I completely understand your point about the intended use of brick:Loop as a grouping construct.

Our motivation for proposing this change comes from the functional flow perspective rather than the membership perspective.
In many HVAC systems, certain equipment (like boilers or heat exchangers) supply heat water to a secondary loop.
For example, a heat exchanger may take heat from a primary loop and feed a secondary hot water loop.

The following diagram illustrates a typical hot water system, showing how the two loops (primary and secondary) are connected through a heat exchanger and how energy flows between them:

This diagram shows the heat exchanger transferring heat from the primary loop to the secondary loop — effectively feeding it.
Would allowing brick:Loop as a valid brick:feeds target make sense in this context?

[gtfierro]

Ok, this use case makes sense. We'll discuss this at the next Brick development meeting. I think we could allow feed to a Loop (but not Collections overall).

As an aside: I wonder if https://docs.brickschema.org/modeling/connections.html would be another approach for modeling (using 223P to model the loop and connections to it).