incubator-clerezza-dev 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 Thu, 11 Nov 2010 18:01:11 GMT
Bertrand suggested that this conversation happened clerezza-dev list: 
main extracts of messages in chronological order:


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 
 > 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), 
 > 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 
 > 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 10/11/10 23:28, Jeremy Carroll wrote:
 >> - The core API for (mutable) graphs in:


 > Iterator<Triple> filter(NonLiteral subject, UriRef predicate, Resource
 > object)
 > vs

 > ExtendedIterator<Triple> find(Node s, Node p, Node o)
 > seems to be the fundamental choice.
 > The latter was the choice Chris Dollin and I made in 2002/2003 and I
 > still find it preferable, for program uniformity, to the closer to the
 > spec choice in Clerezza.
 > We were writing the spec at the same time, and I always saw it as a
 > description of a Web exchange format, and not of a programming interface
 > (for instance implementing RDF Semantics Rec is hard with the Clerezza
 > interface).
 > I am not quite sure what that means in terms of this discussion which is
 > more procedural than technical.
 > Like in all things people make different choices and have different
 > preferences, and a decision to all use the same libraries would be a
 > restriction in design freedom, on such issues, which might be good, or
 > might be bad.
 > ===
 > On

 > [[
 > - graph isomorphism code
 > ]]
 > what are the goals of the Clerezza isomorphism code? The Jena code is
 > essentially scoped to testing, so that I checked that small pathological
 > cases were OK, and larger non-pathological cases, but it is not meant to
 > have production level performance, particular on graphs for which
 > something like nauty would be more appropriate.

On 11/11/10 10:21, Andy Seaborne wrote:
 > Isn't the model interface operation a more appropriate comparision
 > because that is what the application sees?
 > StmtIterator listStatements(Resource s, Property p, RDFNode o)
 > Graph.find is the SPI interface to storage. The Graph level has named
 > variables, not just RDF terms.  SPARQL uses this, heavily.
 > In SPARQL, literals can occur in any position during query processing.
 > Patterns involving literals as subjects, or as predicates, just simply
 > don't match the data (section 12.3.1).
 > Once upon a time, when we were going Jena1->Jena2, the idea was that the
 > application API was just one presentation.  There could be other RDF
 > APIs over the SPI.  There's not been a second RDF presentation API but
 > the design concept was there and still is.  All the interfaces in the
 > API are mainly implemented only once, and I'm not aware of any users
 > which use the extensibility within the Resource API anymore
 > (Parliament/BBN used to - I think they now use an associated
 > datastructure to map to internal information for any API
 > resources/literals from their storage).  The Resource-level API
 > implementation could be simplified if theer is only one implementation
 > of that presentation.  There is generality in Jena that we thought was a
 > good idea at the time but looking at way the world has gone since, not
 > all of it is used or useful nowadays.  Better use of factory/interface
 > at the SPI would be more helpful. The experimental Jena3 core also has
 > extension nodes and graph nodes with an eye to future possible needs
 > from the standards world.

View raw message