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