[ssivark]

> Then, I go back to the implementers and tell them to design in a tagging system, which is a DIY taxonomy, and except in ridiculous use cases, I can make indexes make it fast enough to let everyone overlay their own classification system.

This 100x! I wish this were more common.

The key property of a tree is that there a unique path (address) for each element, which is a useful property in the implementation layer. But forcing that on users is a horribly leaky abstraction.

Ideally separate the low-level implementation from the interface, and allow users their own way to address content. I imagine object storage (with UUIDs or whatever) is often good enough for the lower layer. For the interface layer, tags are an improvement on categories (tree structure), but I think there's also room for more innovation (fuzzy matching, AI-driven interfaces, etc) that start by allowing trading-off precision for recall but then allow regaining precision by adding more approximate qualifiers to the filtering.

----

PS: Pushing this approach to 11/10...

An intriguing (crazy?) application of this idea would be: what if we did this to the concept of a codebase? Make it a database (with all the corresponding improvements over a filesystem) -- it's no longer a tree of files, and allow users to query code like "that foo which accepts a bar, frobnicates its internal state, and emits a mutated baz". Note that this might also solve the "naming things" problem.

This setup seems like a powerful abstraction for AI coding agents. All that back-end power (database >> filesystem) is something they can easily leverage, and they can also be built to robustly resolve your fuzzy queries into precise addresses, and then update the code based on your desired outcome.

[frogulis]

> that foo which accepts a bar, frobnicates its internal state, and emits a mutated baz

Tangential, but that reminds of the Haskell "hoogle" tool which allows searching for functions _by type_ across a large database of libraries, even by abstract types. So you might wonder "hmm what's that function that has a type structure like `t a -> (a -> t b) -> t b`?" and it'll happily tell you that it's monad `bind`

[Jarwain]

There's some prior work on the codebase thing:

[Unison](https://www.unison-lang.org/docs/the-big-idea/) content addresses every definition. Kinda interesting.

A [Code Property Graph](https://en.wikipedia.org/wiki/Code_property_graph) takes a codebase and turns it into three graph representations: it's AST, a Control Flow Graph, and Program Dependence Graphs. These graphs are overlaid and shoved into a single property graph. It's a structure mainly used by some static analysis tools like [Joern](https://joern.io/)

---

This has been a topic of a lot of interest and research for me. I've been experimenting with figuring out a system inspired by these ideas, among others, to apply the same idea (shoving multiple graph representations together) to a broader set of information

[m3047]

Tag Clouds were sticky tasty web goodness a few years back.

I've got a legacy tag cloud curation tool for random collections (each collection gets its own id) of URLs. It IFRAMEs each URL to present it; no whining. I've used it for classifying technical docs, photo libraries (then I used the tags to train an image classifier), and to present an analysis of a customer's web site.

It's written in Perl, and (still) runs on modern Perl. Make friends and maybe I'll toss the code your way and help you with your project.