#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

Steve Eynon Sat 18 Sep

Hi, this is good and the analogy with programming generics works well.

What I am not so keen on though, is the "special" case with regard to the of tag. Can we simply allow any tag to be referenced on the right hand side?

The example then becomes:

def    : ^conduit
conveys: ^phenomenon
inputs : ^conveys
outputs: ^conveys
---
def    : ^pipe
is     : ^conduit
conveys: ^fluid

It would then allow for multiple "generics", such as:

def     : ^machine
consumes: ^phenomenon
produces: ^phenomenon
inputs  : ^consumes
outputs : ^produces
---
def     : ^thing
is      : ^machine
consumes: ^elec
produces: ^water

If, however, a special syntax is required to reference tags in the def, then I would still prefer that over a special of tag.

def    : ^conduit
conveys: ^phenomenon
inputs : #conveys
outputs: #conveys
---
def    : ^pipe
is     : ^conduit
conveys: ^fluid

To re-iterate, my main dis-content is perhaps with too much emphasis on "special cases" or "exceptions to the rule"; as in the of tag being a special case that means you can do xyz. I feel this is a slippery slope that can quickly lead to a "non-standard" standard.

Login or Signup to reply.