As I have recently (March 4, 06) come to the realization of the great
potential there is in tagging, I come up with the concept of the TagFS. A lot
of the content that use to be on this page has moved and so I would suggest
first reading A look at a Tag Hierarchy before
continuing here. I know I'm not the first and therefore have done some research
to find what other people have done. Here are some links that I have found.
TagFS - Tag Semantics for Hierarchical File Systems
Logic File System <http://aryx.kicks-ass.org/~pad/wiki/wiki-LFS/doku.php>
Delicious Style File Tagging <http://blueslugs.com/wordpress/index.php/archives/2005/07/12/tag1-delicious-style-file-tagging/>
Universitat Kablenz Landau <http://www.uni-koblenz.de/FB4/Institutes/IFI/AGStaab/Research/TagFS/>
Student Project "Gnowsis" <http://www.gnowsis.org/>
Tagfs Perl Script <http://blueslugs.com/wordpress/index.php/archives/2005/07/12/tag1-delicious-style-file-tagging/>
Apple's Spotlight <http://www.apple.com/macosx/features/spotlight/>
Though I realize this is not exactly a new concept, I have taken the idea even further than those in my research (the first link being the closest). (I am still, btw, looking for more implementations of a tagfs, not bookmarking stuff though). Infact the ideas I cover here could probably be implemented ontop of tagsistant. German readers may be interested in taking a look at Ideen für ein Tag-Dateisystem. No I don't know German, I just used google translator and found that he is describing the same concept I am.
Let me present an example for this, think music and the corresponding media libraries. A song isn't just by Yadi Yada, but it is of type Genre and from the album Yadi Yadder. Files are the same way in many respects, they can exist in multiple categories. *nix solves this by using symlinks, windows shortcuts. Tagging solves this by attaching another tag to the file. Symlinks and shortcuts point to a file, if the file is removed the link is brock but the shortcut stays, now you must delete all the dead links.
Tagfs Simulation This is only java source code and is a gui, it will need to be compiled to work.
This is an attempt at a proof of concept. The idea is to show that browsing files via tags is a viable option. This is in alpha and as it is only a sim, it is likely to stay that way. This means there are many things wrong with it and need overlooked. (CTRL lets you select multiple tags)
The browsing techniques will change as little as possible. To change tags on the command line 'cd' would still be used. It is likely that tags from different places may need to be combined; this can be done giving two or more aguments to 'cd' ($cd /tag1/tag2/ /tag3/). Another problem might be that you have a large hierarchy to get to one tag (/tag1/tag2/tag3/tag4/) browsing to it can be a of work so one could use the comand ($cd /*/tag4) relative would still work too ($cd */tag4).
With the use of '*' there are two ways to handle it. One is that we filter for just that tag; the other is to filter the hierarchy to that tag. I think the defult should be the former and an option could be used for the latter. If there is more than one path (as there would likely be) one would pass a second argument for the choice of where the path varies.
The hierarch will be structured as: (please read the conclusion first as
this is likely to change)
$ cd /tag1/tag2 /tag1/tag2$ cd tag3/ /tag4/ /tag1/tag2/tag3 /tag4$ cd /
$ cd */tag3 tag3$ cd -h tag
#pressing tab twice here tag1/ tag2/ tag4/ tag5/
#tags 1, 2, & 5 are part of 3. #As we are not in a "sub tag" tag4 #shows up because it is in the root. tag3$ cd -h tag4 tag3 tag4$ cd /*/
#pressing tab twice here #Shows all tags tag3 tag4$ cd /*/
$ ls tag1/ tag4/#And files
$ cd -h */tag5#2(tab) tag1/ tag4/ $ cd -h */tag5 tag1/ /tag1/tag2/tag3/tag5$ cd /*/tag3
#tag3 is alread filtered /tag1/tag2/tag3/tag5$ cd . /tag4 /tag1/tag2/tag3/tag5 /tag4$ cd ..#2(tab) tag1/ tag4/ /tag1/tag2/tag3/tag5 /tag4$ cd .. tag1 /tag1/tag2/tag3 /tag4$
So in conclusion browsing can get complicated. Lukily multi tag browsing should be kept down to a minimum. Though now I just thought about, sometimes adding tags would be used to broaden rather than narrow a list of files. I'm thinking '&' would be used that it is including both, but how to navigated I will think about. Suggestions are welcome.
First off, I have it laid out with 4 list boxes. The first three should be thought of as a tree. When you click on one, the contents are displayed in the next panel rather than below like they should be. The last panel is the file list.
The use of Genre. This is not really a tag but the sim thinks it is, this means that no files will be displayed because it can't find any files with the Genre tag. What Genre is, is a "folder" for tags. You can't really have a file that is a Genre, but you can have tags (Action, Rock, Adventure, Romance, Action) that are.
You will also notice that Genre/Game will give you the Genre option in the 3rd panel. This really shouldn't happen.
Ultimately I would like to see a Tagfs at the core of an operating system. I'm talking about the structure system on the harddrive itself. However, this would be a huge leap for most people and I have no idea how to work at that level of programming. So I have an idea for a more medial proposal
As I fully believe that the full power of a Tag file system would only be unleashed when built at the core, I know it will be difficult to get the needed backing starting there. So I have created the concept of the emulated TagFS. This is still far beyond my current capabilities, but I don't see any reason it couldn't be done.
Let me do a quick explination of these projects:
The TagFS Emu would be installed somewhere and the user would specify it's database directory. The TagFS Emu when run with no arguments would be a file manager, prompt or gui, and the user could then add tagged files to it storing them somewhere in the database directory (there is likely to be sub directories as filenames my collide otherwise). But to give an even greater feel for TagFS the programs that are installed on the system would need to also use TagFS Emu. In linux it will be easier to force all progam installation and runs to go through TagFS Emu, but in windows this is not possible and having the user run the progams installer through the Emu would be easiest, and I believe easier then that suggested for linux. (If the explination still leave questions, please contact me about it).
To keep my current plans current. As it is likely that when my current plans change ie. I'm not doing anything on the project, I am not likely to update that here. Keep an eye on the "Page Last Modified" tag at the bottom.
Language: I currently plan on using D as the language for creating this. Why? I think D needs a good backing, I like the language, and I think D can do it. I realize that this will make it more difficult to bring in fellow programmers, which I will really need, but when this thing begins to form and if it takes off... they will come. The D community is nice and helpful too so I should be able to get a nice backing.
First Step: I have the simulation, but it contains nothing that would be used in the Emulator. So my first step is to create an AI that will categorize the tags into a decent hierarchy. Why is this the first step? The AI will reduce the need to have the user define the tag structure, we have already added the burden of having the user tag their files they should at least get some automation from it. It will give greater incentive to use the TagFS.
Even with its great power, there are still things that need looked into, things that should be considered before a TagFS could be considered as a feasible replacement to the current system.
Efficiency: How quickly can files be found. Does the overhead of looking through all the files with the tag become to great with large amounts of files leaving the current system more efficient? I'm thinking not, do I know how to do it? No, but google searches through millions of documents quickly, in fact they may be working on this and not telling anyone.