just started with Haystack and have been reading existing posts with great interest.
The posts about spaces / zones etc have been particularly interesting as they remind of an issue I have come across twice before in previous companies.
In both cases we had systems that were applying particular data constructs / models in telecoms systems where you would want to model equipment, configuration settings, people, locations and other things.
In both cases, initial attempts defined specific levels and associations. E.g. a building could have zones that contain spaces that contain rooms. In every case these a priori models eventually broke down for one of three reasons:
a) a project introduced a level of abstraction not thought of when the model was put together (e.g. everything was fine until we saw a building that needs wings as well as zones, spaces and rooms)
b) different parts of the same project used terms differently (e.g. what was a zone in one building was very different to a zone in another)
c) the client changed something (e.g. three rooms were combined into one - or a new department was created that spread across parts of different spaces)
What then normally happened was that some poor engineer would have to figure out how to shoe-horn reality into the data model that had been created in increasingly imaginative ways.
At both companies the same solution was eventually found which was simply to allow things to be created that link to zero or many other things. A way to think about this (but not entirely accurate) is to think of them as arbitrary groups. So you could have a group that is Room 101, that is linked to group First Floor and also linked to group Executive Offices. Equipment in the room can then be linked to Room 101 group plus maybe the HVAC zone 3 group.
I think(!) this is similar if not identical to the type of thing that Brian has suggested on some posts where you have a hierarchical linkage of non-specific elements. In this way rooms / floors / zones / spaces / departments / systems / projects / upgrades can all be modeled and - importantly - changed as required.
Anyway... I thought I would throw something (hopefully) significant in on my first post - so how about a abstract Group / GroupRef tag?
Brian FrankMon 18 Feb 2013
As you correctly pointed out there is tons of ways to semantically "group" things: rooms, floors, zones, spaces, etc.
But I personally think figuring out specific modeling of precise concepts like room, space, etc is what we need to do instead of resorting to a catch-all concept like group. But I think if we can a proper definition/model for something like space/zones that should encompass specific use cases like rooms and floors.
Departments, systems, etc are kind of a different dimension to model equipment (and should be tackled in their own right)
William Box Fri 15 Feb 2013
Hi,
just started with Haystack and have been reading existing posts with great interest.
The posts about spaces / zones etc have been particularly interesting as they remind of an issue I have come across twice before in previous companies.
In both cases we had systems that were applying particular data constructs / models in telecoms systems where you would want to model equipment, configuration settings, people, locations and other things.
In both cases, initial attempts defined specific levels and associations. E.g. a building could have zones that contain spaces that contain rooms. In every case these
a priorimodels eventually broke down for one of three reasons:a) a project introduced a level of abstraction not thought of when the model was put together (e.g. everything was fine until we saw a building that needs
wingsas well as zones, spaces and rooms)b) different parts of the same project used terms differently (e.g. what was a
zonein one building was very different to azonein another)c) the client changed something (e.g. three rooms were combined into one - or a new department was created that spread across parts of different spaces)
What then normally happened was that some poor engineer would have to figure out how to shoe-horn reality into the data model that had been created in increasingly imaginative ways.
At both companies the same solution was eventually found which was simply to allow things to be created that link to zero or many other things. A way to think about this (but not entirely accurate) is to think of them as arbitrary
groups. So you could have a group that isRoom 101, that is linked to groupFirst Floorand also linked to groupExecutive Offices. Equipment in the room can then be linked toRoom 101group plus maybe theHVAC zone 3group.I think(!) this is similar if not identical to the type of thing that Brian has suggested on some posts where you have a hierarchical linkage of non-specific elements. In this way rooms / floors / zones / spaces / departments / systems / projects / upgrades can all be modeled and - importantly - changed as required.
Anyway... I thought I would throw something (hopefully) significant in on my first post - so how about a abstract
Group/GroupReftag?Brian Frank Mon 18 Feb 2013
As you correctly pointed out there is tons of ways to semantically "group" things: rooms, floors, zones, spaces, etc.
But I personally think figuring out specific modeling of precise concepts like room, space, etc is what we need to do instead of resorting to a catch-all concept like group. But I think if we can a proper definition/model for something like space/zones that should encompass specific use cases like rooms and floors.
Departments, systems, etc are kind of a different dimension to model equipment (and should be tackled in their own right)