Re: Storing data and code in a Db with LISP-like interface

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 17 Apr 2006 00:40:05 GMT
Message-ID: <FtB0g.61083$VV4.1133269_at_ursa-nb00s0.nbnet.nb.ca>


Marshall Spight wrote:

> Bob Badour wrote:
>

>>Marshall Spight wrote:
>>
>>But if we accept the closed world assumption, the cardinality-0 relation
>>says we know that no instances of the predicate are true. This, of
>>course, contradicts the initial condition where we know some value
>>satisfies the predicate, but we do not know which value.
>>
>>And if we use this trick to model the missing information, how do we
>>distinguish it from the situation where we genuinely know that no value
>>satisfies the predicate?

>
>
> If we have a requirement to distinguish between
> exists-but-we-don't-know
> and doesn't-exist, then the cardinality-0 model is insufficient. But
> there
> are also cases where we won't need to so distinguish, and cases
> where doesn't-exist is not a possibility. In those cases, I would
> propose that cardinality-0 is often a better choice than SQL's NULL.

Yes, well, you are not putting the bar very high. Now, are you? Besting SQL's NULL for handling missing information is rather like tripping over a shoelace.

The closed world assumption is going to bite you more often than you seem to suppose. Presumably, if you have a relation valued attribute, you intend to use the relational algebra or calculus on it. However, the closed world assumption is central to both which means they will yield incorrect results in many cases unless the user takes extraordinary measures to account for the not-quite-closed nature of the model's world.

One must consider those consequences when considering relation valued attributes as a means to describe missing information.

Considering that the method basically uses the relation type generator to inject a new type for the attribute, I can imagine other type generators that would provide a more appropriate set of operations for the resulting type.

> I don't think it's a complete solution, though. I think some kind of
> sum type, as in SML, is also quite desirable. This lets the
> modeller create special values according to the requirements
> of the domain.

I could not find a comprehensive enough reference for SML online to decypher what you are saying above. Is a sum type similar to a union type of some sort?

I would certainly like the ability to model new type generators, and SML looks like it has some nice features for doing that. (Based on the very brief look I took at what documentation I could find.)

>>I really see no way around knowing all of the requirements and
>>reluctantly choosing the least among evils for each individual
>>situation. I admit this is ad hoc and risky, but I find it less risky
>>and no more ad hoc than the known alternatives.

>
>
> I agree.
>
> To clarify, I am certainly *not* proposing that there is any
> shortcut for doing the hard work of building a good model
> for the domain in question.

Okay. I apologize if your brief comments led me to believe you were more enthused by relation valued attributes than warranted. Missing information requires hard work and difficult tradeoffs. Received on Mon Apr 17 2006 - 02:40:05 CEST

Original text of this message