The downside of tagging is you still need to establish conventions to ensure things can be found again, but enforcement of your conventions is harder.
Exploring, learning, and using an unfamiliar folder hierarchy is easier than exploring, learning, and using an unfamiliar tagging methodology.
But manually searching for something in somebody else's tagged data is easier than manually searching for something in somebody else's folders.
And, similar to how a sugiyama graph automatically redraws when an edge is added or removed, a filesystem hierarchy could be automatically restructured to minimize the above scores when files are added or removed from the various folders.
That's why I stick to Documents/{folder1..folder∞} and folders don't have hierarchical sub folders, just contextual folders. Eg: Documents/taxes 2021/{invoices, stuff}, Documents/taxes 2021/, Documents/Cthulluh Roleplaying/{pdf files of characters}, Documents/Covid vaccination certificates,
Yes, it's messy but I don't have the mental burden of a holding a tree in my head or a tagging system.
This is one way to think about the hybrid model of folders + tags that is currently available:
1. Folders tell you where the file is stored.
2. Tags tell you what is the file.
So basically use the Tags to add more data (metadata) about your files, so that if you forget where the file is, you can still search for it by what is in it. This also slightly helps in easing the burden of trying to figure out where to store a file (e.g. "Do I put a home video in my 'Videos' folder or my 'Personal' folder?" - if you tag it properly, you can put it in either, as you can use the tags to figure out where the video is later).
Examples:
1. In Documents folder - "mom-2020.xls" (tags => docs, tax, finance, mom, unfiled).
2. In Videos folder - "newyear bash.mp4" (tags => video, family, 2021, home).
Gmail uses tags rather than folders, nice easy way to have a play if you've already got a google account.
Conceptually, I think of it as basically being able to have lots of different hierarchical folder structures applied to a set of objects at the same time. Or to flip it round, a normal folder structure is like using tags but where you are limited to one tag (the folder that holds the object) per object.
So, if I have a tag called 'projects', and another tag called 'newproject', the overall tag is 'projects-newproject'.
If I try to see everything under 'projects', it'll only show me the ones tagged 'projects' directly, not the ones under 'newproject'.
The tags themselves end up in an hierarchy without it affecting the tagged contents.
From a tagest perspective, and the discovery affordances, there is a significant difference.
Hierarchical tagsets allow you to navigate via tags, affording document discovery by that mechanism.
That becomes more significant as you're working with a larger, richer, and more structured tagset.
If I recall, CBFS and Dokan were the closest things you had to FUSE on Windows back then. Alternatively considered emulating a network drive. Like you pointed out, it had to be transparent to your existing software's Open / Save dialogs (although there was some effort to hook the standard ones to give users a place to apply tags when saving).
We've been stuck in the same old directory paradigm for a long time. There are some use cases where the traditional hierarchical approach is desirable (e.g. when you need to "visit" a set of files exactly once, like to browse through a folder to clean it up, enumerate for backup, calculate sizes, etc). But it's a constraint when a file belongs in more than one place.
This way I can just wipe the whole scratch folder whenever I want, and there are much less files I actually need to organize.
find /tmp -type f -mtime +30 -deleteDirectories are just a method of breaking the collection into usefully small / specific subsets for humans (mostly) and computers (a secondary but important performance optimization).
There's no technical reason some form of Standard couldn't be added to, or on top of, a filesystem that added tags as an alternate view or foreign index against the data.
The holdup is that there isn't any single standard for adding or searching by tags. The current directory structure is the lowest common denominator and has existed for longer than many of us have been alive. Change is _hard_ and those file open/close dialogues and interface methods still have to work, and they can work, at least for limited numbers of tags or maybe by some addition / removal special path syntax... However then it's stupid hard for the humans. Hard for the use case the tags are supposed to simplify.
Maybe this change can be added to what everyone really needs: a set of GUI calls that work on all the platforms, that isn't writing a damned web-page and using a DLL-hell-bloat bundled web-browser to do the cross platform lifting. Something that can work across all the desktops (as a target) and maybe all the mobiles (as another target) and maybe tablets too (slightly different target, somewhere between).
I imagine one of the problems you'd run in to is mass updates since deleting a directory with many files in it below a single tree node is very much limited to that part of the filesystem's tree, but doing it with tags causes updates all over the place.
It does remind me of this more metadata-like FS: https://github.com/marook/tagfs
As well as the thing Apple does in Finder where it has a tag database and dynamic 'tag' directories where it shows you everything that was tagged with that tag. Then the search function would allow selecting files based on tags so you can do many-tag searches and only find the files that match all of them. I think that one is based on an in-filesystem metadata stream.
Tags have a problem with names. How do you stop users from messing with files that belong to the OS or some application? Should we require that they all have the tags "OS" or "app" on them? Should binaries have the tag "binary"? What happens when the user tries to delete one app but chooses "tag 'app' and name startswith 'word'"? Should all application files named "word"-something from different applications be removed? Should the user have known to use a meta-query with "tag 'app' and tagname:startswith 'word'"?
I do see a lot of problems but of course some things would be easier.
Users should never touch system files nor have to look at them. I never want to see any asfawe.sdwae file ever again. Its like keeping power tools in the cup board or having screwdrivers in your utensils drawer. Its like keeping the manual in the washing machine. You open the door and instantly know it's a ridiculous idea.
The user should be able to do what he wants, anything should go, there should not be any bad moves besides deleting their own stuff, they should be able to simply delete everything. Make it a partition with a warning prompt.
There's a very neat project (can't remember the name, and some details below may be wrong,) that mounts a FUSE filesystem that uses only tags.
Paths have identical syntax to hierarchical ones, only each segment of a path is a tag.
so `/document/taxes/2020` would return a collection of files, but you could also write `/taxes/2020/document` and it would mean the same thing.
The advantage is you can use standard unix tools like ls, mv, cp, etc. as well as R/W using standard programs (like how you'd export an image.)
I'm sure there's edge cases to it, but I always found the idea very neat. Anyone remember what I'm talking about?