3 ms·
I'd argue that "mental anguish" is probably less of a problem on the latter design, since the additional parenthetical material is used pure for disambiguation
by aragonite 3y ago
I'd argue that "mental anguish" is probably less of a problem on the latter design, since the additional parenthetical material is used pure for disambiguation (and so is optional), not for categorization. So, on the latter design we can have:
/Francis Bacon
/Francis Bacon (artist)
without having to answer anguish-inducing questions that would be raised by
/Francis Bacon
/artist/Francis Bacon
e.g. questions such as:
1. "Maybe we should put Lord Bacon under a category also, maybe `philosopher/Francis Bacon`"
2. "But he's also a statesman ... what about `statesman/Francis Bacon`? Is he more of a philosopher or a statesman"?
3. What about ordinary people (who happen to be involved in historical events) that have wikipedia entries, like George Floyd? Should he be assigned something like `person/George Floyd`? If so, should the two Francis Bacons be assigned `person/philosopher/Francis Bacon` and `person/artist/Francis Bacon` instead?
And so on
- dgb23 3y agoThat’s exactly right. And this is not just a “mental anguish” or “skill issue”. It’s a fundamental issue: Hierarchical naming and categorization sucks. In 95% of the cases, you want sets or even graphs rather than trees. You _might_ be getting away with trees, because you didn’t encounter a case where the hierarchy breaks. But you’re being fooled by happenstance. In the 5% of cases where trees are fine, you could also use sets or graphs. This issue comes up all the time with all sorts of things, including urls and file structure. The trick is to have a general “/type/name” format and to be as liberal and general as possible with what “type” means.