Comments on: Kowari 1.1 coming soon, Jena support removed

By: Andrew Newman

Andrew Newman — Sun, 25 Sep 2005 14:06:59 +0000

The Jena API in Kowari was initially just the Graph interface. As Tom says, the reason why it was extended further was to get a lot more performance out of the API - especially through querying (RDQL). By wrapping QueryHandler and the rest gave it orders of magnitude improvement in speed and scalability.

Although, everyone was still confused about it and the semantics didn’t quite match up (you had to wrap things in transactions using Kowari’s Session API).

All in all I think JRDF is going to be a bit better as an API for this kind of stuff - maybe even removing the need for transactions at all.

By: Tom Adams

Tom Adams — Mon, 12 Sep 2005 06:39:37 +0000

I believe we implemented Jena like that for a lot of extra performance. Jena uses a naive iterator-based query resolution system (get everything, then filter out what I want), so is rather slow and memory intensive.

I was starting to implement SPARQL support in Kowari, but it’s too hard to do TDD on a codebase like that, so I switched to implementing it in JRDF. The plan is (well from our end) is to implement SPARQL in Kowari by just upgrading the JRDF support.

JRDF is the application-level interface you should be using for programmatic access to Kowari. At Tucana, we always used that or straight iTQL.