- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Wed, 21 Jul 2010 10:15:42 -0700
- To: Harry Halpin <hhalpin@w3.org>
- CC: Richard Cyganiak <richard@cyganiak.de>, Marcelo Arenas <marcelo.arenas1@gmail.com>, public-rdb2rdf-wg@w3.org
Harry, Juan: The SQL spec is very large and you need to pay money to get it. I have a courtesy copy that, unfortunately, I cannot share. The other problem is that the list of features in the Core covers many pages. I'll see what I can find on the Web All the best, Ashok Harry Halpin wrote: >> Why don't we agree on SQL08 Core? This is what every compliant RDB >> vendors MUST support. >> All the best, Ashok >> > > That would be fine with me. Do we have a pointer to a URI for it? > > >> Harry Halpin wrote: >> >>>> Harry, >>>> >>>> On 19 Jul 2010, at 15:42, Harry Halpin wrote: >>>> >>>> >>>>>> The fragment of Datalog that we need to use for the mapping language >>>>>> has a simple syntax and a semantics that can be easily understood, so >>>>>> it is a good alternative. >>>>>> >>>>>> >>>>>> >>>> ... >>>> >>>> >>>>> The other topic would be to see if this SQL fragment would be a good >>>>> starting point for the SQL-based approach as well. >>>>> >>>>> >>>> I don't understand the purpose of defining a SQL fragment for the SQL- >>>> based approach as part of this WG's work. >>>> >>>> >>>> >>> I guess my concern was "portability" of SQL and the desire of some >>> people >>> in the WG (Eric) to use RIF and/or SPARQL constructs to do the mapping. >>> >>> The concern was that "full" SQL might not be portable amongst vendors, >>> so >>> if there's just a black box with arbitrary SQL between angle brackets in >>> R2ML it might not be portable. We brought the idea of referencing the >>> SQL >>> ISO Spec up with the W3C, but there was some disagreement as they aren't >>> publically available and that vendors just implement them differently. >>> >>> However, it seems that disallowing "full vendor-specific SQL" is also >>> probably a bad idea. So...what to do? I think for ETL purposes language >>> could have 4 parts. Each except 3) is optional. >>> >>> 1) Full vendor specific SQL to create a view >>> >>> 2) A portable subset of SQL to create a view >>> >>> 3) Mapping of that view to a default graph >>> >>> 4) Possibly running RDF-to-RDF transforms here (RIF). >>> >>> I think Marcelo and Juan were wondering if steps 2-4 had a common core >>> that could be thought of semantically as Datalog. >>> >>> But if people choose 1) then they just have to know that R2ML will not >>> guarantee portability. 4) and 2) can be optional. >>> >>> What this does not bring up is what eric and soeren were really wanting >>> to >>> do earlier as well, which was SPARQL->SQL mappings. I was hoping that >>> could be covered by Datalog as well. But maybe algebraically... >>> >>> However, before descending into the black hole of semantics and options, >>> Im'm happy to agree to get a rough-draft out on 1) and 3) if people >>> can't >>> agreee on 2) and 4). >>> >>> >>> >>>> I think there is a clear desire to allow full SQL in a compliant >>>> implementation of the SQL-based approach. This is at least what I >>>> gather from Souri's and Orri's comments. I can not remember anyone >>>> making an argument that only a restricted SQL fragment should be >>>> allowed in the SQL-based approach. >>>> >>>> Can you please explain, or point me to the discussion that motivates >>>> the need for restrictions in the allowable SQL in the SQL-based >>>> approach? >>>> >>>> Best, >>>> Richard >>>> >>>> >>>> >>>> >>> >>> >> > >
Received on Wednesday, 21 July 2010 17:17:52 UTC