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

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.

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?

We actually built several prototypes using multiple "generic" variables during Haystack 4. It had mixed results. But I don't think using of actually prevents that in the future. Using of just builds on what we already do today for ref/list/grid. I was thinking we would add some tag to of to indicate its special "variable-ness", and that applications would use that instead of hardcoding the of name. But certainly today there is only use cases for one generic variable.

I was thinking we would add some tag to of to indicate its special "variable-ness"

If we're able to retrospectively tag the of tag so the name of is no-longer hardcoded, then I'm happy with that. :)

today there is only use cases for one generic variable.

Maybe for use-cases you're aware of, but if given free-reign I think you'll be surprised at how creative some people can be!

Design seems way easier, +1

Once I got into this, I saw a simpler solution which was to just make these use cases normal choices with the tagOn. But still allow the of tag to select which taxonomy tree should be used:

Here is normal choice where we the subtypes are used to select the options:

def: ^pointFunction
is: ^choice
tagOn: ^point
---
def: ^sensor
is: ^pointFunction
---
def: ^cmd
is: ^pointFunction
---
def: ^sp
is: ^pointFunction

Or we can use the of tag instead of subtyping to reuse some other taxonomy tree:

def: ^pointSubject
is: ^choice
of: ^phenomenon
tagOn: ^point

For the specific use cases of pipes and tanks I coined two new tags:

// replaces the conveys function
def: ^pipeFluid
is: ^choice
of: ^fluid
tagOn: [^pipe, ^valve-actuator, ^pump-motor]

// replaces the stores function
def: ^tankSubstance
is: ^choice
of: ^substance
tagOn: ^tank

I think it worked out quite elegantly and was pretty consistent with the old design. But comments welcome.

See changeset