Olivier Grisel wrote:
On 8 November 2010 15:54, Bertrand Delacretaz <bdelacre...@apache.org> wrote:
Hi,
I'm following up on discussions here regarding relationships between
the incubating Clerezza podling and incoming Stanbol and Jena podlings
(see proposals at http://wiki.apache.org/incubator).
Do people agree with the following structure?
1. Clerezza, Stanbol and Jena are independent podlings, each aiming
for top-level status
There is a depedency relationship:
- Stanbol is a of application level HTTP services and set of OSGi
components that use:
- Clerezza as an OSGi service provider which in turn is using:
- Jena as a lib for parsing and serializing RDF models and as a SPARQL
enabled triple store.
These are, at the moment, the Jena classes used by some of the
Clerezza modules:
com.hp.hpl.jena.datatypes.TypeMapper
com.hp.hpl.jena.datatypes.xsd.impl.XMLLiteralType
com.hp.hpl.jena.graph.Graph
com.hp.hpl.jena.graph.impl.GraphBase
com.hp.hpl.jena.graph.Node
com.hp.hpl.jena.graph.Node_URI
com.hp.hpl.jena.graph.Reifier
com.hp.hpl.jena.graph.Triple
com.hp.hpl.jena.graph.TripleMatch
com.hp.hpl.jena.mem.TrackingTripleIterator
com.hp.hpl.jena.query.Dataset
com.hp.hpl.jena.query.QueryExecException
com.hp.hpl.jena.query.QueryExecution
com.hp.hpl.jena.query.QueryExecutionFactory
com.hp.hpl.jena.query.QueryFactory
com.hp.hpl.jena.query.QuerySolution
com.hp.hpl.jena.query.ResultSet
com.hp.hpl.jena.rdf.model.impl.NodeIteratorImpl
com.hp.hpl.jena.rdf.model.Literal
com.hp.hpl.jena.rdf.model.Model
com.hp.hpl.jena.rdf.model.ModelFactory
com.hp.hpl.jena.rdf.model.RDFNode
com.hp.hpl.jena.rdf.model.RDFWriter
com.hp.hpl.jena.rdf.model.Resource
com.hp.hpl.jena.rdf.model.RSIterator
com.hp.hpl.jena.rdf.model.Statement
com.hp.hpl.jena.rdf.model.StmtIterator
com.hp.hpl.jena.shared.AlreadyReifiedException
com.hp.hpl.jena.shared.Lock
com.hp.hpl.jena.shared.ReificationStyle
com.hp.hpl.jena.sparql.core.DatasetGraph
com.hp.hpl.jena.sparql.core.Quad
com.hp.hpl.jena.sparql.util.Context
com.hp.hpl.jena.tdb.TDB
com.hp.hpl.jena.tdb.TDBFactory
com.hp.hpl.jena.util.iterator.ExtendedIterator
com.hp.hpl.jena.util.iterator.Filter
com.hp.hpl.jena.util.iterator.NullIterator
com.hp.hpl.jena.vocabulary.DC
com.hp.hpl.jena.vocabulary.RDF
com.hp.hpl.jena.vocabulary.RDFS
Reto Bachmann-Gmür wrote (on jena-devel):
> In Clerezza Jena is used in the implementation of some modules:
> - Jena Based Serializers and Parsers
> - Jena Sparql
> - Jena TDB Based storage
> - Implementation of the Jena API on top of Clerezza Graphs (jena.facade)
>
> Apart for the last one the modules are independent of Jena in terms of
> the API they expose. Clerezza can be used without any of these modules
> but if one of these are used Clerezza needs Bundles for the whole of
> Jena, it would be nice if the various modules could depend only on the
> parts of Jena that are actually needed by them.
Paolo
The dependency between Clerezza and Jena is optional as many OSGi
services in Clerezza can also work with sesame as an alternative RDF
lib and triple store.
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.
Ok on the principle but I would suggest not to create this as long we
don't have any code that does not belong to one of the three previous
projects. Developers of the upstream project should try to take care
an not reinvent the wheel and try to move new features and bugfix to
upstream if they naturally belong there.
3. It is expected that those projects will have a number of committers
in common, as there are many collaboration possibilities.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
