#935 Sub-proposal: Choices as Exclusive Markers

Brian Frank Mon 19 Jul

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

The common use for choices is to model an exclusive set of markers. This pattern is used extensively in the ontology:

  • sensor, cmd, sp
  • duct discharge, return, exhaust, mixed, etc
  • pipe leaving, entering, bypass, etc
  • hotWaterHeating, steamHeating, naturalGasHeating, etc
  • chilledWaterCooling, dxCooling, etc

We currently have 18 choices which use this pattern.

The way choices work is fairly complicated to handle the use case of modeling fluid equip functions in tank, pump, valve, and pipe. This specific use case is examined in the separate sub-proposal 936.

I propose to simplify choice as a simple exclusive set of marker tags defined via subtyping.

// current design
def: ^point
pointFunction: ^pointFunctionType
---
def: ^pointFunction
is: ^choice
of: ^pointFunctionType
---
def: ^pointFunctionType
is: ^marker
---
def: ^sensor
is: ^pointFunctionType
---
def: ^cmd
is: ^pointFunctionType
---
def: ^sp
is: ^pointFunctionType

Proposed new design:

// proposed new design
def: ^pointFunction
is: ^choice
tagOn: ^point
---
def: ^sensor
is: ^pointFunction
---
def: ^cmd
is: ^pointFunction
---
def: ^sp
is: ^pointFunction

Key aspects of the new design:

  1. Choice subtypes from maker now instead of symbol
  2. This collapses all the pointFunction vs pointFunctionType twin defs into a single def
  3. Choices are registered using tagOn just like any other tag and no longer added a tag on the entity def itself
  4. Choice subtype hierarchies must be flat. A subtype of choice must have no subtypes of its own

Login or Signup to reply.