51–60 of 169 posts
when you have a large numbers in deep path then tags should be the way to go, you will need a database to manage it for portability across OSes etc.
with tags we need isolate how-to-store-the-files from how-to-organize-them-for-easy-access, tags can be used to build a virtual folder hierarchy for example.
The biggest directory in my document hierarchy is "flotsam".
I think part of the problem is that organizational tactics/schema/heuristics aren't global. We need an array of safe, high-quality tools with good system support/interfaces, and the knowledge to reason about how and when to use which. Patterns.
A stack is probably a fine way to think about organizing mail or clothes. It's probably less useful for deciding where furniture or paintings should go. A filesystem that made sense for organizing source code is probably not the best tool for organizing a movie collection or a lifetime of personal documents. Genre apparently seems like a great way to organize most of the world's movie, book, and music store/sections, but I (unless I can get someone to check the store's inventory system) never know whether what I'm looking for is out of stock or just hiding in the taxonomical hinterlands.
Search can help. Tags can help. Hierarchy can help. Metadata can help.
Earlier quoted context omitted.
I eventually had to use a series of command-line tools to shepherd my badly-organized photo collection into something like a usable state, and it basically involved finding all the JPEGs on my system, de-duplicating them, and dropping them into folders based on their date-taken metadata. It was a huge pain, and entirely an artifact of the tyranny of the folder-based filesystem.
for i in *.jpg; do date=$(exif $i --machine-readable --tag=0x9003 | cut -d ' ' -f 1 | tr : -) mkdir -p $date mv $i $date done But don't many photo-browsing programs allow browsing by date, or even GPS-tagged location? e.g. on KDE's DigiKam I choose "timeline" view (or map view).
I find one of the key concepts that's not a first-class concept is _when_ the file was modified. Rather than a file-and-folder physical analogy for the file system UI, I think a timeline-oriented UI could present some advantages for the way that humans actually think and work. Tags would be a helpful orthogonal organization scheme, but I don't think they work as a primary UI for navigation.
This is great work, though! I love the compilation of various other works, the references, and the way you've dug into the details!
Google Drive used to be based around tags, not hierarchies. It was wonderful. Then as it matured and catered to more and more 'normal' people it introduced the concept of folders. The folders were initially tags 'really' - the same file could exist in multiple folders at the same time. But they made that harder and harder, and now I think it's hierarchical folders through and through. I miss the old days.
I think it has more to do with capacity growth. Relying in tag+search would be insane if most queries returned hundreds of files,
Earlier quoted context omitted.
My problem, at least with Windows, is that it's an unholy mishmash of the two ideas. I really just want something like a Unix filesystem, with a single root. Just with things coming off that root that actually make some goddamn sense and aren't relics from the PDP days. Yet on Windows I have different drives that act as independent file trees, and then I have special folders that are handled somewhat differently, app…
It doesn't help that Windows /never/ (still hasn't) developed an actual standard library abstraction of what the filesystem is. In the Unix world your standard library either handles all supported filesystems for you, or more often, just provides a working abstraction of that via the kernel's own VFS abstraction of the supported filesystems. Literally, in the UNIX/POSIX world there is exactly one way to open a file f…
for simple use cases, folder beats everything else. when you have a large numbers in deep path then tags should be the way to go, you will need a database to manage it for portability across OSes etc. with tags we need isolate how-to-store-the-files from how-to-organize-them-for-easy-access, tags can be used to build a virtual folder hierarchy for example.
Earlier quoted context omitted.
I think most people would agree a tag filesystem or a similar concept is a great idea. I have wanted one myself for a long time. Yet, for some reason, it doesn't take off. Do you think it is just a problem of implementation?
A few things I can see off the top of my head that would need to be solved for tag filesystems to be able to take off: 1. Inertia. Most software assumes hierarchical filesystems, and assumes it can control some portion of that hierarchy. This includes things ranging from search paths for various things ($PATH for binaries, library paths, etc), temporary files, preferences files for applications, assumptions made abou…
They rule out this solution because it's not perfect, but surely if the idea had real merit this would be a serviceable test bed?
I think we have hierarchies because it's human nature to create hierarchies to make sense of the world, we try to force them into place where they don't make sense. We see it in biology, we see it in organisations and we see it in code, I'm sure most of us here have worked with examples of OO hierarchies that made no sense.
Tagging is the first step, but how do you know if you don't have overlapping or duplicate tags, say country and folk music? If you need something that fits both categories, you eventually start designing taxonomies and eventually ontologies, there's just no end to it. I think tagging is a sensible, lightweight approach, but it has limitations...
> country and folk music Folk music has nothing to do with country. Country was invented in the 1800s by a businessman who aimed it at primarily white Americans. Folk music has a rich history dating before the 1200s and before much of written language. Many songs of Irish and Welsh descent date before record, still being played today. Nevertheless, to answer your question: 1) metatags, parent tags, and the like provi…