Hackathon project: Update RDF::Helper

Kip Hampton khampton at totalcinema.com
Mon Apr 12 18:41:09 CEST 2010


Kjetil Kjernsmo wrote:

> Since posting this yesterday, I found that RDF::TrineShortcuts and RDF::Helper 
> has more overlap in scope than I realised. So, we may want to consolidate or 
> find out if the two can co-exist with a clearer picture of their scopes. 

My goals fpr RDF::Helper were/are:

1) Provide a predictable, abstract DBI/DBD-like Driver interface for the 
various other RDF packages (Core, Redland, etc) that

2) includes certain sugary conveniences like URI shortcutting (mostly 
for predicates); object auto-detection (is the Object just a string? 
then the user probably means its a Literal) graph merging; and so forth, and

3) provides an RDF::Object interface (similar in theme to DBIx::Class or 
Class::DBI) built on top of the above Driver interface layer that 
allowed app-level coders to interact with RDF-backed Perl objects 
without having to know much, if anything, about RDF itself.

The general ideas is to have a driver-like system that would implement 
these common conveniences without, insofar as is possible, blocking 
access to whatever whiz-bang features the underlying modules offer.

RDF::Helper grew out of my need to switch underlying datastore 
implementations while we found one that would scale to the needs of the 
app. The convenience sugar and RDF::Object bits were a mostly-successful 
attempt to take the complexity and drudgery out of dealing with RDF in 
our applications.

I'll admit that, sadly, I haven't really kept up the Trine dev (or much 
of anything else in the Perl+RDF world) for the last couple of years. 
Ultimately, we never found a datastore that would scale to the needs of 
the app and I ended up having to replace the whole data foundation with 
an RDBMS, ORM and SQL queries. As much as I enjoyed doing the Helper, 
RDF was a poor choice and the endless delays resulting from trying to 
paper over the scalability issues ultimately cost us the contract. I 
haven't touched anything RDF-related since. That said, hope (and blind 
optimism) springs eternal and I'd be happy to help out where I can.

Given all of the above, I'm not sure where Teh Helper would even fit in 
the current Perl+RDF ecosystem. I think the general ideas are worth 
saving I'm curious what others think.

Cheers,
-kip



More information about the Dev mailing list