The Jena interface has been removed completely (it had to use too much of Jena’s internals, and suffered badly because of it). The JRDF interface wasn’t doing ACID correctly at one point, but I believe this has been fixed, so I don’t think it’s exactly “deprecated” anymore. All the same, these are not the interfaces I’d recommend.

The 3 remaining interfaces (for the moment) are RMI, embedded, and REST. Fedora uses Mulgara as an embedded system. This is an identical interface to the RMI interface. The only difference is that the SessionFactory is a Database instance, and not an RmiSessionFactory.

REST is relatively recent (October 2008), and I’m still working on it (when I have time). It grew out of the SPARQL endpoint. You can do everything in it…. except transactions. I know you can do everything in it, because this is the only programmatic interface I use now. (I hate RMI). I’m hoping to get time to do REST transactions in a few months, but I have a lot of performance work to get to first, plus I need to learn more about how they’re done in REST. In the meantime, I should document it a little more.

Initially I didn’t want to call the interface “REST”, as a lot of people were very particular about what can and can’t be called REST, so I called it the “HTTP” interface. You’ll see some of my discussion of it on my (infrequently updated) blog: http://gearon.blogspot.com/2009/02/resting-ive-had-couple-of-drinks-this.html

I’m glad you got the JRDF interface up and running. If you want to use any other interfaces then please let me know, and this time I promise to be more responsive.

Paul

Thanks for trying Mulgara. Unfortunately, you came to the project with several misconceptions that hampered your initial review. I’d like to try to clear those up, while also admitting the legitimate criticisms you provided.

Mulgara is not a user-friendly system. You are absolutely right about that. The institutions that funded its development had requirements that didn’t include an easy path toward broader acceptance. That is a shame, but fact. It can also be difficult to keep documentation up to date in Open Source projects and Mulgara has definitely suffered from that.

However, Mulgara has never been designed to compete with relational databases. It is useful in specific cases where the traditional RDBMS data model is not efficient (that is different from saying where “relational systems are not efficient” because Mulgara is a relational system – just ofg a different sort).

The Jena and JRDF connectors are deprecated and not recommended for use. At the time Mulgara’s early code was laid down (2000, in a company called Tucana, which spawned Kowari), Jena was the most common way to deal with RDF. That situation has changed over the years with the introduction of RDFa, GRDDL, RDBMS connectors, SPARQL standardization, etc. JRDF was a project started at Tucana, but went its own way as well and is no longer useful with Mulgara. Poor performance can and does result from the use of those connectors, which is why they are not distributed. The best “modern” ways to talk to Mulgara are its included Web interface, command line, SPARQL endpoint and Java API.

Mulgara’s backing store, a transactional native quad store, is also undergoing significant changes. If and when we can get enough funding to implement our current designs, Mulgara will be able to store and efficiently query literally huge quantities of RDF. Until that time, you may have to play at a deep level to see the benefits.

Lastly, did you post messages to the mulgara-dev or mulgara-general mailing lists? I didn’t see any and the community surely would have responded. A quick check of the archives shows interest, activity and decent response times. I hope you look at Mulgara more closely.