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): 

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.