RE: Context Sensitive Property Concepts

Dear Joel,
Assigning different types to an individual in different named graphs seems normal practice to me, at least in principle. Putting provenance statements in a separate graph is a common pattern that certainly does not preclude other uses of named graphs. In my own practice, we often create layered graphs, in which each layer adds some extra SHACL statements, e.g. for controlling the UI, or adding derived L1 properties (with derived values). Something can be an rdfs:Class (or void:Dataset) in one graph and a sh:NodeShape (or prov:Entity) in another.

So I think the principle is perfectly normal. However, the particular puzzle you are dealing with suggests you better use an extra property relation, as Mads and Ville propose.

There is something I do not fully grasp about the example with the two graphs. It is the same instance of brick:Air_Temperature and sosa:ObservableProperty that occurs in both graphs. Why couldn't it be two different instances, each with a different subtype? Is it because it is really the same equipment and same sensor, only the fan blows on way for some period of time, and then the other way for another period? Best, -j


From: Mads Holten Rasmussen <mhoras@byg.dtu.dk>
Sent: 24 January 2020 08:24
To: Joel J. Bender <jjb5@cornell.edu>; public-lbd@w3.org
Subject: 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<mailto:jjb5@cornell.edu>>
Sendt: 20. januar 2020 18:15:53
Til: public-lbd@w3.org<mailto: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