A long time ago I thought writing a tag based filesystem would help me get rid of hierarchies. I wrote a quick hack with python and fuse bindings and learned a few things in the process:
1) Tags need hierarchy (as the simplest form of relation). Imagine the tags "linux, ubuntu, debian, suse". Without this tags are a mere classification. When you can introduce hierarchy you can express your mental model to the system. An online bookmarking and publication management tool that implements this is http://www.bibsonomy.org 2) Depending on the type of files you may want the traditional filesystem (source code vs. holiday photo collections vs. downloads) 3) The most natural form of organization is a timeline (see twitter / facebook). 4) All UIs for tagging files were crap. There is not a single one that felt right. Feel free to point out a decent one ... Don't get me wrong. I'd love to dive back into tagging support and add metadata search based on them etc ... but this is not as easy as "revolution! let us move on to tagging". Personally, I think it makes more sense to implement a timeline or add filters to the activity app. Those filters could respect tags. Nevertheless, we should think about the UI here first. There is a reason why virtually nobody uses the tagging support of trackerd / beagle. just my 2 cents Jörn Am Montag, den 23.03.2015, 09:39 +0100 schrieb Christian Reiner: > 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 -- Jörn Friedrich Dreyer ([email protected]) Solutions Architect ownCloud GmbH Your Data, Your Cloud, Your Way! ownCloud GmbH, GF: Markus Rex, Holger Dyroff, Frank Karlitschek Schloßäckerstrasse 26a, 90443 Nürnberg, HRB 28050 (AG Nürnberg) _______________________________________________ User mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/user
