3 ms·

Trees/hierarchies ("folders") are for organization, unconstrained graphs/networks ("tags") are for ontologies. Crossing these streams leads to a lot of trouble.

Trees/hierarchies ("folders") are for organization, unconstrained graphs/networks ("tags") are for ontologies. Crossing these streams leads to a lot of trouble. When flexible graphs/networks are abused for organizational purposes, you get circular dependencies, spaghetti code, and general dysfunction. Organizations (code or people) need to be easy to navigate. When rigid hierarchies are abused for classification purposes, you run into "class House, class Boat, class HouseBoat extends ???" knots. Ontologies need to be flexible. Modern filesystems necessarily use both: we have folders, and we have file types/tags.

irrational 5y ago
The challenge is knowing which one you are dealing with at any particular time.
culi 5y ago
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.
- pphysch 5y ago
  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").
  - throwaway_Aef8 5y ago
    maybe on top of your idea ensure there's a graph feature like at the top right of https://help.obsidian.md/Obsidian/Index https://help.obsidian.md/Obsidian/Index
  - bo1024 5y ago
    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.
- githubalphapapa 5y ago
  Here's a library for writing such classification systems in Emacs Lisp: https://github.com/alphapapa/taxy.el https://github.com/alphapapa/taxy.el Especially, see this example: https://github.com/alphapapa/taxy.el#sporty-understanding-completely https://github.com/alphapapa/taxy.el#sporty-understanding-co...
willbudd 5y ago
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?)
- deleted 5y ago
  [deleted]
- jeddy3 5y ago
  I'm having troubles visualising what you mean, without it becoming "just folders". Can you elaborate?
  - willbudd 5y ago
    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.
    - jholman 5y ago
      > Similar to symlinks, but arguably less hacky, because there is no differentiation between "actual" location and "linked" location. In other words, similar to hardlinks
      - willbudd 5y ago
        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.

irrational 5y ago

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

culi 5y ago

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.

pphysch 5y ago
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").
- throwaway_Aef8 5y ago
  maybe on top of your idea ensure there's a graph feature like at the top right of https://help.obsidian.md/Obsidian/Index https://help.obsidian.md/Obsidian/Index
- bo1024 5y ago
  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.
githubalphapapa 5y ago
Here's a library for writing such classification systems in Emacs Lisp: https://github.com/alphapapa/taxy.el https://github.com/alphapapa/taxy.el Especially, see this example: https://github.com/alphapapa/taxy.el#sporty-understanding-completely https://github.com/alphapapa/taxy.el#sporty-understanding-co...

willbudd 5y ago

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?)

deleted 5y ago
[deleted]
jeddy3 5y ago
I'm having troubles visualising what you mean, without it becoming "just folders". Can you elaborate?
- willbudd 5y ago
  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.
  - jholman 5y ago
    > Similar to symlinks, but arguably less hacky, because there is no differentiation between "actual" location and "linked" location. In other words, similar to hardlinks
    - willbudd 5y ago
      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.