RE: ODBC driver for RDF?

We've got an OLEDB driver for RDF Gateway (nearly identical in purpose to an
ODBC driver). Rather than trying to automatically map the contents of a
triple store to a particular relational schema, it lets the user create an
"rdf view" - a canned RDFQL query - that projects a schema onto the triple
store. We'd looked at the more general approach - mapping classes to tables,
etc. - but so many assumptions need to be made, it seemed better to put the
control in the user's hands.

We also of course have an ADO driver which takes RDFQL queries of any form
and returns recordsets - it's the driver of choice for the RDF aware. The
OLEDB driver is useful for applications that expect to be able to retrieve
fixed schema info - especially useful for integrating with tools such as
Crystal reports that have graphical query builders.

Rgds,

Geoff Chappell



> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Sandro Hawke
> Sent: Wednesday, November 21, 2001 12:25 AM
> To: Thomas B. Passin
> Cc: www-rdf-interest@w3.org
> Subject: Re: ODBC driver for RDF?
>
>
> > [Sandro Hawke]
> >
> > > I was trying to explain RDF to my sister who makes her living building
> > > database backed websites with Cold Fusion, and I had a good idea.
> > > Maybe it's been done.  I dunno.
> > >
> > > Someone should write an ODBC driver for RDF.  It would make the
> > > (nascent) universe of RDF data available on the web just look like
> > > another SQL database -- which my sister could format into web pages,
> > > or alter with web forms, etc, etc.
> > >
> >
> > Interesting... Clearly any one statement could return its
> triple as a row.
> > What would play the role of a table?  The RDF data on one
> particular server
> > at one base URL? The fields would be pretty unintelligible to
> people unless
> > there were human-readable labels - where would they come from,
> if they were
> > not specifically supplied as labels by other RDF statements?  How should
> > anonymous and generated nodes be handled?
>
> I'm imagining something that would look natural at both sides.  I
> think that means
>
>      SQL      RDF
>      ===      ===
>      table    Class
>      column   Property
>      row      object ("Resource")
>
> Unfortunately, this assumes all properties are daml:UniqueProperties.
> daml:UnambiguousProperties would be SQL UNIQUE KEY columns.
>
> Maybe non-UniqueProperties should be handled by having more rows which
> have otherwise-the-same column data.
>
> Sub-property inference, etc, could be handled by the ODBCdriver.  The
> ODBC application modifying data would see other data automatically
> added/changed, much as with other databases-with-rules.
>
>      -- sandro

Received on Wednesday, 21 November 2001 07:31:13 UTC