#957 Attributes Proposal

Leroy Simms Wed 10 Nov

The Haystack Labs WG is proposing a new first class object type called an Attribute or attr. The purpose of an attr would be to provide a method for storing infrequently changing information about another entity using standard Haystack tags to identify that information. An attrOf tag would be used in conjunction with the attr tag to reference the object the information pertains to.

An example would be documenting the rated heating capacity of a package rooftop unit.

{equip ahu rtu id:@ahu naturalGasHeating}
  {attr attrOf:@ahu heat energy max rated output val: 425kBTU}

Another example is the design max occupancy of a space.

{space room navName: “Rm 221 Meeting Rm C” area: 295ft² id:@rm221}
  {attr attrOf: @rm221 occupancy max design val: 21} 

This format will allow all the standard tags to be leveraged in describing the information the attr stores; however, as use cases evolve we anticipate the need for additional tags to be developed as well, such as design and rated tags used in the above examples.

design- Marker tag indicating the information represents the intended design, such as information from documentation such as engineered drawings.

rated- Marker tag indicating the information represents a manufacturer’s ratings, such as information from an equipment data plate or cut sheet.

Defs

def: ^attr,
doc: Object to describe and store information that rarely changes.
is: ^entity
---
def: ^attrOf
doc: Reference to the entity an ‘attr’ pertains to. 
is:  ^ref
tagOn: ^attr
of: ^entity
---
def: ^design
doc: Marker tag indicating the information represents the intended design, such as 
information from documentation such as engineered drawings.
is: ^marker
tagOn: [^attr, ^point]
---
def: ^rated
doc: Marker tag indicating the information represents a manufacturer’s ratings, 
such as information from an equipment data plate or cut sheet.
is: ^marker
tagOn: [^attr, ^point]

We welcome feedback on this new concept, if accepted the next step will be creating protos for typical use cases.

Brian Frank Wed 10 Nov

Thanks for posting this Leroy! This has been an ongoing effort within the Labs WG for several months, so its great to see it finally become an official proposal to the wider community.

I just want to add my take on the importance of this direction. For a long time we have struggled how to model equipment data which doesn't cleanly fit the point model. Its been tempting to coin a bunch of new tags you might stick on an equip such as heatEnergyMaxRatedOutput. But you can see how that is not really extensible, nor future proof. In the Haystack 4 WG we discussed at length using nested dicts in entities too. But for lots of reasons keeping entities flat like you would in a RDBMS or spreadsheet is more aligned with how Haystack is used. So with this direction we double down on two core Haystack principles: keeping entities flat and combining marker tags for consistent terminology.

I like to think of attributes as a list of marker tags + value attached to an entity via the attrOf tag. Its really a compound tag name with a value. I'm actually imagining that we will provide some special UI support for this in our product.

The next phase of this proposal is to develop a list of children prototypes which are formalized on equip and spaces to drive tooling and validation.

Login or Signup to reply.