Minutes_RDB2RDF_XG_Dec-12-2008 Follow up...

Hello,

Wanted to follow up on the minutes of Dec-12-2008.  We must had bad phone connection as the dialogue below does not capture what I stated?

<Ashok> Ahmed: How about a JDBC like interface that takes a SPARQL query and returns RDF
<iv_an_ru> Why "JDBC like"? Use JDBC...
Orri says SPARQL and SQL can be mixed and used together
SQL should be writeable inside SPARQL
<iv_an_ru> If needed, I'll implement that quickly
DAWG working group exists
<iv_an_ru> Actually, some SQL fragments appear in our mapping rules already, so the required infrastructure is in place.fairly limited scope right now in DAWG
<Ashok> Orri: Put a SQL view in SPARQL instead of graph-pattern
<Ashok> SPARQL must have views and these may be SQL-views
Satya asks whether a SPARQL view can be considered as a sub-graph
<Ashok> Orri: It would be a derived table in-completeness of SPARQL complicates the problem
<scribe> ACTION: Ashok we remind on the public list on documents for review by the group [recorded in http://www.w3.org/2008/12/12-RDB2RDF-minutes.html#action03<http://www.w3.org/2008/12/12-RDB2RDF-minutes.html>]
next meeting 9th of Jan 2009
<Ashok> Soeren: Result of SPARQL query is not always a graph ... SPARQL does not have relational completeness. Not easy to acheive.

My statement was to provide a capability from SPARQL level to call any data source with the query to that data source expressed as a string, and passing SPARQL endpont-id to interpret the string correctly at lower layers.  It is below that level where JDBC comes in the picture for SQL data sources.

I shared the above in the context of SPARQL WG (Andy Seaborne from HPL Bristol was talking with me about adding capabilities to SPARQL) as well as to point out that RDB2RDF mapping will not be visible to the SPARQL programmer.  In this later context I used JDBC where mapping SQL data types to Java is done in the driver.  As a follow up on comment that Java is not a query language, I stated that stored procedures are called from a query language and that can call other target languages and the mapping is still transparent to the SQL application.

This is an alternative to generating the SQL from SPARQL automatically (query rewrite); I think both models should be supported as data sources are not limited to SQL only.   Mixing SQL and SPARQL (Oralce style) and earlier mixing SQL and Xquery (IBM DB2 9 - code name Viper) is different as they approach the problem from SQL point of view while SPARQL should have generic approach (SQL is most important but not the only data source).

Hope this clarifies and I assume appropriate editing/clarification to the minutes will be done - thanks.

One observation to share: SQL data sources are the most critical data sources but they are not the only one.  Most of the Enterprise EIS serevrs like ERP, SCM, etc do not expose SQL API to clients and the client does not interact with the database directly.

 2nd observation to share: if the only data sources of interest are SQL, the value of RDF is less than the case where you have structured and unstructured data sources.  The issue of dealing with different databases/schemas by an application is an old one and the SQL world typically adopt MDM and BI approach.  Dealing with heterogenous databases is not resolved by using RDF but it still needs to be dealt with at higher level at the domain ontology level.  The advantage in my view of RDF/SPARQL is for data integration when hetrogeneous structured and unstructured data sources are involved.
Regards, and best wished for the new year,

Ahmed

Ahmed K. Ezzat, Ph.D.
HP Fellow, Business Intelligence Software Division
Hewlett-Packard Corporation
11000 Wolf Road, Bldg 42 Upper, MS 4502, Cupertino, CA 95014-0691
Office: Email: Ahmed.Ezzat@hp.com Tel: 408-447-6380 Fax: 1408796-5427 Cell: 408-504-2603
Personal: Email: AhmedEzzat@aol.com Tel: 408-253-5062 Fax: 408-253-6271