-------- Original Message --------
> From: Stefano Mazzocchi <mailto:stefanom_at_mit.edu>
> Date: 9 March 2006 22:25
>
> Seaborne, Andy wrote:
> >
> >
> > -------- Original Message --------
> > > From: Stefano Mazzocchi <mailto:stefanom_at_mit.edu>
> > > Date: 9 March 2006 17:14
> > >
> > > Came across RDF2Go today, basically a JDBC-like layer for RDF
triple
> > > stores in java, which would allow us to be triple-store neutral
and
> > > allow easier performance testing across various containers.
> > >
> > > Has anybody tried it? Are there severe performance drawbacks?
> >
> > Sorry not tried it in - but the javadoc says it does work at the
Jena
> > Graph level (the lower level interface) which is the right place to
> > hook in.
>
> ok
>
> > It's a object-copying adapter, converting to it's object model
> > (java.net.URI, blank node, it's own literal implementations). Blank
> > nodes wrap the underlying system blank node - amusing way to do it.
> >
> >
> > An alternative store abstraction is to use SPARQL (QL and protocol)
> > which would then work for non-Java stores as well.
>
> sure, but I wonder how much the the cost of network transmission (even
> on localhost), resulset serialization/parsing and object model
creation
> would impact our operations.
It's avoidable - have a common interface to SPARQL and map it to the
toolkit. This is the SPARQL abstract protocol as API calls.
You still get the separation of application from implementing toolkit
that way which is the key benefit.
What might be nice is a common API to SPARQL. That seems more tractable
than an common API to RDF because it is a lesser problem. It might be
good timing as well.
(Actually, a simple Graph/Node API might also be possible but the key is
to keep it simple - all the attempts I see seem to escalate to introduce
extra features (well motivated by the problem domain) and then it gets
to be a larger burden (implementation overhead grows) with less buy-in
from other groups.
So far, RDF2GO looks to have kept to the core triple (although it adds
quads and different systems have different uses for quads).
Look at JRDF which has a stated goal of being a standard API: it's goals
are
* a graph API [good]
* Creating and manipulating Graph objects (Statements, Nodes, etc.),
[This is getting into storage issues and interface vs class but
maybe OK]
* A standard system level interface for storing triples,
* Transactions,
* Event Handling (addition/removal of nodes from a graph),
* Query Handling (including results, transport, etc),
* RDF Datatypes,
* Security,
* Inferencing.
and it is now rather complicated. It isn't a thin abstraction layer
anymore - it's another API. The design is (as I understand it), even at
the graph API level, to avoid a copy but I don't see how an API can
abstract a toolkit without scome copying or without the target toolkit
supporting the interfaces. (Mutter about typing in Java :-)
That all said, the real trick bit, IMHO, is building a neutral community
(e.g. namespace, then a group with reps from some toolkits). It's kinda
hard to see how a group separate from the current toolkits will make
headway.
We (Jena) would be more than happy to add another presentation API to
Jena - we have always planned to allow more than one API over the core
(Graph/Node). The usual Model/Resource is a layer over this.
>
> > seeAlso: There is project to do a JDBC driver for SPARQL (SPARQL4j)
> > on SourceForge. http://sourceforge.net/projects/sparql4j/ (despite
> > being named on the project, I'm not active).
>
> nice. Do you know how active the project is? seems pretty much dead
> from here.
I think they are working off line much of the time. A little
encouragement might get them in the open.
Andy
>
> --
> Stefano Mazzocchi
> Research Scientist Digital Libraries Research Group
> Massachusetts Institute of Technology location: E25-131C
> 77 Massachusetts Ave telephone: +1 (617) 253-1096
> Cambridge, MA 02139-4307 email: stefanom at mit . edu
> -------------------------------------------------------------------
Received on Fri Mar 10 2006 - 14:20:14 EST