Hi all, and especially thanks to Matthew, Mike and Alexis for the valuable feedback!
We certainly all agree on the power of organizing things in hierarchies. We learned that it is vast superior to a flat collection of stuff. We all learned to do that the only way offered to us. And as I myself wrote: humans are very capable when it comes adaptation to such requests. But I think we also agree that this does not mean automatically, that a single, structured tree hierarchy (yes, a single, different volumes align in to a singe tree) is necessarily the best way there can be. I have the impression you did not really try to wrap your mind around my suggestion. The main reason for this obviously is my very limited way of expressing my approach: indeed my "battle cry" (I like that expression, thanks) calls for killing file hierarchies. Which certainly might be miss leading. So let's take a closer look at what I mean by that and why this certainly does *not* mean that I want to kill hierarchies. In contrary. A file hierarchy in a traditional sense means the logical placement of files in a strict tree. There are exceptions, links and mounts, but we still think of it as a tree. All current operating systems, and therefore all relevant file systems, follow that paradigm. There are actually two aspects involved here: the tree structure and the placement of items. I have nothing against the structure, not even against placement as such, in contrary, that is exactly what I suggested. I have something against the dictatorship of a single hierarchy which is what we currently have. That is what collides with our requirements. Because it is an artificial limitation enforced by limited implementations. In my post I suggested the usage of two organizational principles: hierarchies (plural!) and relationships (for example expressed along an ontology). Organizing items in a structure is a human habit, I agree. And it makes sense, it is an easy means of finding things again afterwards, especially because it allows to find things we forgot existed. I never suggested the removal of the structure to be replaced by a flat mass and a tag cloud with a search feature. That would not work. And I agree that all those tag cloud approaches once en vogue in the net can only play a supporting role, not more. Instead I suggested strict, hierarchical tag structures to be used. I was inspired by the power of that approach when really diving into the organization of my picture collection using the Digikam application. Digikam offers not only the usual tagging system, but it allows hierarchical tags. Here implemented in a free form (which causes issues, I suggest otherwise), but it offers one of few usable implementations of such feature. It allows to create a very precise structure to label items, exactly like what a naming pattern in a file tree offers, but it does not limit the same way. You learn that when you start to find your pictures again. In consequence (though not visualized good in Digikam), it allows you to navigate through your hierarchy just as if it were a classical file hierarchy, but it also allows to use different hierarchies on one single collection of items where these different hierarchies even contain the same items. Kind if virtual hierarchies, though it is actually just multiple, non-exclusive hierarchies. This allows to use always that hierarchy that is most suitable for a given situation or task. I found myself falling back less and less often to the classical way of locating files, because using the tag hierarchies instead is so much more powerful and intuitive. So what I suggest is not that you should be taken your hierarchies away, certainly not! What I suggest is that we get rid of the need to press everything into a single, static file hierarchy. Which is only a limitation forced upon us by the way current file systems are implemented. Which is something that was created back in the early 50th. Things progressed since, you know? Let's take an analogy: todays digital technology is still founded on the principles of the von Neumann architecture. That is how nearly all of todays computers work. But still we humans invented lots of different languages to interact with them. Languages following different principles. Why is that? Because for different situations or tasks different languages make sense. They allow to express ourselves in different ways for different tasks. You will always chose amongst those languages that suit your current needs best. In the end all the code written in different languages boils down to more or less the same instructions executed by the computer. Still it clearly makes sense to have different languages at our disposal. We all know that type of programmer who implements all tasks using the same language in the same manner. And we all very well know the problem with that, don't we? But still we are stuck in one single, inflexible way to organize our collections of files. That is stupid, we limit ourselves without reason and advantages. Just like we differ between the executed instructions on a lower level and the implementations code in higher level languages above we should here differ between the physical location of a file in a file system and its logical placement. That also means we should finally get rid of limiting us to the pseudo physical requirements of classical file system hierarchies. That is what I mean with my "battle cry": to remove the limitations of classical file hierarchies from our view. As I wrote: we are not really interested in that if we take a closer look. I would like to add: of course only if we have better means at our hands. What I sketched would offer such means: the approach certainly would allow everyone to use the system just like a classical file hierarchy. But it would not limit to that, neither in location, not in association, nor in concurrency. It allows us to "go multi"! Christian Reiner (arkascha) _______________________________________________ User mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/user
