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).
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.
I am not quite sure what that means in terms of this discussion which is
more procedural than technical.
Same here.
Advice on an appropriate discussion forum welcome - while we're in a
state of exploring the relationships of projects, I'm guessing that here
is the only common place there is.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
