You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we model water and air systems (HVAC) we typical want to model various thermodynamic sensors, such as temperature, pressure and flow.
BRICK supports such in the brick:Sensor class hierarchy but no equipment to attach to exists.
The ICT_Equipment::SensorEquipment superclass and its subclasses where by definition not thought to be in the water or air systems but rather mounted in spaces.
Hence it would semantically make more sense to add sensor equipments to for instance the HVAC equipments.
Hence we suggest to add brick:Sensor_Equipment (or similar) as a subclassOf brick:HVAC_Equipment
Further hierarchy under would be nice but not necessary for now. If there were to be a hierarchy it would likely encompass different kind of sensor equipments, ie not what it measures (since this is captured by the Sensor::Point) but how it measures somehow. This may be a separate effort with a later release.
Also note that we're not suggesting to remove/deprecate existing ICT sensor equipments. Rather complement.
Bets Peter
The text was updated successfully, but these errors were encountered:
Hi @PeteHart we agreed with this in our last discussion with a couple amendments. I would recommend placing Sensor_Equipment under Equipment, not HVAC EQuipment (you can have lighting sensors, occupancy sensors, etc). What would the hierarchy consist of? As it stands, Sensor Equipment is similar to https://www.w3.org/TR/vocab-ssn/#SOSAPlatform which I think is a good target.
We could rename the current "ICT"-flavored Sensor EQuipment to ICT_Sensor_Equipment or something similar
The reason I suggested the HWAC equipment as super class was that I felt other sensor like lightning, occupancy, etc already exits and may continue to reside under the ICT equipment sensors.
However, specifically for HVAC sensors I have a feeling they don't really have any other utility that being in pipes and ducts in such systems (which very well could be wrong). Any subclasses in this domain would likely be flow, pressure etc.
With that said i thin k it makes sense to have a generic sensor equipment super class hosting all kind of sensors. Then the ICT equipment could become switches and routers etc which is was originally meant for?
@gtfierro
As we model water and air systems (HVAC) we typical want to model various thermodynamic sensors, such as temperature, pressure and flow.
BRICK supports such in the brick:Sensor class hierarchy but no equipment to attach to exists.
The ICT_Equipment::SensorEquipment superclass and its subclasses where by definition not thought to be in the water or air systems but rather mounted in spaces.
Hence it would semantically make more sense to add sensor equipments to for instance the HVAC equipments.
Hence we suggest to add brick:Sensor_Equipment (or similar) as a subclassOf brick:HVAC_Equipment
Further hierarchy under would be nice but not necessary for now. If there were to be a hierarchy it would likely encompass different kind of sensor equipments, ie not what it measures (since this is captured by the Sensor::Point) but how it measures somehow. This may be a separate effort with a later release.
Also note that we're not suggesting to remove/deprecate existing ICT sensor equipments. Rather complement.
Bets Peter
The text was updated successfully, but these errors were encountered: