[Mulgara-general] Sommer

[Paul Gearon]

On 9/7/06, Henry Story <henry.story at bblfish.net> wrote:
> I suppose I should put a little context on my questions, though your
> answers have helped.
> I am writing a java rdf mapper called so(m)mer [1] that currently
> uses Sesame 2.0. Architecturally it is like Hibernate, in that it
> uses annotations and class rewriting to get its work done.

I've been thinking of doing something similar (in amongst the 100
other things on my plate ATM), though I was planning on making heavy
use of reflection and ASM, rather than annotations.

> Essentially a mapping between java objects and rdf is made by either
> assigning a java object a URI when possible, or assigning it a blank
> node. For this to work the mapping has to be constant.

Well the ID on a blank node is just an automatically assigned integer
that you have no control over.  If you don't like the one that Mulgara
gives you, then why not assign one of your own?
i.e. Instead of inserting blank nodes, just use a counter to generate
IDs for you:
sommer:1
sommer:2
sommer:3
etc.

This is exactly what Mulgara does internally for its blank nodes.  The
only difference is that we re-use numbers when they get freed up.
Otherwise, if there are no freed-up numbers, we just increment a
counter and use that.

The ONLY differences you'd find would be:
1. Every node you create will create an entry in the StringPool.
2. Node IDs will be consistent for the lifetime of the node (due to
the entry in the StringPool).

> Without that I would have to work by building up queries with Inverse
> Functional Properties and such which would mean the queries would be
> more complex as you say, and make my work more complex initially too.

Yeah, I avoid it where possible, but if your objects have a keying
identifier (read: Primary Key), then the queries get easy again.

> As I am still in the stages of laying the groundwork it looks like
> more complexity than I can deal with at present on my own. (though if
> people want to join and help out connecting mulgara to so(m)mer, then
> it would be great)

Maybe...

I expect to check in some significant progress in OWL very soon (I
hope).  I'll get back to you after I've done that.

> The Sesame Graph api has this fall out right, which makes my life
> simple. Of course it means I cannot really map my object to remote
> databases I guess, but that would make things quite slow in any case,
> or would require thinking deeply about caching. For the moment I am
> using Sesame's native database or its in memory database, so there is
> no problem with client server communication.

Well, using your own IDs would solve the remote database question.

As for it being slow... don't optimise prematurely.  Get it working
first, and THEN optimise it.  Besides, you may be optimising in the
wrong place.  Perhaps read-only sessions on Mulgara should cache
everything for you.  Since we only allow one read/write session (for
now), then caching would also be possible, so long as you checked that
the current session still has the ticket for writing.

> I will probably be looking at Mulgara for client server use cases
> which I can see popping up, independently of So(m)mer.

Let me know if there are any questions, issues, feature requests, etc.

Regards,
Paul Gearon