I don't really know where to start in responding to this, and I only have
limited time. Here are a few points. I apologise in advance for the fact that I
am going to have to bunk out of the discussion at this point -- entertaining
though it is, it doesn't pay the rent! (01)
You describe my discussion of robustness as "hopelessly misleading", an
argument you support by introducing a discussion of the difficulty of rendering
"ordinary language" into logic. I don't dispute this difficulty, but it is
completely orthogonal to the discussion we are having (or at least that I
thought we were having), which is about the computational properties of
different logics. What I say about robustness is nothing more than simple
statement of what follows directly from complexity theory. (02)
In response to my argument about the incorrect use of reasoners you introduce
the notion of NAF. This is irrelevant and potentially confusing -- the failure
in NAF refers to "not provably true" and not to the failure of a given
(incomplete) algorithm. (03)
You seem to say that it is best to allow users to write whatever they like and
then leave it to the reasoner to figure out how best to deal with it.
Unfortunately, this approach isn't really practicable as users often want or
need to know what kind of behaviour they can expect from a reasoning system,
without necessarily knowing the exact problems they are going to be solving.
Language subsets are convenient ways to define sufficiency conditions for
(more) robust behaviour (or at least the possibility of more robust behaviour). (04)
Many of your arguments, including the above one, seem to presuppose a situation
in which the reasoning system is used only by expert users -- in fact you say
that other kinds of users, e.g., those who don't fully understand NAF, should
avoid using logic or logic based tools. Perhaps, but you might equally well
declare that only expert programers should be allowed to produce software. IMHO
it is more realistic (and more useful) to try to develop tools and
methodologies that help people to do a better (if not perfect) job. (05)
Regards,
Ian (06)
On 2 Aug 2010, at 17:07, John F. Sowa wrote: (07)
> 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
> (08)
_________________________________________________________________
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 (09)
|