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.
Andy
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:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
