Brick v1.5.0 Release Candidate 1
60 views
Skip to first unread message
Gabe Fierro
Jun 11, 2026, 12:50:29 PMJun 11
to Brick User Forum (Unified Building Metadata Schema)
Hi everyone!
I've finished the build on Brick v1.5.0-rc1. The changelog, added/removed concepts, and download the ontology are available on GitHub: https://github.com/BrickSchema/Brick/releases/tag/v1.5.0-rc1 . https://docs.brickschema.org/ contains updated documentation on v1.5.0 concepts (these should be marked so they are obvious) and I have updated the ontology documentation as well: https://ontology.brickschema.org/1.5.0/
Please take a look at the release candidate and let us know what you think! Are there bugs? Omissions? Problems loading it into your software? Please feel free to respond here in this thread, start new threads, or open issues on GitHub.
Thanks to all of you who contributed to this release!
Best,
Gabe
(I've finally added my work email to this forum, so I will be *much* quicker to respond to messages moving forward).
Nauman Rafique
Jun 11, 2026, 6:22:32 PMJun 11
to Gabe Fierro, Brick User Forum (Unified Building Metadata Schema)
Hi Gabe,
I am Nauman, working at Visum. We are extending Brick to
cover data center infrastructure, with an early focus on liquid cooling, and we are
building on top of the core schema rather than around it. We want to engage with the
community and understand the model as it evolves, so we tested this release candidate
with that in mind.
A few notes from testing v1.5.0-rc1.
Loading: both Brick.ttl and Brick+imports.ttl parse cleanly in rdflib 7.6.0,
62,083 and 181,630 triples respectively, with no errors.
A question on host cardinality in the new Controller and ICT equipment model. We
noticed the shapes appear to constrain a Point to at most one isHostedBy
ICT_Equipment (sh:maxCount 1 on the Point side, with the message "A Point can be
hosted by at most one ICT Equipment"), and we wanted to check whether that is
intended. We may be reading it wrong, but it suggests a point can be hosted by only
one device. In some deployments a single logical point seems to be exposed through
more than one device, for example a field controller and a supervisory gateway, a
BACnet/IP gateway in front of a field bus, or a redundant controller pair. Would it
make sense for a point to be hosted by more than one ICT_Equipment, or is single
host the intended model here?
One small documentation note: the four new relationships controls, isControlledBy,
hosts, and isHostedBy carry rdfs:label but no skos:definition, so in views that use
definitions for descriptions they appear without descriptive text. The Controller
class itself already has a clear definition. A short definition on each relationship
would help adopters. I realize a fair number of existing relationships are in the
same state, so this is more a nice to have for the headline feature than a
regression.
Hoping to learn more through this conversation.
Thanks.
Nauman
I am Nauman, working at Visum. We are extending Brick to
cover data center infrastructure, with an early focus on liquid cooling, and we are
building on top of the core schema rather than around it. We want to engage with the
community and understand the model as it evolves, so we tested this release candidate
with that in mind.
A few notes from testing v1.5.0-rc1.
Loading: both Brick.ttl and Brick+imports.ttl parse cleanly in rdflib 7.6.0,
62,083 and 181,630 triples respectively, with no errors.
A question on host cardinality in the new Controller and ICT equipment model. We
noticed the shapes appear to constrain a Point to at most one isHostedBy
ICT_Equipment (sh:maxCount 1 on the Point side, with the message "A Point can be
hosted by at most one ICT Equipment"), and we wanted to check whether that is
intended. We may be reading it wrong, but it suggests a point can be hosted by only
one device. In some deployments a single logical point seems to be exposed through
more than one device, for example a field controller and a supervisory gateway, a
BACnet/IP gateway in front of a field bus, or a redundant controller pair. Would it
make sense for a point to be hosted by more than one ICT_Equipment, or is single
host the intended model here?
One small documentation note: the four new relationships controls, isControlledBy,
hosts, and isHostedBy carry rdfs:label but no skos:definition, so in views that use
definitions for descriptions they appear without descriptive text. The Controller
class itself already has a clear definition. A short definition on each relationship
would help adopters. I realize a fair number of existing relationships are in the
same state, so this is more a nice to have for the headline feature than a
regression.
Hoping to learn more through this conversation.
Thanks.
Nauman
--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/brickschema/c81ac3a6-3ba4-4508-9595-cfe0305a209fn%40googlegroups.com.
Gabe Fierro
Jun 30, 2026, 12:55:05 PM (10 days ago) Jun 30
to Nauman Rafique, Brick User Forum (Unified Building Metadata Schema)
Hi Nauman:
(was on travel, but I’m back now! Sorry for the delay)
Thanks for reviewing Brick 1.5-rc1! I’ve added some updated definitions in this PR:
https://github.com/BrickSchema/Brick/pull/788 . Please let me know if you like these or have any other suggestions
We’ll discuss the hosting cardinality question this Thursday. We had single host in mind for the implementation; the hostsPoint relationship specifically means that the controller is responsible for exposing that point to the rest of the network. In your use
case, do you think you’ll need a separate relationship to differentiate between the primary/secondary ‘hosts’ of a point? In ASHRAE 223 we developed an ‘internal reference’ relationship for pointing out this relationship, so maybe it is worth making the ‘virtualization’
of a point a separate relationship?
Best,
Gabe
--
Dr. Gabe Fierro |
https://gtf.fyi
Assistant Professor of Computer Science | Colorado School of Mines
Joint Appointment | National Laboratory of the Rockies
From: brick...@googlegroups.com <brick...@googlegroups.com> on behalf of Nauman Rafique <nau...@visum.ai>
Date: Thursday, June 11, 2026 at 4:22 PM
To: Gabe Fierro <gtfi...@mines.edu>
Cc: Brick User Forum (Unified Building Metadata Schema) <brick...@googlegroups.com>
Subject: [EXTERNAL] Re: [Brick] Brick v1.5.0 Release Candidate 1
Date: Thursday, June 11, 2026 at 4:22 PM
To: Gabe Fierro <gtfi...@mines.edu>
Cc: Brick User Forum (Unified Building Metadata Schema) <brick...@googlegroups.com>
Subject: [EXTERNAL] Re: [Brick] Brick v1.5.0 Release Candidate 1
CAUTION: This email originated from outside of the Colorado School of Mines organization. Do not click on links or open attachments unless you recognize the sender and know the
content is safe.
To view this discussion visit
https://groups.google.com/d/msgid/brickschema/CA%2BuLVCKXSypLnOcDc8BMiz-L_EyHyzttp16MoAvCfN8gT9k16w%40mail.gmail.com.
Nauman Rafique
Jul 1, 2026, 2:04:26 AM (9 days ago) Jul 1
to Gabe Fierro, Brick User Forum (Unified Building Metadata Schema)
Hi Gabe,
Welcome back, and thanks for turning these around.
On #788: the definitions read well and close the gap. The four we flagged (controls, isControlledBy, hosts, isHostedBy) all now say what they mean, and the split between hosting a point on the network and controlling equipment is clear.
On the cardinality question: yes, I think the split you describe is the right one, and a separate virtualization relationship would cover our cases. Here is where it comes up for us.
In a liquid cooling loop a single logical point often surfaces through more than one device. A CDU coolant supply temperature is measured by the CDU controller, and the same logical value is re-exposed to the building network through a BACnet/IP gateway that polls that controller over Modbus. On critical loops we also run redundant controller pairs where either controller can expose the same sensor value after failover. So multiple devices can expose one logical point, but in the gateway case there is one authoritative source and the others mirror it. Keeping hostsPoint to a single device plus a separate virtualization relationship models that cleanly, and it maps to something we need directly: in a procedure we have to know which reading is authoritative and which is a mirror, so a step can cross-check the two.
One case I would be careful with is the redundant pair. There is still a current source of truth, but that role moves during failover. The internal reference direction fits the gateway case cleanly, where one object references another. I am less sure how to model a pair where the authoritative object changes over time. How would you handle that in 223, and would the virtualization relationship carry a notion of which side is currently authoritative?
I will not be on Thursday's call, but happy to keep this going by email. Thanks for opening it up.
Nauman
Welcome back, and thanks for turning these around.
On #788: the definitions read well and close the gap. The four we flagged (controls, isControlledBy, hosts, isHostedBy) all now say what they mean, and the split between hosting a point on the network and controlling equipment is clear.
On the cardinality question: yes, I think the split you describe is the right one, and a separate virtualization relationship would cover our cases. Here is where it comes up for us.
In a liquid cooling loop a single logical point often surfaces through more than one device. A CDU coolant supply temperature is measured by the CDU controller, and the same logical value is re-exposed to the building network through a BACnet/IP gateway that polls that controller over Modbus. On critical loops we also run redundant controller pairs where either controller can expose the same sensor value after failover. So multiple devices can expose one logical point, but in the gateway case there is one authoritative source and the others mirror it. Keeping hostsPoint to a single device plus a separate virtualization relationship models that cleanly, and it maps to something we need directly: in a procedure we have to know which reading is authoritative and which is a mirror, so a step can cross-check the two.
One case I would be careful with is the redundant pair. There is still a current source of truth, but that role moves during failover. The internal reference direction fits the gateway case cleanly, where one object references another. I am less sure how to model a pair where the authoritative object changes over time. How would you handle that in 223, and would the virtualization relationship carry a notion of which side is currently authoritative?
I will not be on Thursday's call, but happy to keep this going by email. Thanks for opening it up.
Nauman
Reply all
Reply to author
Forward
0 new messages