Re: Defining a SQL fragment?

Can you send us a link to the exact SQL08 core? what does it include?

Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com


On Wed, Jul 21, 2010 at 11:45 AM, ashok malhotra
<ashok.malhotra@oracle.com>wrote:

> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>