Re: compound propositions

From: David BL <davidbl_at_iinet.net.au>
Date: Fri, 19 Mar 2010 00:39:06 -0700 (PDT)
Message-ID: <31225a39-4dd8-4acf-8dd2-4586279c3670_at_k6g2000prg.googlegroups.com>


On Mar 19, 10:41 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Bob Badour wrote:
> > paul c wrote:
>
> >> David BL wrote:
> >> ...
>
> >>> I wonder what is meant exactly by 'internal predicates' and 'external
> >>> predicates'. I would appreciate it if someone could provide a
> >>> definition.
> >>> ...
>
> > sigh See ISO/IEC 2382 -- defined there.
>
> > I will start by directing you to the ISO/IEC 2382 standard vocabularies
> > so that you will have the necessary grounding to understand the
> > differences between conceptual, logical and physical as well as the
> > definitive difference between information and data. The standard also
> > defines internal and external. When I use these terms, I use the
> > definions in ISO/IEC 2382.
>
> > Once you have done so, the remainder of this post will be redundant.
>
> > When I use terms like relation, predicate, extension etc. I use the
> > common definitions in mathematics and in predicate logic particularly.
>
> > Conceptually, a relation is the extension of some predicate. A relation
> > variable is the varying extension of some varying predicate. Most
> > commonly, both predicate and extension vary with time.
>
> > Considering a simple example from business like inventory, the number of
> > various items on hand depends on myriad factors: how many people called
> > in sick at various businesses on various days, when and for how long
> > various fabrication equipment broke down, labor disputes, customer
> > demand, varying commodity prices etc.
>
> > Conceptually the predicate and its extension depend on all these
> > factors; however, most of these factors are immeasurable and/or
> > uninteresting. While all these past events conceptually create
> > information that eventually determines inventory, they are not data. The
> > information is not represented suitably for machine processing.
>
> > The myriad factors, many of which are never directly recorded anywhere,
> > make the predicate unamenable to representing for machine processing.
> > For our logical system, we choose instead to work directly with the
> > extension of the predicate in relation form.
>
> > While the predicate overall may not be known, some properties of the
> > predicate are. For example, the inventory on hand will never be
> > negative. The relational algebra or the relational calculus allows us to
> > describe some parts of the predicate using well-formed formulae. These
> > parts of the predicate have a data representation amenable to machine
> > processing. As such, they have a representation internal to our logical
> > formalism. The rest of the predicate exists but only external to our
> > formalism.
>
> > When expressed to a dbms, these representable parts of the predicate get
> > represented internal to the dbms, and the rest of the predicate exists
> > only external to the dbms. Within the scope of the dbms, the rest does
> > not exist.
>
> > Thus, the internal predicate is that part of the predicate amenable to
> > machine processing and actually expressed within some system. In
> > general, internal predicate refers to those parts of the predicate
> > available at the logical level of discourse. Predicate (unqualified)
> > refers to the predicate at the conceptual level of discourse. External
> > predicate refers to what's left of the predicate after one factors out
> > internal predicate.
>
> > Other than a shorthand for "the parts we don't care about", the term
> > external predicate is somewhat superfluous. Database constraints are the
> > internal predicates of the relations in the database. As such, internal
> > predicate is superfluous; although, it gives us a way to place and
> > orient database constraints to the conceptual level of discourse.
>
> There is one thing that bothers me about the above definition of
> "internal predicate". One could define a boolean function that returns
> true for any argument tuples contained in a relation and false for all
> other arguments. That function is arguably a characteristic function or
> predicate and is represented internal to the formalism.
>
> In that sense, it has perhaps a stronger argument in favor of being an
> "internal predicate".

Indeed, and when I first came across the term "internal predicate" I assumed it meant this (boolean valued) characteristic function of a base or derived relvar of a given database.

I had no idea C.Date intended "internal predicate" to represent integrity constraints on a relvar. It appears to be a predicate that is parameterised by a relation, rather than a tuple!!! I think it's quite confusing. But it does seem to be the case. See this heavily elided quote from Date (taken from pages 1-3 starting at http://www.dbdebunk.com/page/page/622423.htm)

<quote>
...
the integrity constraint concept is easy enough to understand at an intuitive level; intuitively, a constraint is just a conditional expression--also known as a boolean ... expression ...
In other words, the expression is a predicate. ...
Let R be a relvar. Then the relvar predicate for R is the 'logical AND' or conjunction of all of the constraints that apply to (i.e., mention) that relvar R.
...
No update operation must ever assign to any relvar a value that causes its relvar predicate to evaluate to false. ...
 I showed ... that each relvar has a relvar predicate and the overall database has a database predicate. They're stated formally ... and of course they're enforced by the DBMS, too. For such reasons, it's convenient to refer to the predicates in question, on occasion, as internal predicates
...
</quote>

I would prefer the term "relvar predicate" to refer to the predicate represented by the current value of the relvar.

Funnily enough one could indeed say as Paul did that a relation satisfies a predicate. (more specifically a relvar must satisfy a relvar predicate). But that's not what Paul meant - he said he was talking about the relation header not the value. Received on Fri Mar 19 2010 - 08:39:06 CET

Original text of this message