Re: Architecture Direction

My understanding is that the Jena client is currently working on SPARQL/HTTP connectivity only, and that the lower level connectivity has been shelved temporarily. On Wed, Apr 3, 2013 at 11:00 AM, Sören Brunk wrote: > For reference: Sesame's architecture has some similarities to what you > propos

Re: Architecture Direction

For reference: Sesame's architecture has some similarities to what you propose. Each Sesame server exposes its datasets via HTTP (a superset of the SPARQL graph-store API afaik). You can query and update the datasets via SPARQL, but at the same time you can also use the Sesame client API direc

Re: Architecture Direction

Have you looked at the two experimental modules: jena-client jena-jdbc to see if there is common ground? Andy On 28/03/13 20:42, Claude Warren wrote: USE CASES AND GOALS * Use Cases All use cases are shared data across multiple endpoints. 1. Multiple SPARQL servers utili

Re: Re: Architecture Direction

USE CASES AND GOALS * Use Cases All use cases are shared data across multiple endpoints. 1. Multiple SPARQL servers utilizing a single RDF server. 2. Multiple Model based applications utilizing a single RDF server such as a mix of live data feeds, bath update feeds, and report

Re: Re: Architecture Direction

On Thursday, March 28, 2013 06:45:08 AM Claude Warren wrote: > I was speaking of literal typing as reporting in the Graph Capabilities > object: > > *handlesLiteralTyping > *() > Answe

Re: Architecture Direction

I was speaking of literal typing as reporting in the Graph Capabilities object: *handlesLiteralTyping *() Answer true iff this graph compares literals for equality by value rather than

Re: Architecture Direction

I am glad, as it was my intent to provoke thought. However, I realize the manner of phasing can come off as rude or condescending, which was not my intent. Let me preface this with I am not a Jena expert. However, I do deal with distributed systems, big data, and other complicated engineering prob

Re: Architecture Direction

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, Dom

Re: Architecture Direction

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 acce

Re: Architecture Direction

I'm not sure what problem(s) you are trying to solve... the driver seems to be "avoid installing fuseki" but certainly you would have to install *something*. Why is fuseki a problem for you? What criteria would you use to determine something else would be "better"? On Wed, Mar 27, 2013 at 1:52

Re: Architecture Direction

Claude, SPARQL endpoint implementation in Graphity Linked Data server can proxy another endpoint, or serve a local Model. It can be accessed via HTTP or directly through JAX-RS object methods: https://github.com/Graphity/graphity-ldp/blob/rf-input-mode/src/main/java/org/graphity/server/model/SPARQ

Re: Architecture Direction

to:cla...@xenei.com] > Sent: Wednesday, March 27, 2013 11:31 AM > To: users@jena.apache.org > Subject: Re: Architecture Direction > > I believe that there are "C" libraries for MySQL that use a low level > connection, but that is neither here nor there. > > What

RE: Architecture Direction

e.org" , Date: 27-03-2013 16:40 Subject: RE: Architecture Direction Other thoughts are that it could operate as a shared server cache (in memory) that operates at the graph or model layer, providing separate client processes with the data at the graph/model layer. The server pro

RE: Architecture Direction

you had in mind? This is similar to how some of the object persistence technologies have been architected. -Original Message- From: Claude Warren [mailto:cla...@xenei.com] Sent: Wednesday, March 27, 2013 11:31 AM To: users@jena.apache.org Subject: Re: Architecture Direction I believe

Re: Architecture Direction

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

Re: Architecture Direction

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 t

RE: Architecture Direction

, including me, that would be willing to contribute to the effort. -Original Message- From: Claude Warren [mailto:cla...@xenei.com] Sent: Wednesday, March 27, 2013 4:53 AM To: jena-us...@apache.org Subject: Architecture Direction Currently Jena seems to require the use of Fuseki (or other

Architecture Direction

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 MySQ