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.
"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.
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/...
Can you elaborate?
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.
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.
In other words, similar to hardlinks
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.