Those are improvements over free-form tags and I especially like the namespaces for attribute/field names, that's clever. The enterprise software my company mak

Those are improvements over free-form tags and I especially like the namespaces for attribute/field names, that's clever. The enterprise software my company makes has decent support for defining and applying structured tags like business terms and attribute values to the data objects our customers manage, and our users do make use of those when filtering and searching. But (in my experience) many people still seem to gravitate towards storing and navigating objects hierarchically. I can think of a few possible reasons: First, some people intuitively think of a data element as having a location in an information space. That is, they seem to intuitively remember "where" something is by piggy-backing on spatial memory in a way that tags don't seem to trigger. Second, navigating a hierarchy involves a sequence of constrained choices, like a wizard. Having a sequence of decisions can be especially helpful for novices. It also generally takes a predictable number of steps to locate an item which can be preferable to something that is faster on average but has slow edge cases. Third, at each level of the hierarchy you can often display all of the options meaning we can rely on recognition over recall[1]. (You could constrain yourself to hierarchical tags and use hierarchy-like positional language such as "object is in baz" at which point I'd consider it a hierarchy.) Of course relying on tags has plenty of upsides -- typically faster, better mental model for overlapping sets -- and large-scale data storage systems need both. But at the end of the day they don't seem to be a replacement for hierarchical systems for most people. [1] https://www.nngroup.com/articles/recognition-and-recall/ https://www.nngroup.com/articles/recognition-and-recall/