Hello all, First of all, thanks for the elaborated opinions so far!!! They help me in defining more sharply the intention behind the feature under discussion.
I would like to point out: - I didn't mean killing filesystems, I just think that in certain scenarios (very common nowadays), they are not the most practical solution. The main problematic scenario to help solving I had in mind is _personal_ media (photos, videos or shared media through IM apps at most). I didn't think of other contents (source code, publications, bookmarks as mentioned) that could be automatically organized, there possibly are some of them. My impression is that there is a gain considering this narrower scope, at least in the current stage where we are just considering the idea itself (current problems, _plain_ user behaviour, shared mental schemes...), at least to be all on the same page as a starting point. - I think that keeping the feature based on filesystems is a must, or at least capable of "translating" into a filesystem hiearchy. The first reason is that, regardless filesystem's adequacy for some purposes, their basic abstractions (folders, folder hierarchy and files) are the most widely spreaded among the target public (again, plain users, not technical ones) the feature would be aimed to, thus the default hierarchy everybody will be able to work with, either using the feature or not. The problem to solve IMHO is not the filesystems hierarchies not being enough, but the discipline, control, organization we users have to show in order to utilize it correctly to get our media-stuff tidy. Once organized, folder and file abstraction can do the job for sure. Interoperability is another aspect that makes me incline to be filesystem-based/friendly: what if I want to share my collection of photos with a relative? Chances are that he will have means to handle a filesystem most probably and things will get quickly complicated if he needs to use / understand a different abstraction... It is only that he will get things organized without me (regularly) spending hours in doing it... - Considering the narrower scope of the contents I had in mind, that is _organizing_ the massive media amounts we generate / get due to our recent customs (taking photos of everything, sharing everything...) in an automatic way. Some of you mentioned ontology, abstractions, mental behavior... My impression is that people organizes media in very similar ways, or at least would find suitable very similar ways: time lines, label for folders (collection of files clustered around a point in time), time periods... Automatizing these ways with minimal user interaction is the first intention of the feature I tried to expose. - Different views of course can be provided based on the same data, as usual, I just suggested *year->seasons->months->weeks->* *days->hours or "day in Paris", "week in Berlin", "The hottest July ever", "Summer with the family", "2015 abroad" *because they looked intuitive to me when looking back at the media I generate. In fact, at is very core, the whole feature could be considered as generating views on stored elements. - I agree that UI aspect is key, but my impression is that for the purpose I had in mind the attention required from user should be mininal... Just guessing of course, need to think a little bit on it. Some expertise there to provide some insight on this? - I still have to play a little bit around with tagspaces.org, looks similar in some aspect (working on plain old file systems and tagging) but I would focus more in simplification and automatization, rather than in intentioned re-organizing / re-inventing voluntarily. I suggest sticking to basics by now: automatizing as much as possible the _organization_ of media, as we people share / would accept similar mental schemes for them, in a nutshell, organizing media using filesystem's folder and file abstractions and generating different timeline-based / tag-based views. I am sure there are already solutions that help you tagging all kinds of contents, relating and establishing semantic relations among assets, but I find this not the same thing than profiting the timeline mental-model to automatize the organization of my media. Thank you once again for your opinions and valuable collaboration!!! 2015-03-23 10:27 GMT+01:00 Jörn Friedrich Dreyer <[email protected]>: > 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 >
_______________________________________________ User mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/user
