Re: Context Sensitive Property Concepts

Jan,

> 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.

Thank you for that, I'm at least not doing something complete off base.  That is different than doing something right, however!

> 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?

I'm trying to line up the B.11 IP68 Smart Sensor example with what I think I want to express and I'm running into a few mental disconnects.

First, <Air> to me is a class of all kinds of different air rather than a specific feature of interest shown in the example. For example, outside air, supply air, mixed air, return air, exhaust air, and discharge air.  The first five are terms related to air within an Air Handling Unit and are all different.  In a 100% outside air system (where there no mixing of air that comes back from a space or zone) the "outside air" is on the input side of the fan and the air on the output side of the fan is called "supply air."  However, with respect to the fan, the air on the output side is called "discharge air".  There is only one sensor in the air stream, so there is only one set of observations, but the feature of interest is called two different things.  One set of analysis queries is going to be asking asking relative to the fan and a different set is going to be looking at the entire system.

It would be convenient if "supply air" was always kind of "discharge air", but there may be a reheat sub-system downstream, so the supply air of the system is actually the air after the reheat coil.  Similarly, the air leaving an exhaust fan is exhaust air, which is pretty close to being coincident with another kind of discharge air.

> 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.

Absolutely.  There is an ASHRAE Guideline (36 I think or maybe some other document) that outlines approximately 50 different typologies of BAS components; fans, heating and cooling coils, dampers, etc., and any one specific concept like "mixed air" is only going to be appropriate for some subset of them.

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

Probably not, I have just been experimenting with using graphs as layers.  So "_x: a ex:Air_Temperature" is in one graph, "_:x a ex:Discharge_Air_Temperature" is in another graph, and "_:x a ex:Supply_Air_Temperature" is in yet another graph.  The first one comes from some core ontology, the second from the manufacturer of the fan, and the third is from the installer than is putting the fan into a system.

Joel

Received on Saturday, 25 January 2020 01:49:55 UTC