Re: contrasing SPARQL Federation + DM/R2RML vs. SQL federation tools

On 2/13/12 6:28 PM, Richard Cyganiak wrote:
> On 13 Feb 2012, at 18:19, Eric Prud'hommeaux wrote:
>>> But from what I hear, you can query the remote
>>> table by
>>>
>>> select * from remoteserver.remotedb.remoteschema.remotetable
>> I read that as #2 then. Isn't
>> remoteserver.remotedb.remoteschema.remotetable illegal in conventional
>> SQL?
> A fully qualified name in standard SQL is something like catalog.schema.table.column. My understanding is that federation systems make remote DBs show up as additional catalogs beside the default one.
>
> Best,
> Richard

Richard,

Some do, but its utterly broken and incompatible in the context of the 
SQL standard which is based on a 3 part qualification scheme.

In Virtuoso we work with remote DSNs without moving outside the 3 part 
object dbms qualification scheme.

R2RML will be adversely affected by N part qualification schemes that 
SQL vendors implement outside the spec.

The goal is for 3rd parties to be able to exchange R2RML files with 
minimal local tweaking. Having to rework qualifiers in such a scenario 
is nothing short of the kind of the kind nightmare that will just render 
R2RML unusable, thus we shouldn't encourage or embrace this problematic 
practice.


Kingsley
>
>
>>
>>> SQL Server has a defined mapping of their types with other types. If I
>>> understand correctly, you either bring in the table into you local sql
>>> server, or you can also push parts of the query to the remote database, and
>>> they can translate sql server sql to other sql dialects.
>>>
>>>
>>>
>>>> 2. User queries are expressed in an SQL-like language with extra
>>>> productions to target joins against particular databases.
>>>>
>>>>
>>> Not that I'm aware of.
>>>
>>>
>>>> 3. Configuration created a virtual warehouse in a single schema. User
>>>> queries against this warehouse/view are re-written to connect to the remote
>>>> database.
>>>>
>>> This is just the general ETL data warehouse data integration approach,
>>> right :)
>> pretty much, though I have the impression that most of these
>> wharehouses are materialized, potentially not using any expressivity
>> beyond SQL (i.e. you write some java code to do SQL SELECTs from your
>> various authoritative databases and INSERTs into the warehouse).
>>
>>
>>>>> I'm giving the Linked Data tutorial at semtech. If our tutorials don't
>>>>> overlap, I could help you out with this.
>>>> Excellent -- tx.
>>>>
>>>>
>>> Don't quote me on any of this ;) I could get confirmation and we could work
>>> this out together.
>>>
>>>
>>>>> Juan Sequeda
>>>>> +1-575-SEQ-UEDA
>>>>> www.juansequeda.com
>>>>>
>>>>>
>>>>> On Mon, Feb 13, 2012 at 10:13 AM, Eric Prud'hommeaux<eric@w3.org>
>>>> wrote:
>>>>>> I'm giving a talk at SemTech which I'm lead to believe will cover
>>>> SPARQL
>>>>>> over SQL databases. One of the motivators for the SemWeb is that we
>>>> get to
>>>>>> connect everything to everything, including e.g. sets of SQL DBs. The
>>>>>> relational world has some tooling for the latter case, e.g. "Oracle
>>>>>> Database Streams" and "SQL Server Integration Services". What do y'all
>>>> know
>>>>>> about them? It could help some audience members if I were able to
>>>> contrast
>>>>>> existing SQL tooling against SPARQL over DB-backed RDF graphs.
>>>>>>
>>>>>> --
>>>>>> -ericP
>>>>>>
>>>>>>
>>>> --
>>>> -ericP
>>>>
>> -- 
>> -ericP
>>
>
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen