Re: 3vl 2vl and NULL

Hugo Kornelis wrote:
> On 15 Dec 2005 14:21:18 -0800, dawn wrote:
>
> (snip)
> >> This definitely improves the quality of how your 2VL logic system
> >> handles missing data. But I still don't like it. :-)
> >
> >If you worked with it for a bit or if you had not worked with a 3VL at
> >all, you would likely be happier with it.
>
> Hi Dawn,
>
> Yes, of course. If I had never known about 3VL, I wouldn't miss the
> extra control it gives. You can't miss what you're not aware of.

OK, so 3VL it isn't essential. Does it provide better value for an organization than using a 2VL? I say "no" and you say "yes." It sounds like we each have experience with both and have arrived at a different conclusion.

> >
> >> And you have already given the reason.
> >>
> >> > Now, perhaps Uncle
> >> >Vernon is 110, clearly older than Aunt Marge, but that fact has not yet
> >> >been recorded since people were pouring over medical and legal records
> >> >to verify this first. He will then incorrectly be identified as
> >> >someone whose age (in this database) is less than or equal to Marge's
> >> >age. When the data are not correct in the system, the results of the
> >> >queries are not correct either.
> >>
> >> But in this case, the data was not incorrect.
> >
> >Yes, it was incorrect. In order to simply, we could say that we
> >modeled the proposition:
> >
> >Uncle Henry's age is unknown
> >
> >with the database data of
> >
> >Uncle Henry has no age
>
> No, Dawn, we didn't model either of those propositions. We only modeled
> a proposition that looks like <person> is <age> years old,

That is a fine predicte. The real world proposition I have in my hand is "Uncle Henry's age is unknown." You may choose to model and include this proposition however you like, including by ignoring this it altogether. I am going to model it in a way that simplifies data handling with an inaccurate proposition "Uncle Henry has no age" and implement this with the predicat you list so it is modeled like

Uncle Henry <person> is without an age <age>. person = Uncle Henry
age = the null set

While it might seem wrong to model the fact I have with an inaccurate proposition, a model is necessarily a simplification in some respects. Simplifying in this way seems to make the data highly useful and useable for developers and end-users alike. While I don't ever recall discussing the meaning of null data with end-users in an MV/Pick implementtion (although I might have), I definitely recall discussing it with end-users and developers alike in a SQL implementtion. This is only anecdotal, however and I don't know that there could be a proof that a 2VL is easier for people to work with. Can you think of an experiment we could do or data we could collect on this matter or must it remain a matter of taste?

> and omitted
> to include a fact for Uncle Henry in the data collection.
>
> Think of the DB components as persons performing a task. The task is
> (for example) to calculate family member's ages in decades.
> For Aunt Marge, the person asks the data keeper for her age. He gets a
> reply, divides by ten, then informs his manager about the age of Aunt
> Marge.
> For Uncle Henry, the person again asks the data keeper for his age. He
> doesn't get any reply (signaled, in the DB, but NULL. Of course, that
> only means that he can't give a reply to his manager either (again,
> signaled by NULL in the DB).

In my scenario, he would be able to pass along the original proposition. He could interpret the data back into the predicate as "Uncle Henry has no age" and recognize that this must mean that we do not know his age or "Uncle Henry's age is unknown".

In this 2VL scenario we are always working with a proposition and not the absense thereof. We can give propositions back when data are requested rather than having to respond with blank face. Although this doesn't prove that the 2VL gives a better bang for the buck (which I would offer as a hypothesis), I would think it would be clear to most with these last two statements that this provides a more satisfying human-computer interaction.

> Real people would still communicate the fact that they can't give an
> answer, and start blaming others. But this fictional DB component is
> constrained to only return an integer to his manager, and this integer
> should be an age in decades.

I disagree. I prefer to be able to model a wider range of propositions that might be collected.

> He can't return this - ergo silence in the
> people analogy, or NULL in the DB.

How unsatisfying, don't you think? The more I read on this topic, the more pleased I am to be using a 2VL end-to-end in software development.  It isn't just a matter of taste, it is a matter of cost. It is very difficult, if not impossible, to isolate such a feature and prove that a 2VL is less costly, however, so I guess this will continue to be a matter of taste and whether a 2VL or 3VL is "in" will depend on what tools are popular. It looks to me like we are moving away from a 3VL as an industry, retaining it only in the SQL world. Is that your read as well? What other tools perpetuate the 3VL? Is there any such thing as doing end-to-end development with a 3VL, interpreting a view of data being collected through a UI as being the lack of a proposition (or whatever it is you would want the interpretation to be in a 3VL UI) whenever a value is missing?

Thanks. --dawn Received on Thu Dec 22 2005 - 15:53:30 CET