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

* Souripriya Das <SOURIPRIYA.DAS@oracle.com> [2010-03-21 23:03-0700]
> 
> 
> 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): 
> 
> 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. 

Given that the goal of this working group is to inject relational data into the SemWeb, our clients will be best served by a representation which is useful in the SemWeb. For instance, the interface side of our mapping can be annotated and shared to enable federation and policies.

The HCLS use cases have been well-met by SPARQL CONSTRUCTs, but Sandro has persuaded me to use RIF as it manages complex rules sets and extensible generators for e.g. URIs. Given that RIF will move to PR this week, we are free to use that specification for logical transformations (and in fact, we will have to answer to the director if we invent another model). We can defend a different surface syntax if we show that the user community will be so much better served that it's worth the dilution of standard syntaxes.

> (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 
> 
> ] 

Could you explore a little which use cases this address and which ones require extra-spec functionality?

> 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. 
> 

-- 
-ericP

Received on Monday, 22 March 2010 18:14:58 UTC