On my birthday last year I wrote up a snapshot of what was happening in my life. A year has flown by and so here's this years snapshot. Warning navel gazing commences...
Our second child, Martha was born last October and has brought as much joy to our lives as Ethan has. Being a parent the second time around is a much calmer experience as you've already built up all the necessary skills for looking after small children. Having said that it's also a lot more tiring! You've got two of them on the go at any one time.
We've virtually cracked the bedtime routine which means that we're getting relatively uninterrupted sleep at the moment which is a blessing. Martha is set to start teething at any minute, so I'm enjoying it while I can...
With two kids the house is feeling a lot smaller than it was and we've been thinking about moving. Exorbitantly high house prices make this unlikely for the moment, so we're thinking about a loft conversion.
Amusingly I look back at last year and see that I was rushing towards an application release. Well this year I can trump that as I'm currently shepherding two two application releases towards delivery. In fact my summer is likely to consist of a series of iterative application launches on a rolling 3-4 week schedule. Fingers crossed.
I've caught the gardening bug big time. We've got quite a long (albeit thin) garden which needs a lot of looking after. I decided to meet it head on and have gotten stuck into all sorts of digging, weeding, pruning, mowing and planting. I've added to the raspberry plants that already in the garden when we moved in (bumper crop every year so far) so we now have a burgeoning fruit garden containing blackberries, tayberries and now blueberries. Strawberries are next on my list. In fact most of the stuff I planted last year has survived so I must be doing something right I suppose.
I think the main reason I'm enjoying being in the garden is because it's a very welcome change from being chained to my desk. Some hard graft with fairly quick results. And there's nothing like sitting down at the end of the day feeling pleasantly knackered a popping the cork on a bottle of red!
Because of this new hobby, and the surprisingly good run of weather we've been having I've been doing less hacking and general geekery lately. Again no doubt a good thing, but I've got several projects that are sorely in need of attention. And I never get round to releasing that Trackback implementation. All in good time though. And then there's that SVG/RDF/Garden Design application I've been mulling over whilst digging through the flower bed...
Over the last year or so I've gotten more and more involved with RDF, as I'm increasingly convinced it's an important, if misunderstood technology. I'm hoping to contribute towards demonstrating it's strengths in my own small way.
XForms and XQuery are my current top XML technologies. I can see real benefits in both of these.
Finally made it to Amsterdam. It's been high on my list of places to go to for a while, I managed to spend the weekend before XML Europe wandering around the city doing a bit of sight-seeing. It's a pretty unusual place, an eclectic mix of communities. Which is what probably made it a good venue for XML Europe.
Prague is next on my list. Wonder what I have to do to convince Edd to have the conference there next year?!
My only other travel plans at present are the, now annual, family jaunts to Weymouth and St. Ives. An extended weekend at the Big Chill is something else to look forward to.
I've not done a great deal of writing recently because of home and work commitments. But I did find time to write a few pieces including a FOAF tutorial for XML.com which I was quite pleased
with. I also managed to contribute some hacks to the forthcoming "XML Hacks" book from O'Reilly.
Unlike last year I don't have to summarise what I'm reading or what I've read as the metadata is already available. Ditto on the music front, although I've only just begun to capture that data. Maybe next year I'll have sorted out that photo album.
Oh, and I realised on my way home this evening that I've now reach the point where my age and my waist can start racing neck-and-neck to see which one is going to get the largest the quickest. My money is on the waist-line.
I think that's enough rambling for now.
Nice article from Bill de hÓra about why he's using RDF and the advantages of doing so.
This reminds me of the bit of my XMLUK talk that I unfortunately didn't get round to doing -- ran out of time due to too much enthusing about XForms.
Basically I was going to take a stab at a sales pitch for RDF but one that tried to undercut most of the hype associated with the term "semantic web". A pitch that a programmer could more easily buy into. Comments welcome.
It went something like this:
If you adopt a common, underlying model for your data (the graph) then you don't have to worry about data storage and persistence mechanisms: you can leave the rocket scientists to design and optimise that for you. Just like you do now with an RDBMS, with the advantage that you don't need a DBA to design your data structures for you.
If you've got a common, underlying model for your data then you can access it uniformly. No need for different APIs for different types of data, and again you can employ a rocket scientist to design a query language for you, and it'll work against all your data.
If your underlying model has built-in support for merging properties, captured from multiple applications, that refer to the same object, then there's one less integration head-ache and one less source of application model changes E.g. the need to extend object models to add mapping into and out of different representations, annotate objects with extra data (or metadata), etc.
If your model had a normative mapping to XML so that you still gain the interoperability benefits of an open, Unicode compliant format, and your toolkit will do it for you (no more worrying about XML to object mappings!)
If you can write a declarative schema to help merge and relate your data to and from other sources then that's less code you need to write, and opens the possibility for many more interesting applications.
...and if it just so happens that whilst you've been playing with this other rocket scientists have slapped rule engines and reasoning frameworks on top of your model, because just like SQL it has formal underpinnings, then you can start to explore all sorts of cool features. Or not. All of the preceeding advantages still hold even if you don't use this aspect.
Wouldn't that be a nice environment to work in?
Any RDF hackers out there want to add anything?
Another great article from Sean McGrath: The mysteries of flexible software. Bang on the money.
I don't know how many times I've encounted software (and yes, some of my own devising) that has all sorts of wonderful flexibility but in all the wrong places. Time spent factoring applications into layer cakes, introducing endless layers of abstraction may have some benefits, but exactly how often do you go through an application and rip out the entire persistence layer? And when you do, what's the biggest hurdle: changing the code, or the data migration and testing involved to guarantee that you've not broken any of the data integrity? Exactly how often do you swap in and out XML parsers and XSLT engines?
I've been a keen advocate of design patterns for some time, but it's easy to get carried away: achieving a particular design pattern (or set of patterns) becomes a requirement in itself and that in all likelihood isn't going to affect the success of a product. The "Just Do It" aspect to XP is one obvious reaction to that experience. Renewed interest in more flexible, easy to author languages like Python is perhaps another.
Abstraction ought to be a defense mechanism. If a particular area of code or functionality is continually under change, then introduce some abstraction to help manage that change. Trust your ability to refactor. Don't over architect too early.
I've been skimming through the info URI scheme RFC. From the Cover Pages we learn that the scheme "was developed within the library and publishing communities to expedite the referencing by URIs of information assets that have identifiers in public namespaces but have no representation within the URI allocation.".
We also learn that "The motivation behind developing the info URI scheme is "to allow legacy identification systems to become part of the Web global information architecture so that the information assets they identify can be referenced by Web-based description technologies such as XLink, RDF, or Topic Maps. The scheme is concerned with 'information assets', not 'digital assets' per se, so the information assets may be variously digital, physical or conceptual."".
I'm trying to get my head around why it's necessary to have a new URI scheme for this purpose -- why not use a URN or an HTTP URI? For further discussion on that we have to look at "Section 7 Rationale" of the RFC.
One main reason seems to be passed on a desire to avoid any expectation of dereferencing semantics. Info scheme URIs cannot be dereferenced, they are for identification only. So the reason for not using an HTTP URI is because they can be dereferenced; one reason for not using a URN is because they're encouraged to have a mapping to a dereferencable form.
Another reason for not using a URN is persistence of the identifier. A URN is supposed to be a stable identifier for a resource, but an info URI has no claims to stability. To be precise: "The "info" URI scheme is neutral with respect to identifier persistence"
Unfortunately I'm still none the wiser to the actual benefits here. It seems that the info scheme gives me a non-deferencable, and in all likelihood non-stable identifier for a resource. Um, doesn't that give us the worst possible scenario?
Being able to dereference a URI is an important quality IMO; and thats one reason I like RDDL. If I can do a GET request and get the resource, or some metadata then that resource is bound into the web infrastructure. If the location isn't stable then following HTTP 3XX codes can lead me to the correct location. Redirection is one of the client-server co-ordination mechanisms that's built into the guts of the web, why not use it?
More discussion on info URIs here.
I've not encounted a URI discussion that doesn't have all sorts of hidden complexities so no doubt I'm missing something. Anyone else see any strong benefits of having a new scheme here?
Passing on a meme I caught from Norman Walsh. The fifth sentence on page 23 of The Diamond Age by Neal Stephenson is:
But while Lord Finkle-McGraw was not the sort to express feelings promiscuously, he gave the impression of being nearly satisfied with the way the conversation was going.
This isn't the book I'm reading, that's Foucault's Pendulum, this was just on my desk in work as I've recently lent it to a colleague.
The W3C have posted a Note discussing requirements for an XML Processing Model. This is good news, there's been a lot of desire to see this work progressing for some time now. Wonder whether XML Pipeline will serve as a possible basis for a specification? It seems to be a good match to the requirements.
It'll be interesting to see how this ties in with the DSDL work which is essentially defining a validation oriented processing framework. Frustratingly there's been little updates to the DSDL web site to see how far they've progressed. This xmlhack report seems to have the most recent summary of activities. Please update your site DSDL people!
I've been thinking about writing some Jabber services or bots recently as we've been trialling a Jabber server at work as a replacement for the myriad different messaging services folk are now using.
I've been hunting round, unsuccessfully I might add, for something as easy to work with as PircBot a Java IRC Bot framework. Not that it has to be Java as I've been making baby steps towards learning Python.
Anyway whilst leafing through my copy of Programming Jabber I started thinking about Jabber's extensibility and its use as an asychronous messaging component in a service framework. How might that be integrated with people-centric, desktop applications? And then I thought about Dashboard.
In the Dashboard architecture, cluepackets are used to send messages between front and back-end applications. Now what if there was a way to tunnely cluepackets through Jabber? Has someone explored this already?
There are some interesting possibilities here. Your front-end application may be talking to a backend on my desktop, e.g. whilst you're browsing for new music a cluepacket may ultimately get routed to my local backend (RDF backed, naturally) which can respond with my reviews and recommendations.
Tie this in with buddy lists and you've got a neat way to mine a community (your community of friends and colleagues) for data without having to index it all in advance. For example it could be used to pull together calendar data so you can co-ordinate a trip with your friends.
There's a Music Metadata Summit today at Stanford Law School. There's a conference "back channel" via #musicmetadata on freenode if, like me, you are geographically challenged.
Some interesting topics in there and a lot of overlap with FOAF (tipjars, playlists, recommendations, etc).
I'll probably be dropping in on the IRC channel later this evening.
The AudioScrobbler folk are thinking very hard about scalability. Having recently switched to a new database server they're now pondering what other changes they may need to make to ensure that the service scales as smoothly as possible.
In this posting to the audioscrobbler-development list Richard Jones outlines some proposed options. It seems that they've already tuned the database server and are considering changes to the submission protocol, the means by which your MP3 player submits track info.
The most fundamental change to the protocol, which is further described in the AudioScrobbler Wiki, is to do more on the client. Each client would hold it's own database of track information and then intermittently upload data, based on a interval controlled by the server. In the existing model data is POSTed to the server after a track is ~50% of the way through.
Personally I think the protocol could be adapted to be more RESTful. The key thing being to make each user account a resource which can have information requested from it (GET) or updated (POST). Making more use of GET ought to help scalability as caching intermediaries can better do their thing.
This would make an good optimisation/design exercise for RESTafarians to get involved with. Comments should be added to the Wiki or sent back to the mailing list.
Update: I posted a suggestion for an alternative interface which I think is more RESTful. I'd love to get this critiqued (hint, hint!)
Liam Quinn wrote an adventure game using RDF (data). Found via the SWIG chump, and noted here so I can find it again in the future.
I was reminded of it after stumbling across Inform a design system for interactive fiction that's been around since 1993.
Since its invention...Inform has been used to design some hundreds of works of interactive fiction, in eight languages...It accounts for around ten thousand postings per year to Internet newsgroups. Commercially, Inform has been used as a multimedia games prototyping tool. Academically, it has turned up in syllabuses and seminars from computer science to theoretical architecture...
This is exactly the sort of thing that could be a huge time sink for me. I used to spend vast amounts of time playing, designing and running role-playing games. No surprise there huh?!
Apparently Inform is based on a world model and accompanying rule system that deals with "rooms, items, vehicles, duplicates, containers, doors, things on top of other things, light and darkness, switching things on and off, opening, closing and locking things, looking up information in books, entering things, scoring and much more".
I've always been a frustrated game designer, that's why I used to spend a great deal of time on this project. Maybe there's still time. Text based adventure gaming is still all the rage isn't it?
I spoke at the XML UK Optimal XML event in Cambridge yesterday under the topic of "Scanning the Horizon: What's Hot in Upcoming XML Technologies". The talk seemed to go well, which I was quite pleased about. Lots of questions at the end which I usually take to be a good sign that people were interested enough to pay attention!
I ended up discussing mainly XQuery and XForms as the two technologies that I think are going to make most impact in the short term. I also gave a few demos using XQuisitor and XSmiles, having decided that it was probably better to showcase a couple of technologies rather than spend 40 minutes reeling off numerous different acronyms.
I'm quite impressed with the flexibility of XQuery and can see me adopting it in a number of cases where I'd normally resort to using XSLT. If you're going to take a look at XQuery yourself then I strongly recommend XQuery From The Experts which is a superb reference which covers the details of the language as well as some often frank discussion about how various design decisions were made.
XForms is a real pleasure to work with. I gave a quick demo of a trial XForms port of the FOAF-a-Matic, something that Micah Dubinko suggested I investigate a while ago. I wish I'd looked sooner as it's a really easy language to work with. I can recommend Micah's XForms Essentials book, but buy a paper copy as it's quicker to leaf through.
The main reason I go to these kind of events is to meet up with other people from the XML community. I encountered a lot of interesting folk at this event, including Sean McGrath who gave the opening keynote. Sean's presentation was excellent, very funny and insightful. I got chance to chat with Sean and ask a few questions I'd had about Service Oriented Architecture's. The most interesting tidbit that he left me with, and which had me buried in a Python tutorial on the journey home, was that when building messaging systems he writes Message Driven Beans using Jython, relying on the Bean Scripting Framework to mesh the two languages together. Sean has an interesting perspective on the relative merits of Java the language as opposed to Java the platform.
I also got time to chat to Tony Hammond and Ben Lund who co-authored the RSS 1.0 Prism Module. Ben was also responsible for the design of Urchin an online RSS aggregator that Nature Publishing Group built in collaboration with the JISC. Ben gave a presentation on RSS Best Practices and, based on his experiences working on Urchin, suggested the use of RSS 1.0 whenever extensibility was an important factor. Tony, Ben and I had an interesting chat about RSS, RDF and using RDF data models and stores.
NPG's exploration of RSS based applications are very interesting. I'm hoping to shortly unveil a number of the prototypes I've written very shortly. These use data (content and user activity statistics) from Ingenta.com to produce some interesting feeds. Got to get a big project out of the way first though.
XML UK are having another event in June (not yet advertised on their site). This one will be in Didcot, and will cover XML Schema languages. There was also a plug for the XMLOpen conference in September. It's pretty likely I'm going to attend both of these events and may submit papers depending on my workload.