Re: Re-opening ISSUE-22 on vendor-specific SQL

* Richard Cyganiak <richard@cyganiak.de> [2011-06-01 22:38+0100]
> On 1 Jun 2011, at 22:16, Eric Prud'hommeaux wrote:
> > I was disputing the opacity of the query. A user would want to identify the language extensions used in particular queries if one query used, for instance, geo extensions and another some simple statistics, and you wanted to give the R2RML engine the best chance of optimizing the queries that it understood.
> 
> This makes absolutely no sense to me.
> 
> To optimize a query, an engine has to parse a query. If the query doesn't parse, then the engine doesn't understand it and has to treat it as opaque.
> 
> And in reality, your engine will be able to optimize queries that only involve inner and left joins, but won't be able to optimize queries that include subqueries and aggregates.
> 
> This flagging business is an additional burden on the user (and on the WG, if it means minting and maintaining IRIs for SQL dialects), with the only benefit that an R2RML engine can flag certain syntax errors.

I'm proposing that the WG establish one IRI for SQL 2008 and put a static document there.

The benefits to allowing users to flag the language include:

  R2RML implementations can support vendor-specific dialects without fishing the name out of highly-variable ODBC or JDBC strings.

  Users can flag specific queries as having extensions which are not peculiar to the database, e.g. OpenGIS's Within(g1 Geometry, g2 Geometry), and implementations can confidently dig into the guts of the constituent types, e.g. knowing that the Geometry is exactly the one defined by OpenGIS.

  We can future-proof R2RML so that when R2RML 2.0 switches to SQL 2012, older implementations will know that they can parse the 1.0's ref's to SQL 2008.


> Best,
> Richard

-- 
-ericP

Received on Wednesday, 1 June 2011 23:05:19 UTC