Inference with measures for Classes. about brick

[JoelBender]

Static_Pressure is an observable property of air, so a Building_Static_Pressure_Sensor is a sensor of Static_Pressure associated with a Building. I don't see a Building_Air definition, but it would seem that it would be narrower concept of Air (purposefully avoiding the subclass/superclass concepts).

The "current" building static pressure is an observation made by the sensor, and should probably have some units. In the case of bacnet:AnalogInputObject, the bacnet:units property would come along for the ride.

[jbkoh]

Yeah, measuring Building_Air and Static_Pressure should be the right solution, but in the current implementation most of the measures for Sensors are missing, so I was curious if we should implement everything before the release or associate the Restirctions with rdfs:subClassOf instead of owl:equivalentClassOf. You opinion seems backing the idea to add comprehensive measures relationships. This should be one of the two major fixes we need before the release.

[gtfierro]

I'm working on improving the coverage of measures relationships in #76 (most recent commits have this done for most of the Sensor hierarchy). This includes modelling Building Air and Static Pressure and associating them with the sensor class you mentioned.

I like the idea of trying rdfs:subClassOf instead of owl:equivalentClass. It has the potential of simplifying the reasoning while preserving the semantics we require.

[gtfierro]

I've written a test case to make sure that use of the brick:measures relationship leads to the correct inference of classes in PR #76, which should resolve this issue when it is merged