Recovered from the Wayback Machine.
I have to laugh when I read statements about the lack of technology related to RDF. I am at a point (past it really) with my book where I’m having to go through this huge list I’ve compiled of RDF tools, APIs, and applications and determine which to keep, and which to drop out of the book.
A technology book focusing on a small and finite subject can be exhaustive in its coverage of the subject, including every tool and every API. However, with a more general topic such as RDF, the key is to pick implementations that meet certain criteria; are unique and interesting; are best of breed; and are up-to-date, relevant, relatively bug-free, and relatively easy to install and use. Most of all, when determining what to include and what not to include, the writer has to keep the audience and their needs and interests in mind.
As an example of meeting my audience needs, in the book I’m covering various aspects of using RDF as ‘data: queries, RDF as a data store, and RDF and databases such as MySql. However, I only briefly mention Guha’s rdfDB — a pure RDF-based database. Why? Because there’s been no activity associated with it in some time; it’s still in beta; it’s been ported to only a few operating systems; and it doesn’t fit mainstream technology.
That “doesn’t fit mainstream technology” was a major influence in my decision to include, or not include, RDF implementations. For instance, I’m not covering any ‘C’ RDF API in the book, though ‘C’ has formed the backbone for applications development for years. The reason is because C is seldom used for web-based applications, and RDF is nothing if not web related. Additionally, C applications can be the most operating system dependent, and the most temperamental to install and configure. I don’t know about other developers, but I’m just not interested in playing Makefile tweak games any more. Been there, done that.
I was thinking this morning that, in some ways, my coverage of RDF reflects how our industry has changed so much in the last few years. Monolithic, standalone, linear, closed, function-based applications have been replaced by lightweight, modular, open, and object-based applications, usually hosted on the Web.
Applications built with ‘C’ and FORTRAN have given way, in most cases, to applications written with Java, Perl, Python, and C++. Distributed has replaced centralized. Open has replaced closed and secretive bits of binary blobs that only work within one environment, and only if you ask pretty please.
Social software has replaced data entry sheets. Documentation is no longer a dirty word. Anyone can peer beneath the covers, and the users have stopped being intimidated by the developers.
And anyone can be heard via “this-is-not-an-outline-dammit” weblogs.
