Ever hear anyone asking a data team to use a spreadsheet in place of a graph database? Who would? So why are taxonomy teams asked to use them? Taxonomists haven’t made taxonomy understandable to non-experts. On the other hand, I’ve overheard teenagers talk about graphs on the subway, thanks to Facebook and Google.
Explaining taxonomy is as hard as doing taxonomy
I’ve sat through many presentations, consulting and vendor sales pitches, and no one’s doing it particularly well. Including myself. The basic premise of abstraction’s unclear. And the way taxonomy gets consumed is explained in theory because you almost have to build end-to-end to prototype it.
In my experience, most people have a specific use case and need for taxonomy, and haven’t been exposed past it. Everyone comes to it with huge assumptions about its very nature, making the first job of taxonomy to answer the question, “What do you mean by taxonomy?” Fitting, isn’t it, nerds?
Around the business, depending on which team you ask, taxonomy is understood as navigation menus, content tags, folders, CSV files or classes of code objects. Barely scratching the surface here, it makes sense that people would believe it’s a spreadsheet.
The situation with spreadsheets
There’s definitely a place for spreadsheets in taxonomy work. Use it for generating system input/output or reports, testing, having initial discussions about categories, brainstorming terms or documenting navigation for the presentation layer—typically volatile display labels and a limited, shallow hierarchy. Layered and mapped into an experience, navigation’s the tip of the taxonomy iceberg.
The spreadsheet is merely an artifact of your core taxonomy. The logic contained in it is only slightly better than a word cloud. That’s about it.
In our taxonomy, we’re capturing relationships between broader and narrower preferred terms along with alternate, hidden and related terms, definitions, scope notes as well as language versions. For both one- and two-way mappings and between schemas. Relationships of this multiplicity simply can’t be documented in a spreadsheet even if you made a mad attempt.
Try documenting taxonomy in a spreadsheet and your brain can’t retain the concepts, enforce rules or prevent circular logic, except if you’re Morgen Kimbrell, a unicorn on my team who defined Intuit’s QuickBooks product taxonomy of 700 nodes using Google Sheets.
Once you get something in a spreadsheet, it can be interpreted differently by every system and uploaded with errors and junk. Spreadsheets make everything manual, tedious, and nearly impossible to update or scale across systems. Still, many companies use spreadsheets for taxonomy. Intuit did before we implemented a taxonomy management tool.
Does your taxonomy need something else?
Obviously not every situation requires specialized software and services. A spreadsheet might suit the task at hand. Instead of letting everyone assume that’s what’s needed and resourced to work with, provoke a better discussion:
- What do you need your content and data to do? How does taxonomy enable it?
- Do you intend to update the taxonomy? How often and how much?
- Are you evolving to more complex and custom relationships like poly-hierarchy and ontology?
- Will the taxonomy be consumed by more than one system? If so, re-used standardly?
- Do you need to pull pieces from the taxonomy dynamically, filtering it for consumption?
- Do you need to associate tags or descriptive metadata?
- Will many people across your company be suggesting vocabulary?
- Do you need a workflow for reviewing changes and keeping a trail of updates?
When you take on chunky taxonomy work, a spreadsheet’s not going to be your pick. Telling that to your stakeholders and management isn’t an easy thing to explain. Until you do, the work will continue to be underestimated. Or worse, problematic for your customers and business.