Hi Reto,

comments inline. ;-)

Am 03.08.2012 um 12:54 schrieb Reto Bachmann-Gmür:

> I agree that clerezza should finally have tha fastlane for sparql query,
> the current approach makes only sense if a query is against graphs from
> multiple backends. This is definitively a bottle neck now.
> 
> What puzzles me is that you seem to think that the sesame api is cleaner
> than the clerezza one. The clerezza api was introduced as non of the api
> available would model the rdf abstract syntax without tying additional
> concepts and utility classes into the core. If you find anything that's not
> clean I'd like to address this.

Essentially, Sesame already provides many of the things Clerezza promises, and 
it is well proven, established, and highly performant. So I don't completely 
understand the rationale of reinventing the wheel with Clerezza. 

I also don't understand your argument of tying additional concepts and utility 
classes into the core. Clerezza implements utility classes in the same way as 
Sesame, so where is the difference? Additionally, the Sesame utility classes 
simply extend the Java core functionality (e.g. with iterators that can throw 
checked exceptions). 

One aspect I like about the Sesame API is its completely modular structure at 
several levels. This allows me to easily and cleanly add functionality as 
needed, e.g.:
- a custom triple store like the one I described before; you can e.g. easily 
provide a Jena TDB backend for Sesame (see http://sjadapter.sourceforge.net/)
- a custom SPARQL implementation that allows a very efficient native 
evaluation; at the same time, Sesame provides me an abstract syntax tree and 
completely frees me from all the nasty parsing stuff and implements the latest 
SPARQL specification for queries, updates and federation extensions without me 
having to actually care
- a very clean Java SPI based approach for registering RDF parsers and 
serializers that can operate natively on the respective triple store 
implementations
- easily wrap filters around triple stores or iterators
You can easily see the modularity by looking at the many Maven artifacts the 
project is composed off. Essentially, if I don't need a functionality I can 
simply leave it out, and if I need it, adding it is a no-brainer.

In addition, the Sesame data model is completely based on lightweight 
interfaces instead of wrapper objects. This makes it very easy to provide 
efficient implementations and is IMHO very clean. In contrast, Clerezza 
provides its complete own RDF model based on your own version of a triple, your 
own version of a node, your own version of a URI, …

What I am missing from Clerezza:
- a lightweight data model that does not require additional instances in main 
memory
- a good reuse of functionality that is already there, e.g. direct SPARQL, 
transactions, …
- support for named graphs / contexts
- support for SPARQL Update
- new TripleImpl(…) is a Java anti-pattern. If something is called …Impl it 
should not be instantiated with new.

I have been working with RDF APIs for about 10 years now in various programming 
languages (even in Prolog, Haskell and Python). And my conclusion at the moment 
is that Sesame by far offers the most convenient API for a developer. But I am 
of course open to switching in case I get convincing arguments. ;-)

> 
> It seems that what you are using of sesame is mainly the spi/api and not
> the actual triple store. This is definitively something clerezza should
> have a good offer for.

So convince me why it is BETTER than the established project ;-)

> 
> When I last looked at it sesame was not ready to be used in apache
> projects, not sure if license issues are the cause of it not being
> available in maven central.


Sesame is under a BSD license, so it should be compatible with Apache projects:

http://www.openrdf.org/download.jsp

The main issue might be that it is not yet completely OSGi compatible (at least 
not on a per-component level).

If it is indeed not compatible with Apache projects, it should be easy to 
contact the developers and simply ask them whether this can be changed.

Greetings,


Sebastian
-- 
| Dr. Sebastian Schaffert          [email protected]
| Salzburg Research Forschungsgesellschaft  http://www.salzburgresearch.at
| Head of Knowledge and Media Technologies Group          +43 662 2288 423
| Jakob-Haringer Strasse 5/II
| A-5020 Salzburg

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to