Re: Defining a SQL fragment?

Shouldn't we, as a group, have a copy of the spec?

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


On Wed, Jul 21, 2010 at 12:15 PM, ashok malhotra
<ashok.malhotra@oracle.com>wrote:

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