Kowari 1.1 is coming soon. Congratulations to the Kowari team, they are through some difficult times and it’s good to see the project moving ahead.
I was slightly disappointed by this:
The removal of Jena support. Kowari v1.0 implemented a Jena storage backend and included an RDQL query language API. This has caused difficulties in maintenance and support as the two projects have gone in different directions. Kowari will remove (not deprecate) support for Jena as of the v1.1 release.
The Jena integration of Kowari was rather weird. They implemented the full API instead of just the internal Graph interface, which means they had to do a whole lot of extra work, and all they got from it was a bit of extra performance at a large cost of flexibility.
SPARQL is not yet supported as far as I can tell, but when it’s ready then that should be a good interface for most of the interaction between Kowari and applications using Jena.
SPARQL could cover queries, but what about updating the store from the application?
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.
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.