- From: Michael Hausenblas <michael.hausenblas@deri.org>
- Date: Wed, 18 May 2011 14:23:15 +0100
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: Richard Cyganiak <richard@cyganiak.de>, Ivan Herman <ivan@w3.org>, Pat Hayes <phayes@ihmc.us>, W3C RDB2RDF <public-rdb2rdf-wg@w3.org>
Enrico, We're doing SPARQL 1.0 here in RDB2RDF land, so all the worries re aggregation and updates are moot. Does this change your proposal? 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:20, 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:23:47 UTC