You could hypothetically collapse the two though. You can have tags and could use those to automatically generate efficient organization structures.

For example, say you have the following datums with the following tags

  apple:     plant, Rosaceae, tree, fruit
  peach:     plant, Rosaceae, tree, fruit
  rose:      plant, Rosaceae, shrub, flower
  dandelion: plant, Asteraceae, herb, flower
  carrot:    plant, Apiaceae, herb, root
  pig:       animal, Suidae

You can then try to generate a folder structures that optimizes certain parameters like keeping the average number of children to not too far away from ~6 and/or minimizing the depth of the repo structure or whatever. Depending on how you wanna optimize it, you could end up with a number of structures such as:

  root
  - plant
    - tree
      - apple
      - peach
    - herb
      - dandelion
      - carrot
    - rose
  - animals
    - pig

or

  root
  - Rosaceae
    - apple
    - peach
    - rose
  - animal
    - pig
  - other
    - dandelion
    - carrot

You can use your imagination to think of better structures or optimization problems, but you get the basic point. We can have tags be our primary classification method and have the organizational structure be an outcome of that.

I like this approach: building a simple folder interface on top of a more flexible tag system, which can always be accessed when necessary. I think many systems would benefit from it.

There are tradeoffs, though: a fair bit of overhead for each heavily nested item. And you would want some support for ensuring the integrity of the hierarchies (i.e. someone accidentally removes "tree" from the tag set of "apple").

I implemented this for my email. Each email can have any number of tags. Each tag can have a directory hierarchy.

So for instance an email can be tagged fun/ski, social/facebook/marketplace, money/receipts.

If you open the social/facebook/marketplace “folder” you’ll see the email, but also if you open the money/receipts “folder”. You could also see it in the intersection of the social tag and the fun/ski tag, etc.

maybe on top of your idea ensure there's a graph feature like at the top right of https://help.obsidian.md/Obsidian/Index

Here's a library for writing such classification systems in Emacs Lisp: https://github.com/alphapapa/taxy.el

Especially, see this example: https://github.com/alphapapa/taxy.el#sporty-understanding-co...

An interesting hybrid approach I've experimented with in the past is to use tags while ensuring that the tags themselves are purely hierarchical. (Is there a name for this scheme?)

I'm not sure of a name, but Tiddlywiki does this. You create hierarchies by having tags by creating an item with the tag as its name which causes all items with said tag to be a child of that item. This has a nice side effect of allowing items to exist in multiple locations (so no unique parent is enforced) while still requiring the graph to be acyclic.

It ends up working kind of like hard links for folders/files, but it is a lot easier to setup since child items are the ones which declare where they are located, not the parents/directories. I think another reason why hard links are more difficult to use than this particular system is that with Tiddlywiki, it is easy to see all the locations an item falls under at once as well as seeing all the items at a particular location. I feel like adding this reverse location information would be quite helpful and would be less of a change than implementing tags for existing filesystems.

Sir Bimlas' TW5-Locator tool is worth checking out: https://github.com/bimlas/tw5-locator.

Forever ago I built something similar for generating canonical urls for SEO from a tag system (and to concentrate "google juice" from linking), though hierarchies were not strictly enforced.

"expert/american" and "american/expert" couldn't have duplicate content so you take your tag system and overlay hierarchies.

Anything that wasn't manually set was auto hierarchied based on highest traffic volume.

I also prevented tags from showing up on the same tag chain, so any given keyword could only appear once. That prevented infinite recursion.

Moving away from hierarchy also made interesting permutations easier to generate.

Since any metadata can become a tag, price or price range ($100hr – $300hr) is easy to generate and "enhance" American/Experts/Between$100and$300anhour.

It worked really well, allowed us to manually enforce high traffic hierarchies/phrases while still auto-generating intelligent canonical links for the rest of the site.

Didn't google punish your site for having duplicate entries under different urls?

I might not have been clear enough I think. I can clarify further if the below is insufficient.

That was the point of labeling 1 version of any duplicated permutation "canonical", to prevent duplicate content penalties.

https://developers.google.com/search/docs/advanced/crawling/...

I'm having troubles visualising what you mean, without it becoming "just folders".

Can you elaborate?

I am not the author of the previous comment so my view could be different. But I have thought about it. With tags, you could have got one note in multiple directories. Imagine I have found an interesting blog post on HN about SQLite in python. It could be problematic to decide is it more about python of Sqlite? Tags could look like this:

python, databases, SQL, SQLite, $date, FromHN, beautiful_site (I liked the look of this blog)

or in proposed system

/IT/Databases/SQL/Sqlite /IT/Python/libraries/SQLite /IntrestingHNposts/2022/July /beutiful_site

the difference between "just folders" and the proposed system is that you could have one note in multiple folders. Which gives you more flexibility in assigning notes to its topics. But it is still more structural than tags which could easily turn into an unpenetrable list of random words.

To be fair you could also achieve it with symlinks.

As a node in a tree hierarchy any folder can only have one parent folder. Tags of course allow nodes to have any number of parents (aka "associations").

The relationship between arbitrary nodes in a tree can be determined by tracing their common ancestry, but tags don't provide equivalent functionality, unless you strictly define how tags themselves relate to other tags. An obvious way to do so is to prescribe that every tag shall have exactly one parent (except for the root abstract "thing" tag).

In other words tags become folders, but any non-folder content of those folders can simultaneously live inside any number of folders. Similar to symlinks, but arguably less hacky, because there is no differentiation between "actual" location and "linked" location.

> Similar to symlinks, but arguably less hacky, because there is no differentiation between "actual" location and "linked" location.

In other words, similar to hardlinks

Right, yes. True. I should have compared with hardlinks instead.

Minor detail: I intended for different deletion semantics from hardlinks. Whereas hardlinks use reference counting for that (only the last deletion actually deletes); for my purposes, delete anywhere meant delete everywhere.

Maybe something like "hierarchical taxonomy", or just simply class hierarchy? Though I'm not aware of such a term that's explicitly for tags if that's the point.

The challenge is knowing which one you are dealing with at any particular time.