Re: Re-opening ISSUE-22 on vendor-specific SQL

On Tue, May 31, 2011 at 3:57 PM, Richard Cyganiak <>wrote:

> > Although my fear is that most real-world mapping will have some vendor
> specific SQL in them
> <snip>

> > and therefore most real-world mappings will have "no particular behavior"
> defined.
> <snip>

> Can you think of some words that work better for you than the proposed
> ones?
Richard- I think if I were going to explain to someone the meaning of a
vendor specific SQLQuery it would be something like:

* the query text is expected to be a string representation of a query that
can be used as a sub-query and submitted as-is to a relational database
* the syntax is unspecified and specific to the relational database engine
* the query is expected to produce a set of tuples
* these tuples can be used as a logical table in R2RML
* the column names projected are as specified in the "column" property (or
without this feature... the column names are unknown until runtime and may
change on each execution (?) like a stored procedure call?)

We don't talk about the datatypes of the columns of other logical tables so
it seems we can avoid talking about datatypes in the case of vendor specific
SQLQueries (?).

What do you think, would it make sense to put a polished version of this in
the R2RML? Or does this bleed too much into the hand waving we need to


Received on Wednesday, 1 June 2011 13:25:48 UTC