--
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 on the web visit https://groups.google.com/d/msgid/brickschema/a59c45c0-f6d8-4769-af11-32f81c0727ddn%40googlegroups.com.
Whether or not Systems contain locations is something we are
currently discussing. I'm in the middle of moving between states
so I haven't had the time to dig in recently, but you can find
notes on the discussions and the draft implementation here:
https://github.com/BrickSchema/Brick/pull/269.
The intent is for Systems to serve as collections of related components that may or may not be actually connected to one another. Loops would be subsets of collections that consist of connected components. I think it makes sense to include locations as well as equipment and possibly even points in those collections. What do you think?
Gabe
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/a869edbe-d467-49a9-8bac-0e2c66bb27cen%40googlegroups.com.
Hi Oskar:
The inference rules are not currently in Brick, so the documentation is a little misleading. I couldn't quite decide on the conditions for having those components inferred to be members of a particular loop or HVAC system (some of it is obvious, other parts are not). You can definitely add it explicitly though.
The intent of the collection design is to group equipment/points/locations into loops, and then to group loops and other equipment/points/locations into systems. One could then ask what kinds of systems are in a Brick model, and then what loops or other components make up that system, and then what components make up any loops. It is a hierarchical decomposition of building subsystems, analogous to how a building can be divided up into floors, zones and then rooms (or rooms and then zones, depending on the building and subsystem).
I hope that helps somewhat, but please respond with further questions! Let me know what would be helpful and I can add it to the documentation: another example, examples of SPARQL queries to traverse system structures, etc..
Best,
Gabe
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/dea672e3-7940-4b1c-b494-eb06fa044cfbn%40googlegroups.com.
Hi Oskar:
We haven't thought through the relationship between the Systems and the Buildings themselves; I suppose "hasPart" would be appropriate there but we haven't encoded any validation definitions for the proper way of achieving that. The easiest way so far is to just have a single graph represent a single building, and then query that graph for the systems it knows about and its components.
Best,
Gabe
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/296efe80-3657-4243-9049-41de86fd4dc1n%40googlegroups.com.