I've been thinking of pretty much the same thing ever since I got a Fujitsu Scansnap scanner to digitize all the documents I have. Tagging is often more appropriate to categorize my documents than hierarchical folders. Spotlight comments may make up for this although they are a bit cumbersome. Right now I only enter a comment for files I know I want to find back.
I have also considered Evernote to handle my document storage (and always accessible, including search) accompanied with its tagging features but I found it too slow and plain directories combined with Spotlight worked better for me. These directories are in my Dropbox folder so I can access them anywhere, some hierarchies are applied for Bank statements etc. but most files are in one big folder. It's a pity there is no good searching in documents from the Dropbox site.
The original goal of the Namesys filesystem (what eventually became ReiserFS) was a similar attempt to replace fixed hierarchies with a form of tagging. While the original paper is no longer accessible, I found a copy here: http://www.dmi.me.uk/blog/wp-content/uploads/2007/11/reiser-...
It seems like you could easily build a file browser like this on top of the file system. That way you preserve operating system hierarchies while getting all the benefits the article talks about. If you kept a database of tags mapped to files, you could keep every file in the same folder, without suffering from linear search of the directory.
But really I think the author just needs to discover 'locate'...
Yup! The question was: how might we move to a tag-based infrastructure while preserving our current interface, so that all of our existing applications and File/Open dialogs would still work.
I've thought about this a little. The 3 options I could think of, along with their issues:
1. Using an OS's comments/metadata field to store tags and include them in a desktop-search program -- the comments/metadata field is not compatible between operating systems and can be lost while copying files between filesystems or operating systems, so this is not a robust solution. And currently only OS X supports comments/metadata field for all file types.
2. Using a central database that does all the file-to-tag association -- this may be 'less universal' or robust than #1; to be cross-platform this requires someone to write a new program that plugs into a given OS and runs constantly monitoring files in case you move or rename them.
3. Storing the tags in the filename itself -- this will give you long, ugly filenames, but should be the most robust because all of the modern OS's and filesystems support 256 character filenames (usually including the path) which gives plenty of room for a number of tags separated by some kind of delimiter character e.g. filename###tag1#tag2#tag3.ext . This would need just a simple tag-management program to help you tag files (and can function as a nice file explorer as well, like http://www.nudgenudge.eu and its clone http://lunarfrog.com/taggedfrog) which does not need to be constantly running, and could use whatever desktop-search program to use the files.
Therefore at the moment I think #3 would be the most robust and versatile solution. Then someone just has to make a frontend for file renaming and tag-database storage/rebuilding from filenames/viewing...
I love this idea but plain tags are simply not enough. I still have a need for hierarchy. If I can have tags like "programming/ruby" and "school/2008-fall/ecology" be organized like mini-filesystems I would be completely sold.
What's wrong with the traditional folder full of symlinks? This article doesn't talk about symbolic links at all, and they would solve all the "problems" discussed here.
This article doesn't talk about symbolic links at all, and they would solve all the "problems" discussed here.
The only problem symlinks can address would that of having files available under multiple locations. But that's still strictly hierarchical and bound to become a maintenance nightmare soon (just think about file renames).
Tag based filesystems are indeed an interesting idea and a somewhat logical next step from the traditional hierarchical fs + desktop search tandem that is commonplace now.
If you were going to do it like this, hard links would make a better option. And in a tag based file system, the actual on-filesystem "filename" isn't as important as the path, er list of tags.
This would end up being a maintenance nightmare for different reason, though. You'd end up with two dirs, for example work/projectX and projectX/work, with some files in one and some files in another. Strict hierarchies don't map to tags.
A while back I wrote a Fuse filesystem for Mac (http://code.google.com/p/xtagfs/) that does exactly what the blog proposes. The fs just provides the directory structure on top of an existing filesystem and the files are symlinks to the actual files on the filesystem.
I have also considered Evernote to handle my document storage (and always accessible, including search) accompanied with its tagging features but I found it too slow and plain directories combined with Spotlight worked better for me. These directories are in my Dropbox folder so I can access them anywhere, some hierarchies are applied for Bank statements etc. but most files are in one big folder. It's a pity there is no good searching in documents from the Dropbox site.