I'm just wondering when we're gonna get tagged filesystems. Maybe something partially hierarchical. Would love a book/ directory that i can query for 'sci-fi' or 'specification'. I guess one could implement it using sym-links :^)
I hope she managed to keep all her files and didn't lose anything.
I literally have no idea what to do with it :(
> TMSU is a tool for tagging your files. It provides a simple command-line tool for applying tags and a virtual filesystem so that you can get a tag-based view of your files from within any other program.
> TMSU does not alter your files in any way: they remain unchanged on disk, or on the network, wherever you put them. TMSU maintains its own database and you simply gain an additional view, which you can mount, based upon the tags you set up. The only commitment required is your time and there's absolutely no lock-in.
> TMSU [does] not automatically detect file moves and renames
I dunno if we can call it a tagged filesystem with this limitation. (Why not store tags, or at least a GUID, in file metadata?)
But presumably there is some API or ABI to monitor, or some signal emitted, when files are moved, added, updated, or deleted. However iwaitnotify works, could that be incorporated (even theoretically) into TMSU?
There are a couple very barebones wrappers around mv and rm, though they could be better (pass through arguments, etc.).
https://github.com/oniony/TMSU/wiki/Tricks-and-Tips#filesyst...
At least one I tried ages ago was one you could use to browse your music collection, it automatically generated "directories" based on mp3tags.
Note: I specifically remember these speculations in the lead-up to the release of Windows 98. They don't seem to be easy to google at this point.
Those searches might be based on title, author/creator/contributor, publication/creation dates, assigned identifiers, full-text search, relations between documents, subjects or topics, document type / format, or other aspects.
How that is specified precisely ... I haven't settled on entirely, though short mnemonics, two- or three-letter where possible (ti -> title, au -> author, date, isbn, oclc, doi, etc.) might work.
If the filesystem lives under /docfs, then, say, /docfs/au:barrie/ti:peter+pan would turn up J.M. Barrie's Peter Pan. Specific document identifiers such as ISBNs, OCLCs, DOIs, or LCCSs could pinpoint specific documents, looser searches such as for Peter Pan might generate a list rather than a unitary response but those individual documents would be further distinguished by other properties.
The filesystem would be virtual rather than static-on-disk. You're effectively exploring the namespace. Creating this as a filesystem rather than, say, as a database query or application-specific data store means that standard filesystem tools would be available to interact with the contents, though modifications of works might require some additional work.
The system could also provide access to works not directly in the stacks, including remote resources (e.g., accessed via URIs and network calls), or applications (through some API). The underlying data store could be in any of several formats, and again the filesystem-based access could abstract between several independent stores.
Now all I need to do is build it ...
There are some similarities, and I'm thinking that TMSU might serve as a component of this system.