Re: Q: ISSUE-41 bNode semantics

On Wed, May 18, 2011 at 8:31 AM, Alexandre Bertails <bertails@w3.org> wrote:

> Very quickly: RDB is not SQL, it's the subset of SQL called DDL,
> concerning the data.
>
> We don't deal with SQL queries at all.
>
> The reverse mapping is about rewriting SPARQL to SQL so that you target
> the Direct Graph resulting from the Direct Mapping.
>

Thanks Alexandre for the clarification. I just did the same clarification in
a different email.

A reminder:

handling NULLs with R2RML is ISSUE-41

handling NULLs with Direct Mapping is ISSUE-42

I hope I didn't make things even more confusing with the tracker.

>
> Alexandre.
>
> On Wed, 2011-05-18 at 15:20 +0200, Enrico Franconi wrote:
> > On 18 May 2011, at 13:28, Richard Cyganiak wrote:
> >
> > > So unless someone (Ted? Enrico?) can propose a better alternative, I'm
> still in favour of simply not producing triples for NULLs.
> >
> > Please let me note first that my arguments are not about "what a NULL
> value possibly does mean among various possibilities", but they are about
> "what a NULL value normatively means in the SQL standard".
> >
> > From a meaningful translation of a RDB in RDF, we should be able also to
> understand the translation of operations (e.g., SQL queries or updates) over
> the original data in, say, SPARQL over the translated data. I am not
> interested in the reverse mapping, but of course I'm interested in how to
> use correctly the data.
> >
> > If the original RDB data does not contain nulls, and the direct mapping
> is employed, then it is sort of obvious how to translate the SQL operations
> into SPARQL operations: basically it goes through reification of the
> relational signature into an object model.
> > However, when NULL values are present, then operations over data
> (queries, updates) became less obvious.
> >
> > Examples:
> >
> > (a) projection over attributes containing NULL values should return the
> NULL values, different from not returning anything;
> >
> > (b) a (self-)join fails for tuples with a NULL value in the join
> attribute;
> >
> > (c) aggregation, updates, etc.
> >
> > By not translating NULL values, you fail (a).
> > By translating NULL values, you fail (b).
> > (c) is even more complex.
> >
> > How does SQL solve the matter? By considering a NULL value as a constant,
> and then tweaking the query answering mechanism letting the join fail
> whenever this constant is found (see the "three valued semantics").
> >
> > To mimic this in RDF2RDF, my suggestion would be to translate a NULL
> value as a special constant from a special datatype, and then we should
> provide precise directives on how a query language should deal with this.
> This is how SQL normatively defines the NULL values. Note that this may not
> be a trivial exercise, due to the complexity of the new SPARQL language,
> which I understand contains aggregations :-(
> >
> > cheers
> > --e.
> >
>
>
>
>