Live data from Hacker News

Yet another hot take on “folders versus tags”

eleanorkonik.com

111–120 of 181 posts

Re: Yet another hot take on “folders versus tags”

#111
post #60

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 purp…

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.

Re: Yet another hot take on “folders versus tags”

#112
post #69

Earlier quoted context omitted.

Is there some reason that a filesystem couldn't be written to permit multiple paths to the same file without the clunkiness of sym links?

The problem with multiple paths leading to the same file isn't with the file system, but with the file system users. When you're writing scripts or programs against file systems it is really convenient to assume that each filename is one and only one file, that the file has a unique name, and that the file system is strictly a tree. File systems can technically break all of these; files can contain multiple files wit…

i make extensive use of hardlinks in my files (especially with photos), and i don't see the problem. if i remove a file, i don't usually want it gone completely, but i want removed from this particular location, if it is hardlinked elsewhere, i usually still want to keep it there.

if i want to really remove it, i can scrub the contents without removing the hardlink, and if i want to delete after scrubbing i check the hardlink count and search for the remaining entries.

Re: Yet another hot take on “folders versus tags”

#113

What can you do with folders that you cannot with tags?

It’s not about ability, but mindset.

Folders are tree structures where each file lives in only one place (in practice, hard links are uncommon, and symlinks are more common but obvious).

That abstraction is useful when navigating, looking for related files, etc.

Tags are more general. Yes, they could implement the features of folders, but the connotation of tags is that they are flat and unstructured.

Re: Yet another hot take on “folders versus tags”

#114
post #110
post #67

I keep my personal notes in an app that I wrote which is backed by SQLite. It resembles a wiki. First, I tried tags. This seemed like a good idea and was a lot of fun at first, but eventually I got _really_ tired of having to curate tags for all of my notes and boy there were a lot of them! It's not something you can just do once either, because every time you update a note you have to remember to change the list of…

for me, folders are just a limited form of tagging. since i switched from mutt with its folders to sup which uses tags for email, i don't want to look back. first of all, my extensive list of mutt folders was trivially translated to equivalent tags, so i could continue as i was used to. but then, tagging allowed me to create additional tags as i needed them. i didn't tag everything, and sup also indexes all mails and…

> for me, folders are just a limited form of tagging.

I understand that this is a very subjective thing... but folders offer an exclusion which isn't immediately available via tagging. Tagging is implicitly an OR operation.

Now, your search engine might offer ways to add "not X", but it's a tradeoff. It you have highly-compartmentalized bits of info you end up with the problem of "how much do have to explicitly exclude from my search?".

It's complicated.

Personally, I think we're missing a level of organization somehow.

Re: Yet another hot take on “folders versus tags”

#115
post #105

> Sometimes people will ask me what I do when I have something that could go into multiple places and the answer has always been pretty simple: if something could conceivably fit in two different folders I need to consolidate my folders. How does that not lead to an end result where you have one folder "everything", and thus no organization at all? There's always edge cases.

I've got over 2k files in my Obsidian vault and haven't had a problem really.

I think it depends on how you categorize things? I'm never going to confuse my tax documents with my short fiction, or my character profiles for a fantasy character for my daily notes page.

Re: Yet another hot take on “folders versus tags”

#116
post #110
post #67

I keep my personal notes in an app that I wrote which is backed by SQLite. It resembles a wiki. First, I tried tags. This seemed like a good idea and was a lot of fun at first, but eventually I got _really_ tired of having to curate tags for all of my notes and boy there were a lot of them! It's not something you can just do once either, because every time you update a note you have to remember to change the list of…

for me, folders are just a limited form of tagging. since i switched from mutt with its folders to sup which uses tags for email, i don't want to look back. first of all, my extensive list of mutt folders was trivially translated to equivalent tags, so i could continue as i was used to. but then, tagging allowed me to create additional tags as i needed them. i didn't tag everything, and sup also indexes all mails and…

The final step GP is describing would correspond to notmuch[1] for mail. Have you looked into that?

[1]: https://www.notmuchmail.org

Re: Yet another hot take on “folders versus tags”

#117
post #100

I've always wanted to see a "folder view" of a purely tags-based system. At the root level, `ls` shows you a list of tags (and possibly "all files"). cd into a tag, and `ls` shows you a list of the remaining tags (and relevant files). Repeat as many times as you like. Example session might look something like this: / $ ls -d foo bar baz / $ cd foo /foo $ ls -d bar baz /foo $ cd baz /foo/baz $ ls -d bar Obviously, at…

I'm really trying not to overly promote Supertag[0] in this thread (disclaimer: I am the author) , but it does exactly what you describe. 0. https://amoffat.github.io/supertag/

Does this also allow looking for e.g. files that are either in tag A or B or both? Intuitively I'd guess this is a limitation when you use a path to filter files, though I might be wrong.

Re: Yet another hot take on “folders versus tags”

#118
post #101

Earlier quoted context omitted.

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 having troubles visualising what you mean, without it becoming "just folders". Can you elaborate?

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.

Re: Yet another hot take on “folders versus tags”

#119
post #67

I keep my personal notes in an app that I wrote which is backed by SQLite. It resembles a wiki. First, I tried tags. This seemed like a good idea and was a lot of fun at first, but eventually I got _really_ tired of having to curate tags for all of my notes and boy there were a lot of them! It's not something you can just do once either, because every time you update a note you have to remember to change the list of…

> I wound up with many articles whose tags no longer (or never did) match the content.

I'm curious about your tagging strategy. Could you show some example of this issue?

I feel like my tags are very different since they're barely curated, but I can't imagine ending up with a "wrong" tag. I may miss some and have to add them later, but i can't remember ever removing or changing a tag. That's both in pinboard and in my scanned documents.

Re: Yet another hot take on “folders versus tags”

#120
post #67

I keep my personal notes in an app that I wrote which is backed by SQLite. It resembles a wiki. First, I tried tags. This seemed like a good idea and was a lot of fun at first, but eventually I got _really_ tired of having to curate tags for all of my notes and boy there were a lot of them! It's not something you can just do once either, because every time you update a note you have to remember to change the list of…

> To put it succinctly, my notes do not fit into a DAG. I think you mean "tree" or "hierarchy"? A DAG would be a superset of tagging, and could place SQLAlchemy under both Python and Databases, as long as you consider the edges oriented (i.e. there's a parent-child relationship). Doesn't solve the tag maintenance issue, though.

Technically, if their notes can't be represented by a DAG, they also can't be represented by a tree either.
Post reply on HN