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

Designing better file organization around tags, not hierarchies (2017)

nayuki.io

Post reply on HN
Print view View original

21–30 of 169 posts

Re: Designing better file organization around tags, not hierarchies (2017)

#21

Post by heavenlyblue »

on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

Why can't you do the tagging with series of symlinks in one directory instead? It is essentially an index.

Re: Designing better file organization around tags, not hierarchies (2017)

#22

Post by xkcd-sucks »

xchaotic wrote: post #6

Tagging is the first step, but how do you know if you don't have overlapping or duplicate tags, say country and folk music? If you need something that fits both categories, you eventually start designing taxonomies and eventually ontologies, there's just no end to it. I think tagging is a sensible, lightweight approach, but it has limitations...

> Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

and any tagging scheme sufficiently good enough to describe the real world will implicitly create a hierarchical ontology

Re: Designing better file organization around tags, not hierarchies (2017)

#23

Post by mamcx »

on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

> The underlying implementation does not matter, we can always add a layer on top of the hierarchical file system.

I don't think so. hierarchical (trees) are too limited, and my intuition tell me that this lead to a impedance mismatch.

This is the reason the relational model take over, is far more powerfull.

To have something comparable, you need full graphs.

I think is not coincidence that tag-based filesystem have never take off, the tree-based file system can never be good for it, you need or a graph database or a relational database (or both?). And this probably is only viable on SSD/RAM-alike disks.

Finally tags are not enough. You need a way to do groups and alias and groups of groups, plus a way to full-text-search and seriously good metadata alongside the file...

Re: Designing better file organization around tags, not hierarchies (2017)

#24

Post by Symbiote »

roywiggins wrote: post #8
on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

I eventually had to use a series of command-line tools to shepherd my badly-organized photo collection into something like a usable state, and it basically involved finding all the JPEGs on my system, de-duplicating them, and dropping them into folders based on their date-taken metadata. It was a huge pain, and entirely an artifact of the tyranny of the folder-based filesystem.

for i in *.jpg; do date=$(exif $i --machine-readable --tag=0x9003 | cut -d ' ' -f 1 | tr : -) mkdir -p $date mv $i $date done

But don't many photo-browsing programs allow browsing by date, or even GPS-tagged location? e.g. on KDE's DigiKam I choose "timeline" view (or map view).

Re: Designing better file organization around tags, not hierarchies (2017)

#25

Post by wrs »

This is good thinking, and mostly overlaps with what I've tried to do a few times, so I would love to see it finally happen somehow.

For example, the Newton storage system I worked on at Apple 1990-1996 was based on separating organization from storage so we could have multiple (tag and/or hierarchy) organization systems. That eventually became the "soup" system in the shipping Newton OS, where objects were retrieved by content rather than hierarchy.

More recently, I spent some painful years working on Microsoft's WinFS, which had a ton of overlap with the principles here, and demonstrates just how hard it is to go from some nice principles that all seem like the Right Thing to an actual successful adopted implementation of the principles.

Re: Designing better file organization around tags, not hierarchies (2017)

#26

Post by tfolbrecht »

An approach I find interesting is the [Perkeep](https://perkeep.org/) or Google Drive model for post hierarchy.

Storing all files as objects and then indexing..

An interesting indexer for images would be one that groups objects by faces recognized or exif data(camera model, GPS location, lens, date, etc) Google Drive does this.

Perkeep can deal with tags, span devices, deal with permissions. Check out HN user @bradfitz

Re: Designing better file organization around tags, not hierarchies (2017)

#28

Post by nyir »

xchaotic wrote: post #6

Tagging is the first step, but how do you know if you don't have overlapping or duplicate tags, say country and folk music? If you need something that fits both categories, you eventually start designing taxonomies and eventually ontologies, there's just no end to it. I think tagging is a sensible, lightweight approach, but it has limitations...

That's what I was thinking, having used RDF a bit. I liked that the article touched on some more intricate details, things like the timestamp when a fact was added, or disputed facts (well, tags ...). But obviously it gets complicated quite quickly.

Re: Designing better file organization around tags, not hierarchies (2017)

#29

Post by megaman22 »

on_and_off wrote: post #5

>But fundamentally, there is a mismatch between the narrowness of hierarchies and the rich structure of human knowledge, and the proposed system will not presuppose the features of HFSes. This hits the nail on the head ! All the fileSystems I had to work with are fine as engineering tools. By that I mean using them as an engineer works just fine, their own implementation is off topic. As a user though. What the hell…

My problem, at least with Windows, is that it's an unholy mishmash of the two ideas.

I really just want something like a Unix filesystem, with a single root. Just with things coming off that root that actually make some goddamn sense and aren't relics from the PDP days.

Yet on Windows I have different drives that act as independent file trees, and then I have special folders that are handled somewhat differently, applications that save things in hidden folders that non-power users don't know are there, three or four different cloud storage providers that all need their own special folders, applications that can and cannot be installed in custom locations, weird special-case access control restrictions on some folders, some of the time. And all manner of other abominations.

It is far too much work to try to setup document storage in a sane way, and commit to actually doing it, and so my experience is that people increasingly don't even bother to try, and just flood their Downloads and Documents folders.

Re: Designing better file organization around tags, not hierarchies (2017)

#30

Post by alanbernstein »

xkcd-sucks wrote: post #22
xchaotic wrote: post #6

Tagging is the first step, but how do you know if you don't have overlapping or duplicate tags, say country and folk music? If you need something that fits both categories, you eventually start designing taxonomies and eventually ontologies, there's just no end to it. I think tagging is a sensible, lightweight approach, but it has limitations...

> Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. and any tagging scheme sufficiently good enough to describe the real world will implicitly create a hierarchical ontology

But it will create multiple hierarchies, as opposed to the single hierarchy to which you are constrained by a conventional filesystem.
Post reply on HN