“There's flesh under that RDF-talk”

I normally shy away from weblog memes but George's shout-out does not deserve to go unrewarded. So:

And if you're wondering the answer is yes, but that would just be wrong. So. Very. Wrong.

Everything I said I wouldn't do

Here's the thing : I bought a Nokia 770 despite the common wisdom that you never buy the first release of anything. It is not a perfect device but it, in its own way, it is almost perfect for my needs. It has a decent web browser, it can play streaming audio (except Windows Media files which is only a problem because so many broadcasters publish nothing else) and has a shell. It is sort of awkward to hold for any length of time but it has a workable sketch application and I can, literally, stuff it in my back pocket. So this is what I did :

• Installed an X terminal.
• Installed a text editor.
• Installed rsync.
• Installed openssh.
• Set up aliases to pull down my address book and recipes to the memory card.
• Bookmarked both directories in the web browser.

This is good. It means that I have a reasonably up-to-date copy of the data I care about. Building and maintaining the headache involved in doing two-way sync is not something I care about. If someone gives me their phone number while I am away from my actual address book I will, you know, write it on a piece of paper. This is good enough. Here's what I learned doing all of this :

• The default browser (Opera) renders XML in Must Ignore mode which makes for an imcomprehensible mess of unformatted text.
• The device has no built-in HTTP server so there's no way to set up an Alias for a xml-stylesheet processing instruction. Hard-coding a path to /media/mmc1/recipe.xsl, or addressbook.xsl, in the source XML documents is not really anything I'm interested in.
• Opera doesn't even support XSLT.
• It was really easy to write a quick script to generate HTML versions of the recipe documents and pull those down to the 770 instead.
• (The address book was already being pulled down as raw vCard files which aren't sexy but can at least be viewed as is.)
• Writing Eatdrinkfeelgood documents by hand is a pain in ass. I don't really want to write a fancy GUI, or whiz-bang scrumjax, application to edit recipes. I mean I do but what I really want is to be able to write recipes by hand.

Stay with me. There's a point in all of this.

Writing a document should be possible with nothing more than a text editor and a little bit of patience, a straightforward, albeit boring affair. Hiding the details of the markup behind a user-friendly graphical interface would be a welcome improvement for many but it should not be a requirement. Similarly, a document should afford the reader the ability to easily understand its structure and content as well as the option of using it as a template for creating their own recipes.

I wrote that and it's one arm of the argument against using RDF, natively, for the next version of the Eatdrinkfeelgood markup language. The other reason is that RDF doesn't play nicely with XPath which makes it impossible (or impractical) to use with XSLT and, if it ever gets off the ground, XForms.

There's also been the idea floating around that version 2 would include a plain-text short-hand format that could be parsed into XML. Despite my reservations about RDF, the other night I started kicking around some ideas of using the N3 format as that short-hand.

A recipe for profiteroles, represented in RDF/N3.

The first thing that's nice about writing recipes in N3 is that it's plain text so browsers will display it without modification. It's an ugly duckling for sure but no worse, and I would offer better, than a raw Eatdrinkfeelgood 1.1 document.

We can argue about how easy it is to write N3 compared to a back of the napkin recipe or something like a wiki-syntax. I was surprised to find that the hardest part is remembering when to use () instead of [] containers. I'm not going to minimize how much of a nightmare it can be to write RDF but short of travelling down the natural languaeg rabbit-hole any markup is going to have it's pitfalls and at least this looks like a normal recipe.

Aside from RDF's ability to easily aggregate a number of different data sources, N3 affords people extensible dorkability without sacrificing (too much) readability. Consider :

• amount "1"; measure "cup"; dstuff "flour" .
• amount "1"; measure I:cup; dstuff "flour" .
• amount "1"; measure I:cup; dstuff f:flour .

I happen to find the second variation the most useful but I know a lot of people who prefer the third. For everyone else the first is about as easy as it's ever going to get.

The part where RDF doesn't work with the rest of the XML ecosystem that the web — meaning web browser developers — is starting to adopt is still a big problem. On the other hand, any other simplified format would require a parser and N3 is already spec-ed out and has a variety of implementations. I've always had this crazy idea that I could write a parser using regular expressions in XSLT 2.0 but I've never gotten around to trying.

Maybe then, the proper approach is to just use N3 as the default and ship with tools to generate XML. I'm not ready to commit — and the model itself isn't done — but the ability to build OS specific binaries, using py2whatever or PAR, to convert source files into XML is more interesting than it was a few months ago.

In the meantime, it would be nice if Nokia would put back the web server that's supposed to be in the embedded Linux they're using for the 770.

A widget by any other name

After something like a year comes another release of the ImageWidget base class, tools and actual applications including one to display random images from Flickr.

Both applications support the ability to copy a photo's URL to the clipboard, post a photograph to your del.icio.us account and, under OS X, use the operating system's speech synthesizer to read the title and description aloud. The FlickWidgt also allows you to favourite photos via a magic key combination.

These are not Dashboard widgets or Yahoo! (née Konfabulator) widgets or gDesklets although they are written in Python. Specifically wxPython which which is the language specific implementation of the wxWidgets (née wxWindows) GUI toolkit. They are standalone GUI applications built to run on any operating system with either the necessary code-y bits or that has a Python to binary executable converter.

Conceptually, the widgets are similar to the incredibly cool tickr application which is probably what I would have tried to write were I an OS X hacker. Operating system specific magic is pretty tempting some days but so is the ability to write myself little tools that will Just Work ™ on whatever machine I happen to be using. It all sounds like a Java dream gone bad and there are always issues but it mostly works. For me.

These are basically feature complete. The only thing keeping me from removing the beta label is being able to build binary versions for Windows. Version 1.0 of the Mirror Project Widget lacked an OS X binary because I didn't have a Mac (and that particular version of wxPython for OS X kind of sucked) and now it's the reverse for version 2.0. Once that's done, I will look into adding Windows support for the SpeechTool and updating the widgets accordingly.

• FlickrWidget 1.0b7 (.dmg)
• FlickrWidget Frequently Anticipated Questions

• MirrorProject Random Image Widget 2.0b8 (.dmg)
• MirrorProject Random Image Widget 2.0b8

• ImageWidget 1.0b9
• ImageWidgetDeliciousTool 1.0b2
• ImageWidgetSpeechTool 1.0b2

For the programming and Python wonks in the crowd, these are not the most elegantly designed programs you will ever see. Nor are they as easily extended as I would like. You live and learn, patches are welcome and all that good stuff. They work.

And finally : The FlickrWidgt is not an official Flickr application. Although I play a member of the Flickr team on TV this is all stuff that I wrote for myself, in my spare time, and I am sharing it with you in the hope that you will enjoy them as much as I do.

That is all.

Who cares?

I was talking to a friend about XForms, yesterday, and ended up quoting myself from a piece about RDF that probably won't ever be published. RDF, or any particular set of technologies aside, I think it's a useful way of approaching things on the intarweb. Everybody got pretty grumpy during the five-plus years it took for Mozilla to reach 1.0, for CSS to get implemented or for projects like Gnome to become usable. But here's the important part : They work.

What people are really saying is : That's nice but there are no applications to do anything interesting with RDF and I'd like to get my project off the ground this week. And they're right. They're right the same way that people were right when they said the same thing about CSS in 1996, JavaScript in 1999 and Mozilla in 2001. But it is wrong to confuse the merit of a format, or a specification, with application support.

Everyone understood that CSS was a good thing almost as soon as the specification was made public but in the chicken and the egg way that so many things happen there was little reason to use it without decent browser support and little reason for developers to implement it in an environment where it was generally dismissed. So too with JavaScript. Both now make up an indispensible part of the so-called Web 2.0 infrastructure.

Does this mean that in five years we will look back and wonder how we ever lived without RDF? Not necessarily but it is a good idea and one that deserves to be nutured and encouraged to see where it will lead.

What is Nokia thinking?

They probably don't know, I'm not sure the arrows are pointing in the right directions and the colours are awful. But it was a fun exercise.