Re: RDB2RDF mapping: Do we really need any alternative to use of SQL queries with conventions and a "trivial" mapping language?

Richard,


>
> 1. Why the SQL query based approach is nice
> -------------------------------------------
>
> First, I definitely see the attraction of the SQL query based approach. I
> understand this approach as: leveraging the expressivity of SQL to do as
> much of the mapping/transformation as possible, with some simple glue around
> it that essentially turns each SQL result record into a few triples
> according to some simple rules.
>
> It's attractive because the approach leverages existing SQL knowledge of
> mapping authors; it maximises expressivity; it means we don't have to
> specify a large chunk of the problem ourselves; it produces syntactically
> compact mappings. So, purely from an authoring point of view it is
> definitely a nicer approach than any of the proposed alternatives (D2RQ,
> Virtuoso RDF views, R2O etc).
>
> In order to run SPARQL queries against such a mapped database, one would
> use the “triple view” approach, as detailed in Juan's work. So the
> SPARQL-to-SQL engine would create a single view in the DB which consists of
> lots of unions and in the end contains one row for each mapped triple, with
> subject, predicate and object. How to run SPARQL queries against such a
> relational structure is well-known from prior work on database-backed triple
> stores. The result is a humongous SQL query over a humongous view
> definition, but as Juan has shown, good SQL optimizers can simplify this
> into a reasonable query plan.
>

You don't have to use a triple view approach. Our inspiration of the triple
view was from the naive triple table approach that initial rdbms backed
triple stores used. It was an experiment to see how the sql optimizer would
work.. and it turned out pretty neat. So Yes, we great a humongous view
definition. But No, this is not THE way to go. Our work shows what can be
done with very little effort (hoping to persuade that this is useful and it
isn't going to cost basically anything)

The same way we create a humongous sql triple view definition, you could
create several views a la triplify or oracle proposal.

The advantage (IMO) of our triple view approach is that the sparql to sql
translation is straightforward and we let all the hard stuff to the
optimizer (hence it needs to be a good optimizer). My guess is that if you
to follow another approach, the sparql to sql translation may be a bit more
complicated (and may not depend on the sql optimizer). However, this
shouldn't be part of the WG.