incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <andy.seabo...@epimorphics.com>
Subject Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Date Thu, 11 Nov 2010 10:21:23 GMT


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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message