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: http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html - Utilities (including resource-centric API): http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.utils/apidocs/index.html 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 <jer...@topquadrant.com>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: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
