#938 Sub-proposal: Filter Inference Operator

Brian Frank Mon 19 Jul

This is a sub-proposal of the broader 940 Haystack 4 proposal.

The current docHaystack::Relationships chapter includes a strawman proposal for how to query relationships. In this sub-proposal we tweak the syntax and tie up a few loose ends.

First lets examine the common use cases:

The overwhelming use case of relationship queries is looking up specific points for an equipment. For example a visualization or analytic on an AHU might lookup the fan enable cmd like this:

discharge and fan and enable and cmd and equipRef==@ahu

I would venture to guess that this pattern is used for 90% of all Haystack queries. The problem is that it doesn't handle varying levels of detail in the model. Haystack 4 allows an instance model to be any of the following:

ahu / enable-point
ahu / discharge-duct / enable-point
ahu / discharge-fan-equip / enable-point
ahu / discharge-duct / discharge-fan-equip / enable-point

In the first case we have a simple instance model where the AHU models the fan enable command point as a direct child. In the last case we have a very detailed model where the duct and fan are modeled as first class entities. And we have valid models between the two. We require a filter syntax so that applications can correctly resolve the point on any four of these instance models.

I propose a new operator to the filter syntax with the following patterns:

name?
name? ^symbol
name? @ref
name? ^symbol @ref

For most the part the behavior is as described in the strawman proposal. However the syntax is slightly modified so that the name and symbol aren't combined like a conjunct. With that syntax we can query for child points as follows:

// query from above using inference operator
discharge and fan and enable and cmd and containedBy? @ahu

// same thing but little more explicit that we expect ahu
// be an equip and not some other entity type like a space
discharge and fan and enable and cmd and containedBy? ^equip @ahu

// query all the points contained recursively by the equip
point and containedBy? ^equip @ahu

// query all entities which contain the given point
contains? @point

Note that per the existing proposal a filter engine would take into account if a relationship has transitive and/or reciprocalOf defined.

Containment is by far the most important and most queried relationship. Next most important is flows including the flow of electricity, air, and fluids with thermal energy. We are capturing these relationships using a suite of tags such as elecRef, airRef, hotWaterRef, chilledWaterRef, etc.

Per the separate sub-proposal 937, we propose to rename the flow relationships as inputsFrom and outputsTo. That allows queries such as:

// query all equip which inputs hot water from the given plant 
// (all downstream equip)
equip and inputsFrom? ^hot-water @hwp

// query the AHU which outputs air to the given VAV
ahu and outputsTo? ^air @vav

Like containment these relationships are transitive so can traverse any number of levels of elecRef, airRef, etc.

The same behavior of the inference operator will also allow use of is? to query supertypes:

// query anything that subtypes from airTerminalUnit
?is ^airTerminalUnit

Login or Signup to reply.