Bertrand suggested that this conversation happened clerezza-dev list:
main extracts of messages in chronological order:
Andy
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 10/11/10 23:28, Jeremy Carroll wrote:
>> - The core API for (mutable) graphs in:
>>
http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html
>>
>
http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/org/apache/clerezza/rdf/core/TripleCollection.html#filter(org.apache.clerezza.rdf.core.NonLiteral,%20org.apache.clerezza.rdf.core.UriRef,%20org.apache.clerezza.rdf.core.Resource)
>
>
> Iterator<Triple> filter(NonLiteral subject, UriRef predicate, Resource
> object)
>
> vs
>
>
http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Graph.html#find(com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node)
>
>
> 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
>
http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201011.mbox/%[email protected]%3e
>
> [[
>
> - 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.
