Adding tags to wiki pages

You know, it’s interesting that Jon Udell should talk about adding tags to wiki pages for categorisation when just a few days before his post Gareth and I were talking about exactly the same thing.

The problem with the existing systems, and the examples Jon quotes is that you not only need to know what you’re doing, you have to know how to do it.

Jon says that c2 and SocialText actually do it already, is by using “category” as a keyword, so at the end of a doc you add “categoryTAG”, then you can list all pages with that tag by performing a search on “categoryTAG”. Except that’s not really true. It actually is what it sounds like, a relatively artificially imposed flat classification, with no true backinking or relationships where the “tagging” can get lost in the middle of any page. The success of this system is almost entirely down to good stewardship by the people who run the wikis which use it.

Trac also lets you do this with the rather arcane [[TagIt(wiki, folksonomy)]]. Well wow, I had trouble explaining to some people how using asterices around a word made it bold. Good luck explaning that one.

So what would be better? Well, given a web-based wiki where you have to explicity move between “read” and “edit” modes, what’s wrong with asking the user to add some tags when you first create the page and listing them alongside it? Basically, I think what I’d aiming for is “copy Flickr” (just like everything else that’s good on the web these days), where you can edit the tags assigned to a photo without having to move into editing all of its other properties.

Keeping tags as a property of the page, rather than an intrinsic part would allow you to start actually doing work with them such as page relationship analysis and subject categorisation, instead of trying to manually maintain lists of pages which contain your magic linking words, which is what c2 and SocialText do.

I think tagging pages is a natural progression for wikis, and a damned good idea, but that it needs to actually be added to the underlying wiki system, not awkwardly shoe-horned in by the users.

Posting stupidity

About a year ago (or maybe more) I stopped using Blogger’s web posting interface and started using w.bloggar because whilst writing my post I’d be looking up resources, gathering quotes etc. etc. and just every now and again my browser (whether it was IE or Firefox) would crash, leaving me with nothing.

Just over the past month or two I’ve been getting back to using Blogger’s web interface, even when I’m on my home computer. So, I was just finishing a post that was a couple of hundred words long, and guess what happened? 🙂

So, at the very least as a note to myself – use a desktop tool to compose your posts! It could even be notepad! Don’t be a dumbass!


FOAFlicious 0.1

FOAFlicious is an application for generating a FOAF file from your inbox.

FOAFlicious is written in Groovy, and can be seen in action on (hopefully this URL will become better in time).

This is the first time I’ve ever used Groovy and so far I’ve not been able to configure it to accept URL parameters (answers on a postcard please) so it’s currently hardcoded to return a FOAF file based on my inbox, here’s looking at v0.2 🙂

The inbox facility is currently turned off except for the list of subscriptions so it currently works by masses of screen-scraping. As soon as the inbox comes back it should be able to switch to using the API (probably using David Czarnecki’s delicious-java API).

Currently it uses the page for each user listed in your inbox to extract a user’s real name and homepage, then looks at their homepage to see if they have a FOAF autodiscovery link, and if so includes it in a <rdfs:seeAlso rdf:resource="blah"/> block.

The (terrible) code is available on it was only written in a couple of hours, so no abuse please 🙂 In order to run it you’ll need the Groovy libraries, commons-httpclient, commons-logging and JTidy.

If you want to stay notified about this project, it has its own feed.

For reasons of my own sanity, you can add comments and questions about this over here.

How to export Firefox’s history to a text file

Note that this doesn’t currently work in Firefox 1.5

Specifically, serialised as RDF/XML.

Early last year, Jamie Zawinski asked about how to extract information from Firefox’s history.dat file and ended up having to write a Perl script to do it.

He actually got further than most – most people who try to access the data not via Firefox itself just give up. This is because Firefox’s history is stored in a Mork file, which is an incredibly over-complicated and under-documented proprietary file format. You’ll learn more about it by reading the comments on Jamie’s post that you would by reading the docs.

Mork is used as a file format all over Mozilla, in both Firefox and Thunderbird in various points, but there are plans to replace it with SQLite in Mozilla 2.0 (see Unified Storage on the official Mozilla wiki) possibly with some interfaces made public via RDF (but I’m not 100% sure on this).

As it stands, there’s an open bug asking for history.dat to be easier to parse (which will probably be fixed by the move to SQLite rather than anything else) which actually has a very useful piece of Javascript attached which will convert the Mork history.dat into an RDF/XML history file, which I personally use as a bookmarklet from my toolbar: export history.dat. Just drag it to your toolbar, load a local file in Firefox to ensure you’re in a trusted context and click it like you would any other bookmarklet. It’ll give you a security warning, which you can click “yes” to (if you trust my link – if not, you can get it from the bug linked to above, or look at the code yourself). It’ll take a few seconds to kick in (or longer, depending on the size of your history) but will eventually ask you to specify a location to save the file to. Give it a name, and you’re free to parse it with whatever you like (although preferably an actual RDF parser 🙂

How to find out which books I’m reading

Andrea wants to be able to stalk my reading list.

I use to keep track of which books I’m reading, which ones I’ve completed, which are my favourites, and so on.

When I start or finish a book I load up Firefox, select the Amazon search engine from the search box, type in the ISBN from the back of the book and then click my consume! bookmarklet, select a status, and hit “save” (adding some extra book metadata if I’m feeling particularly generous with my time) at which point the book is added to my list.

Anyone is then able to browse those books on letting them see what I’m currently reading, what I’ve finished reading and what my favourite books are.

What, however, I had planned to do for this site, was to utilise the RSS feed for the books I’m currently reading (also available in a proprietary XML format either via REST or pre-generated XML file) and the PHP-based Magpie RSS Parser to display a list, but it turns out that not only does the ‘currently reading’ RSS file not provide links to images, All Consuming only provides RSS feeds for your “currently reading” and “favourite books” lists, not which ones you’ve completed, which you’ve bought, never finished, and so on so the best I would be able to come up with would be something like this.

So. Until I get around to either writing a stylesheet for converting All Consuming’s XML format (which includes a link to a picture of the cover from into RSS (or I find one on the web) or something which parses it directly, you’ll have to make do with my page on All Consuming.

So Andrea, happy now? 🙂