Add `measures` relationship?

[gtfierro]

We would like to capture the relationship between some sensor and what it is associated with.

We have hasLocation, but this is not the same as knowing what entity a sensor is actually measuring.

We have hasPoint/isPointOf, but this seems to be more about encapsulating points in a single piece of equipment.

I think there's a need for a more generic notion of what a point is measuring, or what its controlling. We already have a controls/isControlledBy, which would be associated with some Command Point.

Just to clarify, it is entirely w/n the realm of possibility that we have sensors not associated with any particular piece of equipment.

Any thoughts?

[kaikreuzer]

Hi @gtfierro! Although this issue is pretty old, I'd like to comment on it.

I think it is pretty important to define a general notion for this. From what I see, you already define according object properties and you have also already a long list of MeasurementProperties defined. I assume they are already an outcome of your idea here?

I cannot find those being used in any examples or documentation, though. Can you provide some information on the status of this concept?

A major question that arises is what kind of impact this has on your tag sets. At the moment, you e.g. define "Temperature_Sensor", but with measurement properties in place, you it would actually suffice to have an instance of type "brick:Sensor" with "hasMeasurement: Temperature".

For processing simply TagSets, it would obviously still be nice to have "Temperature_Sensor" for grasping the semantics easily - but that would mean that one would need to mix a TagSet with type and property information; probably not desired, right?

Would love to hear your ideas about that!

[gtfierro]

Hi @kaikreuzer! Thanks for following up on this issue.

Measurement properties are included within the current Brick release, but we took some care to separate them out from the main files. You can find them in the BrickUse.ttl file (example). I don't think the usage has been very refined, as a lot of the structure is auto-generated. For instance, we'd expect a measurement property such as brick:Average_Temperature to be a subclass of brick:Temperature, but this isn't reflected in the ontology. I think a lot of these discrepancies will be solved by a long-outstanding move towards a new tagset construction method

In terms of how this affects tag sets, we could definitely take the direction of having a Sensor class that has the attribute hasMeasurement: Temperature, but I think its more "Brick-like" to have that be an independent dimension. The Brick ontology largely follows a nominative typing scheme, so the names of the tagsets are important and significant. We have properties attached to those tagsets -- right now these are the "tags" that consist a tagset, and the "measurement properties" that describe its behavior. I like to think of these dimensions as describing the tagset, which could help clarify its usage but also serve to help filter/search through the valid tagsets. So, in this case, we would have something like

mysensor    a    brick:Temperature_Sensor .
brick:Temperature_Sensor    a     brick:TagSet .
brick:Temperature_Sensor    hasTag    brick:Temperature .
brick:Temperature_Sensor    hasTag    brick:Sensor .
brick:Temperature_Sensor    measures    brick:Temperature .

Instances in a Brick model will only have the pointer to the Brick tagset, but the tagset has additional properties that can further refine that definition along certain semantic dimensions, e.g. measurement properties.

This is my current thinking, but it would be great to hear your perspective on it. @jbkoh would you like to weigh in as well?

[kaikreuzer]

Thanks for your response!
So it basically boils down to how your "new tagset construction method" is supposed to look like.
Effectively you are saying that you will construct tagsets that are of the pattern

<subclass of MeasurementProperty>_Sensor

and probably also

<subclass of MeasurementProperty>_Alarm
<subclass of MeasurementProperty>_Command
<subclass of MeasurementProperty>_Setpoint

Btw, why is MeasurementProperty currently a TagSet and not just Tags? And what is the differentiation to Resource TagSets?

While I agree that it is nice to add a single TagSet to an entity to fully describe it, I am not so convinced it is a good idea to define those TagSets as entities within the ontology at all - the involved combinations are almost endless and let the ontology explode. You won't be able to decide what such entities exactly represent (and e.g. provide a proper human-readable description for it) - many combinations will simply be unrealistic and not worth being part of the ontology.

My take is that the TagSets are rather a different (constrained) way to express an entity, i.e. as per your example, if X has the TagSet Temperature_Sensor it simply expresses that:

X   hasTag    brick:Temperature .
X   hasTag    brick:Sensor .
X   measures  brick:Temperature .

I know that your main objective for the TagSets was to reduce the possible combinations of Tags on entitites - but instead of coding your constraints into a TagSet generator, those could be formulated as a convention instead and validation logic could be provided next to it.

[gtfierro]

MeasurementProperty is a TagSet rather than a Tag because it can be compound; e.g. we have Air Temperature, Water Temperature, Outside Air Temperature, etc.

---

You are right that if we're not careful, there's a potential explosion of the ontology. I don't know if you've had the time to give a read through BrickSchema/Brick#36, but it discusses some of these issues, but the short answer is that I think that if we generate the TagSets in a structured way, we can mitigate this "explosion". No matter how those TagSets are generated, we will need some way of pointing to the definition for a particular combination of tags/measures/etc. I would like to put a name and a definition what I would call X if X has the properties you mentioned

X   hasTag    brick:Temperature .
X   hasTag    brick:Sensor .
X   measures  brick:Temperature .

Adopting this structural typing approach forces the user to be familiar with how that system is composed. I think there's value in doing this --- and the structural typing approach definitely has its scaling and discovery benefits --- but ultimately being able to give a name to a type drastically simplifies the queries and expression of the model. Once the structured tag stuff is done, the approach you are describing will also be possible, and it may be used for querying the entities themselves or even just for exploring the large ontology.

Another benefit for having explicit names rather than the structural typing is that occasionally you have situations where the name of the class is greater than the sum of its parts. One of the issues that Haystack has run into is a point that has the oil tag and the heat tag. Does it heat oil? Does it use oil to heat? They had another that was gas heat tags, but it heated up gas rather than using gas to heat.

[kaikreuzer]

Thanks for the hint at BrickSchema/Brick#36, which I wasn't yet aware of - that's a good discussion. And I think it very much reflects what I was writing above ("that would mean that one would need to mix a TagSet with type and property information"), since the Point TagSets might be constructed as

<measurement dimension>_<point class>+<further modifiers>

So while you have class hierarchies for equipment and location, the point TagSets are mixing two hierarchies (the one about measurement properties with the one about points).

MeasurementProperty is a TagSet rather than a Tag because it can be compound

From BrickSchema/Brick#36, I thought to understand that it will always only be a portion of a Point TagSet, but not a TagSet on its own right? But yes, that's my argument above: If we can assume that any Point entity refers to a MeasurementProperty, those could exist as their own (class hierarchy) TagSet and would have to be declared as an additional TagSet besides the Point TagSet - i.e. the current "full" one would be split into two; or rather being kept only as a serialisation format, but not as an ontological entity on its own right.

So in short: As per the title of this issue, I think a Point entity should have a measures property instead of holding the measurement property information in its own entity definition. measures is propably not the best name as it should imho combine measures for sensors/alarms and controls for setpoints/commands, etc. Don't have a good suggestion for a better name though.

[kaikreuzer]

We already have a controls/isControlledBy, which would be associated with some Command Point.

As per my latest comment above: Wouldn't it make much more sense for the controls relation to refer to a MeasurementProperty instead of a Control Point? What's the current use of that relation, does it really make sense?

[gtfierro]

I'm in agreement we should have a measures property on Points; perhaps in addition to having the MeasurementProperty be part of the point's name, but it should also suffice to describe the tagset/class by querying a more generic Point class and attaching the `MeasurementProperty. Ideally, the query engine/ontology should consider the two methods of expression equivalent, and any point should be discoverable/describable using either method.

Regarding the controls relationship: we've used this in the past to identify specific Points that are involved as input/output in a specific control loop, rather than describing what that control loop is doing. The reason for this decision at the time was that it was harder to come up with a taxonomy for what control loops in a building were doing; it quickly devolved into trying to capture the logic of the controller, which was too complex to model in an ontology. So, we just left it at identifying the inputs/outputs for some black box controller. I'm open to revisiting this if there's a call for it