Conversely, tags are unable to represent parent-child relationships. It doesn’t mean both tags and hierarchies are fundamentally flawed, just that they serve different purposes (with some minor overlap).
The screenshot I posted above comes from home automation software called Premise Home Control (a.k.a. Premise) and it offers both concepts. For example, to create a new location, you right-click the tree-view, wherever you wish to insert the new Location (its term for Area), and then select the Location’s Type (a new ‘Bathroom’ in this screenshot).
I can name it whatever I want (‘Guest_Bathroom’) and its parent-child relationship may be something like
House.Second.Guest_Bathroom but its Type remains ‘Bathroom’. That means that I can turn off all lights in all areas whose Type is ‘Bathroom’ (i.e. the ‘tags’ concept).
The following screenshot shows the Type of an existing bathroom in my house (
The support for both concepts isn’t just for areas but is also used for entities. For example, this screenshot shows an entity called ‘CeilingLight’ in the bathroom (parent-child relationship) and its Type is ‘RecessedLight’.
Because all entities have types, it allows you to, for example, turn on all ‘TableLamp’ entities in a given area (but not any RecessedLight or Sconces or etc).
If I create a new light in that bathroom, I don’t have to create tags such as House, Second, Master, Bathroom. Its placement within the hierarchy takes care of its relationship with respect to locations (and other entities). All I need to do is indicate its Type (i.e. Light > Sconces).