Principle of Most Annotation

I've slowly evolved a style of taking notes and todos whose philosophy is very different to the approach that most people take. Instead of keeping notes and todo items in one place and sorting them on time or priority, I scatter them across a categorisational landscape. Instead of having push based todo items, I have pull based ones. There's been a fair amount of sweat and toil on the way to developing this style.

I spent a fair amount of 2003 working on note taking programs and data structures, ranging from the most ridiculously simple to the most hideously complex. To be simple, one can simply use unix "touch" and create files whose very names are the notes; most unix filesystems will allow any characters in filenames apart from "/" and null. On the complex side, on the other hand, I had used an RDF backend to manage associations between links, and studied some alternate topologies for binding notes together.

The whole process made me learn a lot of things. Foremost was that I don't like adding metadata, and so making the most out of the inherent metadata of a system is the way to go. Second, thanks to an aphorism from William Loughborough, is that the clutter is inherent in the organism. In otherwords, don't try to organise unorganisable messes, not least because if you do you'll probably lose information along the way anyway. Even so, I didn't really learn the combined corollary of these until recently: that making a mess is grand!

So I used to keep notes in text files, and in notebooks, but now I work more naturally by studying what I actually ended up doing anyway. For inamidst I have two hierarchies: one for the actual published website, and another shadow directory for stuff that I'm working on but haven't yet published. Since I invested so much time in the inamidst hierarchy making sure that all the URIs are to my pedantic liking, I figured that I may as well reuse it. So when I have something that needs doing, I create a file for it, and usually make a slight start on it. Or, as often happens, if the idea is simply an organisational one, I try to make the organisational change apparent. A recent spin is that I've been creating filename.todo files too.

So basically I'm using the filesystem to take notes, but alongside much of my current work, since one of the goals for inamidst is to make sure that I work on things there primarily so that I release them early and release them often. Due to the shadowing system, the "early" part doesn't actually happen all that often, but the synchronicity between the notes and filesystem means that the notes aren't segregated to some place where I'll just summarily ignore them. Instead, when I'm working on something, at the time when I'm most likely to work on a todo, I'll come across the previous breadcrumbs that I laid on the path. So, for example, say I get the urge to make a Python XSLT module. I might make a file called shadow/proj/xslt/xslt.py and put a few lines of documentation in there. Because it's next to my other XSLT hackings, I'll discover it again when I'm in the mood to hack on XSLT.

The ironic thing about it is that the filesystem hierarchy is a very forced categorisation mechanism and one which I'd rather not have to use, but on the other hand I would suspect that the system would work with non-hierarchical filesystems too, though perhaps in a slightly different way.