The role of Brick

[J Li]

Hi guys!

I am new to Brick, I got the assignment to use Brick Schema. I am trying to understand the role of Brick in the processes from device installation to data analysis. 

I read your papers, tutorials, presentations, and the conversations involving Brick's role in the Group, also tried py-brickschema, mortar, scrabble, and plastering. Then, I went to see Google's DigitalBuildingPlatform and Microsoft's RealEstateCore. In the end, I came up with this picture:

It seems to me that Brick is a unified framework for organizing data. The role of Brick is not obvious when setting up devices, it's mainly providing a standard name. Its existence gets stronger after data collection. Data analysis can be seen as Application. Data Query can be seen as Session. Graph can be regarded as Presentation.

I am not sure if I get the core of Brick, correct me if I'm wrong.

Thanks.

[Gabe Fierro]

Hi Ji:

Welcome to the Brick community!

I would be careful in trying to squeeze everything into the ancient OSI model: in your diagram above you are comparing a networking protocol stack (BACnet), an ontology (Brick) and a platform architecture (GDB) which all interact and overlap in different ways. BACnet describes how one reads from and talks to BACnet objects (including what the bits look like "on the wire"): this includes data types, units, names, addresses, etc. It is an encoding of information; however, it is *just* the encoding of information. BACnet only has the "network" view of a building: it doesn't know which are physical devices or equipment vs logical devices or equipment, where they are, what they do, how they behave, what they are connected to, etc. That said, BACnet is great for pulling data out of all the sensors, alarms, commands, setpoints, etc that are in a building.

Brick is an ontology that defines the concepts and relationships and data model for contextualizing the data that comes from a building. Where BACnet would say "this data point has address X, units Y and current value Z and comes from controller C", Brick provides the additional information "this data point is a Supply Air Temperature Sensor, it is in VAV box X which is downstream of AHU Y and which feeds HVAC Zone Z containing rooms 1 2 and 3. The Data point can be found at database D with a primary key of P and units U". I don't think the OSI layers make sense here.

Brick is designed to enable data-driven applications in buildings. At this point in time, it does not have an obvious role in setting devices up, though this is definitely an area I'm interested in. I do think that there are some interesting opportunities for creating a Brick model when devices are installed (this is one of the directions that ASHRAE 223P is looking --- RDF data could come delivered on a device when you buy it).

The platform is how to provide data collection, metadata + data management, and APIs and data access for applications. GDB is one view; Mortar is another; Brick-server is yet another

Hope that helps!

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/b4b52fbe-d5fc-4bb0-8397-4edc32d67885n%40googlegroups.com.

[J Li]

Thanks, Gabe,

Thanks for explaining, when you mention "it does not have an obvious role in setting devices up", I remembered the hasTimeseriesId in the documentation example. 

:sensor1 a brick:Temperature_Sensor ; 

brick:hasUnit unit:DEG_F ; 

brick:timeseries [ 

brick:hasTimeseriesId "8f541ba4-c437-43ba-ba1d-5c946583fe54" ; 

brick:storedAt :database ; ] ; .

How to make sure the temperature sensor's sending data is consistent with the hasTimeseriesId in the Brick model?

Thanks.

[Gabe Fierro]

The brick:timeseries property is simply a way of representing a foreign key relationship between the Brick model and the timeseries database.

It is up to the tooling, database, ingester, registration, or whatever mechanism or component that makes sense in a particular deployment to ensure that the timeseries identifier is consistent and correct.

For example, in the Mortar platform, the user allocates a UUID for each data stream and uses that UUID to insert into the database. Mortar then makes sure that the correct UUID is inserted into the Brick model for that sensor.

Best,

Gabe

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/769482da-9f4e-4207-a87b-7dd54511d6b9n%40googlegroups.com.