The difference between tags and hierarchies is this: if you don't know what you're looking for, hierarchy can guide you.
In both cases, the hierarchy is inherently positional, affords locality, and guides both the reader and the document by asserting that locality inherently.
If you're in a place, then that place gives nearness or farness from objects.
If you're an object, you're in some location inherently.
Tags, in this sense, are placeless, and don't provide attributes of or guidance to nearness. At least not without some additional mechanism.
For example my audio player does just that, e.g. `%artist%/(%year%) %album%/%tracknumber%.%title%`
Progressively "drilling down" is super low-hanging fruit with regards to tag-based organization, it's seriously neglected.
I also agree that the lack of drill-down on tag-based organisation ... kills about 99.9996% of the value. It's sufficiently valuable that you'd expect this to be part of basic implementation libraries by now.
A tagging system is flat by default.
Though that makes rendering the tree somewhat easier...
1. genre 2. artist 3. album 4. title
or
1. genre 3. album 4. title
or just
1. title
or even less useful ones like
1. title 2. album
Magic?
Note that in the case of artist -> album -> title, there is in fact an actual explicit hierarchy that's being reconstructed. In the case of conceptual tags ... any such structure is far less evidently defined.
song_1: genre_1, album_1, title_1
song_2: genre_2, album_2, title_2
song_3: genre_1, album_3, title_3
genre_1
|-> title_1
|-> title_3
genre_2
|-> title_2
Edit: In fact since the player allows for multi-value tags, items can even appear multiple times in the tree, e.g. when a song has multiple artists.
In the artist -> album -> song case, to repeat myself, the recognised hierarchy reflects an actual one that's present in the original artefacts. (This needn't always be the case: multiple artists might play the same song, the same song might be on multiple albums, song title itself does not necessarily imply either artist or album. Though in the simple case it does.)
In the genre/title example, how would it be clear that title is a subclass of genre rather than the other way 'round?
And what of fusion or crossover works --- is DNA's remix of "Tom's Diner" folk-rock, a capella, or trip-hop?
It's not clear and it can be the other way around. You can also ask the player to list the genre as a subclass of titles. It'll be just a less useful representation, because the first level usually holds almost as much entries as there are songs, since titles are often unique.
> And what of fusion or crossover works --- is DNA's remix of "Tom's Diner" folk-rock, a capella, or trip-hop?
It can be all of those, like I said you can have multi-value tags. Then this song would show up three times in a tree with a genre level.
Or is there no presumption of specificity / generality at all, and just an association between tags.
If the latter, it's not clear to me how the tags are directed, other than in the sense of an RDF triple's subject, predicate, and object.
No, all tags are handled in the same way by the player. It's completely up to the user to specify the hierarchy in which tags can be browsed. The player then builds the tree dynamically.
> If the latter, it's not clear to me how the tags are directed, other than in the sense of an RDF triple's subject, predicate, and object.
I'm kind of lost here, since I'm failing to see where the confusion comes from. Also, I'm not a native English speaker, so I might be missing something or my explanations just aren't well enough. So let's try this again with some simple pseudo code. Tags here are nothing but key:value pairs associated to audio files. So if the user asks for the tree structure like key_3/key_4/key_1 the player can simply do the following:
keys = {key_3, key_4, key_1};
tree = new Tree;
for song in songs {
subtree = tree
for key in keys {
// key here might be something like "Artist"
// value here might be something like "Iron Maiden"
value = song.get_key_value(key)
if !subtree.has_node(value) {
// if the subtree doesn't already have the "Iron Maiden" node in the current level, add it
subtree.insert_node_sorted(value)
}
// use the "Iron Maiden" node as the new subtree
subtree = subtree.get_node(value)
}
subtree.insert_song_sorted(song)
}The number of tags should be more or less similar to the number of non-leaf nodes in a hierarchy, or else you aren't capturing the same information. Any tag that applies to more than half of the files is probably useless. On my blog, the tags "blog" and "technology" are definitely useless. That's fewer than 250 entries and already it has cruft.
Were people consistent when they added tags? Does your system suggest tags automatically? Is this actually a full-text search minus stop words? Is there a librarian who cleans up after you and merges tags that have the same meanings? Would the full-text search be more useful than tags?
I use ... a lot of tags.
(I couldn't tell you without downloading my entire archive and doing some magick to count them, as Pocket won't give me a count itself.)
Pocket lags by well over a minute in even starting to populate my tags list after I enter some text into the field. (Chrome/Android, using an external keyboard.) It similarly takes several minutes to scroll through the tag list using either the Web client or the Android app.
You could argue that this is a piss-poor UI/UX issue, and I'd agree. It's piss-poor UI/UX issue that Pocket have failed to address since I first reported it over five years ago.
https://old.reddit.com/r/dredmorbius/comments/5x2sfx/pocket_...
If you'd like another list that has rapid-scannability issues, there's the Library of Congress Subject Headings:
These are publicly available. In 27 PDF files, corresponding to printed books ranging from 12 to 842 pages in length: