Re: ISSUE-3

Hi all,
I am new to the group so I don't know if I understood correctly the
previous work done by the group and the objectives. I would like to
ask some questions for clarifying a couple of points related to the
issue came up during the last conference call which is about the
Mapping Language we should deliver.
I apologize if I am misunderstood or if this is not focused on the
objectives of the group.
I am currently leading a data integration project at the instance
level using the OKKAM infrastructure. We were thinking to use D2R for
avoiding the implementation of a big KB.
A big issue I see also in this experience is the necessity to run
queries on multiple data sources.
>From the project presentations we listened to till now it emerged that
we are able to map databases to RDF but we are not able to connect
them so we are not able to run queries which span multiple databases
(please, tell me if I am wrong...I am not an expert, just trying to
clarify to myself some ideas in order to be helpful in the future).
I was thinking that since it's possible to decompose queries using
relational algebra and this mapping should be an objective of this
group (?) then the same mapping could be used to understand to which
database (or sparql endpoint) to send a piece of query.
I am not sure that this problem is part of the objectives of this
group, even though I think that the data integration issue should be
addressed, as written in the W3C RDB2RDF Incubator Group Report
http://www.w3.org/2005/Incubator/rdb2rdf/XGR-rdb2rdf/  (point 1.1.3
Integration of Enterprise Information Systems)
My question is:
Could the mapping delivered by this group also solve (or provide a way
to solve) the problem of the sparql federated queries ? I think this
will be extremely important for implemented the linked data idea.
In my point of view once we have created a mapping from sparql to sql
then this can also be re-used for implemented federated queries.

Thanks in advance.
Angela

On Thu, Nov 12, 2009 at 2:33 PM, ashok malhotra
<ashok.malhotra@oracle.com> wrote:
> Hello Ahmed:
> I envision that the work of the WG is one-way: from RDB to RDF/OWL.
> So, to answer your question, I do not envision creating SQL tables in the
> RDBMS from SPARQL application using R2RML.
> All the best, Ashok
>
>
> Ezzat, Ahmed wrote:
>>
>> Hi Ashok,
>>
>> Thanks for the follow up. I agree with your clarification regarding the
>> mapping SPARQL to SQL is out of scope; having discussion about it if the
>> team want to pursue is fine - I am trying to separate what we discuss, with
>> time constraints, from what we will commit to deliver which we need to pin
>> down early 2010.
>>
>> I liked the D2R presentation scope in the mapping area; is reasonable.
>>
>> Regarding DDL statements mapping support: do you envision creating SQL
>> tables in the RDBMS from SPARQL application using R2RML or do you envision
>> the ability through the R2RML to read the different schema objects
>> definitions in the RDBMS from a SPARQL application?  I agree that the latter
>> is a must and would be interested in getting your input as well as others on
>> the first.
>> Regards,
>>
>> Ahmed
>>
>>
>> -----Original Message-----
>> From: public-rdb2rdf-wg-request@w3.org
>> [mailto:public-rdb2rdf-wg-request@w3.org] On Behalf Of ashok malhotra
>> Sent: Wednesday, November 11, 2009 13:58
>> To: RDB2RDF WG
>> Subject: ISSUE-3
>>
>> Since the goal of the WG is to create a mapping from RDB Schemas to
>> RDF/OWL classes, perhaps
>> we should rephrase the bullet point in the requirements as
>>
>>    * The mapping language MUST define the set of SQL DDL
>>      to be supported in the first release. The set to be supported
>>      SHOULD be as complete as possible and be defined as soon as
>>      possible after the WG official launch.
>>
>> This will let us exclude Table Types if we wish.
>>
>> I apologize that the original bullet was interpreted to mean that the the
>> WG should define
>> a mapping from SPARQL to SQL.  That was not the intention.  In my view,
>> the mapping of
>> SPARQL to SQL should be left open as a technology on which various
>> implementations
>> can compete. .
>>
>

Received on Thursday, 12 November 2009 14:27:56 UTC