This is based off of my original posting of the TagFS. As I am unable to really get down an dirty with implementing it, I decided to seperate the main consept from the implementation. This idea is that Tags are and should be hierarchical. I wish to show why it is wrong to do away with the hierarchy and to present a much needed change. Another reason this should be seperate is that it can be applied in more places other than just a TagFS.
I have seen decent uses of tags (Gmail, social bookmarking), but they all seem to miss the fundamental aspect of tags, they are in fact hierarchical by nature. When the tag is used the hierarchy is thrown out as though it was only applicable to a directory tree. (Side Note:: I only briefly used Gnowsis, so there is more to it then what I explored). And I am unsure where Vista has taken tagging, but its not where it should be.
The power of the tag lies in its dynamic hierarchical nature. Yes, the very thing that is left out by others is what makes it so great. When something is tagged (in a Tagfs it would be a file) it will likely and should have more then one tag attached to it.
My example of this is with programming and source files. Tag a file foo.java (Programming, Source Code, Java, Foo Project) As you can see I have labeled it from general to specific. Programming can be applied to more then just Source Code or Java, there is more to Source Code then just Java. (When tagging it could be in any order it just makes it easier to discuss). So, the navigation of this structure would be to go /Programming/Source Code/. . . But wait, java isn't always Source Code, it might be a class file.
This might mean that you would want to tag foo.class (Programming, Binary, Java, Foo Project) At which point the navigation can change (dynamic) to /Programming/Java/ (Source Code OR Binary).
The best way to create a tag hierarchy is to implement an AI that would dynamically place where tags should be. This means that the structure has the potential to change and organize itself based on how files are tagged. These changes would become less frequent as more tagged files exist. (User could force rules of course). And shifts would be done gradually (add to "proper" place, signify in old place that it is moving)
Oh, did you think I wanted to forget about directories completely? No, that would be almost as bad as leveling out the hierarchy. These directories aren't file directories, but tag ones. My next example uses music, or was it movies, no no it was games, oh I remember now books.
Tags can easily fit in a linear structure unlike files. I will explain the use of directories through Genre. In a way this is Tagging tags. (Which in turn might be a better method). Genre tags apply to many categories: games, music, movies, books. Some overlap, others not so much (Action, Rock, Drama, Fantacy) They are all a Genre, so they could be placed into a directory called Genre.
There is one problem, the user would have to define what tags fit into the directory, and it would not be able to dynamically change with more tags. So maybe replacing the Directory with a label, then tags could be labeled and change dynamically. But would it be worth it, how many fields can 'action be put under?
The idea of things moving around without your consent is a fairly scary thought. If all these things keep moving how the hell are you supposed to find anything. Really the key to a good hierarchy is to have the most general tag received first, that is the tag with the most things associated with it. So in reality it the move should make it easier to find. Not only that but tags won't only appear in one branch, but multiple branches so there will be many ways to get to the same place.
The other part, is having a predefined 'root' does not limit where you could start navigating the tree, if you know one of the tags you could claim that as a starting point and navigate from there, or list out all your options.