You're viewing a "classic" blog entry.

Navigation

2007‎ > ‎11‎ > ‎07‎ > ‎

The State of RDF support in Ruby (2007): Conclusion

In my last article "The State of RDF Support in Ruby (2007)," I did a quick overview of the available implementations of RDF for Ruby, and talked about the history, strengths and weaknesses of each.

I'd like to talk about where we should go from here. I'm not the King of RDF(tm) for Ruby, so obviously this is just my opinion, and the community as a whole needs to take on this challenge, but I'd like to help spur the community to action...

The Ruby community would benefit greatly from an RDF implementation that is fully compliant with the specification and embraces the ideals of RDF. Here are some ideas about how such an implementation would look, and how it would help the community.

Pure Ruby. For portability purposes, a pure Ruby implementation would go a long way. It may not be the fastest, but it would be a portable way for someone to do experimental work with RDF on a small scale, and to do so anywhere that Ruby can go.

Modular. RDF is a graph-based model, and so it seems obvious that in addition to a pure Ruby graph implementation there could also be graph implementations that talk to high-performance triple stores. It also makes sense that this RDF library would try to provide a consistent interface across all of its graph implementations, so having something like a pure Ruby reasoner that could be mixed into graph implementations for triple stores that do not support reasoning would be very helpful.

Distributed. One of the main ideals of RDF is distribution. In some cases it may be necessary to pull the triples from a remote graph into a local graph (such as when querying an RDF/XML document), but in all other cases pulling in every remote triple is not scalable. Additionally, it should be simple to consolidate graphs into a single interface that can be queried, and that query should be federated out to each of the remote triples stores, with the reasoner reasoning across all of those triple stores.

There have been calls in the past to unite those interested in Ruby and RDF. Dan Brickley setup a Public RDF Ruby mailing list to be used for coordination between people interested in furthering the cause. Dmitry Borodaenko (author of Samizdat) posted a message there four years ago proposing a unification of Ruby RDF interfaces.

So my challenge is, if you're interested in RDF support in Ruby, join the Public RDF Ruby mailing list, and let's start a conversation about where we should go. There's a lot going on now. In my estimation RDF in general is gaining a good bit of steam, the redland bindings needs someone to officially support them, and Ruby has great potential in this space.

Addendum

I wasn't sure if I wanted to do this, but here is some code I've been working on. I don't want to fragment things further, but I would imagine it becoming a general 'rdf' gem and that there would be 'rdf-sesame,' 'rdf-mulgara', 'rdf-redland,' etc. gems as plug-in graph implementations for different triple stores.

This implementation includes a fully compliant RDF implementation of a pure Ruby graph with a mix-in query executer, NTriples read/write support, and pretty good test coverage. It does not have a reasoner, but I do have an implementation of a reasoner from a previous iteration in an SVN branch that I could re-appropriate for this iteration.

I'd create a new RubyForge project, but I have two concerns: 1) I don't want to take control of the name 'rdf' as a gem without having some kind of consensus support in the community, and 2) there are several other RubyForge projects related to RDF and maybe my code would be better served to integrate into one of them.

Originally published on November 7, 2007 at 11:57

Comments

  1. Lyle Johnson Says:
    November 27, 2007 at 10:33 am

    Paul, I sent you an e-mail on this a week or so ago but never heard back from you. I’m glad that you’re taking the lead on this, and I’m about to download your code to check it out (I’ll also subscribe to the mailing list).

    I think you might as well go ahead and set up a new RubyForge project since most or all of the other projects (with noted exceptions) are dead. I don’t think you should call the gem “rdf”, however; I’d try to come up with some other name.

  2. danbri’s foaf stories » RDF in Ruby revisited Says:
    February 8, 2008 at 2:31 pm

    [...] the list of libraries, but Paul Stadig has already done a great job of this recently (see also his conclusions, which make perfect sense). There has been a lot of creative work around RDF/RDFS and OWL in Ruby, [...]

  3. Dan Brickley Says:
    February 8, 2008 at 3:00 pm

    Hey there! Great posts. I found them after meeting up with Rich Kilmer last week. RDF toolkit convergence in Ruby is long overdue. Let’s get all interested parties on the W3C list and throw some ideas around there?

    I don’t have a lot of time to code, and others could do it better, but I’ll help in any other ways I can. I just posted http://danbri.org/words/2008/02/08/270 with some of my wishlist items.

    Probably the simplest strategy is to begin with an RDF/XML parser plus basic api, and work up. There are several parser options already, I think first step ought to be to evaluate them against the W3C Test Case files, but also benchmarking and a unicode strategy are important.

  4. Dan Brickley Says:
    April 3, 2008 at 8:09 am

    Hey there, just a ping to see if you could drop a note to public-rdf-ruby@w3.org with any progress/ideas you have. I’d love to see some collaboration towards a modernised Ruby RDF library…

  5. Edward Benson Says:
    August 7, 2008 at 9:27 pm

    Have you gotten any farther along on this? I’m interested in doing a bit of RDF hacking in Ruby and was wondering if you needed some spare hands to help out.

Č
ċ
ď
rdf-0.4.0.tgz
(25k)
Paul Stadig,
Nov 3, 2008, 10:54 AM