Re: Q: ISSUE-41 bNode semantics

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:50:31 UTC