I've heard of this concept of 'set-based' filesystems (although with different terminology), and I think it's brilliant. And not just for documents either. Generally speaking, websites have moved away from storing data in a hierarchical matter (e.g. old-school Internet directories), and on to flat, tag-oriented categorization (e.g. delicious) because of the abundance of information to categorize. Hierarchies do not scale and are difficult to change, whereas free-form categorization do not suffer from this.

Personal systems have more files on them than ever before, and fitting them to hierarchies that were invented decades ago can be tricky. These issues have been abated for now with things like OS X's Spotlight and Win7's Libraries, but my suspicion is that set-based filesystems would be far simpler than the current paradigm.

A good example off the top of my head is resolving what command-line executables are available. In most operating systems, this is done by setting a PATH variable with a list of directories that contain the executables. While this is trivial for the type of people on HN, it is far from for your average user. Instead, command-line executables could be given a specific tag, and the command-line would be able to execute any application that has that tag.

Now, whether set-based filesystems could replace hierarchical ones is a different question. Such a filesystem would diverge so greatly from current assumptions that people might be too aversive to change. It wouldn't be the first time; I think Plan 9 was light years ahead in so many respects, but it never took off because it was such a radical departure.

That's what I'm thinking too. However, those are assumptions (which I share). I am thinking maybe it would be interesting to see this simulated in the web environment and get feedback on that - web file system.

I started playing with tags on Aleveo for that reason, maybe I should take it further on a separate test project. It makes a big difference using it and thinking how it would be used.

Also, I am not sure what would be best for executables but how are those currently seen - as having an "+x". Having an executable tag is not much different. That also means, tags are a bit "smarter" than the regular ones seen on the web.

I am mostly thrilled by the ability to see the relations of files and folders to others. Those are not folders anymore as "storage units" but "meanings".

Also currently a file can exists only in one place. Having symlinks is cruft in my opinion, compensating for the need of multiple context presence of data. Symlink is a separate file, a pointer different than the original. Windows is excluded completely :) I think file can be in several places depending on the need. After all this is not the physical world.

> Instead, command-line executables could be given a specific tag, and the command-line would be able to execute any application that has that tag.

FWIW, plan9 allows you to control which portions of the filesystem are mounted into the visible namespace of a specific process.

Contrived but possible:

src/share/test.cpp share/src/test.cpp

Also certain implicit build systems, rely on the hierarchy to know what is parent, and what is child. You lose that with sets.

I still think it's cool idea, but not for all of your documents...

Besides how would you deal with sharing, inheriting security attributes, etc?

If I have

share/test/something.cpp and share is shared to everyone, would

test/share/something-else.cpp got shared too the same way as the first one?

Good points.

but that form of structuring has been imposed by the nature of directories/files. I am not sure what the right solution would be for that case, perhaps internal tags for a set, but that would make things complicated.

In the nature of sets, maybe this could be done: "Source Code", "Shared With XYZ", "Application1"

Sharing could be defined on the set, "Shared With XYZ" is a tag that when defined could have the permissions etc. When a file is "placed in it", it is automatically shared.

We need to get detached from hierarchical thinking to see the possibilities, which is difficult as it is all present.

Maybe some sort of namespacing on tags would fix that; ie. so that your 'conf' tag for a software project doesn't conflict with the system 'conf' tag, which may have a different set of permissions.

In practice, you would probably have different filesystem tables, so that system:conf+share/filename would be distinct from projects:conf+share/filename. The meaning of the same tag may be different in different contexts.

They could be partitioned by department, so (for example) searching through math research wouldn't have to search the biology department's archives as well.

This would allow for defining the context of the search, so that would be a benefit, wouldn't it? Although I am focusing on personal computing, distributed fits too?

Naturally.

You might be interested in the filesystem research associated with plan9. :)