I found your questions, and their phrasing, to be thought provoking and helped me clarify what I was thinking.
I can see that SDB graph could be used by multiple servers but SDB has some issues. In my case it is that it does not handle literal typing. Claude On Wed, Mar 27, 2013 at 5:38 PM, Dominique Brezinski < dominique.brezin...@gmail.com> wrote: > The reason I asked in the way I did was because your question and the > desired outcome was not clearly defined nor communicated. > > For example, the C api you describe for MySQL literally just speaks a > binary protocol that serializes SQL statements. It also does the auth > protocol and provides access to server variables, but it does not expose a > different model for querying/modifying data. If this is what you want, > Fuseki is the logical equivalent. Instead of the SQL over the MySQL > client/server protocol, it uses SPARQL over HTTP. Fuseki implements > concurrency control and provides a layer where authentication and > authorization could be implemented. > > Through follow-on responses, your desire has been somewhat clarified -- > you want an access method that serializes the Java Model/Graph API over a > network protocol to single logical Model/dataset. For multi-client access, > do you want ACID semantics for changes to the model, or would eventual > consistency be OK? > > As pointed out, using Jena with an SDB-style backend does achieve much of > what you want. There is a single dataset, but multiple processes or > processes on different machines can all operate on the Model/dataset using > the Model/Graph APIs. Since the underlying datastore supports concurrency > with defined semantics, you will get consistency across all the clients. > The important point here is you need to identify what, if anything, about > this approach does not meet your needs. For example, maybe your dataset is > fairly small and you need the performance characteristics of the in-memory > datastore. > > Dom > > On Mar 27, 2013, at 8:31 AM, Claude Warren <cla...@xenei.com> wrote: > > > I believe that there are "C" libraries for MySQL that use a low level > > connection, but that is neither here nor there. > > > > What I am talking about is more along the lines of a remove Graph > > interface. Something that does not use SPARQL but that uses the Jena > Graph > > model over the wire. > > > > +------------------- > > | SPARQL > > +------------------ > > | Fuseki > > +------------------ > > | ARQ > > +----------------- > > | Jena Model > > +----------------- > > | Jena Graph > > +--------------- > > > > I am talking about network connections that operate at the Model or Graph > > level not SPARQL. So it would be possible to take an application that > uses > > the Jena Model and run it against a remote or central Jena server. > > > > So that you can make Model.findSubjectsWithProperty( "foo" ) calls > against > > the server without having to convert it to SPARQL. The other advantage > is > > that the resources that are returned by that call can then be used as > > resources not result set values. > > > > The interface I am thinking of operates at a different layer and has > > different semantics from the SPARQL layer. > > > > -- Claude > > > > On Wed, Mar 27, 2013 at 2:55 PM, Dominique Brezinski < > > dominique.brezin...@gmail.com> wrote: > > > >> What do you think Fuseki is? What protocol is used by the MySQL client > to > >> query the server over the network? SQL. What protocol is used by the > client > >> to query Fuseki over the network? SPARQL. > >> > >> Using your analogy, Jena is more like InnoDB, and Fuseki is more like > >> MySQL. What exactly do you want to build if it is not Fuseki? > >> > >> Dom > >> > >> On Mar 27, 2013, at 1:52 AM, Claude Warren <cla...@xenei.com> wrote: > >> > >>> Currently Jena seems to require the use of Fuseki (or other web front > >> end) > >>> to handle multiple applications talking to the same > dataset/model/graph. > >>> > >>> Is this an intended (planned) direction or has there been any thought > put > >>> to the idea that a Jena server at a lower level. Something akin to the > >>> MySQL C API which, as I understand it, allows multiple application to > >>> attach to a single MySQL instance. > >>> > >>> What I am thinking of here is basically a Graph implementation for the > >>> client that uses a network connection to proxy the requests to a server > >>> component. All this without the need of installing Fuseki. This would > >>> allow multiple applications written against the Jena API to execute > >> against > >>> a shared Jena server. > >>> > >>> Other possible implementations are a Model implementation or a Dataset > >>> implementation. Or perhaps all 3, depending on the performance we can > >> get > >>> from the low level calls. > >>> > >>> > >>> +-----+ +---------------+ +-----+ > >>> |App1|------|Jena Server| -------|App2| > >>> +-----+ +---------------+ +-----+ > >>> | > >>> +----------+ > >>> | Fuseki | > >>> +----------+ > >>> > >>> Is there any interest in this? > >>> > >>> > >>> > >>> Claude > >>> > >>> > >>> > >>> -- > >>> I like: Like Like - The likeliest place on the web< > >> http://like-like.xenei.com> > >>> Identity: https://www.identify.nu/user.php?cla...@xenei.com > >>> LinkedIn: http://www.linkedin.com/in/claudewarren > > > > > > > > -- > > I like: Like Like - The likeliest place on the web< > http://like-like.xenei.com> > > Identity: https://www.identify.nu/user.php?cla...@xenei.com > > LinkedIn: http://www.linkedin.com/in/claudewarren > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> Identity: https://www.identify.nu/user.php?cla...@xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
