#936 Sub-proposal: Choices as Specialization

Brian Frank Mon 19 Jul

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

I have proposed a mechanism to drastically simply the common use case of choices in 935. However, the current complexity stems from the following thorny problem: there are concepts we wish to model which can be narrowed both in the ontology subtype taxonomy and in instances themselves.

These are the specific use cases:

  • plants: produce a phenomenon
  • boilers: product/heat a fluid
  • conduits: convey a phenomenon
  • valves: regulate a fluid
  • pumps: move a fluid
  • tanks: store a substance

The common theme is related to equipment which process a fluid. As with most Haystack problems it boils down to avoiding type explosion. Defining a new fluid type, implicitly means we can have a pipe, valve, pump and/or tank of that fluid.

In programming languages we have a mechanism to solve these use cases elegantly with parameterized types/generics. Generic types are essentially "type templates". For example:

// generic type can be thought of a type pattern
class List<V>

// instances of that generic type
new List<String>
new List<Date>

// so you can imagine...
class Valve<Fluid>
new Valve<ChilledWater>

Those of you who participated in the Haystack 4 WG might remember that we prototyped something like this. But it was too complicated and we abandoned the idea. I'd like to revisit it with a more narrow scope to solve the choice specialization problem.

We already use the of tag as a semi-generics mechanism for list, ref, dict, and grid. For example the definition of the children tag is a list of dicts:

def: ^children
is: ^list
of: ^dict

I'd like to propose using the of tag as a the mechanism to define entity specialization along one dimension:

// current design
def: ^conduit
is: ^equip
conveys: ^phenomenon
---
def: ^pipe
is: ^conduit
conveys: ^fluid
---
def: ^duct
is: ^conduit
conveys: ^air
---
id: @hot-water-pipe
hot
water
pipe
equip

Proposed new design:

// new proposed design
def: ^conduit
of: ^phenomenon
inputs: ^of
outputs: ^of
---
def: ^pipe
is: ^conduit
of: ^fluid
---
def: ^duct
is: ^conduit
of: ^air
---
id: @hot-water-pipe
hot
water
pipe
equip

In the code above we are using of as a type parameter that is restricted to subtypes of the phenomenon. As a type variable it can be used on the right hand side of the inputs and outputs associations. Furthermore we can narrow of in subtypes. For example ducts only convey air and pipes only convey fluid. Just like choices work today, when you encounter an entity type that has an of type with subtypes, you should narrow it instances. Instead of defining steam-pipe, hot-water-pipe, etc we parameterize the of variable in the instance entities.

For the most part this is how choices already work today. The difference:

  1. We are simplifying it to one dimension via the of tag
  2. We are allowing it to be used on the right hand side of associations

Login or Signup to reply.