Hi Adeel,
what follows are just my opinions.

As far as I know there isn't a Tinkerpop implementation on top of Jena (even if it should not be that hard to write one, if someone need it).
My opinion is that any additional layer would not make things go faster.
Blueprint APIs are also a bit more general and not focused on RDF data or SPARQL.

Comparing performance and scalability between Jena and Sesame can be a good exercise. They both support SPARQL and writing different code to load or run queries does not seem to be much work. I used BSBM and SP2B with Jena and Jesame, you might find something useful here:
https://github.com/castagna/bsbm-automated
https://github.com/castagna/sp2b-automated
(these might need some small changes and just ugly bash scripts)

Have a look at what Andy wrote (in Scala) here:
https://svn.apache.org/repos/asf/jena/Experimental/JenaPerf/trunk/

I think it's better to load data and query it without using any additional layer or bridge. This way you can compare two different software using the same data/queries on the same hardware.
An intermediate layer might introduce inefficiencies (in one or both).

You say one is fast in loading and slow at querying, but "fast" and "slow" are a bit vague.
How big was the dataset? How you load it? What queries? Etc.
Make your experiment replicable by others, so other people can rerun and see.

Jena can be used by any language via REST APIs, see Fuseki (which supports SPARQL 1.1):
http://jena.apache.org/documentation/serving_data/
However, this is not the same as having native clients.
Stephen wrote a jena-client (experimental), you can find it here:
https://svn.apache.org/repos/asf/jena/Experimental/jena-client/
Maybe something similar could be done for other languages.

Re: Hadoop... if you have MapReduce jobs which you want to run over and over, I think you can make things go faster with Java (since MapReduce APIs are Java and you have no need of extra layers).

Is your goal to easily compare Jena and Sesame?

Paolo

On 12/07/12 01:01, Adeel Ahmad wrote:
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?



  • jena/sesame Adeel Ahmad
    • Re: jena/sesame Paolo Castagna

Reply via email to