[Mulgara-general] Mulgara as embedded engine

[Peter Becker]

On Wed, 12 Dec 2007 15:59:45 Edwin Shin wrote:
> On 12/12/2007 01:34 PM, Peter Becker is rumored to have said:
> > - how do I load the RDF programmatically? Or do I have to submit a "load
> > <file:myrdf.rdf> into <local:///...>;"?
>
> If you use JRDF (http://jrdf.sf.net/) interfaces, you can create Sets of
> JRDF Triples which can be inserted into a JRDFSession. The list archives
> for last month should have a LuceneModel test case I sent around that
> has an example of this.

I have seen the JRDF website before, but the documentation there is sparse at 
best -- more closer to nonexistent.

With your example do you mean this mail:

  http://mulgara.org/pipermail/mulgara-general/2007-November/000204.html

I can't see any code for loading RDF files in that.

> > BTW: is there a version of the Mulgara source to bind against the JAR
> > within an IDE (in my case Eclipse)?
>
> see the README.txt in the root of the source distribution for
> instructions on building in Eclipse (basically, execute "build.sh
> ideSupport")

I know about that feature, but my usage pattern is a bit different: I don't 
set up a project for each library I use, I just want to be able to 
browse/debug into the source code at any time, so I check in a source-code 
attachment as ZIP file into my projects. Unfortunately Eclipse seems to 
insist for that to be flat, in the sense that the ZIP's root is the package 
root. The bit of bash I gave in the last mail seems to create that, but I'd 
like someone who knows the project layout to confirm that it should be 
allright.

But I think I might go back to Jena anyway -- things are just getting too 
complicated if I have to either understand the code base myself or ask about 
every little thing on this mailing list. Once the program is doing something 
halfway useful I'll publish it on SF anyway and then I can hassle the guys at 
the UQ to help me in adding Mulgara support. That is probably easier for both 
sides.

Although I don't want to sound bitter let me say this: I would hardly ever use 
a product with this lack of documentation in a Real World(tm) project. While 
a team might get up and running using this mailing list, tacit knowledge is a 
huge maintenance risk. So unless the project has a budget for documenting the 
missing bits Mulgara would never be an option, independent of its technical 
merits. And estimating that documentation effort could be tricky unless you 
already have someone who knows the product.

Of course that applies only to the use cases I am tackling here -- since I am 
currently not (yet) interested in the others, I can't tell how good or bad 
the documentation is for them. The only thing I am saying is that if Mulgara 
aspires to be used in the way I am trying to use it there is still a long way 
to go in terms of documentation -- although the equivalent to the short Jena 
introduction I linked would be a very good start. But maybe that is not 
really a goal of the project -- in which case I just stick with Jena for 
these cases. No harm done.

Just my 2c of course ;-)

  Peter


PS: as a last shot I might look into the unit tests for Mulgara -- somehow 
they would have to do similar things, wouldn't they?