Systems and Relationships

[Tim Jagenberg]

Hei Gabe,

the 'Relationships memo' does not mention any 'https://brickschema.org/schema/1.1/Brick#System' types and none of the relationships in the ontology has a domain or range of 'System'.
How are systems planned to be used in relation the other ontology elements?

Greetings

Tim

[Gabe Fierro]

Hi Tim:

A Brick System is a group of equipment/components organized and assembled for a specific purpose. We are still discussing how/if we'd like to break this down further (modeling specific loops, for example), but for now you should System like Equipment in terms of relationships. This is to say that we'd expect Brick models to contain statements like System hasPart Equipment and System hasPoint Point. Systems connect to each other through their components (equipment), though we may revisit this in the future.

I was waiting until we finish some of our development conversations before I update the documentation to reflect how System should be used --- are there particular use cases that you are trying to solve?

Best,

Gabe

--
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.

[jonas...@gmail.com]

Does this mean that Systems relates to locations indirectly by its components?

[Gabe Fierro]

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.

[Oskar Nilsson]

Hi!

A question about the usage of collections in the example here:

https://github.com/BrickSchema/docs/blob/5a826f456d31d9bb8aba3bbea60ac398f410591d/modeling/collections.md

Maybe I got my SPARQL wrong but I can’t infer that the loops are members of the HVAC system. If I add that explicitly, would it be wrong to instead make AHU and VAV’s be members of the air loops (and implicit members of the HVAC system)? The reason for asking is that I’m thinking of how collections could be used to improve user experience when exploring a brick model in a GUI but I’m not clear of what the best practice is.

/Oskar

[Gabe Fierro]

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.

[Oskar Nilsson]

Hi Gabe,

Thanks, this makes sense and I like the idea of hierarchical decomposition of building subsystems.

Let’s say we have a brick model containing a site and several buildings. If I want to explore the model and see what systems a particular building has - should I then make a query asking for systems with equipment/points located in that building (and ignore child systems)? Or should I explicitly associate a building with its top systems when modeling?

/Oskar

[Gabe Fierro]

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.