Re: rubyrdf

On Thu, 2003-09-11 at 06:02, Dmitry Borodaenko wrote:
> Ah, finally some traffic on this list! :)

Yes yes!  I'll be posting more in a couple days after I figure out a
technical issue with the GUI side of my project, so I can focus again on
the metadatabase parts.

> On Wed, Sep 10, 2003 at 11:59:04AM -0600, Aredridel wrote:
> > > My stuff was always a bit rough,
> 
> Yeah, that was one of the reasons I've decided to write my own RDF
> storage for Samizdat instead of hacking RubyRdf for my needs: I just
> couldn't force myself to lay hands on that code ;-)

Not so bad, but then, I'm comparing to what I have to write in PHP at
times. Now /that/ is an inelegant language.

> > > but I think there is now the basics of an interesting system falling
> > > into place: we have query engines, SQL backends, a half-decent RDF
> > > parser, etc.  but plenty of room for improvements.
> 
> Agreed. One thing in particular I would like to see is decoupling of all
> these components and development of a common RDF API for Ruby. And then
> have different projects such as RubyRdf, Redland, Samizdat, map to
> different parts of this API.

I, too, would like to see this. 

The OO Graph/Statement/Node approach is a good start.  Being able to say
	RedlandStore.new("file.rdf").store(Samizdat.ask(nil, nil, nil)) 

or equivalent would be killer -- common APIs for Node and Statement
enough that perhaps only Graph is implementation specific, and even that
would have enough of a common API that pretending they're the same would
work.

> > Yeah -- the code is functioning but ugly. Functioning is what other
> > RDF projects often lack in my experience, though.
> > 
> > I'm not sure as to the state of the SQL support -- I've found
> > basicrdf's Graph#toSQL, but dumping the entire graph from memory to
> > SQL as fresh insert statements seems counterproductive to me.  Am I
> > missing a greater part of the interface?
> > 
> > I've not made heads nor tails of RDF4R yet -- just the basicrdf
> > library.  I'm planning to run the whole thing through rbbr and rdoc
> > and browse a little more intelligently than my survey so far.  All I
> > know is that my sixth sense for what project is most promising says
> > "RubyRdf". <wry grin goes here>
> 
> Hm, why don't you take a look into Samizdat then? It doesn't need rbbr
> to grasp: the whole storage module is less than 500 lines :)

Yeah, but it's postgres-only, and there's a lot of plpgsql code that I
don't quite grok yet in there.

> And it is functioning (being the basis for a real project), and its SQL
> support is fairly advanced (being the core of the RDF storage).

Good deal.  I'll at least watch it for ideas.

> > > I'd be very happy to collaborate with you on this, anyway. Re
> > > alternate backends, I've had MySQL working OK btw., but am generally
> > > more focussed on Postgres. SQLLite would be interesting certainly.
> > Alright.  For Ruby, using the DBI layer might make the most sense,
> > though I'm using SQLite directly at the moment.
> 
> In Samizdat, I also use DBI, although, since I develop on Postgres, I'm
> using some Postgres-specific constructs. I know that it won't be
> possible to port it to MySQL (triggers, transactions, and subqueries),
> but I don't know enough about SQLite to check what may be missing there.

SQLite doesn't do any stored procedures, though it does have limited
triggers.  It's amazingly complete, actually.  I was surprised.

> > > Dave Beckett's redland is now quite nicely packaged with Ruby
> > > wrappers, so there is work we could do there too. So many things to
> > > do, so little time... ;)

> > There's plenty to do there.  I compiled redland and the ruby module
> > the other day, and was less than impressed by the API.  It's about as
> > un-ruby as one can get -- it's basically the C API wrapped into Ruby,
> > hardly object-oriented.  It might be okay to /use/, but extending it
> > in Ruby isn't going to fly without some major wrapping of the core
> > API. I'd love to see the API reworked into a proper Ruby module, with
> > all the namespaces sorted out and planned support for inheritance
> > added.
> 
> I think first we need to agree on what common RDF API for Ruby should
> look like?

Or just evolve it until some consensus is reached.  Each do what makes
life easy for them, and eventually, one or two Right Ways will show up. 
Then, in usual ruby fashion, do both.