Everywhere I look in the information management profession I see examples of hierarchies in the form of taxonomies and classification schemes being used, relied on in fact, to get users from the general to the specific. And in some ways this is a great way to do that. Hierarchies, in addition to taking us from the general to the specific, offer some other key points. They create relationships between the different levels so that it makes sense why connections were made according to this particular convention. It establishes consistency in the terms selected to describe items.
Common examples of hierarchies in the information management world include the extensive use of records classification schemes and folder structures. Many of the best practices and guidelines instruct us to create records classification schemes as a foundation tool to organize our records. Currently the best practices suggest creating these taxonomies as function based, meaning that the levels should be constructed to closely mirror the activities being performed by an organization that result in records production. One common interpretation yields a taxonomy that looks something like this:
-
Level 1 = Function
-
Level 2 = Activity (Process)
-
Level 3 = Record Class
What’s interesting about doing it this way is that it is creating relationships between the different levels. An activity (or process) is part of a function. The record class is part of the activity (or process). By laying it out in a hierarchy, it provides some basic rules of logic governing the structuring. The hope is that the user understands the rules so that it feels somewhat intuitive and makes sense.
This is similar to the methods we use to create folder structures to store electronic and/or physical records. In the physical world we’re a bit more limited with the applications of our hierarchies, but we can aim to create some by designating areas of our filing systems for a specific type of records or for a specific year, etc. Example:
Section 1 of the filing system is for current year
Section 1 contains 5 bays, each bay = a different portfolio.
Each bay contains 5 shelves, each shelf = folders with different records or subjects related to that particular portfolio
So it would look something like this:
-
Level 1 (Section) = Current Year
-
Level 2 (Bay) = Portfolio name
-
Level 3 (Shelves) = Subject files or Record types
This is maybe how we might think to replicate the folder structure in a shared network drive or repository as well, creating cascading levels with a defined relationship between each one. Or we might think to align our folder structures with our function-based classification scheme and arrange the top level by function.
However, hierarchies only represent one method to go from the general to the specific. Another way to go from the general to the specific is through faceted browsing or filtering with metadata elements. When I search for books at my local public library I narrow my initial search by applying available filters such as language, availability, age range, genre, subject, format, etc. All of these facets are enabling me to focus my search, but none of them exist in a traditional hierarchical structure that is so commonly used in the work world to organize our records and information.
So here’s the question: why are we so married to the idea that a hierarchy is the best way, or sometimes the only way, that we can get from the general to the specific? What about creating something like the library system, or an online retail site, where users can search or browse for their records and information by selecting a series of facets to narrow down the selection? And is it possible to have meaningful metadata that is not part of a hierarchical structure? How will relationships be defined and consistency established between terms?