John,

Yes, the concept mining task behind database
mining requires that the miner develop theories of how the data is organized.

But there has to be an allowance for
theories which, while useful for many cases, are not always unambiguously true
or false for every case. If a theory assigns True to a signature row r, it
may not always get that assignment right as compared to the reality being
approximated by the theory. So the theory can assign True to a false
case, False to a true case, T-t and F-f or, gasp, inconsistencies such as T-f
and F-t.

So actually, there are four combinations
of TrueS and FalseS for any given row r:

True (r
in TrueS) and (r not in FalseS);

False (r
not in TrueS) and (r in Falses);

Unknown (r
not in TrueS) and (r not in FalseS);

and Inconsistent
(r in TrueS) and
(r in FalseS).

The Inconsistent version is sometimes abbreviated
as STP (a polite interpretation isn’t available). In a nutshell, it
suggests that the theory may need further refinement. But that might be a
very useful theory because it sheds statistical light on just how much coverage
the theory provides given a fixed set of cases, each with a row r to be
classified.

And of course, there can be tables of many
current theories in the database, some theories of which are true, some of
which aren’t, and some of which are not fully defined yet. Therefore
the theory-based approach to database classification tasks can be viewed as a
recursive process of cut and fit.

But the point is that, if someone neglects
the complexity of negation, thereby avoiding the duality and even
inconsistencies of real world theories, she can get too comfortable settling
into a complete world of theory without meaning. Too much internet.

Empirical knowledge is an essential addition
to theoretical knowledge, and constitutes those terminal concepts which can be
personally experienced – the meaning. Those are the concepts that
our tiny tot uses when she processes language at age two. She builds still
more meaning as she grows, developing representations on top of (and in
addition to) the earlier concepts.

You may be right that there is no set of
universal primitives, even though Anna Wierzbicka seems to think even “very
general” primitives can be adequate for elaboration, or specialization,
or generalization, into deeper meanings. But there are definitely effects
of early learning which are felt throughout our lifetimes. So the
primitives are there, even though they may also be augmented with entirely new
experiences (and thus new primitives) from time to time as we age. At
least until we start losing concepts faster than we gain them!

JMHO,

-Rich

Sincerely,

Rich Cooper

EnglishLogicKernel.com

Rich AT EnglishLogicKernel DOT com

**From:**
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] **On Behalf Of **sowa@xxxxxxxxxxx

**Sent:** Friday, December 25, 2009
10:54 AM

**To:** [ontolog-forum]

**Subject:** Re: [ontolog-forum]
blogic iswc keynote

Rich,

I agree.

>
"without negations" literally means without KNOWING EXPLICIT
negations.

> Most DBs that get exception cases store them in a table like the one that

> caused the exception. So, in effect, there are tables of TrueS and Tables

> of FalseS - or "fluents" as some logicians like to call them.
Therefore,

> negation is in fact modeled where appropriate in current DB practices.

Your note
illustrates the point that a relational database

can be used to support various kinds of semantics.

The default way of using SQL is negation as failure: each

table contains the n-tuples for which a relation is true.

Any n-tuple not listed is assumed to be false. That is the

so-called closed-world assumption. If the conditions of

that assumption hold, then negation as failure is the

equivalent of true negation.

But it's possible to use two tables per relation: one would

contain all the n-tuples for which the relation is known to

to be true, the other would contain all n-tuples for which

the relation is known to be false, and the truth value of any

n-tuple not in either table would have the truth value unknown.

With an appropriate front end, the RDB would support a three

valued logic: known true, known false, and unknown.

John