incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Date Tue, 09 Nov 2010 12:19:45 GMT
I haven't understood yet the relationship of Stanbol and Clerezza to be 
able to say anything about how a commons area between those two systems 
might work.  In terms of direct dependencies, does Stanbol just directly 
depend on Clerezza and only indirectly on Sesame, Jena rdf2go and the 
OWLAPI that the proposal lists?

Jena has two levels of API, the Model/Statement/Resource that 
applications usually use, and the SPI Graph/Triple/Node thathe the 
storage and inference layers plug into.  Roughly, speaking, the API 
faces upwards to applications and the SPI downwards to components. 
There is also the same design for the support for RDF datasets for 
SPARQL.  SPARQL, especially SPARQL Update, works on quads for named graphs.

There are significant investments by users in uses of both API and SPI 
and the cost of change for users isn't trivial.  Worse, the SPI is used 
by systems that are distributed on making any change over messy. There 
needs to be a real advantage to change.

Speaking personally, I'm not strongly motivated by a common API; I don't 
think it helps the semantic web enough compared with other things I 
could work on.  If others are working on one, I'll do what I can to make 
my contributions work as smoothly as possible with that through 
discussing what hooks and flexibility I can contribute to Jena to make 
it work smoothly with other systems.

I'm not particularly worried about there being several APIs since that's 
the state we're in and I don't see it changing particularly quickly 
because there are large investments in deployed systems that exists.  As 
some of these systems themselves are distributed onwards, chnage woudl 
be slow.

Most of my contribution is storage and query which works at the lower 
level anyway, so it has less effect on me but the SPARQL related parts 
of the public APIs are mostly my fault. I am currently working on a 
SPARQL 1.1 compliant server - the on-the-wire standardization is more 
important.  Working on storage and query does result in a slight 
obsession with efficiency - storage and query need to be tightly coupled 
for performance.

Jeremy identified the IRI library as a potential contribution to a 
commons area.  It is free-standing, and does not use or call any Jena 
RDF code - it depends only on ICU4J (and JUnit + Jflex in the build).

The client-side content negotiation code in Jena could do with an 
upgrade so if there is system-independent code that can be reused for 
the systems here and more widely, that would be great.  I would use it 
as I need to provide code-level access to for client SPARQL 1.1 access.

If nothing else, shared knowledge and expertise would move things along 
faster, and even if functionality needs tying to specific systems, 
having all the projects in Apache greatly helps community.


PS Reto - GVS [*] isn't on the list of thing to contribute to Apache as 
we're focusing on the core system that is used and we support.  But that 
does not preclude including GVS either now or later.  It is covered by 
our agreement-in-principle with HP.  Do you want to do that?

[*] Reto wrote a graph versioning system for Jena several years ago.

On 08/11/10 21:39, Reto Bachmann-Gmuer wrote:
> Hi Jeremy
> One of Clerezza aims was to use an RDF api that is maximally close to RDF
> abstract syntax and semantics, on this RDF core api we have different
> fa├žades and utilities as well as a frontend adapter implementing the jena
> API. Related standards like SPARQL and the various serialization formats are
> supported as well, respective engines can be added at runtime (when running
> in a OSGI container). We decided to design our own API as we found the
> various API available (jena, openrdf, rdf2go) would neither be as modular
> nor as close to the spec as we wanted them to be. The API comes with the
> typical utilities like a command line tool and a maven plugin for the
> transformation of vocabularies into classes
> Apart from core part tightly coupled to RDF and related specs Clerezza also
> provides a framework for implementing rest applications (JAX-RS). The
> encourages design pattern is that requests are answered in terms of RDF
> (i.e. a graph and typically a selected resource within this graph), clerezza
> takes care about content-negotiation and for RDF formats the serializer
> registered for that media type is used. For non RDF formats a template
> (typically a Scala Server Pages) is selected and takes care of the
> rendering.
> I described this parts of Clerezza because they seem to be quite close to
> what you suggest for commons. As it is hard to share utilities without
> having shared APIs for the core stuff our code deals with I think some
> efforts in this area could have the greatest benefit.
> If you have some time, I would like to encourage feedback on the respective
> APIs as currently used in Clerezza
> - The core API for (mutable) graphs in:
> - Utilities (including resource-centric API):
> These two layers are similar to the Graph/Model separation in Jena.
> Cheers,
> Reto
> On Mon, Nov 8, 2010 at 7:32 PM, Jeremy Carroll<>wrote:
>> To make the commons discussion more concrete I would suggest the following
>>   items for the commons:
>> - an IRI library
>> - some code to do with vocabularies.
>> - connecting to a URL and doing semweb aware content negotiation (this is
>> typically done badly)
>> (Actually the IRI code should probably be wider, Jena initially used the
>> xerces URI code but then the needs exceeded what they supported)
>> Jeremy
>> On 11/8/2010 7:22 AM, Ian Dickinson wrote:
>>> On 08/11/10 15:09, Mattmann, Chris A (388J) wrote:
>>>> Wow! Jena is proposing to come to Apache??!
>>> Yep, the proposal has been under discussion for some time within the
>>> project, and Ross is now taking the lead in bringing it publicly into
>>> the incubator process.
>>> Bertrand wrote:
>>>> 1. Clerezza, Stanbol and Jena are independent podlings, each aiming
>>>>> for top-level status
>>>>> 2. A Semantic Commons area is created for common code between these
>>>>> (and other) projects. Details to be discussed, this does probably not
>>>>> warrant a separate Apache project, but might be managed by Clerezza,
>>>>> as they were here first.
>>>>> 3. It is expected that those projects will have a number of committers
>>>>> in common, as there are many collaboration possibilities.
>>>> As an Apache newbie it's hard to comment definitively, but it's not
>>> clear to me what the common needs of the projects might be, and how
>>> dependencies would handled. Are there examples of existing "commons"
>>> areas between Apache projects, other than basic application->library
>>> dependencies?
>>> Ian
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message