ONT Re: Inquiry Driven Learning Environments (IDLE's)
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤
| Document History
|
| Subject: Extensions Of Mind
| Subhead: Essays And Reports On Intelligent Systems
| Contact: Jon Awbrey <jawbrey@oakland.edu>
| Version: Draft 3.04
| Created: 10 Sep 1993
| Revised: 11 Feb 2002
| Advisor: C.C. Wagner
| Setting: Oakland University, Rochester, Michigan, USA
| Excerpt: Division 4 (An OAR For Odysseus: Offline Analytic Resource)
| Excerpt: Subdivision 4.3 (Multi-Sage Deconstruction: Post*Modern Elephant)
| Excerpt: Section 4.3.2 (Prospective Needs Analysis: Talking About Tables)
4.3.2 Prospective Needs Analysis: Talking About Tables
Let us make a short list of critical needs that most acutely
confront us in attempting to carry out several components of
this project, after which we can elaborate the implications
of these prerequisites, and then set to work on designing
a prospective implementation.
4.3.2.1 Prerequisites: Preliminary Outline of Needs
A. We need a formal language for talking about relational tables.
B. We need conventional logical connectives that operate on the terms for
relational tables and that obey the dictates of propositional calculus.
C. We need to get clear about the interplay among the various
empirical, extensional, formal, and intensional aspects of
our prospective tables.
D. We need to get clear about whether and, if so, exactly when we
ever need the distinction between "subset of" and "element of",
in other terms that are used, between "is a" and "instance of".
4.3.2.2 Elaboration of Prerequisites
Need A.
| We need a formal language for talking about relational tables.
For the sake of maximal concreteness and simplicity in the initial
discussion, let us say that we have in mind a finite set of tables:
$T$ = {T_1, ..., T_j, ..., T_n}.
A formal language of any kind or for any purpose is based on and
built up from a finite set $A$ = {a_1, ..., a_m} of elements a_j.
The set $A$ is called the "alphabet", "lexicon", or "vocabulary",
of the prospective formal language L, and the elements a_j in $A$
are called the "expressions", "formulae", "formulas", "sentences",
"symbols", "terms", or "words" of the language L, choosing among
the optional designations as befits the occasion of application.
Taking the finite set $T$ = {T_1, ..., T_n} of tables T_j as
an "object domain", that is, as a set of objects that we need
to talk about, what sorts of formal languages L can we imagine
that might be of use to us in doing so?
Since we are currently supposing the object domain $T$ to be a finite set,
one of the easiest things to do at this early and very elementary stage
of the game would be to declare an alphabet $A$ = {a_1, ..., a_n} such
that a_j = "T_j" for all j = 1 to n. In other words, we would have:
$A$ = {a_1, ..., a_n} = {"T_1", ..., "T_n").
Not a very subtle strategy, of course, but one that is always available,
in principle, for a finite set of objects, and it should do for a start.
But the language L = L($A$) = L($T$) that we need for talking about
even so well-bounded a family of relational tables as this will be
rather more bounteous than the mere alphabet $A$.
Need B.
| We need conventional logical connectives that operate on the terms for
| relational tables and that obey the dictates of propositional calculus.
Negation, a 1-argument operator, and conjunction, here taken to be
a "multigrade" or a "polyscopic" k-argument operator, are convenient
and sufficient to serve as primitive operators for generating all of
the other propositional connectives, and these supply enough terms to
cover the corresponding set-theoretic operations. (A high degree of
expressive efficiency could be gained by introducing the k-argument
operator "just one false", but maybe later.)
A calculus consists of a set of expressions and a means of evaluation
that can be applied to them. In our case, we generate a language of
expressions by applying the following two conventions to the basic
alphabet of terms for tables:
1. Negation is represented by bracketing the term for a table T with
parentheses of a special font. In the context of a running ascii
text we may use the stricken parentheses "-(-" and "-)-", commonly
reduced to single indications of the stricken context at the onset
and the reset of the context, but in set-off displays it is easier
and quite safe enough to use regular parentheses. Thus, for example,
the expression "-(T)-" denotes the table for "Not T" or for "Non T".
(As long as we can manage to remain clear about what terms are in
the alphabet $A$ = {"T_1", ..., "T_n"}, this practice should not
create confusion with other uses of parentheses, for instance,
this one:->)
For example, if W = Wayne's World and if W belongs to $T$,
then "-(W)-" = "Wayne's World -- Not!", otherwise -- Not!
2. Conjunction is represented by simple concatenation of terms, preserving
their integrity as whole words by leaving spaces or raised dots between
the conjoined terms. In view of the associative property of conjunction,
there is no reason not to go ahead and allow k-place conjunctions without
the bother of the extra bracketing. So the conjunction "T_1 · T_2 · T_3"
denotes the table "T_1 and T2 and T3", which enjoys the combined intension
and the common extension of all three tables.
3. The logical constants, "true" and "false",
can be represented as "0-place connectives".
a. A no-place conjunction would look like a blank space. Since blank
spaces are what one uses for the logical conjunction of terms, any
number of them can be conjoined with any other expression without
changing its value. Technically speaking, this makes the blank
space an "identity element" for the operation of conjunction.
The only conceivable identity element for conjunction is the
logical constant "true", also known as "1" in boolean argot.
b. An empty negation is the expression "()" that consists of an
empty pair of parentheses. This is logically indistinguishable
from the expression "( )", that is formed through the negation of
a blank space. This form of expression has the meaning of "not true",
or a value of "false", and it is also known as "0" in the boolean lingo.
c. In sum, we have the following brief expressions for logical constants:
False = 0 = () = ( ).
True = 1 = "" = " " = (()).
To sum up the more salient implications of what has been set down so far,
if T, T_1, T_2 are terms for tables, then we need to be able to talk about,
even if not necessarily to construct, the following kinds of derived tables:
| 1. "(T)" for "not T", denoting the Complement of T.
|
| 2. "T_1 · T_2" for "T_1 and T_2", denoting the Intersection of T_1, T_2.
|
| 3. "((T_1)(T_2))" for "T_1 or T_2", denoting the Union of T_1, T_2.
The last example is an application of DeMorgan's Law. The lack of a separate
connective for disjunction may appear inconvenient at first, but the resulting
simplicity of syntax affords major advantages in the size and the speed of the
parsers and the interpreters that one becomes able to write for this language.
If you follow a custom of reading patterns like "((...)(...)(...))" in a slot
and filler style, voicing "((" as "either", each ")(" as "or", and "))" as an
optional "end or", then you may eventually come to prefer this form of syntax.
Need C.
| We need to get clear about the interplay among the various
| empirical, extensional, formal, and intensional aspects of
| our prospective tables.
With regard to the tables that we want to talk about and with regard
to the language that we want to use to to talk about them, we need
to clarify the following aspects:
| 1. Their form, defining features, or intended meaning.
|
| 2. Their exhaustive, projected, or intended contents.
|
| 3. Their enumerated, empirical, or exemplary contents.
We cannot accord a due respect to the contemporary variety
of word usage in this area without noting a few ambiguities
and trying to negotiate a reasonable compromise among them.
It will help to picture a small number of concrete examples.
To consider one of the simplest, suppose that "T" is a term
like "People" that refers to a 1-adic relational data table.
Then the People Table is nothing more than a list or a set
that holds the names of all the people that we know about,
or that we need to know about in a particular application,
with room to hold any number more, so long as the entities
that are named therein fit the description of being people.
In parallel with this consideration, we might want to think
about the following special cases:
| T_1 = The set of transitive relations needed in our application.
|
| T_2 = The set of 2-tuples defining a single transitive relation,
| for example "implies" or "precedes".
|
| T_3 = The set of 3-tuples defining a single 2-argument operation,
| for example, "sum" or "product".
Intensional aspects of the People Table derive from reflection on the
ordinary meaning of the term, whether taken as an undefined primitive
or analyzed in terms of other logical features. These include among
their variety the formal aspects of the relation or set, contemplated
as an abstract logical or mathematical object, for example, its arity,
its cardinality, and its axiomatic or higher-order logical properties.
It can at times be a benign pun to connect the intension of a term with
the intentions of those who use the term, since we normally select names
for relational tables with the intention that the tables will satisfy the
usual properties and cover the usual cases that are suggested by the name
in question. To give an integral formulation: Our intention is that the
table's extension will be limited solely by its intension.
Extensional aspects of the People Table will have to do with the
complete or exhaustive set of instances that fall under the term.
Unless the term is unusually well constrained, like "People issued
paychecks dated 31-Dec-1993 on the books of Firm XYZ", it is seldom
that we ever enter anything approaching the full extension of a term
into its associated table. This may happen for artificial terms, but
rarely for natural terms, and never for terms with infinite extension,
for example, the set of "non-people", the set of "primes", the function
"square root" or the relation "less than" viewed as sets of ordered pairs.
Enumerative, exemplary, empirical aspects. This aspect of terms and tables,
of their contents and their discontents, has no standard name. It refers to
the actual contents of a table at a given time, the entries actually made and
explicitly mentioned in an output listing. It represents the empirical content
of a relational table, the actual and always finite experience that it itemizes.
The explicit table is a source that we resort to for samples of the extension,
for examples of the intension, and as a basis for enumerative induction with
regard to the term in question. If our prototypes and our stereotypes are
to any extent derived from contingent experience, they would be based on
something like the finite acquaintance with a topic that finds itself
recorded under this empirical aspect.
Need D.
| We need to get clear about whether and, if so, exactly when we
| ever need the distinction between "subset of" and "element of",
| in other terms that are used, between "is a" and "instance of".
The practical reason for bothering with this theoretical question is this:
It makes the difference between getting away with a single type of inference
engine and having to build two radically different types of inference engines,
not to mention coordinating all their interactions in the just the right ways.
This is due to the fact that "subset of" is transitive, while "element of" is
an intransitive relation. The question here is not whether we can ultimately
avoid this distinction -- probably not in logic and mathematics, perhaps so
in computable and finite information applications. The question is whether
something good would come from fully implementing the single capacity for
transitive inference, as a starter for more complete inference engines.
Jon Awbrey
¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤~~~~~~~~~¤