[Mulgara-general] Sommer

[Henry Story]

Thanks for the answers.

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.

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.

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.  
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)

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.

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

Henry

[1] https://sommer.dev.java.net
     see longer description here:
https://sommer.dev.java.net/servlets/ReadMsg?list=users&msgNo=131

On 7 Sep 2006, at 20:23, Paul Gearon wrote:

> Hi Henry,
>
> On 9/7/06, Henry Story <henry.story at bblfish.net> wrote:
>> Hello, I see things have  been moving on with Mulgara...
>
> It's moving, but not always in anticipated directions.  I know that
> each of us has features we're trying to develop, which means that some
> essential features are not being worked on yet.
>
> Just saying this so people know that we're doing stuff, even if
> doesn't show up as the bug fixes or features they are waiting for.
>
>> So I was wondering if the following had been implemented yet:
>>    - Is there a way to query the store in a way that one can keep
>> track of anonymous nodes? In sesame one can query a graph and
>> anonymous resources will be identical between nodes
>
> Yes and no.
>
> If someone is deleting and inserting blank nodes, then the IDs will be
> re-used.  This is why we make no guarantees about the IDs behind a
> blank node from one query to the next.  This is completely consistent
> with the RDF specification.
>
> That said, there are ways around it.
>
> - If you can guarantee that no one else is writing to the database,
> then the nodes will be the same.  Not an easy guarantee to make
> though.
> - If you keep the same session object, you will always get a
> consistent view of the data.  This is because you read a fixed phase,
> and no writes will be visible until you update to the latest phase.
> Make sure you keep the same session to guarantee that the data stays
> consistent.  This is only a viable option if you are doing a series of
> reads at one time, rather than coming back some time later.  I rely on
> this behaviour in the rules engine.
> - Follow RDF Semantics, and select blank nodes according to a unique
> labelled node (URI reference or a Literal), or unique set of nodes.
> This will always work, but can lead to unwieldy queries in some cases.
>
>
>>    - can one query such a graph and have inferencing.
>
> Inferencing requires writes from another session.  If you kept the
> current session alive then you wouldn't see the inferred statements.
> If you DON'T keep the current session alive, then you don't know if
> anyone deleted and then inserted statements.
>
> That said, inferencing does not delete any statements (this is a
> consequence of the open world assumption), so if you know that no one
> else will be doing any writing, then you're OK.  You're skating on
> thin ice though.  :-)
>
> In reality, the best way to handle it in this situation is to use
> labelled nodes to find your blank ones.  This is always possible,
> otherwise you'd have no way of accessing those nodes in the first
> place!
>
>
>>    - does one still need to connect via a client server?
>
> I don't understand this question.  The client is not, and has never
> been, a server.  The "client" is just a library found in the
> itql-1.0.0.jar file.  You access it with the ItqlInterpreterBean
> class, which is really just a thin wrapper around the ItqlInterpreter
> class.  The library also includes the ItqlSession class, which is the
> GUI console for interactively making queries.  (this "interactive"
> console is the "i" in "iTQL").
>
> I understand that ItqlInterpreterBean has been made to work with SOAP,
> so non-Java applications can use it, but I heard that this may not be
> working all that well at the moment.
>
> Hmmmm, I should also mention that servers have a client built in, and
> that this client is accessible from a web page.  However, no
> real-world system should ever use this, as it was created solely for
> demonstration purposes, and it is HTML only.  It also has a history of
> bugs which are enitrely due to it's integration into the server JVM.
> If you are asking about this, then my answer is to learn to use the
> proper interfaces (ItqlInterpreterBean).
>
> Did this answer your question, or are you referring to something else?
>
> Regards,
> Paul Gearon