Re: compound propositions
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 18 Mar 2010 23:41:26 -0300
Message-ID: <4ba2e462$0$12459$9a566e8b_at_news.aliant.net>
>
> 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.
Date: Thu, 18 Mar 2010 23:41:26 -0300
Message-ID: <4ba2e462$0$12459$9a566e8b_at_news.aliant.net>
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".
Do I recall someone mentioning that Date has shied away from internal/external predicate in recent years? If so, perhaps, that is one reason why. Received on Fri Mar 19 2010 - 03:41:26 CET