Re: RDB2RDF mapping: Do we really need any alternative to use of SQL queries with conventions and a "trivial" mapping language?

> Before we delve deep into exploring any alternatives, we need to firmly
> establish that the following SQL-based approach is insufficient (and/or
> inconvenient or non-performant):

I agree with the general idea that various proposals should be clarified,
but I do not want to vary from the general plan, which I think is a good

1) There will be two general approaches obviously, one based on SQL that
serves the wider database community and one based on RDF/SPARQL that
serves the Semantic Web community. If both general approaches can be given
in a draft specification form by early June, then we will should try to
map them (ideally via formal semantics) and standardize that. If not, the
most mature one should be standardized. This decision will likely be
discussed at the face-to-face at SemTech. Therefore, teams - let's make
those draft specs!

2) And a trivial mapping language that would be shared by either approach
is also likely to be part of the RDB2RDF language, as is some sort of
function call (API) that can be used by RDB2RDF mappers to locate URIs for
various names in the relational data.

Apologies for being out of loop, at W3C Team Day, our once-a-year meeting,
with EricP and others. RDB2RDF was discussed extensively, people at the
W3C and member organizations are very keen on this standard. So let's keep
up the good work!

> 1) Use SQL language expressivity to specify the SQL queries (with
> conventions for optionally defining instance URIs, rdf:type columns, and
> graph URIs) for various extents of customization for the mapping of
> relational data to RDF terms.
> (Queries could be as simple as "SELECT ... FROM <table>" OR as complex as
> it needs to be possibly involving INNER JOINs, OUTER JOINs, expressions,
> aggregate functions, table functions, OLAP functions, hierarchical queries
> (CONNECT BY), ...).
> 2) A rather "trivial" mapping language that maps 1) the queries to
> RDFS/OWL classes and datatype properties and 2) constraints to object
> properties.
> [For an example, please see the use of SQL queries and a trivial mapping
> language in the following example:
>     € Example of SQL-Query based Approach
>         € Part 1: Schema => RDB Schema, RDB2RDF Mapping, and generated
> RDF Schema
>         € Part 2: Data => RDB (relational) Data and corresponding
> (virtual) RDF Graphs
> ]
> I look at it this way: We are trying to see or transform relational data.
> But, as we all know, SQL was designed specifically for that purpose.
> Expressive power of SQL and a "trivial" mapping language to map the
> logical tables returned by SQL queries to RDFS/OWL classes and properties
> and the referential integrity (foreign key) constraints to object
> properties are all that we need.
> So far I have not seen or heard any convincing arguments to establish that
> we need anything more than SQL and a "trivial" mapping language. Before
> going for an alternative, we must first establish the need for such an
> alternative.
> Thanks,
> - Souri.

Received on Monday, 22 March 2010 22:12:31 UTC