Re: Agenda for June 14 Telcon - Revision 1

* Enrico Franconi <franconi@inf.unibz.it> [2011-06-14 17:35+0200]
> As I said, if you are a good db designer, you would design the schema of your db in a way that no attribute is nullable if you want to represent just total absence of values. How? By decomposing the potentially nullable attributes as separate (pseudo binary) relations (primary key of the relation + the attribute), and by adding a foreign key. The attributes in this relation will never have NULL values, since the absence of a value would be represented as the absence of the tuple. This is exactly your proposed DM where the null values just mean absence of information.

it sounds like you have an example in mind. if you share it with us, we can use it to make informed modelling decisions.

> On the other hand, in SQL I can also write a relationship with some nullable attributes. In this case I mean something different, namely the ambiguity between the total absence of a value and its presence but with an unknown specification.
> Queries over nullable attributes may have the NULL value in the answer; its presence may affect further queries, such as in the query (c) in the wiki.
> --e.
> 
> On 14 Jun 2011, at 17:20, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> > * Enrico Franconi <franconi@inf.unibz.it> [2011-06-14 16:58+0200]
> >> 
> >> 
> >> On 14 Jun 2011, at 15:19, Eric Prud'hommeaux <eric@w3.org> wrote:
> >> 
> >>> Not making assertions *is* the standard RDF way of dealing with missing information. There is no rdf:NULL. 
> >> 
> >> I guess we all know that.
> >> 
> >>> We don't know or care about the difference between NULL and a non-existent value
> >> 
> >> You don't care, but in SQL there is a huge difference. As a matter of fact in SQL you can model both and they would behave in different ways. And the data we are talking about does come from SQL RDBs.
> > 
> > Please provide an example grounded in real-world data of a database which conveys this distinction and a query which respects it.
> > 
> > 
> >>> (nor does SQL, for that matter).
> >> 
> >> FALSE. I already argued that SQL can represent both absence of information (in the same way as your DM: new pseudo-binary property plus a foreign key as the rsf:type) and NULL values with their peculiar distinct semantics and behaviour.
> > 
> > SELECT company FROM Contacts WHERE name="Sue" does NOT respect the difference between NULL and no value.
> > 
> >>> Given a relation R with a attributes, compose a query:
> >>> "SELECT " + ("?" + a₁) … + ("?" + aₐ)
> >>> + "WHERE { _:s a <" + R + ">"
> >>> + "          ; <" + R + "#" + a₁ + "> ?" + a₁
> >>> + "          ; <" + R + "#" + aₐ + "> ?" + aₐ
> >>> + "      }"
> >>> 
> >>> Conctacts Example:
> >>> Table:              SPARQL Query:                           Result:
> >>> ┌┤Contacts├──────┐  SELECT ?name ?company                    ┌────────────────┐
> >>> │ name │ company │  WHERE { _:s a <Contacts>                 │  who │ company │
> >>> ├──────┼─────────┤            ; <Contacts#name> ?name        ├──────┼─────────┤
> >>> │  Bob │   BobCo │            ; <Contacts#company ?company   │  Bob │   BobCo │
> >>> │  Sue │    NULL │        }                                  │  Sue │ UNBOUND │
> >>> └──────┴─────────┘                                           └──────┴─────────┘
> >>> 
> >>> No information is lost. NULL is no longer spelled "NULL", but instead as a lack of a binding. Applications using SPARQL interpret this lack of a binding the same way applications using SQL interpret NULL.
> >> 
> >> As I said several times, this confuses the presence of a NULL value with the absence of any value. So this can not be a general solution.
> > 
> > Hopefully, answering my above request for an example will clarify your point here.
> > 
> >> --e.
> > 
> > -- 
> > -ericP

-- 
-ericP

Received on Tuesday, 14 June 2011 19:46:03 UTC