Re: [Gzz] Wrapper mini-API to RDF

[Benja Fallenstein]

Tuukka Hastrup wrote:
> Before we have written much code to Jena API, should we consider 
> using a minimal API of our own, implemented as a wrapper to Jena?

I think that would be exactly backwards: First make your experience with 
the APIs out there, then decide whether you need your own... :-)

> Such API 
> could be specialised for the operations we need for our views, instead of 
> supporting everything you could imagine doing to general relations.

Now, yeah, we need something that works well with the views, for speed, 
but we also will need a lot of bindings and plumbing code that will want 
to look at the data in the most convenient way possible. Actually this 
is a big quibble I have with the Jena API: It is not convenient enough.

> My concern is that the broadness of Jena API will hinder our possibilities 
> for optimisations

I don't think a wrapper API is going to gain you speed :-)

Do you mean an own API with an own implementation, but using Jena's parsers?

> On the other hand, I suppose we'll need extension to Jena, in order to 
> support xanalogical media. Would those be best implemented into our own 
> RDF API, or as utility classes working on standard Jena objects?

As utility classes working on standard Jena objects, or else as utility 
classes working on standard our-own-RDF-API objects ;-)


If I had to design an RDF API today, I'd offer three kinds of access: 
Object-oriented style, triples lookup style, and fast access.

Object-oriented style: using methods on nodes--

        node.get(rdf.type) --> Node
        node.getString(rdf.label) --> String
        node.getInt(person.age) --> int
        node.all(rdf.type) --> List of Nodes
        node.getStrings(rdf.label) --> List of Strings
        node.getInts(person.age) --> int[]
        node.get(rdf.type, -1) --> Node
        node.all(rdf.type, -1) --> List of Nodes
        
        node.set(rdf.type, node2);
        node.add(rdf.type, node2);
        ...

Here, we're trying to get the idea across that you're accessing *a 
property of a node*, representing the node as an object.


Triples lookup style: using methods on the graph--

        graph.get(node, null, null) --> List of Triples
        graph.get(node, prop, null) --> List of Triples
        (get(subject, prop, object); 'null' matches anything)

        graph.add(node, prop, node2);
        graph.remove(node, prop, node2);

        graph.getTriples() --> List of Triples


Fast access style: for views, using a special kind of iterator to avoid 
object creation--

        graph.getIterator() --> RDFIterator

        iter.lookup(subj, prop, obj);
        iter.go() --> boolean [whether there are more triples]

        iter.s() --> Node [subject]
        iter.p() --> Prop [property]
        iter.o() --> Node [object]
        iter.getString() --> String [content of object]
        iter.getInt() --> int [content of object]
        
The s(), p(), o() methods etc. would be the same in triple objects; 
lookup() gets the same parameters as graph.get(). After lookup(s,p,o) 
and a single go(), the iterator would contain the first triple that 
graph.get(s,p,o) would return. This would allow writing something like 
the following:

        RDFIterator i = graph.getIterator();

        for(i.lookup(focus, prop, null); i.go();) {
            showConnection(i.p(), i.o(), +1);
        }

        for(i.lookup(null, prop, focus); i.go();) {
            showConnection(i.p(), i.s(), -1);
        }

This would process all forward and backward connections of the focus 
node, without creating a single new object. I think that may be a good 
compromise between speed and readable code.



All that said, I would think it isn't the time yet to roll our own API. 
Maybe once the views get to slow, and we identify Jena's interface as 
the bottleneck?

- Benja