incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <castagna.li...@googlemail.com>
Subject Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Date Tue, 09 Nov 2010 08:11:26 GMT
Olivier Grisel wrote:
> On 8 November 2010 15:54, Bertrand Delacretaz <bdelacretaz@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message