Re: Defining a SQL fragment? (was: Re: Using Datalog as a common semantics)

> 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