Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yet another hot take on “folders versus tags”

eleanorkonik.com

Post reply on HN
Print view View original

161–170 of 181 posts

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

#161

Post by tshaddox »

bityard wrote: 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 like tags which are structured as a tree, so that you can tag something as “Python” and it will also acquire the parent tag “Programming”. When you add a new tag for the first time you still need to eventually curate it by giving it other tags as parents if applicable. I suppose this is roughly equivalent to a directory structure where each item can be in multiple directories at the same time.

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

#162

Post by zdragnar »

em-bee wrote: post #136
Quekid5 wrote: post #114

Earlier quoted context omitted.

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

not sure i follow. can you give an example how exclusion works? all i see is that without using symlinks i can have only one folder/tag per item. i can choose to do that with tags too if i want, but i don't see how using folders helps with that other than forcing me to do it.

If you can nest folders, then a thing is all of its parent folders in addition to the folder it is directly contained in. This is the AND relationship, which you don't get with most tagging systems.

To highlight exclusion, consider an example- folder Animals with subfolders Cats and Dogs. A thing can be either a cat or a dog, but not both.

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

#163

Post by tatersolid »

em-bee wrote: post #112
jerf wrote: post #69

Earlier quoted context omitted.

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…

Doesn’t a lot of software break hardlinks on edit? I think non-database software usually completely replaces the file via overwrite or atomic rename.

Sometimes you might want that behavior, but other times you might not. But there’s no option in any app I’ve seen to choose how to handle hardlinks on edit/save.

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

#164

Post by charlieyu1 »

bityard wrote: 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…

How good is the search performance? I have used an a couple of apps that provide full text search, but it is very slow when the number of notes is large.

I think the best solution is a mix of 3, folder structure with tags, full text search when needed

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

#166

Post by fouc »

alpaca128 wrote: post #155
fouc wrote: post #150

Earlier quoted context omitted.

I think it's possible to avoid using symlinks and just use plain folders to represent tags only. By using a special naming strategy on the folders themselves, it would be possible to have a set of scripts for "tagging" files and operating on them. Tagging would be equivalent to just moving the files into the relevant nested tag directories. No duplicate files or symlinks necessary.. Can make scripts like tagcd and ta…

I don't think that would scale. The nested directory structure could reach a depth equivalent to the number of tags to support all combinations. Meanwhile with symlinks you only need one folder per tag and it can be comfortably used with file browsers.

If there was a limit of 10 tags per file, then the max depth would be 10 folders.

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

#167

Post by ciphol »

stickfigure wrote: post #86

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 think 'ls' should show you tags plus any untagged files. Thus no files "fall through the cracks" due to not being tagged.

So if your files (and their tags) are as follows:

  file1 ()
  file2 (t1)
  file3 (t2)
  file4 (t1,t2)
your session would look as follows:

   / $ ls
   t1 t2 file1
   / $ ls t1
   t2 file2
   / $ ls t2
   t1 file3
   / $ ls t1/t2
   file4
And 'ls' should have a flag to show all files regardless of additional tags:

   / $ ls -a
   file1 file2 file3 file4
   / $ ls -a t1
   file2 file4

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

#168

Post by ciphol »

ryanjkirk wrote: post #54

Folders work perfectly in a pure hierarchical taxonomy. Many classifications defy this rigid of a structure, however. For example: Widget 1: it is A and B but not C, so tag it with A and B. Widget 2: it is A and B and C, so tag it A, B, and C. Widget 3: it is B only, so tag it B. That is pretty simple, but you couldn't represent that in a folder system without permutation folders, meaning you now have folder sprawl,…

Folders have the weakness which you describe. But that weakness is also a strength - folders are a form of encapsulation which, for example, discourages or prevents processes in one folder from destroying data in another folder (accidentally or maliciously). With just tags, that is a bigger danger.

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

#169

Post by jholman »

willbudd wrote: post #118
jeddy3 wrote: post #101

Earlier quoted context omitted.

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

> Similar to symlinks, but arguably less hacky, because there is no differentiation between "actual" location and "linked" location.

In other words, similar to hardlinks

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

#170

Post by EleanorKonik »

PeterisP wrote: post #142

I strongly disagree with the article's assertion "take my word for it — it’s much easier to tell a computer “do this to every file in this folder” than to tell it “first, find everything with this tag, then put those into a string, then do a thing to every file in this string…”" because in most reasonable filesystem API's that's exactly what you would do with folders - first, find everything matching this wildcard fr…

It's easier in the sense that if you're a brand new baby programmer, it takes fewer easily-findable-via-Google commands. Sorry if that wasn't clear!

The article wasn't really written for the HackerNews audience, sorry I never expected to wind up here — it was written for, like, college kids majoring in archaeology.

Post reply on HN