- From: Harry Halpin <hhalpin@w3.org>
- Date: Wed, 21 Jul 2010 19:25:08 +0100 (BST)
- To: ashok.malhotra@oracle.com
- Cc: "Juan Sequeda" <juanfederico@gmail.com>, "Harry Halpin" <hhalpin@w3.org>, "Richard Cyganiak" <richard@cyganiak.de>, "Marcelo Arenas" <marcelo.arenas1@gmail.com>, public-rdb2rdf-wg@w3.org
> See http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2fIEC+9075-2%3a2008 Note the W3C, after an internal discussion quite a while ago, was distinctly unhappy with referencing a normative spec that costs money to download. They said that it's fine to cite the spec, *as long* as the spec we write is written in such a way implementers do not have actually pay for and read the spec. I do not think the W3C realized how the SQLCORE08 this spec was. Thoughts? The advantage of the SQL->Datalog (->RIF) approach was that we could probably specify the core. The disadvantage is that this would limit the ability of people to write SQL, which people are naturally strongly against. One way out could be just to say informatively "We strongly suggest that SQL used in creating the view before the mapping of that view to the graph be compliant with SQLCORE08" but not sure if that approach would work for the W3C. I'm happy to bring the issue up again with the W3C on this one. Hmmm...I feel an impasse. Any ideas? > All the best, Ashok > > > Juan Sequeda wrote: >> Shouldn't we, as a group, have a copy of the spec? >> >> Juan Sequeda >> +1-575-SEQ-UEDA >> www.juansequeda.com <http://www.juansequeda.com> >> >> >> On Wed, Jul 21, 2010 at 12:15 PM, ashok malhotra >> <ashok.malhotra@oracle.com <mailto:ashok.malhotra@oracle.com>> wrote: >> >> Harry, Juan: >> The SQL spec is very large and you need to pay money to get it. I >> have a courtesy copy that, >> unfortunately, I cannot share. >> The other problem is that the list of features in the Core covers >> many pages. >> I'll see what I can find on the Web >> >> All the best, Ashok >> >> >> Harry Halpin wrote: >> >> Why don't we agree on SQL08 Core? This is what every >> compliant RDB >> vendors MUST support. >> All the best, Ashok >> >> >> >> That would be fine with me. Do we have a pointer to a URI for >> it? >> >> >> >> Harry Halpin wrote: >> >> >> 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 18:25:13 UTC