- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Tue, 23 Mar 2010 08:24:29 +0000
- To: Juan Sequeda <juanfederico@gmail.com>
- Cc: Souripriya Das <souripriya.das@oracle.com>, Public-Rdb2rdf-Wg <public-rdb2rdf-wg@w3.org>
Hi Juan, On 23 Mar 2010, at 04:24, Juan Sequeda wrote: > The advantage (IMO) of our triple view approach is that the sparql > to sql > translation is straightforward and we let all the hard stuff to the > optimizer (hence it needs to be a good optimizer). Agreed. > My guess is that if you > to follow another approach, the sparql to sql translation may be a > bit more > complicated Agreed. > (and may not depend on the sql optimizer). No. If your mapping is expressed as one or more atomic, opaque blobs of SQL (such as in the SQL query based approach, no matter if you use views or subselects to implement it), then you will always have to either rely on the quality of the native SQL optimizer for implementing SPARQL-to-SQL, or parse the mapping SQL queries yourself and implement your own optimizer to patch over problems with the native optimizer. > However, this shouldn't be part of the WG. The working group has no business specifying a certain algorithm for SPARQL-to-SQL rewriting. However, one criterion for evaluating competing proposals for expressing RDB2RDF mappings has to be their implementability. Thus, WG members have to establish the implementability of their proposals. This is not too much to ask -- a lot of work on RDB2RDF has been already done, both in implementation and in the research literature, so the implementability of many things has been already well established. And if one proposal has significantly higher implementation costs in important scenarios, then this should be factored into the WG's decision about which proposal to pursue. Best, Richard
Received on Tuesday, 23 March 2010 08:25:04 UTC