RE: Context Sensitive Property Concepts

Hi Joel,

Thanks for the clarification.

I've been delving into "Ontology Driven Information Modelling" lately (see [1], there is more to explore) and I think this method for evaluating modelling options might offer some interesting takes on the matter.



There are classes that refer to rigid kinds, and there are those that are not. Person is a rigid kind, teacher is non-rigid (more specifically, a role, which is a phased-sortal). John is a person in all possible worlds because personhood bestows identity. John is not a teacher in all possible worlds, and even is he is one in this world, he is temporarily so, during a phase of his existence. All this is not about OWL, but about "real-world semantics", i.e. the logical consistency of a model. A specific topic in this line of thought is the modelling of "mass terms"  like air or wine [2].



From this perspective, modelling exhaust air as a subclass of air is absolutely fine. From a more practical OWL-perspective though people sometimes argue that a subclass should only be defined if there are properties that hae that subclass as domain (excluding the superclass). That line of reasoning suggest using a property-value pair other than rdfs:subClassOf. I think both styles are okay. In the particular case you are dealing with, I think I would go for a specific relation other that subclassification:



> Select readings of any sensor S that measures quantities of air that has the function of supply air wrt an AHU of type X

> Select readings of any sensor S that measures quantities of air that has the function of discharge air wrt an AHU of type Y



If this is the preferred style of querying, it seems natural to model "that has the function of" as something different from rdfs:subClassOf.



Interesting subject, thanks for sharing, -j







[1] https://ris.utwente.nl/ws/portalfiles/portal/6042428/thesis_Guizzardi.pdf

[2] (if the picture is lost, see the UML-diagram in [1] on p. 180)

[cid:image002.jpg@01D5DB3B.C93B2E70]



-----Original Message-----
From: Joel J. Bender <jjb5@cornell.edu>
Sent: 25 January 2020 02:50
To: Jan Voskuil <jan.voskuil@taxonic.com>; public-lbd@w3.org
Subject: 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