On 2 Aug 2010, at 17:07, John F. Sowa wrote:
> Pat, Ian, and Adrian,
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Yes, but I'll also add that a huge number of very practical problems
> are handled by model checking rather than theorem proving.
>
> 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.
>
> 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.
>
> 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".
>
> PH> I dont think it is fair to say that they are *typically* used
>> in this incorrect way. (?)
>
> I agree with Pat. The difference between classical FOL and
> negation as failure is very well understood by Lenat and the
> people he hired.
>
> 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.
>
> (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.)
>
> 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.
>
> I think we all agree on that point.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> IH> There are other users who have the opposite problem --
>> they want/need a more expressive ontology language...
>
> 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.
>
> IH> Bottom line: there is no "right choice" of ontology language.
>
> 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.
>
> 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.
>
> John
>
> _________________________________________________________________
> 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
>
_________________________________________________________________
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