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

The current path we are using requires coining three defs every time you want to create a flow relationships. For example:

• hotWaterRef
• hot-water-output
• hot-water-input

This pattern leads to lots of boiler plate definitions. And furthermore it doesn't actually work today unless we also coin a first class hot-water-tank, hot-water-valve, hot-water-pump, etc.

Instead, I propose that inputs and outputs just become associations as part of the ontology. But with that change, we no longer have a single symbol that identifies the referent type of a ref tag. So I propose to replace the of tag (which is a symbol value) with the refTo tag with a filter string value.

// old design
def: ^hotWaterRef
is: ^ref
of: ^hot-water-output

// new design
def: ^hotWaterRef
is: ^ref
refTo: "outputs? ^hot-water"

We will discuss the actual syntax above in a separate sub-proposal 938. Putting it all together:

// current design
def: ^hotWaterRef
is: ^ref
of: ^hot-water-output
tagOn: ^hot-water-input
inputs: ^hot-water
----
def: ^hot-water-input
is: ^input
----
def: ^hot-water-output
is: ^output
----
def: ^hotWaterHeating
is: [^heatingProcessType, ^hot-water-input]

Proposed new design:

// proposed design
def: ^hotWaterRef
is: ^ref
refTo: "outputs? ^hot-water"
tagOn: ^hotWaterHeating
inputsFrom: ^hot-water
----
def: ^hotWaterHeating
is: ^heatingProcess 

Couple aspects to note:

1. We are using inputs/outputs on the entity level to replace the foo-input and foo-output pattern
2. So we use inputsFrom and outputsTo now as our relationship terms

Hi, the new design is certainly a lot less verbose and cuts down on a lot of boiler-plate. However, I am not keen on the use of "filter expressions" in the tag definition.

It seems too open ended and effectively shifts any associated warnings from mis-typed tags in the filter expressions to the runtime. I feel that where possible, defs should be absolute, giving typos no room for manouver!

If the proposed filter expression always follows the same simple template, could it not be broken down to something like:

def       : ^hotWaterRef
is        : ^ref
refToTag  : ^outputs
refToType : ^hot-water
tagOn     : ^hotWaterHeating
inputsFrom: ^hot-water

If the proposed filter expression always follows the same simple template, could it not be broken down to something like:

I don't fully follow your suggested proposal. Are you suggesting that instead of an arbitrary filter that we coin a suite of new tags with some predefined semantics to deal with the fluid input/output case?

Are you suggesting we coin a suite of new tags with some predefined semantics to deal with the fluid input/output case?

Yes.

I have many fears of opening up the use of filter expressions in tag definitions. It seems fraught with potential complications and misuse; both for users defining tags, and for my fellow software implementers.

If fluid input/output is the de-facto use-case that can be solved with the proposed refTo: "X? ^Y" syntax then to replace it, we only need a means to define X and Y.

I feel that allowing filter expressions in tag definitions is akin to opening up Pandora's Box; so I do think it's beneficial to explore other possible options - before it is too late!