Re: Defining a SQL fragment?

Why don't we agree on SQL08 Core?  This is what every compliant RDB 
vendors MUST support.
All the best, Ashok


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:47:40 UTC