Re: On semantics-based approaches and still using full vendor-specific SQL

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,


On 7/23/10, Daniel Miranker <> 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