Pat, Ian, and Adrian, (01)
I'm back from my travels, and I'd like to address a few issues
about Cyc, about the many ways of using logic, about "robustness",
and about how any or all of these issues affect practical problems
that people are desperately trying to solve. (02)
By the way, I'll make some strong positive statements about Cyc
in the following remarks, but I also have strong criticisms
about many aspects of Cyc. But on the particular issues in this
thread, I have a great deal of sympathy with the Cyc approach. (03)
PH> The real difference here is one of academic style: the CycL
> developers are ruthlessly pragmatic and do not care a whit for
> theoretical analyses of completeness or for proving correctness. (04)
One has to distinguish the many different "CycL developers". As the
principal stockholder, Lenat has the final say on what directions
are supported. But the complete Cyc system has over three dozen
different inference engines, which are based on a wide range of
different principles. (05)
Over the past 26 years, Lenat has hired (and fired) some of the
best and brightest logicians, linguists, computer scientists, and
experts in various fields, disciplines, and paradigms. Many of
them have been very sensitive to the theoretical issues, and they
have designed inference engines that are as technically respectable
as any that have come from any academic department. (06)
Some of the Cyc inference engines process subsets of logic that
are eminently decidable, others use an open-ended variety of
heuristics, and others use very "quick and dirty" methods of
getting results for the "easy" cases. (07)
IH> OWL's expressive power could, of course, be easily (indeed
> arbitrarily) extended if one were prepared to compromise on
> some or all of these design constraints. (08)
I suspect that the word 'compromise' is being used as a criticism
rather than a desirable trait. Among the Cyc inference engines,
some are highly disciplined tools that don't make any compromises
with precision or decidability. But the total Cyc system has to
accept anything and everything that anybody might throw at it. (09)
In that sense, Cyc makes compromises in a positive way: it analyzes
the problem at hand in order to choose which of the many inferences
engines to use. In cases of doubt, it can run more than one in
parallel to see which one finishes first. (010)
PH> Ian is using "complete" here to mean "complete and decidable",
> which can be characterized as: if a sentence is a theorem, then
> the prover will tell you that - completeness - AND if it isn't
> a theorem, the prover will also tell you that it is not. (011)
Yes, but I'll also add that a huge number of very practical problems
are handled by model checking rather than theorem proving. (012)
The SQL WHERE-clause, for example, uses the full power of FOL for
queries, constraints, and triggers. But it doesn't attempt to prove
those statements. Instead, it evaluates their truth value in terms
of a model -- namely, the current state of a relational DB. That
evaluation is done in polynomial time in the worst case, and in
many of the most common cases, in linear or logarithmic time. (013)
That is the advantage of having a single very expressive language
such as CycL (or Common Logic) and a method for determining which
of the many inference engines (or other tools) to use for any
particular problem. (014)
IH> In fact such reasoners are typically used in a way that is
>> actually incorrect, in that failure to find an entailment is
>> treated as a non-entailment, whereas it should be treated as
>> "don't know". (015)
PH> I dont think it is fair to say that they are *typically* used
> in this incorrect way. (?) (016)
I agree with Pat. The difference between classical FOL and
negation as failure is very well understood by Lenat and the
people he hired. (017)
The people who don't understand that difference are congenitally
incapable of using *any* logic-based tool in a serious way --
that includes CycL, CL, OWL, and even SQL. (018)
(Please don't say that non-AI professionals can use OWL, because
I've seen what they've done and it proves my point. For the subset
of OWL they actually use, they'd be better off using simpler tools.
And yes, Adrian, your Executable English would be a good option.) (019)
IH> I completely agree that being decidable is no guarantee that
> reasoning tools will always work well in practice. We can imagine
> a graph with complexity classes on the x-axis and robustness on
> the y-axis. (020)
I think we all agree on that point. (021)
IH> Increasing complexity inevitably means decreasing robustness.
> Robustness is a very important quality of reasoners from a user
> POV -- what it means is that small changes in the input (e.g.,
> the ontology) produce only small changes in the performance of
> the reasoner. We can think of undecidability as simply being
> a very high complexity class, i.e., one where we can expect
> relatively poor robustness. (022)
Every sentence in that paragraph requires so many qualifications
and caveats that it is hopelessly misleading. First of all, every
version of formal logic from Aristotle's syllogisms to the present
is notoriously brittle, and the primary source of brittleness is
*not* the complexity class. (023)
The major source of brittleness is the definitions of terms.
Everybody from A to Z (Aristotle to Zadeh) has observed that words
in ordinary language don't have a one-to-one mapping to definitions
in any formal logic. (024)
URIs that link to formal definitions are irrelevant when the people
who use the terms don't know or understand the definitions. I'd give
Cyc much higher marks in addressing the issue of trying to determine
(i.e., guess) the intended word senses than systems (automated or
manual) that map words to arbitrary URIs. (025)
I would also question the term 'small changes', the definition
of robustness in terms of relating "small changes", and the
assumption that OWL (or any formal system from Aristotle to
the present) contributes much, if anything to the solution. (026)
And I repeat the point that decidability depends on what you do
with the logic rather than the expressive power of the logic.
For example, the SQL method of processing an FOL statement is
more robust than most theorem provers -- primarily because the
SQL evaluation takes fewer steps than most proofs. (027)
IH> There are other users who have the opposite problem --
> they want/need a more expressive ontology language... (028)
Nobody but a professional knowledge engineer knows what an
ontology language is, let alone what properties it should have.
Those people who have been exposed to talks about such things
are hopelessly confused. (029)
IH> Bottom line: there is no "right choice" of ontology language. (030)
I certainly agree with that statement. I'd add that only highly
trained experts (knowledge engineers, logicians, or computer
scientists) are capable of making such a choice. (031)
I'll also claim that the Cyc software is far more capable of
choosing an appropriate subset of logic and an inference engine
to process it than the majority of people who have been exposed
to lectures about OWL or any other formal logic. (032)
John (033)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (034)
|