Re: Defining a SQL fragment?

Harry,

Thanks for the clarification.

On 21 Jul 2010, at 17:42, Harry Halpin wrote:
> 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).

Where in these 4 do I say that USER.NAME should be mapped to foaf:name  
rather than mydb:USER.NAME?

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

Ok, but the differences between SQL dialects are mostly about syntax  
and hardly about semantics; so I'm still unsure how Datalog helps with  
SQL portability.

> What this does not bring up is what eric and soeren were really  
> wanting to
> do earlier as well, which was SPARQL->SQL mappings.

Are you saying that we need separate languages for ETL access and for  
SPARQL access to the mapped database? I don't think so; it's the same  
language. R2ML should specify how to derive an RDF graph from a  
relational DB. How to access that RDF graph (linked data, SPARQL, ETL,  
brainwave transmission) is up to implementations.

Best,
Richard




>
> 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 18:33:16 UTC