[Mulgara-general] Mulgara as embedded engine

[Peter Becker]

Hi Paul,

maybe the problem with me not finding the documentation I am looking for (note 
that I am not saying you lack documentation in general, just for my use case) 
is that the feature I am looking for is not really there. I guess JRDF would 
be the one to go -- but as you said it is broken and while the JavaDoc might 
be ok it seems to lack introductory material.

If I understand you right what you recommend is using the same approach as 
JDBC: just grab a data source using some API and then switch to a different 
language (SQL or TQL). It's not what I was looking for since that lacks 
typesafety and editor support (no Ctrl-Space for you, buddy ;-) And no 
inline-documentation. And no syntax highlighting. Of course you can't 
refactor things automatically! ). At least you guys don't claim the approach 
is useful across multiple data sources as JDBC sometimes seems to do :-)

Since I will need only a small subset of the features I might go and write my 
own wrapping code to hide the strings away, though -- after all I will need 
only basic query expressions and no writing.

Regarding the source in Eclipse: I see your problem with the generated code. I 
have a Mulgara project set up, so I will try to extract the sources from that 
one.

Thanks,
  Peter


PS: a question still open: do I need to specify a directory or is there an 
option to run Mulgara in-memory only?



On Fri, 14 Dec 2007 04:34:33 Paul Gearon wrote:
> Hi Peter,
>
> On Dec 12, 2007 4:52 PM, Peter Becker <peter at peterbecker.de> wrote:
> > 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.
>
> While true, the interfaces are so simple that I never really
> considered that to be an impediment.  I've used a lot of commercial
> and OSS libraries, and JRDF (while not perfect) holds up reasonably
> well with it's Javadoc.
>
> I haven't been using the JRDF interfaces myself, as they were broken
> for a while.  But Andrae says they're working again, so they should be
> fine.  Have a look at:
>
> http://docs.mulgara.org/system/jrdfexamples.html
>
> > 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.
>
> Eclipse is flexible enough to allow for a lot of different
> arrangements for finding classes, libs, etc.  I've often found it to
> be confusing, but it does let you do a lot (with great power comes
> great complexity).  I suggest that sticking to a single pattern like
> this will always cause you grief, even if you never look at Mulgara
> again.
>
> Back to your situation.....
>
> Mulgara is a complex enough system that your approach is going to
> cause you problems.  It is far easier to create a project and use
> that.  But if you insist, then I suppose it can be done.
>
> The main problem is that a number of the classes used by Mulgara are
> generated.  These include classes built by Axis (for SOAP), rmic (this
> used to create .java files, but now only creates .class files), and
> parser code generated by SableCC.  It's because of these missing
> classes that Mulgara has compiler errors in Eclipse when you first
> download it.  Building the ideSupport target creates a jar file with
> all of those missing classes that Eclipse wants.  We haven't included
> this jar with the sources, as it changes with the source code, and it
> needs to be rebuilt with every change.
>
> Your script will get a lot of the code, but to get the generated stuff
> you'll also need to include the contents of
> obj/jar/*/java/
>
> So maybe you can run this from the root:
>
> for folder in src/jar/* obj/jar/*; do pushd $folder/java;
> zip -r ../../../mulgara-1.1.1-src.zip *; popd; done
>
> I'm not a big fan of the package system, but it's what we have, and I
> don't have time to rewrite it.
>
> > 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.
>
> If you're at UQ, then speak with Andrae Muys or Simon Raboczi, as both
> are enrolled there.  Simon wrote a lot of the code (and set up a lot
> of the build system IIRC), and Andrae is an active developer still.
>
> Also, have you looked at the docs?  I acknowledge that they are
> getting out of date, but they are still a good starting point.
>
> http://docs.mulgara.org/
>
> (The link is also on the home page for Mulgara)
>
> > 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.
>
> Yes, the documentation is getting behind, and I know it's a problem.
> Jena is much better with this, I know.  But you write like we have
> none at all.
>
> > 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.
>
> Jena is fine, works "correctly" and has many more features.  The main
> difference is that Mulgara can handle a lot more data.
>
> > 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?
>
> There are two type of tests in Mulgara.  Unit tests and integration
> tests.  And they're all run with JUnit.  While these tests can be
> useful for seeing how an interface works, you can also get lost trying
> to work out when an internal interface is being tested (which you
> don't want to know about) and when an external interface is being
> tested.
>
> Really, what you want to do is set up an ItqlInterpreterBean and call
> the methods on it using TQL queries and commands.  You can (and
> should) do *everything* through this interface.  This means that you
> don't have to learn much about the interface at all.  Instead you
> learn the TQL language.  This shouldn't be surprising, as it is the
> same approach used for talking to MySQL (yes, MySQL has non-SQL
> interface, but its use is discouraged - which parallels Mulgara
> exactly).
>
> The integration tests which use TQL commands are all in
> jxdata/iTQL/*/test.jxu.  The testing targets set tags in these files
> like @server@ to you local host, and then run a system called JXUnit
> on them.  All it does is set some values in a Properties map, and then
> calls eval() on a named class.  If you look in the test.jxu files
> you'll see all the queries that get run (giving good examples of how
> TQL works), and the classes that execute these queries are all found
> in src/jar/itql/java/org/mulgara/store/jxunit.  You'll see examples of
> how to use an ItqlInterpreterBean in these classes.
>
> If you persist with this, and you discover some stuff that you really
> needed to know that isn't anywhere in the documentation (or is
> possibly hard to find), then let me know and I'll try to get it in
> there, or make it more visible.
>
> Regards,
> Paul Gearon
> _______________________________________________
> Mulgara-general mailing list
> Mulgara-general at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-general