- From: Marcelo Arenas <marcelo.arenas1@gmail.com>
- Date: Fri, 23 Jul 2010 23:20:39 -0400
- To: Harry Halpin <hhalpin@w3.org>
- Cc: Daniel Miranker <miranker@cs.utexas.edu>, public-rdb2rdf-wg@w3.org
Hi Harry, I agree with the other messages, this is a very nice summary that could help us to come to a consensus. All the best, Marcelo On 7/23/10, Daniel Miranker <miranker@cs.utexas.edu> wrote: > Harry, > > I think your summary is spot-on. > > Thank you very much for taking the time with the Edinburgh database > group. > Per an earlier email of mine, one hour teleconferences is a very > challenging way > to transmit all the necessary explanations. > > Sincerely, > > Dan > > > > On Jul 23, 2010, at 1:23 PM, Harry Halpin wrote: > >> >> I spent most the day with the Database Research Group here at >> Edinburgh, >> who kindly managed to read most of the proposals on the table. So, I'm >> going to try to channel the results of the discussion to the group. >> >> One way is to use a purely SQL-based approach (which I hope Souri >> will be >> present the week after this one) that allows the mapping to be done >> as a >> view (that is isomorphic to the triples) using the full >> expressivity of >> SQL. Then a very simple mapping construct can map the results of >> this SQL >> to a graph, i.e. by generating URIs. >> >> Another way is a purely SQL-based approach, but then expect the >> mapping >> language to provide a few easy-to-use basic constructs besides just >> generating URIs in order to do common tasks, i.e. create new nodes >> etc. I >> think this is the approach that Marcelo and Juan have been >> advocating for. >> >> Now, I think these two approaches are compatible, as long as the few >> easy-to-use basic constructs can be limited to a sensible amount >> that can >> be translated into SQL and they do *not* preclude using full-vendor >> specific SQL to create the mapping as well, i.e. in a view. This >> makes >> sense, as SQL itself can be viewed using Datalog semantics. >> >> Furthermore, people that are SQL wizarde, these basic constructs may >> not be necessary, but some people may find them (particularly >> people from >> an RDF background) easier to use than doing everything in pure SQL. >> So, >> Marcelo and Juan's approach this does not necessarily limit the >> expressivity of SQL as long as it does preclude creating a view >> using full >> vendor-specific SQL before some basic mapping functions are called. >> >> Lastly, the differences between Eric's RIF-based approach and the >> Datalog >> approach are negligible in practice, as RIF is essentially also >> based on >> Datalog semantics, i.e. RIF *is* a syntax for Datalog (which does not >> have its own syntax) plus some bells and whistles for >> extensibility. The >> argument between using Datalog or a set-theoretic semantics for >> mapping is >> not necessary, as Datalog also has a standard set-theoretic semantics >> (although we do need to get the exact semantics of what we mean by >> "Datalog" down).Soeren's approach of mapping SPARQL to SQL is also >> useful, >> and should be used as a test if there is enough time, as it still >> depends >> on the first possibly non-trivial mapping of relational data to RDF >> to be >> done (likely non-materialized). >> >> Would like to hear opinions - just trying to build consensus in the >> group, >> which despite surface differences, is actually becoming closer I >> think. >> >> cheers, >> harry >> >> >> >> > > >
Received on Saturday, 24 July 2010 03:21:07 UTC