- From: Harry Halpin <hhalpin@w3.org>
- Date: Wed, 21 Jul 2010 17:50:12 +0100 (BST)
- To: ashok.malhotra@oracle.com
- Cc: "Harry Halpin" <hhalpin@w3.org>, "Richard Cyganiak" <richard@cyganiak.de>, "Marcelo Arenas" <marcelo.arenas1@gmail.com>, public-rdb2rdf-wg@w3.org
> 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 16:50:17 UTC