[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] Wrapper mini-API to RDF
From: |
Benja Fallenstein |
Subject: |
Re: [Gzz] Wrapper mini-API to RDF |
Date: |
Tue, 18 Mar 2003 21:55:38 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030316 Debian/1.3-1 |
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
- Re: [Gzz] Wrapper mini-API to RDF,
Benja Fallenstein <=