Fwd: Q: ISSUE-41 bNode semantics

Classy!

Begin forwarded message:
> From: Enrico Franconi <franconi@inf.unibz.it>
> Date: 19 May 2011 21:02:39 GMT+01:00
> To: Richard Cyganiak <richard@cyganiak.de>
> Subject: Re: Q: ISSUE-41 bNode semantics
> 
> I'm not answering to you anymore, sorry.
> --e.
> 
> On 19 May 2011, at 21:43, Richard Cyganiak wrote:
> 
>> Enrico,
>> 
>> On 19 May 2011, at 14:50, Enrico Franconi wrote:
>>> You appear to fall into the following category of people:
>>> 
>>> On 18 May 2011, at 22:22, Enrico Franconi wrote:
>>>> It may well be the case that the WG and the SW community at large does not like this approach (since it requires to adhere to a recipe in order to get the right answers, á la 'best practices').
>> 
>> The question is not whether I like your proposal. The question is whether your proposal is consistent with the semantics of RDF. And it isn't, as I've pointed out before:
>> http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011May/0116.html
>> 
>>> so you should be happy with my second proposal:
>>> 
>>> On 18 May 2011, at 22:22, Enrico Franconi wrote:
>>>> "Note: if a relational database contains NULL values, then the direct mapping is not applicable. This case is postponed for consideration to a future WG."
>> 
>> No. This proposal fails to deliver a practical solution.
>> 
>>> I believe that the thing we can do to deal with NULLs is to layer a best practice on top of the translation.
>> 
>> It can't be called a best practice because best practices are based on experience.
>> 
>> You can call it a convention if you like.
>> 
>> The problem with your convention is that it violates RDF Semantics.
>> 
>> I don't believe that W3C should publish a spec that contradicts the W3C spec it is based on.
>> 
>>> It is ugly, I agree, but any other solution which does not do this has been proved wrong.
>> 
>> You keep saying that, but it's not true, as I said here:
>> 
>>>> You defined your own non-standard query mechanism, declared that it should return X, showed that it does not return X if applied to the graph produced by the Direct Mapping, and hence declared the Direct Mapping unsound. This doesn't show anything.
>> ...
>>> Please check my story on the Wiki, where it has been summarised hopefully in a coherent and clearer way.
>>> 
>> 
>>> Basically, my argument is the following:
>>> 
>>> 1) I start with some RDB with NULL values;
>>> 
>>> 2) I show some queries and their answer according to the standard semantics of NULL values in SQL;
>>> 
>>> 3) I introduce two different proposals for a mapping from the RDB to RDF triples;
>>> 
>>> 4) I show how the answers of the queries considered in (2) are different from the expected ones;
>> 
>> Look, here's the problem: SQL is defined over the SQL data model, and not over RDF graphs. If you try to apply SQL semantics to an RDF graph, you're bound to get gibberish results. To query an RDF graph, you need a query semantics that is defined over RDF graphs. SPARQL, for example.
>> 
>> So to query RDF triples, you need to translate your SQL-semantics query into a SPARQL-semantics query (or some other “queries over RDF graphs” semantics). And you first need to *define* that translation before you can claim that you executed the “same” query over the SQL database and over the RDF triples.
>> 
>> And if you get different results afterwards, then all you've shown is that your query translation is incompatible with your database-to-triples mapping. That can show neither the correctness nor incorrectness of either.
>> 
>>> the first one differs from the expected one in an incomplete and unsound way - namely it returns sometimes fewer tuples and sometimes more tuples;
>>> 
>>> 5) I conclude that the proposals are wrong;
>> 
>> That's a wrong conclusion, because another possible explanation (which I maintain is the correct one) is that you have simply translated the queries from SQL semantics to … some unspecified RDF-query semantics in a way that does not preserve results.
>> 
>>> 6) I introduce a third proposal, which in addition requires that the original queries should be also mapped in a mechanical (and very easy) way;
>> 
>> And which I have shown to be incompatible with RDF Semantics.
>> 
>>> 7) I show how this latter proposal does the right job;
>> 
>> For some strange notion of “the right job”.
>> 
>>> 8) If you do not like the third proposal, then I conclude that we should not deal with NULL values at all, unless we find a working proposal.
>> 
>> The proposal to not translate nulls works.
>> 
>>>> But did you read the RDF Semantics document?
>>>> http://www.w3.org/TR/rdf-mt/
>>> 
>>> I don't see a smiley here, so I take that you are serious in asking. I guess I already replied to this very specific question <http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011May/0113.html>.
>> 
>> I just read that message again and didn't see an answer to this very specific question, Enrico: Did you read the RDF Semantics document?
>> 
>>>> If you did, then you can surely speak to the very specific technical problem with your proposal that I pointed out above?
>>> 
>>> For the n-th time, try to follow me. Tell me what do you specifically do not understand of my argument.
>> 
>> I understand your entire argument and have pointed out repeatedly what's wrong about it. For your convenience, once more:
>> 
>> 1) Your proposal violates RDF Semantics, as I said here:
>> http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011May/0116.html
>> 
>> Please respond to that.
>> 
>> 2) Your attempt at showing that the without-null-mapping is incorrect is flawed because you tried to attempt to apply SQL-semantics queries to RDF graphs. That doesn't work because SQL evaluation is defined over multisets of tuples of potentially nullable values, while RDF graphs are sets of triples consisting of names that denote, non-nullable values, and existential variables. You can't just gloss over these differences. The issue at hand -- how NULLs in SQL ought to be handled -- is at the very heart of the differences between the SQL and RDF data models.
>> 
>> Best,
>> Richard
>

Received on Friday, 20 May 2011 10:04:28 UTC