Thanks, @edmay .
I’m glad that you think a strategy could work that maps Rooms to Space with a Zone being made up of several Rooms.
However, I can see that the implementation that we have in mind is a little different from what you were thinking since we were thinking that Honeybee Room.zone should be implemented very similarly to how Room.story is implemented. You can see here in honeybee-schema and here in the honeybee-core Room docs that Room.story is just the id/name of the story on which the Room is a part of. It is not an object with its own properties and therefore would not have .properties that could be extended.
I realize that this runs a little bit counter to how most other BEM interfaces have implemented Stories and Zones, which tend to be full objects with their own properties and Spaces nested underneath them. It’s not that I think this approach is wrong but it really limits your ability to use the schema to construct/deconstruct/edit models. You are essentially forced to have a full zoning setup in mind when you start model-building so that you first lay out your Zones and Stories on which to put your Rooms/Spaces. This also makes it tougher to do things like delete/add a Room from the Model or change a Room from one Zone to another.
You’re essentially forced to walk though the whole hierarchy every time that you want to make a change. So the schema becomes more of a “full building energy documentation” tool to be used after you have already finished the design process rather than a “building energy creation/translation/experimentation” tool that you use throughout design.
If the zone is only the text property assigned to a Room, it becomes very easy if you want to change the zone that a Room is apart of (just change the text). It’s also easy to edit the model geometry this way since deleting all of the Rooms in a Zone automatically deletes that Zone without the need to delete some other object in the hierarchy. And, because we can always fall back on the idea that one Room gets a single Zone with the name of the Room whenever a Room.zone is not assigned, this enables people to build new model geometry without having to know the zoning layout first.
If all of those arguments aren’t enough of a reason, I may invoke the “flat is better than nested” axiom of the Zen of Python. It’s not that nesting things never has a purpose but, if you have an opportunity to avoid nesting, it will usually pay off to keep things flat.
I’ll try to think more about whether there is some elegant way that we might be able to give you something similar to Zone .properties. We will be developing a set of rules to resolve things like what happens when two Rooms have different Setpoints (probably the more stringent ones will govern the full Zone). Maybe the methods that we implement to resolve this will give you something that you can use on your end.