- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Wed, 21 Jul 2010 10:46:55 -0700
- To: Juan Sequeda <juanfederico@gmail.com>
- CC: 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 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 17:49:04 UTC