Sv: Context Sensitive Property Concepts

Dear Joel and co.


Please see below the remarks by Ville Kukkonen (Aalto/Granlund). He was not part of the mailing list when you wrote, so I forwarded your question. He is now on the list, so he should be able to follow the thread from here on.


"Brick indeed appears to encode the context of a data point in the class, which in my opinion is the greatest drawback of the schema. The problem is further accentuated by the fact that names or concepts like “exhaust air” are not exactly unambiguously defined for all contexts.

My planned approach to this is building on our work in FSO [1], and using relationships between the relevant systems/components to annotate the context of a data point. Thus, there are relationships “hasSupplyPoint” and “hasExhaustPoint” or similar, which relate a piece of equipment to a data point. Without using FSO, my approach to modeling a temperature measurement in AHU return side before the return fan could look something like the following:

_:fan
a ex:Fan ,
ex:hasSupplyPoint _:point .

_:point a brick:Air_Temperature, sosa:ObservableProperty .

_:ahu
a ex:AirHandlingUnit ,
ex:hasReturnPoint _:point .

This of course does require new vocabulary. Additionally, I think this will require more detailed modeling of the systems and components, and their relationships, as opposed to the approach taken by Brick.

I didn’t quite understand how the separate graphs were utilized in the original email, but I think that should indeed not be required.

I hope this was useful, and I’m happy to talk more about this theme.

Best,
Ville

[1] https://w3id.org/fso"

________________________________
Fra: Joel J. Bender <jjb5@cornell.edu>
Sendt: 20. januar 2020 18:15:53
Til: public-lbd@w3.org
Emne: Context Sensitive Property Concepts

I have been working on an OWL/SHACL model for ASHRAE 223 [1] which is similar to BACS [2].  It draws on concepts from Brick Schema [3] and BEDES [4] and is similar to SEAS [5], my current effort is to organize the concepts in Brick with SSN/SOSA features of interest and properties.

My puzzler is that the same core property has different labels depending on the context.  For example, there is a fan that has a temperature sensor in an air stream, usually on the discharge side, so [discharge air] is the feature of interest and [discharge air temperature] is the [observable property], the sensor is usually labeled [discharge air temperature sensor].  However, when the fan is a [supply fan] component of an [air handling unit] system the air magically becomes [supply air] if it is discharging into the [space/room/zone] or [return air] if the fan is on the return side.

To keep the concepts separate I have been using a quad store so that "_:x a brick:Discharge_Air_Temperature" and ""_:x a brick:Supply_Air_Temperature" belong to different graphs even though _:x is the same in both cases, and both graphs would contain "_:x a brick:Air_Temperature, sosa:ObservableProperty".  Note that the [discharge air] of an [air handling unit] is often also called [exhaust air].  I'm not convinced this would be appropriate for a "standard" because I would expect that quad stores are already be using named graphs for other things like attaching PROV information to collections of triples.

If you have ideas on some options going forward  I would appreciate them.


Joel
[1] https://www.ashrae.org/news/esociety/ashrae-bacnet-committee-works-with-other-organizations-on-new-standard
[2] http://publica.fraunhofer.de/documents/N-497126.html
[3] https://brickschema.org/
[4] https://bedes.lbl.gov/bedes-online
[5] https://ci.mines-stetienne.fr/seas/index.html