Re: Agenda for June 14 Telcon - Revision 1

On 14 Jun 2011, at 13:51, Michael Hausenblas wrote:

> 
>> The proposal says that the DM is not applicable to RDBs with NULL values.
> 
> I didn't see your proposal, yet.

uh? From the wiki:
"Proposal EF-1: If a relational database contains NULL values, then the direct mapping is not applicable. This case is postponed for consideration to a future WG."

cheers
--e.


> 
>> Don't restart all the discussion again.
> 
> Please let's not go there. As a WG co-chair it is my responsibility to ensure progress. If you don't like that, you're more than welcome to take over my position, I'll happily resign.
> 
> 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 14 Jun 2011, at 12:44, Enrico Franconi wrote:
> 
>> NO.
>> The proposal says that the DM is not applicable to RDBs with NULL values.
>> Don't restart all the discussion again.
>> 
>> On 14 Jun 2011, at 13:37, Michael Hausenblas <michael.hausenblas@deri.org> wrote:
>> 
>>> 
>>>> Fair enough. If you believe so, then the proposal should be the one where we give up on NULL values, since it is the only one where there is no technical disagreement in the WG :-)
>>> 
>>> OK. So here is the proposal:
>>> 
>>> [[
>>> PROPOSAL: To resolve ISSUE-42, the Direct Mapping will include triples representing the relational schema and will omit triples for NULL values.
>>> ]]
>>> 
>>> 
>>> 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 14 Jun 2011, at 12:24, Enrico Franconi wrote:
>>> 
>>>> On 14 Jun 2011, at 13:17, Michael Hausenblas <michael.hausenblas@deri.org> wrote:
>>>> 
>>>>> 
>>>>>> In the wiki I came up explicitly with 3 alternative concrete wordings; please look at them.
>>>>> 
>>>>> 
>>>>> Looked at them. I need one (1) not three (3).
>>>>> 
>>>>> 
>>>>>> What I can not do is to solve the open technical problem for the representation with missing NULLs, since it is hard and complex.
>>>>> 
>>>>> That's also my understanding. Hence we can't normatively spec something where even the scientific part is not solved.
>>>> 
>>>> Fair enough. If you believe so, then the proposal should be the one where we give up on NULL values, since it is the only one where there is no technical disagreement in the WG :-)
>>>> I argued that also the proposal with materialised NULLs is technically sound, but not everybody in the WG believes so.
>>>> --e.
>>>> 
>>>> 
>>>>> 
>>>>> 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 14 Jun 2011, at 12:15, Enrico Franconi wrote:
>>>>> 
>>>>>> In the wiki I came up explicitly with 3 alternative concrete wordings; please look at them.
>>>>>> What I can not do is to solve the open technical problem for the representation with missing NULLs, since it is hard and complex. The proposers of this representation should come up with an answer to this question, so to support their argument. Otherwise only my proposals can stand.
>>>>>> 
>>>>>> On 14 Jun 2011, at 13:07, Michael Hausenblas <michael.hausenblas@deri.org> wrote:
>>>>>> 
>>>>>>> 
>>>>>>>> It is ages I'm asking to this WG how to rebuild the correct answers with explicit NULLs from your representation
>>>>>>> 
>>>>>>> This is, IMO, the core of the problem. You're asking rather than coming up with a concrete wording for the proposal.
>>>>>>> 
>>>>>>> Please, for the sake of getting this issue closed and meeting the September deadline for LC: Enrico, can you draft a concrete wording such as:
>>>>>>> 
>>>>>>> 
>>>>>>> [[
>>>>>>> PROPOSAL: To resolve ISSUE-42, ...
>>>>>>> ]]
>>>>>>> 
>>>>>>> 
>>>>>>> that we can discuss and hopefully resolve today?
>>>>>>> 
>>>>>>> If we fail to get this done today I'm inclined to change the overall timeline because we have a lot of more issues to resolve and simply can not afford it to discuss one single issue (no matter how important it is) till the cows come home.
>>>>>>> 
>>>>>>> This is not a scientific beauty context. We're writing a spec, for heavens sake.
>>>>>>> 
>>>>>>> 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 14 Jun 2011, at 11:44, Enrico Franconi wrote:
>>>>>>> 
>>>>>>>> On 13 Jun 2011, at 23:16, Eric Prud'hommeaux wrote:
>>>>>>>> 
>>>>>>>>> There is a fundamental difference between SPARQL and SQL users in that SQL users either prohibit a query from answering with NULLs:
>>>>>>>>> SELECT name, company           ┌────────────────┐
>>>>>>>>> FROM Conctacts         │ name │ company │
>>>>>>>>> WHERE name="Sue"         ├──────┼─────────┤
>>>>>>>>> AND company IS NOT NULL     └──────┴─────────┘
>>>>>>>>> or they write in some application code to skip over the NULLs, or, pretty commonly, the UI paints an empty string and the interface user has to guess whether it's was a NULL or a company named "". The intent of the query in this example was clearly to get the names of the companies which Sue represents, for wich neither NULL nor r2rml:NULL nor "" are acceptable answers.
>>>>>>>> 
>>>>>>>> I claim that you can filter out NULLs, exactly like you would do in SQL. On which ground do you claim that applications built on top of RDF data are different from applications built on top a RDB wrt the usage of NULLs? I don't see any evidence that there is such a radical difference to justify your non-standard way in dealing with standard NULLs.
>>>>>>>> 
>>>>>>>>> At any rate, I was just arguing that given a tension between putting burden on the query author to incorporate <code>FILTER (?company != r2rml:NULL)</code> into the above query, vs. requiring the person who wants to see the NULL to know the schema:
>>>>>>>>>                                               ┌────────────────┐
>>>>>>>>> SELECT *                                            │  who │ company │
>>>>>>>>> WHERE { ?who <Conctacts#name> "Sue"              ├──────┼─────────┤
>>>>>>>>> OPTIONAL { ?who <Conctacts#company> ?company } }   │  Sue │ UNBOUND │
>>>>>>>>>                        └──────┴─────────┘
>>>>>>>>> , I *think* the rest of the WG is in favor of the the latter (hence the claim of rough concensus).
>>>>>>>> 
>>>>>>>> No, this doesn't work, since you would confuse the answer with a NULL value with the answer with a non existing value. So, the above query doesn't do the job you are declaring. It is ages I'm asking to this WG how to rebuild the correct answers with explicit NULLs from your representation (even with the schema). To no avail.
>>>>>>>> So, please tell me explicitly how do you get the right answer in the above case, with all the details (how the schema is used, how do you distinguish the missing value with the NULL value, how this can be applied mechanically to general queries, etc).
>>>>>>>> 
>>>>>>>>>> That's why I am saying "This mapping for NULL values is arbitrary since the WG has left unexplored its relationship with the original meaning and behaviour of NULL values in the source RDB."
>>>>>>>> 
>>>>>>>> I can repeat that :-)
>>>>>>>> 
>>>>>>>>>> What I am asking you since ages is to go through my three examples and see how your proposal would actually encode the answers, and show how this would lead to a generic recipe.
>>>>>>>> 
>>>>>>>> This request still stands.
>>>>>>>> 
>>>>>>>>>> My argument is that this will most likely be possible, but that it will be overly complex since it will necessarily require the ability to recognise whether a missing value is a NULL or not (also in the answer set!).
>>>>>>>> 
>>>>>>>> Let's see your answer to my question in bold above.
>>>>>>>> 
>>>>>>>>>> Clearly, by having explicit NULL values this problem is avoided. Moreover, you can easily switch the the absent-NULL representation by just filtering all the tuples with NULL values in one simple shot.
>>>>>>>>> 
>>>>>>>>> In <http://www.w3.org/2001/sw/rdb2rdf/wiki/RDBNullValues#Comments_and_Proposal_by_Enrico>, you asked how to discriminate between the direct graphs of
>>>>>>>>> ┌┤R├────────┐ and ┌┤R'├┐
>>>>>>>>> │ ID │    A │     │ ID │
>>>>>>>>> ├────┼──────┤     ├────┤
>>>>>>>>> │  1 │ NULL │     │  1 │
>>>>>>>>> └────┴──────┘     └────┘
>>>>>>>>> , but we do that by knowing the schema so the question doesn't help us learn what is a reasonable mapping.
>>>>>>>> 
>>>>>>>> This is too vague: "we do that by knowing the schema". As I said above, please tell how do you proceed explicitly.
>>>>>>>> 
>>>>>>>>> I instead propose that you ask questions of the ┤Conctacts├ database above and show how, even knowing the schema, the direct graph doesn't give you reallistic access to information. Remember, this isn't a database interchance language, but instead a way to give RDF users an useful view of relational data.
>>>>>>>> 
>>>>>>>> I don't understand this point :-(
>>>>>>>> 
>>>>>>>> cheers
>>>>>>>> --e.
>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>

Received on Tuesday, 14 June 2011 13:08:06 UTC