Interestingly, we have a similar "BASIC line numbering" system in our company. Allows for easy traversing the directories if you can remember the numbers (I cannot), such as "05_Contracts/15_Employees/041_John_Doe/07_Testemonies".
I like how simple the core concept is explained, but I feel it would box me into categories when I like tags more (categorizing items in multiple orthogonal domains). OTOH maybe well thought-out categories would bring more structure than tags.
My current notes strategy is to prefix the date to markdown filenames (for example '2023-05-31 canvas scan transform matrix.md') and put them into single dir. These are active journal-style notes that I'm free to update over next days while they are still in focus. Every few weeks the list of nodes gets busy and I 'archive' older notes into sub-dirs (personal, hobby project, work project) and backup the whole structure. The method requires minimal maintenance and the full text search works well for my needs.
Edit:
I like how the author leverages the CLI auto-completion and I try to do the same, but I think Johnny would work against my brain. When naming the directory or a script, I put myself in mind frame where I'd want to use it and I'm trying to recall its name. So I give semantic names like 'build-android.sh'. If it's a new thing I try to come up with a short catchy name for it. Having to recall the `10-19` category each time I want to access specific subscope seems like too much cognitive burden. Just theorizing, haven't given it a shot so far.
Where I work we do use that structure. I can never find anything. For me remembering the numbers is as remembering IPs instead of URLs.
The problem is not the naming of the directories, the problem is that the next idea after “johnny decimal” was to make a standard structure. Because this structure has to serve the full company, is HUGE! So irrespective of project or area size, you have an structure of 10 levels with 30 directories in each level. The names are very generic, and sooner or later somebody has a different interpretation of where document X should be placed… we have lost days searching for lost documents…
If only life was that simple that it could be enclosed into series of two digits categories.
The problem with such strongly hierarchical system is that it fails if there is some document, note, picture, etc. that would be useful to keep in multiple locations. Obviously we can introduce links between objects, but I believe tags are more comfortable to use.
Hierarchical system, folders are artifacts of the physical world in which a single object, tool, pipe, screw, book cannot be in two places at the same time. In the abstract world of computers a note about new game could be in #games, #fun, #to-check, #interesting-ideas, #great-graphics, etc.
I think that's the whole point of this system, when you have infinite tags it's impossible to maintain a correct taxonomy, you add #great-graphics to this game, but now you have to backfill it to all other games, or in the future you may miss them.
They created this so the hierarchy is unambiguous (as much as possible), you want a document, you are two steps away from it in an easy to find way.
tag systems have far too much maintenance and adding a new tag is almost impossible to do exhaustively so you have a lot of partial tags.
> you want a document, you are two steps away from it in an easy to find way
This isn't a response to the parent commenter's point, right? They were describing how many projects have items where a resource easily fits within the scope of N different categories, at which point they become max N steps away from it, not max 2 steps.
1. This is much, much less likely with the enforced limits on categorization in the post.
2. No - you are still 2 steps away. Make a choice about where that item lives. If it's shared across many categories, maybe you really need a distinct category like "Ambiguous" or "Shared"
#great-graphichs problem is not something category based system will solve either, as you have the same problem. Nothing will, to be honest, maybe AI eventually and even it can't do it in all the things.
> you want a document, you are two steps away from it in an easy to find way
This is not how people work in general. This kind of thing might be OK for institution for taxonomy like collections.
This is a great point about tag maintenance *if you have to make the tags yourself*. However, if you have a simple ML system that you can run to categorize your files and pull out good single word descriptors that have a large explained variance over your files, you can run this and check the tags that are constructed.
I think there's a good way forward that uses typical hierarchical Johnny.Decimal filesystems, with an overlay filesystem with tags that can update the tags every so often based on the content in the files. Obviously letting the user have a hand in this via a TUI/gui would be helpful for choosing tags for which they're comfortable.
Unfortunately I haven't settled on a good filesystem with tags (how to do this with ZFS?) or how to interact with it as a network filesystem served to many different OS (cifs with tags?).
It doesn't seem to me like a simple ML system, it needs to be able to extract tags from all kinds of filetypes (video, games, images, assets, text, ...), at a decent speed and then it has to assign tags to what you would also assign, because if it doesn't do that then it's even worse, because you can never find anything as your mapping and the ML mapping would not be the same.
Your argument seems to come up a fair amount in these discussions. In the end, you have to deal with storage of many items, and you can either browse or search. The browse approach requires you to know where you'll be browsing in the future. The searching approach requires you to know what to search for. No system is going to deliver all relevant documents, but you can do a good enough job with a hierarchical system plus search.
I think this is exactly right, and it is a facet of the same discoverability issues that crop up when people talk about GUI vs CLI - one is more useful when you're discovering, and one when you are searching. Tags are really set-based search operations like a SQL query, but the 'primary key' is the filename, and if you knew that you'd just search for it. You're rarely going to have a tag or attribute that can pinpoint a single document.
>Hierarchical system, folders are artifacts of the physical world in which a single object, tool, pipe, screw, book cannot be in two places at the same time.
Many think hierarchies come from limits in the physical world but that's not what's happening. Yes, that's some of the cause but does not explain all of it.
The deeper rooted reason is that hierarchies are a convenience to aid the human mind. Even without any limitations of physical shelves, the brain likes to:
- notice the relationships from the general-to-specific and navigate them with spatial cues of dirs parent-->child-->grandchild-->etc
- group related items together -- using spatial cues of moving file icons into a file system folder
The world the the blog essay is working in is the os file system. The various files have to be put somewhere on the file system. Since putting hundreds/thousands of files into a single flat folder is useless, one creates some child subfolders to organize it it in some way.
The tagging system assumes a different mechanism (e.g. a separate "database" of tags which filesystems like Microsoft NTFS and Linux ext4 do not have natively.) This happens above the native filesystem. (Incidentally, by placing a file into a subfolder, the name of that folder and the names of parent folders above it act as an "implied set of tags" for free.)
That said, both hierarchical folders and tags solve different needs. Also, hierarchies simulate/approximate "tags" by "virtual folders" and 1-to-n softlinks. Likewise, tagging can simulate "hierarchies" via compound-multi-word-tags.
Personally - I've come to the absolute opposite opinion. To be overly blunt:
"Tags fucking suck."
They are literally the worst possible way to store and organize your information, and they are only useful when you just want a random sampling of a category - not a specific document or piece of information. Ex: Great for social media or looking at old photos or just playing a song from a genre you like, bad (fucking terrible) for organization and structure.
---
Hierarchical structures have downsides, but the exact thing you complain about (artifacts of the physical world) is exactly their strength... You have a body that is adapted to the physical world - routing and navigation through a series of ordered steps is a VERY well developed human skill. We are primed to be able to remember things like:
- Go left at the tree,
- Straight until you hit road
- Right at the road
- continue until you hit a red house with a big garden
- etc...
That skill set maps directly into the hierarchical system of folder:
- Find the "documents" folder on the desktop
- scroll down to "my super sweet project"
- open that folder
- Find the "icons" folder
- open it and double click "exactly_the_thing_you_wanted.jpg"
------
You can absolutely still make horrible, unorganized messes - but if done well (ex: this article is actually a fairly good system) it's a much, much better system than tags.
I’ve thought a bit about tags++, that is adding some logical and not-so-logical features to them.
For instance there are ideas from OWL where you could define a category instead of other categories and their attributes, for instance tag D could be the union of tag A and tag B and the complement of tag C.
Implication is also useful both as a way to implement subclassing but also containment relationships. For instance on Danbooru a character that has several forms would have the various forms of the character imply that character and the character would imply the media property that the character comes from.
I am looking at what a tagging system looks like in the transformer age and one key idea is a kind of three value logic around tags which can be in a “positive”, “indeterminant” and “negative” state. If you are training a machine learning system to auto tag you will need (1) a number of examples where a tag does not apply (the tag not being applied is not evidence that the tag doesn’t apply, poor coverage of negative examples is one reason why YouTube recommendation is worse than TikTok) and (2) to deal with cases where the ML model tags something incorrectly. If the model tagging something puts it in an indeterminant polarity and that result can later be switched to negative or positive that is a great way to manage the situation.
They used to call the semantic web that OWL is a part of “Web 3.0” which failed to make an impression or was overwritten with the “Web3” moniker for NFT grifts by exceptionally ignorant people.
I learned OWL the hard way, I had been involved with the semantic web for 10+ years on and off and didn’t meet anyone who knew how to do meaningful modeling with OWL until last year, and that even includes famous academics who”ve written books in it.
OWL and RDF interest me immensely, intellectually. I've never been positioned to use either one professionally, but it looks fascinating. Is there a shorter path to successful modeling than the hard way? Is there a good source on this?
If you are willing to eat the up-front cost of coordinating global resource identification— a daunting task make no mistake, you get non-trivial dataset integration almost for free. Imagine if concatenating two ginormous JSON documents describing different aspects of the same entity would amount to a useful merge into a single combined JSON. If you Need this with a big N, RDF has no alternative.
The rise of SSDs has also more or less obviated the need for clustered indexes as a practical performance consideration. For the small price of trebling your storage footprint, commodity RDF triplestores will index _all_ your attributes/columns without a schema (usually red/black or equiv). Will it scan an integer PK over 100b records as fast as postgres? No. Is that use case in your hot path? Also no (most likely).
Edit: as for OWL, just take the plunge into rule based inference directly. From forward chaining inference (if you want performance and decidability guarantees) all the way up to full blown prolog or [miniKanRen](http://minikanren.org/) (if you want it in a library in your runtime of choice)
> You have a body that is adapted to the physical world - routing and navigation through a series of ordered steps is a VERY well developed human skill.
I find that this skill is better utilized with a system that has hyperlinks like Obsidian.
> To my surprise, we tend to think in hierarchical categories all the time. As I have written in my article on Logical Disjunct Categories Don't Work, the real world does not fit into disjunct categories.
> Therefore, we should embrace multi-classification more often. If you do want to learn more about the rationale, you may as well read the first chapters of my PhD thesis or the book "Everything is Miscellaneous" by David Weinberger, just to give you two resources of many.
> Long story short: tagging does take away the burden of finding one single spot in a strict hierarchy of entities which is actually a heavily intertwined network of concepts we do find in the real world. It's far from being a neat hierarchy. Everybody who tries to put "the world" into a strict hierarchy will fail.To my surprise, we tend to think in hierarchical categories all the time. As I have written in my article on Logical Disjunct Categories Don't Work, the real world does not fit into disjunct categories.
Tags are superior because tags can model hierarchies, but hierarchies cannot model tags. There are far too many times when a single document crosses multiople categories that are served by tags. I used Outlook for 15+ years and thought tags were a joke, then moved to GSuite for 13 years and learned to use tags, now I"m back on outlook and I feel like I'm suffocating without them. That's two decades of experience with both systems. Not to make a fallacy / whizzing contest out of this, but how long have you tried both systems? I'm guessing not as long.
> Tags are superior because tags can model hierarchies
Tags are inferior because tags must be coerced into hierarchies.
Tags are inferior because they do not properly link hierarchies that they model without extensive software support (which is present for file directories by design, and absent for tags). I have yet to see a hierarchical tagging scheme work well when you need to do something like change a mid-level directory name (you end up having to re-write many tags, often without good software support for what you're trying to do)
Tags themselves are fine. It's a perfectly valid way to label data. It is not a good way to organize that data for human recall and reference.
And here I am, using Johnny Decimal for over five years and I can find everything all the time. As Johnny himself said below, if it doesn't work for you - that's cool - use something else. But you assertion that this can't work is not correct. It's just that it can't work for YOU.
Hierarchies are better because they form a natural hypertext.
I'm in my documents folder. I see a list of all the categories of stuff I have. Whatever I'm looking for, it's in one of them. I go into a folder, and I see all the categories in that folder and none of the stuff outside of it. I've narrowed my focus and increased my depth. I can browse.
Sure, tags are more flexible, but (1) I find I almost never actually need them, because in most cases a hierarchy is good enough, and (2) tags don't function as a hypertext and won't let me explore. A big list of tags is much harder to dig through than nested folders.
Granted, it doesn't stop at tags or hierarchy. You can use both—on top of which, there are hierarchical tags, soft links, hard links, and even textual hyperlinks. But out of all of these, I find hierarchy to be the most important one. Given the choice among all of them, I always start with hierarchy and I typically find I don't need anything else.
Tags are great as an adjunct to a thoughtful folder hierarchy, IMHO.
Links are great as part of that too, they can provide shortcuts.
Real-world use: I am an artist, and I have found that the best way to organize my work is with a series of yearly directories. If I begin a large, multi-year project, it goes in a directory within the year I start it; I'll make a link to it that lives next to all the yearly directories.
I also use OSX's tags a ton. Files get marked as 'in progress', 'complete', 'paid for', 'commission', and 'experiment' (and a few other things). When I want to decide what to work on in any particular day it's super easy to open up the saved search for "everything in progress" that I keep on my desktop; this shows me everything in those yearly directories that's marked as 'in progress', whether it's personal work, client work, whether it's part of a large multi-file project with its own folder hierarchy or just a single file in the yearly directory. I also have a saved search for 'commission'+'in progress' for those days when I know I want to work on clearing the commission queue. And whenever I spend some time just fooling around with different effects to create interesting looks, I'll save my scribblings with the 'experiment' tag; when I decide to use it later I can easily tell Illustrator to open a file, and look through the 'experiment' tag to find the file full of some crazy procedural explorations, regardless of how long ago I did it. This habit has saved me hours of digging for that one file where I did that cool trick once.
Trying to organize all the files in my artwork directory with just tags would be a total fucking nightmare, the subdirectory for a multi-year graphic novel has its own folder hierarchy that's several levels deep, and when I know that what I want to work on today is "getting the prepress files together for book 3 of the graphic novel" it's definitely great to be able to just hit the top-level link to the graphic novel directory, then go into "books", then "3", and have its own little file hierarchy in there.
Tags by themselves are not very good for serious organization, but they can be very good for pulling things out of a hierarchical structure. They take work - I have to remember to mark a new file as 'in progress' and possibly a 'commission', though that's become routine, and changing something from 'in progress' to 'complete' is a pleasure. But it's work well worth doing to create a nice little network of shortcuts and secret passages through the terrain of your thoughtfully-laid-out tree of folders.
Your example about navigating roads has nothing to do with hierarchy. And, in fact, most road networks are not hierarchical and the interconnectedness is their strength:
Your brain doesn't organize information hierarchically. Let's say I ask you:
1. Name a band that starts with "B".
2. Name a band from England.
3. Name a rock band.
If your brain stored bands in a hierarchy, you'd only be able to come up with "The Beatles" as an answer for one of those questions. You'd have to figure out whether to categorize the Beatles by name, location, or genre and it would be absent from the other categories.
Or you'd have to do an inefficient search in order to find something that matched, which would be slow, but not impossible.
Or you'd have to maintain several redundant hierarchies.
(I agree with you that our subjective experience and speed in thinking of things is evidence that we probably don't mentally represent things this way.)
I strongly agree with the commentator who likened the hierarchal folder structure to the physical world, it’s a much more direct mapping of how human memory actually works.
Humans aren’t actually magical AI computers of energy floating in midair, they’re made of physical meat. Even if some abstract concepts (like tags) may make more theoretical sense (I agree with people who say that certain things can be classified in 2 different locations), it may not play to the actual structure and advantages of the human brain.
> Navigation memory is the most core type of memory- most other forms of memory evolved later. There’s a reason why GPS usage is correlated with dementia. Human memory actually evolved out of a sense of navigation.
That seems very possible, and probably important, but it's hard for me to relate that to the experience (as an "anatomically modern human") of having other kinds of associative memory that are very effective and don't have a discernible spatial or other hierarchical component.
It seems that navigation memory theory should imply not a hierarchical structure, but a wiki-like structure with many links. In a tree, there’s only one path to a given element, which is not the case in the physical world.
I agree. But are there any better solutions than manually ln -s? I'm in a band, and also manage booking for a venue. I have $venue/poster/$date\ $bands/$posterfile. I also have $band/poster/$date\ $venue
I don't know of any system that lets a single poster be in multiple places at the same time.
If you want to model this using your filesystem, that's exactly why symlinks (shortcuts on Windows and Mac) were invented.
On Mac, you can write tags on files and then use Spotlight to search for them. Pick one (more or less arbitrary) primary category to use as the directory for the file, then write tags for the other ways you want to be able to search for it.
> I strongly agree with the commentator who likened the hierarchal folder structure to the physical world, it’s a much more direct mapping of how human memory actually works.
But the physical world isn't hierarchical at all. It's spatial. It's much more like a graph than a tree where there are usually multiple paths between any two points.
If you have to pick up your kid from school and stop at the grocery store for milk on the way home from work, you probably do not:
1. Drive to school and get kid.
2. Drive back to work.
3. Drive to grocery story to get milk.
4. Drive back to work.
5. Drive home from work.
Or:
1. Drive to school and get kid.
2. Drive to grocery story to get milk.
3. Drive back to school.
4. Drive back to work.
5. Drive home from work.
If the physical world was hierarchical, all navigation through multiple waypoints would look like this kind of stack pushing and popping.
I'm telling you that all navigation through multiple waypoints DOES usually look like this kind of pushing and popping (just on a massive scale).
So here's a possible day for me:
I work at corporate office A, it's near the highway entrance. I have to pick up my kid - they are at school down the local street heading west. I travel west and pick up my child.
Now I need milk. The closest grocery is back east, just past my office, so I drive back by my office and pull into the grocery.
Then I load up and set off for home. To get there, I need to take the highway to the north, so I head back past my office on that same street and get on the highway using the closest entrance.
I take the highway until I'm home.
---
That sure seems like a normal day to me. It's exactly what you said folks would never do, but it's super common. And it's hardly something the modern introduced with cars - there's a cost function to travelling anywhere in the world, and people like to connect using low cost paths - which tends to model a folder hierarchy.
Sure, some routes end up being tree-like, because trees are a subset of graphs. But just as often you see waypoints like:
1. Leave the office.
2. Drive to the grocery store.
3. Drive to school.
4. Drive home.
Where there is no backtracking between them.
> And it's hardly something the modern introduced with cars - there's a cost function to travelling anywhere in the world, and people like to connect using low cost paths - which tends to model a folder hierarchy.
A tree doesn't minimize the cost for any given trip or for the aggregate cost of all trips between pairs of points. Because a tree has only a single path between any two points, it has the highest possible aggregate trip cost for all possible trips while still being connected.
What it does minimize is the cost of building and maintaining the paths. Since there is only a single path between any pair of points, it has the fewest redundant edges. If you were tasked with building a road network for a country and your sole goal was to minimize the amount of concrete used, you'd build a tree.
If your only goal was to minimize the aggregate distance all travellers took, you'd build a fully-connected graph where every pair of destinations has a dedicated road.
In practice, road networks are designed to minimize both road maintenance costs and drive time and balance those opposing forces. The result is more connected than a tree but less connected than a complete graph, something like a semilattice.
Everywhere where you have a lot of stuff to manage (photos, music, videos, documents, links) hierarchies don't work and only tags can tame all the chaos.
The analogy to "path finding" doesn't hold, imho. That's not how our brains organize information! We organize memories by association and not by some hierarchical structures.
there have been many, MANY historical attempts to organize the worlds knowledge hierarchically. They have all failed to achieve their goals spectacularly.
some of the most common reasons
- things exist in multiple categories that aren't in the same branch of the tree
- different state of mind during data retrieval means you expect the same item to be in different categories.
- different humans think the same thing belongs in different hierarchical locations
there's also been a LOT of scientific research around informational organization. It all came to the same conclusion. Hierarchies have interesting promises but fail when it meets the practical reality of the human brain.
in the end hierarchical organization of knowledge is a terrible solution expect in VERY restricted cases.
Do you have any suggestions of where to start reading on this? A seminal paper or cluster of papers? I want to deep dive on this not just to map out where it doesn't work but also to get a map of the restrictive cases where it does work.
edit: never mind, I just put your quote into gpt-4 and it passed me on to Eleanor Rosch, prototype theory and some other interesting works. I feel like this is my own modern lmgtfy moment.
I've done both as well, tagging everything and then assigning the tags into exclusive hierarchical relationships (for discovery purposes and grouping), but it only works to subdivide within an existing noun like "talent" or "wood panels", without a seed noun tags start becoming too abstract and the object with those tags start to lose all semantic cohesion.
I think once you start talking about unbounded universal tagging with hierarchies, they are not compatible, you need search and weighting or intelligent interfaces.
Search and LLMs really are major organizational improvements in our lifetime imo.
The only reason we're even discussing the topic is because search is so poorly implemented in client operating systems. Tags suck, hierarchical structures suck, everything that isn't search sucks. Search still kind of sucks, but it sucks much more because the search available on your own computer for your own files is about thirty years behind the state of the art.
The article points out that it is too easy to create duplicate files. Part of that ties into what you're talking about. Part of that deals with how people deal with files (e.g. few people use versioning outside of software development). The article is suggesting that a strong hierarchical system will help to avoid that problem.
Of course the other problem with tags is management. Placing something into multiple relevant categories involves more effort. Failing to place something into a relevant category makes it harder to find since you are now dealing with either a flat file namespace (worse yet, a disorganized one) or a flat tag namespace. In theory, some of this can be handled by letting someone else handle the tags (e.g. the creator, the publisher, or the seller), but that has its own problems since there is frequently a conflict of interest (e.g. irrelevant tags are applied to increase the visibility of a product).
At the end of the day, we have to accept there is no perfect system of categorization. Some will prefer hierarchies. Some will prefer tags. From the tone of the article, it is clear that they prefer hierarchies.
> At the end of the day, we have to accept there is no perfect system of categorization. Some will prefer hierarchies. Some will prefer tags. From the tone of the article, it is clear that they prefer hierarchies.
I’m the Johnny who wrote Johnny.Decimal and this is basically it.
The OP clearly isn’t one of the people for whom finding JD is a massive mental relief. I know those people exist: they write and tell me.
Others find the idea baffling. Stupid, even. That’s fine. If this helps you, enjoy it. If it doesn’t, use something else.
While I haven’t gone so far as to attribute a numbering system to my organization, I have done well at organizing things into red-line distinctive categories. The idea is to create categories that _cannot_ overlap. If there’s any commonality between them that’s not useless, they need to be grouped at a higher level.
As an example, if you’re organizing your toolbox, you don’t mark a drawer “hand tools” because it’s a useless categorization. You mark one “socket tools” which will include everything from the sockets and wrenches themselves to adapters that connect a socket to an impact wrench (but an impact wrench does not go in there because it is not exclusively a socket tool). If it really does come down to something that may really fit in two categories (hey, there’s always exceptions), you put your mindset in the place of yourself when you want to look it up: what’s the most common situation in which you’ll be looking this thing up?
This is the crux of it right here. You need to decide up front, thoughtfully and carefully - where you are going to put something. Just like in the physical world. Then you need to adjust and adapt it as you go. All the benefit comes downstream from those small additions to the workflow when you go to save something digitally.
I built a hierarchical note-keeping system for myself and have been intending to add tags to it, but I've never gotten around to it -- because the hierarchy is generally "good enough" after I added two features: linking, and grep.
Grep is self-explanatory. Linking works like hard links in Unix, where the same note appears as a child of multiple different parents (added a command to find "orphans" in case you unlink it from everywhere).
At this point I might not even bother adding tags.
> Linking works like hard links in Unix, where the same note appears as a child of multiple different parents (added a command to find "orphans" in case you unlink it from everywhere).
> At this point I might not even bother adding tags.
What you described with hard links is exactly how I use tags, so that would satisfy my need for tags as an organizational tool.
I spent some time studying the world of professional home organization(as seen on Youtube) and the core concepts always come down to these:
* Allocate space up front in the form of containers
* Position containers around workspaces
* Use containers appropriate to the type of object and its use(e.g. "rounds in rounds" - put round bottles on turntable racks so you can spin to access)
* Duplicate objects you need to use in multiple locations, e.g. scissors for the kitchen and for the office
* Label spaces where things belong
And the key thing to it is that this isn't a hard rule like always organizing hierarchically or always labelling. The hierarchy helps compress space(that's why books and folders are powerful) and the labels help define uses, but in many instances, the level of organization you need is an open bin with some dividers - the drawer organizer, cube storage, cardboard box, book bin, cafe tray etc.
Computer file systems are somewhat resistant to unlabelled open-bin storage because that means you're allocating with less precision, but I think everyone in practice knows that they will shove things in "Documents" or "Downloads" and just periodically purge it.
There's a lot of nonsense in that article, talking about evolutionary conditioning to alphabetical folder organization. Hundreds of millions of humans can't organize their documents alphabetically because they don't have an alphabet. They don't seem to have a problem with that.
I thought most languages have a collating order — I think even a slightly generous reading is what they mean by 'alphabetical'? Even Chinese (an important edge-case) has the traditional radical-and-stroke ordering mechanism.
In reality, natural language uses synonyms that often start with different letters. So without numbers, I still need to scan every directory one by one.
With numbers, I assign categories according to the phase of the process in which the item occurs. For example,
1 plans
|- A first draft
|- B Lisa's notes
`- C design
2 analysis
|- A exploratory
`- B design implementation
3 deliverables
|- A May 2023 report
|- B June 2023 presentation
`- C August 2023 report
I can limit my search to folders and items that are in the low/medium/high range, according to what I am looking for. But alphabetically sorted, this directory structure would look much more ad hoc:
analysis
|- design implementation
`- exploratory
deliverables
|- August 2023 report
|- June 2023 presentation
`- May 2023 report
plans
|- Lisa's notes
|- design
`- first draft
Collation order is not necessarily best for organizing. Many of us think spatially. Having related things near each other can be useful. Same with putting the most commonly used or most important things near the top.
This can work extremely well for one or two people. It becomes a problem when different people need to agree on what are the 10 things, categorization and maintenance.
And even when defined, at some point some document will be “in the middle”, one coworker will place it in 10, the other in 50. Has happened to many much more times that I can remember
If anyone has implemented this successfully/satisfactorily please post your folder hierarchy so everyone can compare notes and improve their organization.
It helps with two things:
- 1. A little easier to be consistent across projects so not to reinvent the wheel every time
- 2. The prefix increments as new folders are added during a project, painting a convenient picture of “progress” as things move along.
We tend to have:
10 to 19 reserved for admin stuff, like Admin, Incoming, Outgoing, Documentation, Meeting notes, etc.
Then anything from 20 onwards is ad-hoc per project
We also timestamp children of Incoming and Outgoing, with an ISO prefix. This is very useful to keep track of what was received and shared and when.
Overall the goal is to have as little protocol as possible to prevent total chaos. Anything more than that is usually too much to ask or doesn’t stick longer than a single project.
I have only used this (alone) for a few weeks because it is the first kind of organization that really resonated with me. I understand it may not be for everyone, but when it comes to organizing small to medium projects, it's really good IMHO. I use the standard organization because I'm not creative. Every project has his directory with a prefix (like "FMW01 xyz" for "firmware, first project, named xyz"), and subdirectories named "00-09 System," "10-19 Project management," and (my choice) "20-29 Data" with "20 Inputs" and "21 Outputs."
I have a template with empty folders and files (like Notes.md, Todo.md, etc.), and I can copy-paste this template for each new project. As long as I improve my template, every future project will have the new structure.
It's like the GTD system (which I also enjoy), but for organizing your thoughts, notes, and files in different projects. It's weird because I'm not fond of naming folders with numbers but this time it seems to work. Every project has the same structure and I'm not lost. I guess it's good for people who needs a serious structures as it forces you to have a good organization.
Interestingly, I had a boss 10 years ago that was using an equivalent method with a template and numbered directories. He was successful at managing projects and I think I discovered his secret.
Last but not least, once a project is done, I can zip it and reuse its number.
Every time I think about implementing this I realize the categories I have today and the categories I have five years from now are unlikely to mesh well.
At least based on my priorities from five years ago.
I've been thinking about that too. We either make broader categories or allow ourselves to deprecate and refactor category numbers in the future.
To me though the overwhelming benefit of the process is the act of bucketing. Another strategy then would be to bucket down to 8 categories instead of 10 — like line numbering in BASIC you allow yourself a bit of space if needed in the future.
It seems like nothing of use is gained by replacing folder names with numbers that index those names aside from making the path shorter. In a library this is useful because books have to be stored physically in order, but a computer does not have these restrictions. You could just as easily apply the same set of rules without the numbers and see similar results, with the advantage that the names of things reflect what they are. You also wouldn't have to create silly rules like "1- is always project management", because under the new system, "project management" will always be project management.
He does seem to address this at least somewhat[0], but the justification is so flimsy it's hardly worth addressing. In essence, he doesn't like alphabetical ordering because the index can change when something new is added. He would prefer new folders to be inserted at the end of the list. He is evidently unaware that folders can be sorted by creation date.
I have invented a superior system - Johnny Binary.
It's basically the same as the described system except you are forced to categorize your files even more severely since every level of the hierarchy only allows two subcategories.
When I first started out I used Johnny Unary. I dumped all my documents into a folder called - get this - "Documents". It actually worked remarkably well for a number of years.
Yeah, there was a system/OS/UI concept I came across years ago that I can't find anymore, but every document on your system is in one time-ordered stack/stream and then I guess you just have filters and such to manage random access.
All of my 100+ development projects exist in a single folder. Everything is easy to find because a) I'm usually looking at half a dozen of these projects actively in any given week and 2) the others have appropriate names that I am able to recall quickly, and 3) modern search functionality is fast and user friendly.
I've tried organizing by language, target platform etc. and all I ever found was that it did exactly as described elsewhere: a) projects did not fit nearly into one category or another and b) extra clicks were required to navigate to them. It also maps to how they are organized on GitHub and various package repos, which invariably give you a single searchable list.
Adopting modern and quirky organisation systems are, IME, frequently just premature optimisation, and most data in massive amounts such as photos are best organized by organic means, e.g. photos are best organized by date.
I find that the numbers are really helpful when trying to find related items. Things that are topically connected sort together and can be filtered by common criteria.
I use SimpleNote a lot for JD content and put the category in the title of each note. I type a piece of the JD number in the search box and it instantly filters down to relevant notes. Sort by title sorts by topic.
The most useful part of the process is simply thinking about how to organize your files.
The 03.65 like naming can indeed be switched out for something with words, but I believe the best of both worlds is to make the words "unix-like", i.e. small, and explanatory.
For instance *~* 10 main directories (code, doc, vid, etc) with *~* 10 subdirectories (note, tv, movie, etc) is nice to try to fit your data into, but if one of the subdirectories has only 8 things, it's not the end of the world.
This tends to work extremely well for "longer term" storage (a drive mounted beside your OS for data when 'finalized' or 'semi-finalized') but the mess of OS and everyday files isn't as appropriate for it.
I'm going to allow that some things, like photos for example, can live in their own folder apart from the Johnny Decimal data hierarchy.
(Also, it would force me to consider ... do I need 1000 files here? I've certainly been known to join related documents into a single PDF, Uber-document, if you will.)
My grandpa was very interested in libraries. He had drawers full of index cards[1] for his personal library, organized using the Dewey decimal system[2].
When he first got a computer, back in Windows 3.11 days, it only seemed natural to use what he was familiar with. So he would store documents and emails in directories based on the Dewey decimal system.
However a problem quickly arose. A document might pertain to multiple topics. With index cards this was simple, you just noted the book or document on each of the relevant index cards.
With files however it was less clear. The only way he found was to save the same file in multiple directories. With the obvious nightmare of keeping it all in sync.
It got somewhat better when I taught him how to make shortcuts to the documents, but still...
Universal Decimal Classification solved this issue by being fully build to do faceted classification. It does take more work to create classes though, and the class notation can get very complex.
I am obssessing over this when maintaining my knowledge/artifact base. Currently I am keeping it in git repository with few categories and I use 3 mechanisms - tags on end of file names and directories, iso8601 dates as prefix on some locations, and nothing on thrid ones.
I keep basic folder hierarchy very limited for now.
I use vscode to commit any change on save and pull git on folder open, making this behave like always in sync cloud a la Github Gists, especially together with vscode sync that brings my plugins, configs and shortcuts everhwhere.
CTRL+P to quickly find stuff by name or tags, and vscodes very fast ripgrep search to get files containing any content - so I just need to remember any word or phrase to find it. If I can't remember anything I browse over tags (having handy script to display all of them) or dates (since I usually know a time range). As another mechansism, I use double commander file manager with its fuzzy file names search to get interactive lists by typing tags or keywords while in particular folder.
To encrypt some pages I use GPG with vscode extension.
This serves me well, and I don't get lost, either when searching for previous knowledge or when trying to find where the single one is.
I evaluated Johnny Decimal prior to this, and it didn't fit this workflow - seems ad hoc enough so I can live without it and has nothing tags or good search can't solve. Also, it feels not flexible enough particularly as stuff can't have multiple categories. Tags are much better mechanism for information organization, you just need to keep them organized, keep their number relatively low, and have mechanism for delete/merge/move/rename which is simple enough here as it is all on the file system and is a few shell commands away.
I love everything about this: the concept, even the name. I feel Johnny Decimal just needs a graphic. From a few minutes of Googling, I think something like this: https://clipart-library.com/img1/1252227.gif
Question aside. Can anyone recommend any opensource de-duplication tool(s)? I've realized that I have the same data over many drives but manually going through them even for a single drive will take a ton of time. I'm wondering if there's something smart enough where you input paths to be scanned and magically outputs de-duplicated data to a single coherent place...
Edit: Some corrections. I forgot to mention which OS: GNU/Linux and/or BSDs.
Though that works fine from a script perspective I'd like some more interactive way of sorting directories etc. Identifying is just the first step, jdupes helps with linking the files (both soft and hard links comes with caveats though!) but that is mostly to save space, not to help in reorganisation.
It seems to me that is not a trivial problem to solve: de-duplication + reorganization. Maybe I'm incorrect. It also seems the kind of problem where it could be super-easy to screw it if you go with a custom made script plugging different tools...
Gosh, that's a really awful explanation. Not sure I get this correctly, but the gist is, you organize things by nesting general Categories with specialized categories and put a number on them. With the "lifehack" that the first digit is the general category, and the second digit is the specialized category? And then every folder under a specialized category gets another number? And this is only meant per Project? Not globally? Meaning every project can have slightly different categories & numbers? Have I understood this correctly?
How does this handle inter-project-files? What exactly is a project even in this context? How does it handle things which can be in multiple categories? This smells for like someone pressing everything into a hard form to circumvent the flaws of their tools, instead of getting better tooling.
As said before about in the post "BIG DATA is just data", a lot of information is worthless after 1 or 2 years and most after 5 years. Long term value data seems to be stored in IT systems' DBs rather successfully.
And I have so far always find important emails (notably because important topics are easily found emails chains and far more often than not in the dedicated meeting report).
Structuring data is cultural so you should rather learn to use the system used by your organization. Only super small teams and solo-founders need to think about how to store data. Most workers should follow their community to let other people find the information.
Folders, drawer, cabinet have been around for 3 centuries at least and imho, we are not gonna reinvent the wheel with this or that way to structure information.
If your organization has a system, by all means use it.
The whole point of Johnny.Decimal is that most organizations have absolutely no system to organize information. It’s tossed into a huge pile.
Even organizations that have systems concern themselves only with organization-wide needs. Individuals still have needs that the organization does not address.
This is effectively how formal military instructions are structured - and generally US code for that matter, with chapters generally reserved for certain functions going down to the .01 decimal specificity [1]
Way back in 2010 or so I published a series of instructions for the 36th Wing that followed this kind of naming/information numbering convention which was frustrating to fit into, but ultimately once you understand the framework it's faster to write.
That isn't to say it isn't confusing and complicated - which happens to everything at scale - simply that this kind of structure for documentation is pretty common and literally battle tested.
Commercial construction specifications are done in this way as well. So all electrical specifications are in division 16000 (or 26000 nowadays) and subdivided from there.
This method of only being two levels deep is interesting. If it works, that's great, but there's nothing to stop you from going three if required, e.g. 10.20.30. But keeping everything constrained has value in itself, if only in that it forces you to think in larger discreet chunks.
Number-based organization systems (e.g. US code) work best when there are frequent references to specific nodes in the hierarchy (e.g. legal citations) and there is no guarantee that they're being accessed digitally.
But there is a good reason why I navigate to news.ycombinator.com and not 209.216.230.240.
For digital resources like URLs or file systems, using numbers as prefixes or primary IDs only makes sense if their ordinal values represent the most important and intuitive way to browse through the hierarchy.
But in most cases, the name rather than the number is the most important thing, and it's very easy to sort or filter by name -- whereas sorting or filtering by number is only useful if there's an inherent ordering (e.g. date modified) to the numbers.
> But in most cases, the name rather than the number is the most important thing, and it's very easy to sort or filter by name
Names can also be difficult if not done correctly / uniformly. For instance, "Category Name", "CategoryName", "category_name", and "category-name" can all return differently through search.
I don't think the key is names vs. numbers vs. whatever else, I think it's more important to pick a system that works for the use case, then define / document / communicate it as wide and loud as possible.
>The Chief, Directives Division (DD) assigns numbers to DoD issuances based on the established subject groups and subgroups provided in Tables 1 through 9 and the recommendations of OSD and DoD Component heads with equity in a particular issuance.
> and the cues that Google uses to determine what’s useful — the links that are the fabric of the internet — just don’t exist at work.
Says someone who’s never worked at Google and used Moma. I still don’t understand why Google doesn’t offer Moma as a on-prem thing to replace JIRA’s suite. Is the market too small? They used to have an on-prem appliance way back when but surely a container package is all you need these days?
Never used such system, but I'm inclined to believe in its promises. In addition to what I've recently commented in another HN post [1], this system also slightly resembles the classification system used in accounting. At a first glance those account numbers look cryptic and arbitrary, but soon enough you realize how helpful they are on enabling accountants to communicate and creating journal entries.
> An important restriction of the system is that you’re not allowed to create any folders inside a Johnny.Decimal folder.
This being said immediately after a screenshot with three levels of directories confuses me. One problem I immediately identified with this system is that I would have to take extra steps to peek into the applicable directory to see what the current index is...
I'm always looking for a good organizational methodology. This seems to be per project, no? Any suggestions for a system for overall data organization?
I'm enjoying using it for overall family/personal data organization. Took me a year to migrate in, and I allow myself the privilege of reorganizing as needed; but I've found it super simple and super stress-relieving.
I do allow myself subsubdirs wherever it makes sense though. E.g. right now I have a file browser open to "64.05 TV Shows" (60 - 69 is "Media"; 64 is "Video"), and within 64.05 I have one subdir per TV show. I don't feel obliged to give each show a special number, and I also don't feel troubled by each show being a sub(sub)dir. This system is searchable and browsable within my tolerances.
> This being said immediately after a screenshot with three levels of directories confuses me.
Me too, but reading more I understand this now. A "Johnny.Decimal folder" is a folder that starts with a name like 12.04, meaning it represents a unique item. It will already be inside two other folders, the 12 folder and the 10-19 folder. The point is that while 12.04 can be a folder if the unique item is actually multiple files, you can't have more folders inside 12.04, because that's considered too much nesting.
> This seems to be per project, no? Any suggestions for a system for overall data organization?
It's always boggled my mind how disorganized most companies are with written information. It's always a wiki here, 7 different file shares over there, most of the latest data is on workers' desktops named "mgmt report 04032023 latest jb edits 2.0.doc". Constant stream of "can you send me the thingamajig file?"
And yet, we've all been to a library. Information organized by topic, then by author, and inside the books everything is further organized into chapters, and then there's an index referencing all of that (plus a card catalog/search system).
I use something similar to the Johnny Decimal system described at work, except the high level is by project not by topic. I find chronological filing split into projects (i.e. chunks of time/money/effort) matches my workday better.
The thing with libraries is that they're full of librarians. For some reason, it has fallen out of vogue for all but the oldest/largest companies (and government agencies) to hire librarians to work outside their libraries.
And, librarians are professionals who are trained specifically in the challenges around managing info, etc...Like many other areas, many corporations don't value long-term attention to things that will help them the most...in the long term. Its just too much short-term thinking...as well as, "oh hell, we don';t need to hire librarians...that takes money away from stockholders...Everyone in the company will just figure out how to manage the data at some point in some fashion on their own...etc." :-p
Libraries have a physical common place where everything always is.
Seems like better tech could improve this.
Arguably Whatsapp history already has, because at least stuff tends to collect in one place and be searchable, as opposed to being on desktops sent to individuals on request and forgotten.
I've been chipping away at moving to my own flavor of JD over the last year. One of the first things I did was add one higher level with broad categories, numbered as x00. Tis way things are broadly organized, I still don't have to 'fundamentally' go more than two folders deep or 'have more than 100 folders', but I can use it for my entire work life despite having 100-ish actual technical projects.
Backporting old docs to this system is a real chore and honestly, I haven't been very disciplined about that part, besides moving old Project folders under the top-level Projects folder. But this is always going to be an issue with any new filing system, and I don't think there's a lot of value in doing it. Maybe would be an interesting programmatic exercise. But I, hotsauceror at his keyboard, am NOT going to go and retroactively assign a 753.0026 etc identifier to every document lol...
I have recently added a 000 - Logs folder for places like coding journals, another trendy suggestion that pops up here on HN from time to time that I may or may not stick with...
We implemented this for our shared storage at $DAYJOB. We had a long tail of decade old files on our shared drive, so we started again with the Johnny Decimal system on a new one. It's helped tremendously for us for finding stuff.
I had previously implemented it on my personal Nextcloud instance, but found it to be less impactful, as I already tended to over-organize my digital files.
I rely on it a lot for my personal data and projects. The simplicity and constraints have a positive impact on the usability of the organized information
Terrible advice. Abitrary rules (make 10 folders!) is just utterly bonkers for everyone except a small subset of people who could categorise their life in this way.
It really grates on me when people offer solutions that work for them, as if they will work for everyone.
197 comments
[ 2.7 ms ] story [ 286 ms ] threadInterestingly, we have a similar "BASIC line numbering" system in our company. Allows for easy traversing the directories if you can remember the numbers (I cannot), such as "05_Contracts/15_Employees/041_John_Doe/07_Testemonies".
I like how simple the core concept is explained, but I feel it would box me into categories when I like tags more (categorizing items in multiple orthogonal domains). OTOH maybe well thought-out categories would bring more structure than tags.
My current notes strategy is to prefix the date to markdown filenames (for example '2023-05-31 canvas scan transform matrix.md') and put them into single dir. These are active journal-style notes that I'm free to update over next days while they are still in focus. Every few weeks the list of nodes gets busy and I 'archive' older notes into sub-dirs (personal, hobby project, work project) and backup the whole structure. The method requires minimal maintenance and the full text search works well for my needs.
Edit: I like how the author leverages the CLI auto-completion and I try to do the same, but I think Johnny would work against my brain. When naming the directory or a script, I put myself in mind frame where I'd want to use it and I'm trying to recall its name. So I give semantic names like 'build-android.sh'. If it's a new thing I try to come up with a short catchy name for it. Having to recall the `10-19` category each time I want to access specific subscope seems like too much cognitive burden. Just theorizing, haven't given it a shot so far.
The problem with such strongly hierarchical system is that it fails if there is some document, note, picture, etc. that would be useful to keep in multiple locations. Obviously we can introduce links between objects, but I believe tags are more comfortable to use.
Hierarchical system, folders are artifacts of the physical world in which a single object, tool, pipe, screw, book cannot be in two places at the same time. In the abstract world of computers a note about new game could be in #games, #fun, #to-check, #interesting-ideas, #great-graphics, etc.
They created this so the hierarchy is unambiguous (as much as possible), you want a document, you are two steps away from it in an easy to find way.
tag systems have far too much maintenance and adding a new tag is almost impossible to do exhaustively so you have a lot of partial tags.
This isn't a response to the parent commenter's point, right? They were describing how many projects have items where a resource easily fits within the scope of N different categories, at which point they become max N steps away from it, not max 2 steps.
1. This is much, much less likely with the enforced limits on categorization in the post.
2. No - you are still 2 steps away. Make a choice about where that item lives. If it's shared across many categories, maybe you really need a distinct category like "Ambiguous" or "Shared"
You misunderstand. The max N steps are at the point of recall, not categorization decision.
> you want a document, you are two steps away from it in an easy to find way
This is not how people work in general. This kind of thing might be OK for institution for taxonomy like collections.
I think there's a good way forward that uses typical hierarchical Johnny.Decimal filesystems, with an overlay filesystem with tags that can update the tags every so often based on the content in the files. Obviously letting the user have a hand in this via a TUI/gui would be helpful for choosing tags for which they're comfortable.
Unfortunately I haven't settled on a good filesystem with tags (how to do this with ZFS?) or how to interact with it as a network filesystem served to many different OS (cifs with tags?).
Or the old-school method, a community of people with tagging powers and a few moderators to do sanity checks.
Many think hierarchies come from limits in the physical world but that's not what's happening. Yes, that's some of the cause but does not explain all of it.
The deeper rooted reason is that hierarchies are a convenience to aid the human mind. Even without any limitations of physical shelves, the brain likes to:
- notice the relationships from the general-to-specific and navigate them with spatial cues of dirs parent-->child-->grandchild-->etc
- group related items together -- using spatial cues of moving file icons into a file system folder
The world the the blog essay is working in is the os file system. The various files have to be put somewhere on the file system. Since putting hundreds/thousands of files into a single flat folder is useless, one creates some child subfolders to organize it it in some way.
The tagging system assumes a different mechanism (e.g. a separate "database" of tags which filesystems like Microsoft NTFS and Linux ext4 do not have natively.) This happens above the native filesystem. (Incidentally, by placing a file into a subfolder, the name of that folder and the names of parent folders above it act as an "implied set of tags" for free.)
That said, both hierarchical folders and tags solve different needs. Also, hierarchies simulate/approximate "tags" by "virtual folders" and 1-to-n softlinks. Likewise, tagging can simulate "hierarchies" via compound-multi-word-tags.
"Tags fucking suck."
They are literally the worst possible way to store and organize your information, and they are only useful when you just want a random sampling of a category - not a specific document or piece of information. Ex: Great for social media or looking at old photos or just playing a song from a genre you like, bad (fucking terrible) for organization and structure.
---
Hierarchical structures have downsides, but the exact thing you complain about (artifacts of the physical world) is exactly their strength... You have a body that is adapted to the physical world - routing and navigation through a series of ordered steps is a VERY well developed human skill. We are primed to be able to remember things like:
- Go left at the tree,
- Straight until you hit road
- Right at the road
- continue until you hit a red house with a big garden
- etc...
That skill set maps directly into the hierarchical system of folder:
- Find the "documents" folder on the desktop
- scroll down to "my super sweet project"
- open that folder
- Find the "icons" folder
- open it and double click "exactly_the_thing_you_wanted.jpg"
------
You can absolutely still make horrible, unorganized messes - but if done well (ex: this article is actually a fairly good system) it's a much, much better system than tags.
For instance there are ideas from OWL where you could define a category instead of other categories and their attributes, for instance tag D could be the union of tag A and tag B and the complement of tag C.
Implication is also useful both as a way to implement subclassing but also containment relationships. For instance on Danbooru a character that has several forms would have the various forms of the character imply that character and the character would imply the media property that the character comes from.
I am looking at what a tagging system looks like in the transformer age and one key idea is a kind of three value logic around tags which can be in a “positive”, “indeterminant” and “negative” state. If you are training a machine learning system to auto tag you will need (1) a number of examples where a tag does not apply (the tag not being applied is not evidence that the tag doesn’t apply, poor coverage of negative examples is one reason why YouTube recommendation is worse than TikTok) and (2) to deal with cases where the ML model tags something incorrectly. If the model tagging something puts it in an indeterminant polarity and that result can later be switched to negative or positive that is a great way to manage the situation.
What is OWL? Except for a good lesson in why not to use common and hence impossible to search for words as names for a project.
I learned OWL the hard way, I had been involved with the semantic web for 10+ years on and off and didn’t meet anyone who knew how to do meaningful modeling with OWL until last year, and that even includes famous academics who”ve written books in it.
If you are willing to eat the up-front cost of coordinating global resource identification— a daunting task make no mistake, you get non-trivial dataset integration almost for free. Imagine if concatenating two ginormous JSON documents describing different aspects of the same entity would amount to a useful merge into a single combined JSON. If you Need this with a big N, RDF has no alternative.
The rise of SSDs has also more or less obviated the need for clustered indexes as a practical performance consideration. For the small price of trebling your storage footprint, commodity RDF triplestores will index _all_ your attributes/columns without a schema (usually red/black or equiv). Will it scan an integer PK over 100b records as fast as postgres? No. Is that use case in your hot path? Also no (most likely).
Edit: as for OWL, just take the plunge into rule based inference directly. From forward chaining inference (if you want performance and decidability guarantees) all the way up to full blown prolog or [miniKanRen](http://minikanren.org/) (if you want it in a library in your runtime of choice)
I find that this skill is better utilized with a system that has hyperlinks like Obsidian.
Also purely hierarchical systems break down over time, they can be supported with tags. https://karl-voit.at/2022/01/29/How-to-Use-Tags/
> To my surprise, we tend to think in hierarchical categories all the time. As I have written in my article on Logical Disjunct Categories Don't Work, the real world does not fit into disjunct categories.
> Therefore, we should embrace multi-classification more often. If you do want to learn more about the rationale, you may as well read the first chapters of my PhD thesis or the book "Everything is Miscellaneous" by David Weinberger, just to give you two resources of many.
> Long story short: tagging does take away the burden of finding one single spot in a strict hierarchy of entities which is actually a heavily intertwined network of concepts we do find in the real world. It's far from being a neat hierarchy. Everybody who tries to put "the world" into a strict hierarchy will fail.To my surprise, we tend to think in hierarchical categories all the time. As I have written in my article on Logical Disjunct Categories Don't Work, the real world does not fit into disjunct categories.
Tags are inferior because tags must be coerced into hierarchies.
Tags are inferior because they do not properly link hierarchies that they model without extensive software support (which is present for file directories by design, and absent for tags). I have yet to see a hierarchical tagging scheme work well when you need to do something like change a mid-level directory name (you end up having to re-write many tags, often without good software support for what you're trying to do)
Tags themselves are fine. It's a perfectly valid way to label data. It is not a good way to organize that data for human recall and reference.
Yet here I am: using them for recall and reference faster than hierarchies (after 30+ years of using both).
I'm in my documents folder. I see a list of all the categories of stuff I have. Whatever I'm looking for, it's in one of them. I go into a folder, and I see all the categories in that folder and none of the stuff outside of it. I've narrowed my focus and increased my depth. I can browse.
Sure, tags are more flexible, but (1) I find I almost never actually need them, because in most cases a hierarchy is good enough, and (2) tags don't function as a hypertext and won't let me explore. A big list of tags is much harder to dig through than nested folders.
Granted, it doesn't stop at tags or hierarchy. You can use both—on top of which, there are hierarchical tags, soft links, hard links, and even textual hyperlinks. But out of all of these, I find hierarchy to be the most important one. Given the choice among all of them, I always start with hierarchy and I typically find I don't need anything else.
Links are great as part of that too, they can provide shortcuts.
Real-world use: I am an artist, and I have found that the best way to organize my work is with a series of yearly directories. If I begin a large, multi-year project, it goes in a directory within the year I start it; I'll make a link to it that lives next to all the yearly directories.
I also use OSX's tags a ton. Files get marked as 'in progress', 'complete', 'paid for', 'commission', and 'experiment' (and a few other things). When I want to decide what to work on in any particular day it's super easy to open up the saved search for "everything in progress" that I keep on my desktop; this shows me everything in those yearly directories that's marked as 'in progress', whether it's personal work, client work, whether it's part of a large multi-file project with its own folder hierarchy or just a single file in the yearly directory. I also have a saved search for 'commission'+'in progress' for those days when I know I want to work on clearing the commission queue. And whenever I spend some time just fooling around with different effects to create interesting looks, I'll save my scribblings with the 'experiment' tag; when I decide to use it later I can easily tell Illustrator to open a file, and look through the 'experiment' tag to find the file full of some crazy procedural explorations, regardless of how long ago I did it. This habit has saved me hours of digging for that one file where I did that cool trick once.
Trying to organize all the files in my artwork directory with just tags would be a total fucking nightmare, the subdirectory for a multi-year graphic novel has its own folder hierarchy that's several levels deep, and when I know that what I want to work on today is "getting the prepress files together for book 3 of the graphic novel" it's definitely great to be able to just hit the top-level link to the graphic novel directory, then go into "books", then "3", and have its own little file hierarchy in there.
Tags by themselves are not very good for serious organization, but they can be very good for pulling things out of a hierarchical structure. They take work - I have to remember to mark a new file as 'in progress' and possibly a 'commission', though that's become routine, and changing something from 'in progress' to 'complete' is a pleasure. But it's work well worth doing to create a nice little network of shortcuts and secret passages through the terrain of your thoughtfully-laid-out tree of folders.
https://en.wikipedia.org/wiki/A_City_Is_Not_a_Tree
Your brain doesn't organize information hierarchically. Let's say I ask you:
1. Name a band that starts with "B".
2. Name a band from England.
3. Name a rock band.
If your brain stored bands in a hierarchy, you'd only be able to come up with "The Beatles" as an answer for one of those questions. You'd have to figure out whether to categorize the Beatles by name, location, or genre and it would be absent from the other categories.
Or you'd have to maintain several redundant hierarchies.
(I agree with you that our subjective experience and speed in thinking of things is evidence that we probably don't mentally represent things this way.)
I strongly agree with the commentator who likened the hierarchal folder structure to the physical world, it’s a much more direct mapping of how human memory actually works.
Humans aren’t actually magical AI computers of energy floating in midair, they’re made of physical meat. Even if some abstract concepts (like tags) may make more theoretical sense (I agree with people who say that certain things can be classified in 2 different locations), it may not play to the actual structure and advantages of the human brain.
That seems very possible, and probably important, but it's hard for me to relate that to the experience (as an "anatomically modern human") of having other kinds of associative memory that are very effective and don't have a discernible spatial or other hierarchical component.
I don't know of any system that lets a single poster be in multiple places at the same time.
On Mac, you can write tags on files and then use Spotlight to search for them. Pick one (more or less arbitrary) primary category to use as the directory for the file, then write tags for the other ways you want to be able to search for it.
But the physical world isn't hierarchical at all. It's spatial. It's much more like a graph than a tree where there are usually multiple paths between any two points.
If you have to pick up your kid from school and stop at the grocery store for milk on the way home from work, you probably do not:
1. Drive to school and get kid.
2. Drive back to work.
3. Drive to grocery story to get milk.
4. Drive back to work.
5. Drive home from work.
Or:
1. Drive to school and get kid.
2. Drive to grocery story to get milk.
3. Drive back to school.
4. Drive back to work.
5. Drive home from work.
If the physical world was hierarchical, all navigation through multiple waypoints would look like this kind of stack pushing and popping.
So here's a possible day for me:
I work at corporate office A, it's near the highway entrance. I have to pick up my kid - they are at school down the local street heading west. I travel west and pick up my child.
Now I need milk. The closest grocery is back east, just past my office, so I drive back by my office and pull into the grocery.
Then I load up and set off for home. To get there, I need to take the highway to the north, so I head back past my office on that same street and get on the highway using the closest entrance.
I take the highway until I'm home.
---
That sure seems like a normal day to me. It's exactly what you said folks would never do, but it's super common. And it's hardly something the modern introduced with cars - there's a cost function to travelling anywhere in the world, and people like to connect using low cost paths - which tends to model a folder hierarchy.
1. Leave the office.
2. Drive to the grocery store.
3. Drive to school.
4. Drive home.
Where there is no backtracking between them.
> And it's hardly something the modern introduced with cars - there's a cost function to travelling anywhere in the world, and people like to connect using low cost paths - which tends to model a folder hierarchy.
A tree doesn't minimize the cost for any given trip or for the aggregate cost of all trips between pairs of points. Because a tree has only a single path between any two points, it has the highest possible aggregate trip cost for all possible trips while still being connected.
What it does minimize is the cost of building and maintaining the paths. Since there is only a single path between any pair of points, it has the fewest redundant edges. If you were tasked with building a road network for a country and your sole goal was to minimize the amount of concrete used, you'd build a tree.
If your only goal was to minimize the aggregate distance all travellers took, you'd build a fully-connected graph where every pair of destinations has a dedicated road.
In practice, road networks are designed to minimize both road maintenance costs and drive time and balance those opposing forces. The result is more connected than a tree but less connected than a complete graph, something like a semilattice.
Everywhere where you have a lot of stuff to manage (photos, music, videos, documents, links) hierarchies don't work and only tags can tame all the chaos.
The analogy to "path finding" doesn't hold, imho. That's not how our brains organize information! We organize memories by association and not by some hierarchical structures.
some of the most common reasons
- things exist in multiple categories that aren't in the same branch of the tree
- different state of mind during data retrieval means you expect the same item to be in different categories.
- different humans think the same thing belongs in different hierarchical locations
there's also been a LOT of scientific research around informational organization. It all came to the same conclusion. Hierarchies have interesting promises but fail when it meets the practical reality of the human brain.
in the end hierarchical organization of knowledge is a terrible solution expect in VERY restricted cases.
edit: never mind, I just put your quote into gpt-4 and it passed me on to Eleanor Rosch, prototype theory and some other interesting works. I feel like this is my own modern lmgtfy moment.
I think once you start talking about unbounded universal tagging with hierarchies, they are not compatible, you need search and weighting or intelligent interfaces.
Search and LLMs really are major organizational improvements in our lifetime imo.
Of course the other problem with tags is management. Placing something into multiple relevant categories involves more effort. Failing to place something into a relevant category makes it harder to find since you are now dealing with either a flat file namespace (worse yet, a disorganized one) or a flat tag namespace. In theory, some of this can be handled by letting someone else handle the tags (e.g. the creator, the publisher, or the seller), but that has its own problems since there is frequently a conflict of interest (e.g. irrelevant tags are applied to increase the visibility of a product).
At the end of the day, we have to accept there is no perfect system of categorization. Some will prefer hierarchies. Some will prefer tags. From the tone of the article, it is clear that they prefer hierarchies.
I’m the Johnny who wrote Johnny.Decimal and this is basically it.
The OP clearly isn’t one of the people for whom finding JD is a massive mental relief. I know those people exist: they write and tell me.
Others find the idea baffling. Stupid, even. That’s fine. If this helps you, enjoy it. If it doesn’t, use something else.
[1] https://workflowy.com/
As an example, if you’re organizing your toolbox, you don’t mark a drawer “hand tools” because it’s a useless categorization. You mark one “socket tools” which will include everything from the sockets and wrenches themselves to adapters that connect a socket to an impact wrench (but an impact wrench does not go in there because it is not exclusively a socket tool). If it really does come down to something that may really fit in two categories (hey, there’s always exceptions), you put your mindset in the place of yourself when you want to look it up: what’s the most common situation in which you’ll be looking this thing up?
Grep is self-explanatory. Linking works like hard links in Unix, where the same note appears as a child of multiple different parents (added a command to find "orphans" in case you unlink it from everywhere).
At this point I might not even bother adding tags.
What you described with hard links is exactly how I use tags, so that would satisfy my need for tags as an organizational tool.
* Allocate space up front in the form of containers
* Position containers around workspaces
* Use containers appropriate to the type of object and its use(e.g. "rounds in rounds" - put round bottles on turntable racks so you can spin to access)
* Duplicate objects you need to use in multiple locations, e.g. scissors for the kitchen and for the office
* Label spaces where things belong
And the key thing to it is that this isn't a hard rule like always organizing hierarchically or always labelling. The hierarchy helps compress space(that's why books and folders are powerful) and the labels help define uses, but in many instances, the level of organization you need is an open bin with some dividers - the drawer organizer, cube storage, cardboard box, book bin, cafe tray etc.
Computer file systems are somewhat resistant to unlabelled open-bin storage because that means you're allocating with less precision, but I think everyone in practice knows that they will shove things in "Documents" or "Downloads" and just periodically purge it.
With numbers, I assign categories according to the phase of the process in which the item occurs. For example,
I can limit my search to folders and items that are in the low/medium/high range, according to what I am looking for. But alphabetically sorted, this directory structure would look much more ad hoc:It helps with two things: - 1. A little easier to be consistent across projects so not to reinvent the wheel every time - 2. The prefix increments as new folders are added during a project, painting a convenient picture of “progress” as things move along.
We tend to have: 10 to 19 reserved for admin stuff, like Admin, Incoming, Outgoing, Documentation, Meeting notes, etc.
Then anything from 20 onwards is ad-hoc per project
We also timestamp children of Incoming and Outgoing, with an ISO prefix. This is very useful to keep track of what was received and shared and when.
Overall the goal is to have as little protocol as possible to prevent total chaos. Anything more than that is usually too much to ask or doesn’t stick longer than a single project.
I have a template with empty folders and files (like Notes.md, Todo.md, etc.), and I can copy-paste this template for each new project. As long as I improve my template, every future project will have the new structure.
It's like the GTD system (which I also enjoy), but for organizing your thoughts, notes, and files in different projects. It's weird because I'm not fond of naming folders with numbers but this time it seems to work. Every project has the same structure and I'm not lost. I guess it's good for people who needs a serious structures as it forces you to have a good organization.
Interestingly, I had a boss 10 years ago that was using an equivalent method with a template and numbered directories. He was successful at managing projects and I think I discovered his secret.
Last but not least, once a project is done, I can zip it and reuse its number.
At least based on my priorities from five years ago.
To me though the overwhelming benefit of the process is the act of bucketing. Another strategy then would be to bucket down to 8 categories instead of 10 — like line numbering in BASIC you allow yourself a bit of space if needed in the future.
He does seem to address this at least somewhat[0], but the justification is so flimsy it's hardly worth addressing. In essence, he doesn't like alphabetical ordering because the index can change when something new is added. He would prefer new folders to be inserted at the end of the list. He is evidently unaware that folders can be sorted by creation date.
[0] https://johnnydecimal.com/10-19-concepts/11-core/11.02-areas...
It forces you to whittle your categories down to ten (and sub categories). I would argue that in and of itself is a useful constraint.
It's basically the same as the described system except you are forced to categorize your files even more severely since every level of the hierarchy only allows two subcategories.
It must therefore be superior, right?
I've tried organizing by language, target platform etc. and all I ever found was that it did exactly as described elsewhere: a) projects did not fit nearly into one category or another and b) extra clicks were required to navigate to them. It also maps to how they are organized on GitHub and various package repos, which invariably give you a single searchable list.
Adopting modern and quirky organisation systems are, IME, frequently just premature optimisation, and most data in massive amounts such as photos are best organized by organic means, e.g. photos are best organized by date.
I use SimpleNote a lot for JD content and put the category in the title of each note. I type a piece of the JD number in the search box and it instantly filters down to relevant notes. Sort by title sorts by topic.
The 03.65 like naming can indeed be switched out for something with words, but I believe the best of both worlds is to make the words "unix-like", i.e. small, and explanatory.
For instance *~* 10 main directories (code, doc, vid, etc) with *~* 10 subdirectories (note, tv, movie, etc) is nice to try to fit your data into, but if one of the subdirectories has only 8 things, it's not the end of the world. This tends to work extremely well for "longer term" storage (a drive mounted beside your OS for data when 'finalized' or 'semi-finalized') but the mess of OS and everyday files isn't as appropriate for it.
"It’s very unlikely you will end up with a hundred categories." -the page
Exactly this will result in about 20-30 folders for most, with any real amount of documents some folders might hold 100-1000 docs.
The advise you should take from this is that forcing structure is useful. Look att large code repos for example.
(Also, it would force me to consider ... do I need 1000 files here? I've certainly been known to join related documents into a single PDF, Uber-document, if you will.)
When he first got a computer, back in Windows 3.11 days, it only seemed natural to use what he was familiar with. So he would store documents and emails in directories based on the Dewey decimal system.
However a problem quickly arose. A document might pertain to multiple topics. With index cards this was simple, you just noted the book or document on each of the relevant index cards.
With files however it was less clear. The only way he found was to save the same file in multiple directories. With the obvious nightmare of keeping it all in sync.
It got somewhat better when I taught him how to make shortcuts to the documents, but still...
[1]: https://en.wikipedia.org/wiki/Index_card
[2]: https://en.wikipedia.org/wiki/Dewey_Decimal_Classification
So,
1. notes a-la gists use tags:
2. event-like things use both dates and tags 3. stuff I just collect dont use anything or some of above I keep basic folder hierarchy very limited for now. I use vscode to commit any change on save and pull git on folder open, making this behave like always in sync cloud a la Github Gists, especially together with vscode sync that brings my plugins, configs and shortcuts everhwhere.CTRL+P to quickly find stuff by name or tags, and vscodes very fast ripgrep search to get files containing any content - so I just need to remember any word or phrase to find it. If I can't remember anything I browse over tags (having handy script to display all of them) or dates (since I usually know a time range). As another mechansism, I use double commander file manager with its fuzzy file names search to get interactive lists by typing tags or keywords while in particular folder.
To encrypt some pages I use GPG with vscode extension.
This serves me well, and I don't get lost, either when searching for previous knowledge or when trying to find where the single one is.
I evaluated Johnny Decimal prior to this, and it didn't fit this workflow - seems ad hoc enough so I can live without it and has nothing tags or good search can't solve. Also, it feels not flexible enough particularly as stuff can't have multiple categories. Tags are much better mechanism for information organization, you just need to keep them organized, keep their number relatively low, and have mechanism for delete/merge/move/rename which is simple enough here as it is all on the file system and is a few shell commands away.
Edit: Some corrections. I forgot to mention which OS: GNU/Linux and/or BSDs.
https://github.com/dpc/rdedup/
I've tried many, but rmlint is the most flexible and reliable. Esp. the tagging works really well.
https://github.com/sahib/rmlint
https://github.com/jbruchon/jdupes
Though that works fine from a script perspective I'd like some more interactive way of sorting directories etc. Identifying is just the first step, jdupes helps with linking the files (both soft and hard links comes with caveats though!) but that is mostly to save space, not to help in reorganisation.
How does this handle inter-project-files? What exactly is a project even in this context? How does it handle things which can be in multiple categories? This smells for like someone pressing everything into a hard form to circumvent the flaws of their tools, instead of getting better tooling.
And I have so far always find important emails (notably because important topics are easily found emails chains and far more often than not in the dedicated meeting report).
Structuring data is cultural so you should rather learn to use the system used by your organization. Only super small teams and solo-founders need to think about how to store data. Most workers should follow their community to let other people find the information.
Folders, drawer, cabinet have been around for 3 centuries at least and imho, we are not gonna reinvent the wheel with this or that way to structure information.
The whole point of Johnny.Decimal is that most organizations have absolutely no system to organize information. It’s tossed into a huge pile.
Even organizations that have systems concern themselves only with organization-wide needs. Individuals still have needs that the organization does not address.
Way back in 2010 or so I published a series of instructions for the 36th Wing that followed this kind of naming/information numbering convention which was frustrating to fit into, but ultimately once you understand the framework it's faster to write.
That isn't to say it isn't confusing and complicated - which happens to everything at scale - simply that this kind of structure for documentation is pretty common and literally battle tested.
[1]https://www.esd.whs.mil/Portals/54/Documents/DD/iss_process/...
This method of only being two levels deep is interesting. If it works, that's great, but there's nothing to stop you from going three if required, e.g. 10.20.30. But keeping everything constrained has value in itself, if only in that it forces you to think in larger discreet chunks.
But there is a good reason why I navigate to news.ycombinator.com and not 209.216.230.240.
For digital resources like URLs or file systems, using numbers as prefixes or primary IDs only makes sense if their ordinal values represent the most important and intuitive way to browse through the hierarchy.
But in most cases, the name rather than the number is the most important thing, and it's very easy to sort or filter by name -- whereas sorting or filtering by number is only useful if there's an inherent ordering (e.g. date modified) to the numbers.
Names can also be difficult if not done correctly / uniformly. For instance, "Category Name", "CategoryName", "category_name", and "category-name" can all return differently through search.
I don't think the key is names vs. numbers vs. whatever else, I think it's more important to pick a system that works for the use case, then define / document / communicate it as wide and loud as possible.
What an opening sentence.
Says someone who’s never worked at Google and used Moma. I still don’t understand why Google doesn’t offer Moma as a on-prem thing to replace JIRA’s suite. Is the market too small? They used to have an on-prem appliance way back when but surely a container package is all you need these days?
[1] https://news.ycombinator.com/item?id=36301140
[1] https://en.wikipedia.org/wiki/Melvil_Dewey
> An important restriction of the system is that you’re not allowed to create any folders inside a Johnny.Decimal folder.
This being said immediately after a screenshot with three levels of directories confuses me. One problem I immediately identified with this system is that I would have to take extra steps to peek into the applicable directory to see what the current index is...
I'm always looking for a good organizational methodology. This seems to be per project, no? Any suggestions for a system for overall data organization?
I do allow myself subsubdirs wherever it makes sense though. E.g. right now I have a file browser open to "64.05 TV Shows" (60 - 69 is "Media"; 64 is "Video"), and within 64.05 I have one subdir per TV show. I don't feel obliged to give each show a special number, and I also don't feel troubled by each show being a sub(sub)dir. This system is searchable and browsable within my tolerances.
Me too, but reading more I understand this now. A "Johnny.Decimal folder" is a folder that starts with a name like 12.04, meaning it represents a unique item. It will already be inside two other folders, the 12 folder and the 10-19 folder. The point is that while 12.04 can be a folder if the unique item is actually multiple files, you can't have more folders inside 12.04, because that's considered too much nesting.
> This seems to be per project, no? Any suggestions for a system for overall data organization?
Multi-project organization is covered later on: https://johnnydecimal.com/10-19-concepts/13-multiple-project...
But first visit to their web site shows numberings exceeding 10.
Ok.
Still a novel idea worth pursuing.
And yet, we've all been to a library. Information organized by topic, then by author, and inside the books everything is further organized into chapters, and then there's an index referencing all of that (plus a card catalog/search system).
I use something similar to the Johnny Decimal system described at work, except the high level is by project not by topic. I find chronological filing split into projects (i.e. chunks of time/money/effort) matches my workday better.
I couldn’t agree more. :-)
- johnny
Companies run on mental models that are occasionally partly solidified (and ultimately ossified) in a textual format.
Seems like better tech could improve this.
Arguably Whatsapp history already has, because at least stuff tends to collect in one place and be searchable, as opposed to being on desktops sent to individuals on request and forgotten.
Backporting old docs to this system is a real chore and honestly, I haven't been very disciplined about that part, besides moving old Project folders under the top-level Projects folder. But this is always going to be an issue with any new filing system, and I don't think there's a lot of value in doing it. Maybe would be an interesting programmatic exercise. But I, hotsauceror at his keyboard, am NOT going to go and retroactively assign a 753.0026 etc identifier to every document lol...
My rough, rough hierarchy is as follows:
I have recently added a 000 - Logs folder for places like coding journals, another trendy suggestion that pops up here on HN from time to time that I may or may not stick with...I had previously implemented it on my personal Nextcloud instance, but found it to be less impactful, as I already tended to over-organize my digital files.
I rely on it a lot for my personal data and projects. The simplicity and constraints have a positive impact on the usability of the organized information
It really grates on me when people offer solutions that work for them, as if they will work for everyone.
No.