It strikes me this is about the difficulty faced when one only has experience of being allowed a single ‘tag’ bucket and the narrowness of analytic vision this creates. Outside the narrow niche of controlled vocabularies, nested tags/keywords is a sticking plaster over the ’ tag-only’ metadata limitation.
As I recall ‘tags’ crept in around because the Web 2.0 hipsters didn’t like the (controlled) keyword approach common at the time. Keywords were for squares, the cool kids were into folksonomies of ‘tags’. Meh, they are actually all just search/indexing terms. Indeed, understanding the latter is key to breaking out of the ‘tag-set’ mentality.
When analysing/annotating your data, what are the strands you need to later recall/revisit? These strands are worth capturing and, if discrete groupings exist, placing in discrete stores (in Tinderbox’s case in attributes). If you started with data from a tags-only app, when arriving in Tinderbox let go of that limitation. You can keep the original tags data (in $Tags - or another attribute of choice), but still tease out the strands with the overall tags into discrete attributes.
Imagine an address book where name, street, zip, etc. were all just tags for a given record. How much easier to use if the zip code is in a $ZipCode attribute, etc. This is an overly simple metaphor but I hope it helps explain the process. So if you have tags like “Organization_United_Nations” and “Organization_DEA” likely you want an $Organization attribute, allowing you to search by organisation and to find ‘United Nations’ as discrete from ‘DEA’, etc…
Just as our tagging styles differ, ‘tags’ is a loosely defined term and thus implemented differently in different apps, even if some sub-groups of apps take a similar approach. In years of migrating data around apps (and from before the dawn of the ‘tag’ approach), really the only thing to bank on in the source data is that you have a list of values. Certainly, a big issue back when keyword hierarchies were popular was that no two vendors used the same method for saving/sharing the hierarchies.
Another thing I’ve seen is note titles used as proxy keywords. Whether you stick with your original imported titles or edit once imported, don’t forget to properly capture the metadata in the titles that isn’t also yet in a tag (attribute!).
Tags are the shallow end of understanding your data; do make use of the extra flexibility Tinderbox offers. Tinderbox isn’t a magic tool that turn your tags into structure, some assembly is required—and rightly so as that way lies greater understanding.
Anyway, I offer the observations above which draw on my own initial experience of Tinderbox and subsequent longterm use in case it helps people getting started.
[edit for typos and easier reading]