Re: ODBC driver for RDF?

At the suggestion of Dan Brickley, I've implemented something similar, a
JDBC (Java's ODBC) driver for RDF databases over the top of a generic
getTriples(s,p,o) interface for my implementation of the SquishQL RDF
query language[1]. So you ask a query and get a set of bindings for the
variables you ask for, e.g.   

SELECT ?sal, ?t 
  (job::advertises ?x ?y)
  (job::salary ?y ?sal)
  (job::title ?y ?t) 
USING job for 

and you get back something like

     ?sal           ?t
     100000         Job title for job1 
     150000         Job title for job2 
     60000          Job title for job33 
     100000         Job title for job22 
     50000          Job title for job11 

as a JDBC resultset, basically an arraylist of hashes. JDBC is nice and
familiar to Java programmers, so this makes for a friendly interface to
RDF databases. The reliance on getTriples(s,p,o) means it can be
inefficient, but you can couple the query and resultset more tightly if
you like, for example using an SquishQl to SQL rewriter for a particular
table structure.

Anonymous nodes are an interesting case. My implementation currently
brings back the internal identifiers for them, but really you want to
have some notion that they are anonymous, while allowing repeated
queries of the same database using them (maybe), and also retaining
the information that one is the same as another, as Andy Seaborne has
pointed out to me. Additionally, you need to retain information about
whether a result is a resource or a literal, which could be done through
resultSetMetadata in JDBC. You might also want to return provenance
information somehow.




On 21 Nov 2001, Pierre-Antoine CHAMPIN wrote:

> On Wed, 2001-11-21 at 06:25, Sandro Hawke wrote:
> >      SQL      RDF
> >      ===      ===
> >      table    Class
> >      column   Property
> >      row      object ("Resource")
> Does not look very RDFish to me...
> The only general purpose RDF-into-DB schema I can imagine is a
> Subject/Predicate/Object table...
> Ok, some people will need more "natural" views of the data, but then you
> could use Views, rather than Tables, like the one above.
> And may be some additionnal columns may be useful, like a StatementID of
> RDFSource column, when the DB gathers statements from different
> sources...
>   Pierre-Antoine

Received on Wednesday, 21 November 2001 06:29:36 UTC