Anyone who has been involved with the Haystack 4 journey knows the thorniest issue has been how far to explode the point types into first class definitions. The philosophy up until recently has been to keep the point taxonomy simple and shallow. Instead we have used prototypes as a way to explode point types as templates instead of first class definitions. Despite the allure of creating a well known identifier for every single "point type", we have avoided it up to this point for lack of a good use case. But now we have that use case....
Cory Mosiman's WG 837 has been extremely busy and actively developing several new directions for Haystack. Perhaps one of the most important problem areas this group has been exploring is validation of Haystack data. It has become clear over the last few months that there is no getting around coining an identifier for every single point type. We need that well known identifier to map to RDF classes and to use as an anchor for validation rules.
So I'm now proposing to revisit this design decision. Specifically what is proposed:
Creating new first class conjuncts as base point types for things like air-sensor, air-temp-sensor, etc
Exploding the combinations into new first class conjunct definitions based on a manual curation process
Replacing prototypes and just having the children tag reference a list of symbols
To take a specific example for common point types used in air side systems, we would create the following new definitions
----------------------------------------------------------
def: ^air-point
is: ^point
doc: "Point which senses or controls a measurement of air"
----------------------------------------------------------
def: ^air-sensor
is: ^air-point
doc: "Sensor for a measurement of air"
----------------------------------------------------------
def: ^air-sp
is: ^air-point
doc: "Setpoint for the control of air"
----------------------------------------------------------
def: ^air-temp-sensor
is: ^air-sensor
doc: "Sensor which measures the drybulb temperature of air"
----------------------------------------------------------
def: ^air-temp-sp
is: ^air-sp
doc: "Setpoint for the control of drybulb temperature of air"
----------------------------------------------------------
def: ^discharge-air-temp-sensor
is: ^air-temp-sensor
doc: "Drybulb temperature sensor for air in discharge duct"
----------------------------------------------------------
def: ^discharge-air-temp-sp
is: ^air-temp-sp
doc: "Drybulb temperature setpoint for air in discharge duct"
----------------------------------------------------------
def: ^return-air-temp-sensor
is: ^air-temp-sensor
doc: "Drybulb temperature sensor for air in return duct"
----------------------------------------------------------
def: ^return-air-temp-sp
is: ^air-temp-sp
doc: "Drybulb temperature setpoint for air in return duct"
----------------------------------------------------------
And you can imagine exploding that for different duct sections, pressure, flow, dampers, etc. And then doing the same for hot-water, chilled-water, and steam pipes, etc. While we plan to manually curate only the point types typically seen in the wild, the point explosion would roughly follow the existing prototypes. We currently have around 600 prototypes, so this would add at least that many new first class defs.
As first class defs, all of these new conjuncts would also map to first class RDF classes which makes them useful for other data science technologies (WG 837 is currently evaluating leveraging SHACL as a potential validation technology).
With this new library of conjuncts, there is really no more need for prototypes. Instead the children tag would just be a list of symbols to other equip or point types:
// today prototypes are just example dicts
def: ^ahu
children: [
{thermostat equip},
{discharge duct equip},
{exhaust duct equip},
...]
// proposed
def: ^ahu
children: [
^thermostat,
^discharge-duct,
^exhaust-duct,
...]
We are looking on feedback to see what the wider community thinks about this direction.
Joel BenderWed 3 Mar 2021
I believe this is critical step in mapping this content to the Semantic Web and I'm looking forward to seeing it progress. There is room for both types of tags, the prototype version and the conjunct version, and maybe there are some inference engine rules or classification techniques that can help with the migration.
Sean StackhouseThu 4 Mar 2021
Hey Brian,
This is a great issue to tackle. We've been using an identifier for each point we see for a number of years now, to help with implementations, and certainly for our machine learning, and more recently for validating analytics. Making each equip/point as a conjunct seems like a good way to both create a unique mapping, while leveraging the tags already present.
For the children tag - would you create a lot of overlap for equipment that could have similar children? Ex. A single zone serving AHU vs a VAV zone serving would both have discharge style points. Or would those both fall under the equipment of "discharge-duct".
Mike MelilloThu 11 Mar 2021
This looks great, the validation note especially hits home. Seems like it would lend itself to proving out a deployment's completeness, not to mention a defined structure for implementing with other systems on a more specific level.
Stephen FrankFri 12 Mar 2021
I'll support this. We already have to explode point types to make a BAS naming and tagging standard for our own internal use. The main challenge might be making the documentation navigable.
Brian FrankTue 13 Apr 2021
An update on this effort: it's a sisyphean task with no hope of success. After working with several different domain experts and with their point lists, there is no clear way to decide what belongs and does not belong as a first class def (RDF class).
There is some value in the level of explosion that types things such as air-temp-sensor because it might be convenient to enumerate some documentation at this level. However, once you get beyond that into discharge-air-temp-sensor or hotDeck-discharge-air-temp-sensor it becomes fairly pointless boilerplate. And looking at specific vendor's equipment point lists it's clear that there is a need for a huge amount of one-offs to fully model.
So instead, the new plan is to double down on the protos direction. Prototypes provide a huge amount of flexibility to model point lists as just an instance templates. The most important feature protos provide is the ability for macro expansion using the childrenFlatten mechanism. This really simplifies the ontology source and keeps it DRY. For example, all someone has to do in a new piece of equipment is to create a new pipe proto and everything gets expanded automatically.
Doubling down on the protos direction involves several new efforts:
1. We will add protos as an output format in the distribution for the next build (protos.csv, protos.json, etc).
2. We are working to compare the protos against some of the extensive point lists that people in the community have developed already (if you have a point list you wish to evaluate please let us know). This effort will likely generate several new tags/prototypes we are missing.
3. I'm actually thinking that validating instance model points against the protos might be the best compromise towards pragmatic validation techniques. It would likely generate some false positives, but if you have points in an instance model for equipment in the ontology which doesn't map to a child proto then very likely your points aren't tagged correctly. I'm going to explore building a simple command line tool to try it out. If you want to work with me to try it out let me know
Brian Frank Wed 3 Mar 2021
Anyone who has been involved with the Haystack 4 journey knows the thorniest issue has been how far to explode the point types into first class definitions. The philosophy up until recently has been to keep the point taxonomy simple and shallow. Instead we have used prototypes as a way to explode point types as templates instead of first class definitions. Despite the allure of creating a well known identifier for every single "point type", we have avoided it up to this point for lack of a good use case. But now we have that use case....
Cory Mosiman's WG 837 has been extremely busy and actively developing several new directions for Haystack. Perhaps one of the most important problem areas this group has been exploring is validation of Haystack data. It has become clear over the last few months that there is no getting around coining an identifier for every single point type. We need that well known identifier to map to RDF classes and to use as an anchor for validation rules.
So I'm now proposing to revisit this design decision. Specifically what is proposed:
childrentag reference a list of symbolsTo take a specific example for common point types used in air side systems, we would create the following new definitions
And you can imagine exploding that for different duct sections, pressure, flow, dampers, etc. And then doing the same for hot-water, chilled-water, and steam pipes, etc. While we plan to manually curate only the point types typically seen in the wild, the point explosion would roughly follow the existing prototypes. We currently have around 600 prototypes, so this would add at least that many new first class defs.
As first class defs, all of these new conjuncts would also map to first class RDF classes which makes them useful for other data science technologies (WG 837 is currently evaluating leveraging SHACL as a potential validation technology).
With this new library of conjuncts, there is really no more need for prototypes. Instead the children tag would just be a list of symbols to other equip or point types:
// today prototypes are just example dicts def: ^ahu children: [ {thermostat equip}, {discharge duct equip}, {exhaust duct equip}, ...] // proposed def: ^ahu children: [ ^thermostat, ^discharge-duct, ^exhaust-duct, ...]We are looking on feedback to see what the wider community thinks about this direction.
Joel Bender Wed 3 Mar 2021
I believe this is critical step in mapping this content to the Semantic Web and I'm looking forward to seeing it progress. There is room for both types of tags, the prototype version and the conjunct version, and maybe there are some inference engine rules or classification techniques that can help with the migration.
Sean Stackhouse Thu 4 Mar 2021
Hey Brian,
This is a great issue to tackle. We've been using an identifier for each point we see for a number of years now, to help with implementations, and certainly for our machine learning, and more recently for validating analytics. Making each equip/point as a conjunct seems like a good way to both create a unique mapping, while leveraging the tags already present.
For the children tag - would you create a lot of overlap for equipment that could have similar children? Ex. A single zone serving AHU vs a VAV zone serving would both have discharge style points. Or would those both fall under the equipment of "discharge-duct".
Mike Melillo Thu 11 Mar 2021
This looks great, the validation note especially hits home. Seems like it would lend itself to proving out a deployment's completeness, not to mention a defined structure for implementing with other systems on a more specific level.
Stephen Frank Fri 12 Mar 2021
I'll support this. We already have to explode point types to make a BAS naming and tagging standard for our own internal use. The main challenge might be making the documentation navigable.
Brian Frank Tue 13 Apr 2021
An update on this effort: it's a sisyphean task with no hope of success. After working with several different domain experts and with their point lists, there is no clear way to decide what belongs and does not belong as a first class def (RDF class).
There is some value in the level of explosion that types things such as
air-temp-sensorbecause it might be convenient to enumerate some documentation at this level. However, once you get beyond that intodischarge-air-temp-sensororhotDeck-discharge-air-temp-sensorit becomes fairly pointless boilerplate. And looking at specific vendor's equipment point lists it's clear that there is a need for a huge amount of one-offs to fully model.So instead, the new plan is to double down on the protos direction. Prototypes provide a huge amount of flexibility to model point lists as just an instance templates. The most important feature protos provide is the ability for macro expansion using the childrenFlatten mechanism. This really simplifies the ontology source and keeps it DRY. For example, all someone has to do in a new piece of equipment is to create a new pipe proto and everything gets expanded automatically.
Doubling down on the protos direction involves several new efforts:
1. We will add protos as an output format in the distribution for the next build (protos.csv, protos.json, etc).
2. We are working to compare the protos against some of the extensive point lists that people in the community have developed already (if you have a point list you wish to evaluate please let us know). This effort will likely generate several new tags/prototypes we are missing.
3. I'm actually thinking that validating instance model points against the protos might be the best compromise towards pragmatic validation techniques. It would likely generate some false positives, but if you have points in an instance model for equipment in the ontology which doesn't map to a child proto then very likely your points aren't tagged correctly. I'm going to explore building a simple command line tool to try it out. If you want to work with me to try it out let me know