Re: Q: ISSUE-41 bNode semantics

I'll try to be there.
But as a member of the group I'll raise a formal objection, then :-)
I'd like not to repeat the mistake of RDF to postpone basic issues by taking decisions that - when changed in the future - will NOT be backward compatible, generating chaos among the practitioners.
--e.

On 18 May 2011, at 15:50, Michael Hausenblas wrote:

> 
> Enrico,
> 
>> What I am saying is that having a RDF2RDF mapping without telling why and how to use it sounds to me bizarre and useless.
> 
> As it seems that you have a strong opinion on this matter I invite you to join us next week at the telecon. My gut feeling is that some 90% of the active WG members seem to agree to go for the option to not produce a triple at all.
> 
> Would you be available next Tuesday?
> 
> Cheers,
> 	Michael
> --
> Dr. Michael Hausenblas, Research Fellow
> LiDRC - Linked Data Research Centre
> DERI - Digital Enterprise Research Institute
> NUIG - National University of Ireland, Galway
> Ireland, Europe
> Tel. +353 91 495730
> http://linkeddata.deri.ie/
> http://sw-app.org/about.html
> 
> On 18 May 2011, at 14:41, Enrico Franconi wrote:
> 
>> On 18 May 2011, at 15:31, Alexandre Bertails 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.
>> 
>> I don't get it. What can you do with the data you have translated into RDF? Does it live in solitude, or should you give at least a hint to the users on how to use it?
>> If you choose to deal with NULL values, then you have to take a stance on this. Otherwise just say that you don't deal with NULL values.
>> 
>>> The reverse mapping is about rewriting SPARQL to SQL so that you target
>>> the Direct Graph resulting from the Direct Mapping.
>> 
>> Uh? Why is this a "reverse mapping"?
>> 
>> What I am saying is that having a RDF2RDF mapping without telling why and how to use it sounds to me bizarre and useless.
>> 
>> cheers
>> --e.
>> 
>>> 
>>> 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.
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> 

Received on Wednesday, 18 May 2011 13:57:25 UTC