On 12/07/12 20:06, Adeel Ahmad wrote:
Hello,
fwd...
Thanks,
-- Forwarded message --
From: Adeel Ahmad aahmad1...@gmail.com
Date: 12 July 2012 01:01
Subject: jena/sesame
To: d...@jena.apache.org
Hello,
I wanted to query about the performance, scalability, and portability
issues with jena and sesame.
If I am correct both can be utilized with tinkerpop? However, sesame
provides a direct sail interface?
What I wanted to get your opinion on is it better to load the data using
jena but then query it using sesame? Or, should such load and extract steps
be implemented from the same api?
I find that jena is fast in terms of loading but very slow in terms of
quering data where as the sesame works better in the opposite approach. I
have noticed the adapter bridge between jena and sesame in some respects
provides a solution for that. Is there a roadmap towards merging their
functionality or perhaps making them equally compatible with each other
atleast in terms of how they work with RDF related data? Also, I noticed
that sesame has more of a portability for other languages apart from just
java, whereas jena seems to be more focused towards java support. Are there
any plans of making the bridge for python and php support such as seen on
redland or for making the interfaces more tangible in use across different
databases and lucene/hadoop streams?
I'm not completely clear in what context your asking this.
SPARQL is the standard RDF query language and is supported (client,
server) by both Jena and Sesame. The graph systems your hinting at for
graph analysis problems are of a somewhat different style.
I don't know of a tinkerpop blueprint for Jena; there is one for Sesame
- but layering other graph languages like this does not lead to
performance. They end up using a triple-by-triple access to the data
when the query/storage engines want larger chunks to work with and be
able to utilize large volume join algorithms.
The last time I used neo4j and it's RDF incarnation, the performance and
scale was not good. A few million triples tops. The indexing is not
suitable for joins - it supports the find-walk style of algorithm.
I find that jena is fast in terms of loading but very slow in terms of
quering data where as the sesame works better in the opposite approach. I
have noticed the adapter bridge between jena and sesame in some respects
provides a solution for that.
To what figures are you referring?
If the data is loaded into system X, it has to be accessed at the lowest
level by X.
All the adapter does is provide one API over the other - the query
engine used is the same as the storage.
SPARQL gives you client-server separation but the Jena query engine
implements SPARQL for Jena storage and Sesame does for Sesame storage.
You can't (with performance) load one and then use the other (the file
formats are different)
Andy
