Brick v1.4 RC1- Real Estate Core & Brick ICT_Equipment type

[Sarah MacDougall]

Hi,

In the Brick v1.4 RC1, there are two classes for ICT_Equipment: a rec:ICTEquipment and brick:ICT_Equipment.  The rec:ICTEquipment is a subclass of brick:Equipment, so in the Brick tree you see both.  This is confusing.  I thought that only Real Estate core spaces would be added to the Brick schema and equipment would remain Brick for the Real Estate/Brick alignment. 

What is the reasoning behind the same class in two different namespaces? 

And why is the REC class a subclass of Brick:Equipment?

Thanks,

Sarah

[ga...@brickschema.org]

Hi Sarah!

I talked a bit with the RealEstateCore folks over email, and we are going to move all of the ICT equipment into the Brick ICT equipment tree. We will "keep" the REC ICT classes around for backwards compatibility, but they will be marked as deprecated and the SHACL rules will add the correct Brick classes (just like we've done for the Brick location classes being replaced with REC location classes). I'll see if I can get this done for the 1.4.0 release, but we may kick some of this to a 1.4.1 release in order to deal with some issues like whether or not SensorEquipment belongs solely under ICT.

Hope that helps!

Best,

Gabe

[Oskar Nilsson]

Hi,

A few questions:

“REC ICT classes around for backwards compatibility” - will they also be subclass of brick:Equipment?

“SHACL rules will add the correct Brick classes (just like we've done for the Brick location classes being replaced with REC location classes)” – Is this in place? If I make a brick:Room inference does not seem to give me a rec:Room

“SensorEquipment belongs solely under ICT”, this could need some clarification before release. For a user it seems ICT is a broad term covering both IT and OT, looking at the description and that it contains “ModbusController”.

Thanks

Oskar

[Gabriel Fierro]

(realized my response didn’t go to the forum as well, so duplicating here)

 

HI Oskar:

 

Yes, they will continue to be a subclass of brick:Equipment so the class tree can look like this: Brick:Equipment -> Brick:ICT_Equipment -> Brick:Sensor_Equipment, etc . Currently, there are both IT and OT equipment under the ICT tree. In our last discussion with the REC folks, we decided a good first step to take for the 1.4 release is to make sure that we standardize the vocabulary of terms (i.e. creating the Brick version of the REC ICT classes), and then, in a future point release we will decide how we want to divide things up between IT and OT equipment. This would not change the class, only the subclass structure. How does that sound?

 

The SHACL rules for inferring the correct classes should be in place. Please make sure you are using the Brick nightly version (https://github.com/BrickSchema/Brick/releases/download/nightly/Brick.ttl). You can see an example input file here and some example code for how to conduct the inference here. If you are still having trouble getting that working, please do open an issue with a minimal example and I can help debug. My plan is to try and create a free web service that does inference for you, so you don’t need to deal with tooling/flags/config/etc, but I haven’t gotten around to that yet

 

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/5874882c-3d08-4ffc-aade-d2867ea084e6n%40googlegroups.com.

[Oskar Nilsson]

Thanks Gabe!

Yes, that makes sense. If brick:Controller is introduced, it would be good to have an example of how to use it, e.g. is a point pointOf both the controller and an AHU? Maybe one could incorporate a brick:Controller in the Terminal units doc example

About the SHACL problem, it seems the reason was that GraphDB by Ontotext does not support sh:construct

/Oskar