Re: On specialization constraints time of application

From: Cimode <cimode_at_hotmail.com>
Date: Sun, 14 Jun 2009 00:36:28 -0700 (PDT)
Message-ID: <af92f612-e800-46b2-bc0d-707c231daf61_at_r10g2000yqa.googlegroups.com>


> Decomposition is only one way to deal with missing information, and all it
> does is move the problem.  Under the Closed World Interpretation, the
> absence of a tuple in a relation does not indicate that information is
> missing, but instead denies it.  

> Decomposition as a mechanism for dealing
> with missing information, therefore, is in my opinion incompatible with the
> Closed World Interpretation.  Darwen's is an inconsistent approach because
> some relations represent what is true, and some represent what is known to
> be true.  Those that represent what is known to be true fall under the Open
> World Interpretation.  That's one problem.

> Darwen's approach is directed at the elimination of nulls, but there are in
> fact two basic sorts of nulls: nulls that indicate that there should be a
> value, but it hasn't yet been supplied, and nulls that indicate that a
> particular attribute is not applicable to what is represented by the tuple.
> Darwen's approach is in accord with the Closed World Interpretation when it
> is applied only to nulls of the 'inapplicable' sort.  Decomposition is
> therefore a good, and in my opinion, the correct mechanism for dealing with
> inapplicable nulls.  But of course, that leaves nulls of the 'applicable'
> sort.
I agree that decomposition as described by Darwen is far from being a perfect solution. As far as I am concerned, the mecanism also describes *applicable* that leaves the applicable type of null at the level of intent by programmers. Since I only inspired myself from Darwen mecanism and use subtyping as method for decomposing I would not be able to say. I have created in the programming language a tools and functions that allow the programmer to decide the type of missing information that may be faced.

> It is my opinion that nulls are not inherently flawed, but that it is the
> misinterpretation, and the consequent misuse of nulls that are.  If each
> instance of null is /always/ an indication that information should have been
> supplied, but hasn't--that is, if there is always only the one accepted
> interpretation of the symbol, null, then each null can be replaced by an
> expression of the form,
Well NULLS are just a method that revealed its limitations. Under POCW, there is no need for such method since we are dealing primarily with missing information. But I agree that the role of interpretation by final user has been underestimated into applying POCW.

> 'Exactly one d such that d is an element of D'
>
> where D is the domain of the constant that should have been supplied.
>
> In this way, each tuple that can be in a 'relation'--even if it is
> incomplete--maps to a formula in a first order language that can be assigned
> a truth value under an interpretation.  I'm quoting 'relation' here because
> in a relation, every tuple has exactly the same number of components as the
> schema has attributes, but if incomplete tuples are permitted, which is the
> case when nulls are allowed, then some of the tuples can have fewer
> components than the schema has attributes.  It should be noted, however,
> that an instance of the schema /is/ a relation just in case all values have
> been supplied, which isn't true when inapplicable nulls are permitted.
>
> This interpretation of null is in accord with the Closed World
> Interpretation because each tuple that appears in a 'relation' represents
> something that is true, not just what is known to be true.  The distinction
> is subtle, and some might call it nitpicking, but I think it bears directly
> on how each tuple maps to something in the Universe.  I think it is
> counterintuitive for a tuple in a base relation to represent the fact that
> something is not known, which is one of the consequences of Darwen's
> approach.
Interesting. However, I am not working at the moment in the layer of RM. Received on Sun Jun 14 2009 - 09:36:28 CEST

Original text of this message