- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 22 Mar 2010 22:12:30 -0000 (GMT)
- To: "Souripriya Das" <SOURIPRIYA.DAS@oracle.com>
- Cc: "Public-Rdb2rdf-Wg" <public-rdb2rdf-wg@w3.org>
> > > Before we delve deep into exploring any alternatives, we need to firmly > establish that the following SQL-based approach is insufficient (and/or > inconvenient or non-performant): I agree with the general idea that various proposals should be clarified, but I do not want to vary from the general plan, which I think is a good one. 1) There will be two general approaches obviously, one based on SQL that serves the wider database community and one based on RDF/SPARQL that serves the Semantic Web community. If both general approaches can be given in a draft specification form by early June, then we will should try to map them (ideally via formal semantics) and standardize that. If not, the most mature one should be standardized. This decision will likely be discussed at the face-to-face at SemTech. Therefore, teams - let's make those draft specs! 2) And a trivial mapping language that would be shared by either approach is also likely to be part of the RDB2RDF language, as is some sort of function call (API) that can be used by RDB2RDF mappers to locate URIs for various names in the relational data. Apologies for being out of loop, at W3C Team Day, our once-a-year meeting, with EricP and others. RDB2RDF was discussed extensively, people at the W3C and member organizations are very keen on this standard. So let's keep up the good work! > > 1) Use SQL language expressivity to specify the SQL queries (with > conventions for optionally defining instance URIs, rdf:type columns, and > graph URIs) for various extents of customization for the mapping of > relational data to RDF terms. > (Queries could be as simple as "SELECT ... FROM <table>" OR as complex as > it needs to be possibly involving INNER JOINs, OUTER JOINs, expressions, > aggregate functions, table functions, OLAP functions, hierarchical queries > (CONNECT BY), ...). > > 2) A rather "trivial" mapping language that maps 1) the queries to > RDFS/OWL classes and datatype properties and 2) constraints to object > properties. > > [For an example, please see the use of SQL queries and a trivial mapping > language in the following example: > > • Example of SQL-Query based Approach > • Part 1: Schema => RDB Schema, RDB2RDF Mapping, and generated > RDF Schema > • Part 2: Data => RDB (relational) Data and corresponding > (virtual) RDF Graphs > > ] > > I look at it this way: We are trying to see or transform relational data. > But, as we all know, SQL was designed specifically for that purpose. > Expressive power of SQL and a "trivial" mapping language to map the > logical tables returned by SQL queries to RDFS/OWL classes and properties > and the referential integrity (foreign key) constraints to object > properties are all that we need. > > So far I have not seen or heard any convincing arguments to establish that > we need anything more than SQL and a "trivial" mapping language. Before > going for an alternative, we must first establish the need for such an > alternative. > > Thanks, > - Souri. > >
Received on Monday, 22 March 2010 22:12:31 UTC