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