WhyRubyRdf

Rationales and rationalisation for RubyRdf's existence.

At the time of writing (2003-04-20), the RubyRdf package has been a relatively solo effort on the part of Dan brickley, although it has benefited massively from other folks efforts. It is important to continually weigh up the pros and cons of undertaking such a project, and to be prepared to reallocate one's energies should there be no plausible story for why something is useful. This page sketches such a story, with the goal of having a better account for 'what would count as having done a good job'.

History and Acknowledgments

RubyRdf is DanBri's third attempt at an RDF implementation. It was preceeded by a similiar implementation in Perl begun while at ILRT, and before that, some work in Java in the DESIRE project in collaboration with Libby Miller, which eventually fed into her Inkling package. RubyRdf includes an RDF/XML parser that was originall contributed by Brandt Kurowski, and has also benefited hugely from the help of various members of the #ruby-lang IRC channel and the larger Ruby developer community, and of course from discussion in the RdfIG. Thanks are also due to Dave Beckett for including SWIG-based Ruby support in his Redland package, allowing for API-based rather than commandline interaction with his Raptor RDF parser. Listing acknowlegments is a neverending task: support for a wider variety of character encodings (via Raptor) was facilitated by the incorporation of Daniel Veillard's libxml library into Redland. This is important for the use of RubyRdf with Japanese content, since when Raptor was build with only Expat support, certain RDF documents were unparsable. RubyRdf also benefits from Max Froumentin's XSLT RDF Parser#5, although we don't yet have an API interface.

The earlier that this was based on included a BerkeleyDB-based store (largely written by Jasper Tredgold) which was in turn based on original designs for Mozilla's RDF system by R.V.Guha. In fact most of all this stuff was based around the Mozilla RDF design...

Goals and Motivations

What's it for? How do we know when it'll be finished? What's the value of DanBri hacking on this rather than, say, Cwm/SWAP or helping with the more polished RDF toolkits?

Here's why I find this worthwhile... --DanBri

(going 1st person for this bit...)

• When I started on this, Ruby was a rather nice language entirely devoid of RDF tools. This is now changing through the combination of RubyRdf (including Brandt Kurowski's RDF/XML parser) with glue code to Dave Beckett's Redland/Raptor software.
• Educational value: I've learned a lot about RDF APIs and QLs through implementing, and lately about testing and packaging through trying to get RubyRdf easily installable for some actual apps.
• I like Ruby, and the Ruby community, and would like to help show them some value from RDF / Semantic Web.
• Many aspects of RubyRdf are language neutral, lowering the cost of my coding in a different language. The SQL backend structures are shared with Libby's Inkling package, the API will hopefully be borrowed from Cwm/rdflib/etc where possible.
• provides a 2nd/3rd implementation for testcase driven collaboration on RDF query, APIs etc.

Risks

Reasons why I'm wondering whether to wind down work on this...

• Most of my collaborators (W3C, ILRT, RDFIG, SWAD-Europe...) don't code in Ruby, and collaborative coding is healthier, saner and more fun than going it alone.
• Cwm/SWAP looks fun, I'm tempted to code on that (though I don't know enough about rule systems to work with the core)
• the existence of RubyRdf might discourage others from attempting (and doing) a better job. (I do hope not, but it's a risk)

Reasons I'll continue for now:

• I want to work on commandline tool and API for common RDF tasks (see WebDataInterfaceDesign) that could be reimplemented around the other non-Ruby tools
• Ripping off the Cwm APIs for basic RDF operations means hassling the Cwm/SWAP hackers into documenting a stable target, and may provide a sanity check 2nd implementation of the basic ideas
• I think RubyRDF is in a state where it can be useful. It's apt-getable, the parser mostly works, and the SQL store it populates can be accessed equally well from Python or Java (though a stablised common SQL represention would be nice).

Next steps

• Packaging. RubyRdf has at various points worked nicely on Linux (esp Debian), MacOS X, Windows. But the dependencies on an xmlparser (typically expat) and a RDBMS setup make this costly. It should at a minimum be easy to install via tarball or Debian package on a linux box, ideally using package management to automatically install supporting packages.
• show SeedApplications, current plan is to show harvesting of events (EventDiscovery), person info (FOAF) and RestaurantReview data. Explore use of APIs versus query languages for these, with explicit focus on drawing out language-neutral patterns of interaction with an RDF dataset, ie. WebDataInterfaceDesign issues.