Re: CG: Re: controlled NLs
I've been out of town, and I'm trying to catch up
on the accumulated email.
First, a clarification about the intended users
for controlled natural languages:
JS> Doug Skuce's ClearTalk, Norbert Fuchs's ACE,
> Rolf Schwitter's PENG, and my CLCE are all designed
> as more readable front-ends for knowledge engineers,
> *not* for casual users.
NF> The second sentence is not true for Attempto Controlled
> English (ACE). ACE has been intentionally designed to be
> used by domain specialist, e.g. by end users, that may or
> may not understand the underlying formal basis of ACE. As
> a case in point, ACE has been used for medical documentation
> by people with a background in (dental) medicine, but with
> no background in logic or computational linguistics.
A domain specialist in medical documentation is *not*
a "casual user". It's better to distinguish casual users
who want to get a quick answer to some question (e.g., most
people who use typical search engines) from professionals
who are not computer scientists, but who are willing to spend
time learning how to use a particular tool, such as a CNL.
I suggest that we avoid the term "end user" because it is
too misleading -- many of us, for example, are end users
of tools that we ourselves may have helped to design.
From Rich Cooper:
RC> From my own perspective, I used ROSIE as a controlled
> NL to develop knowledge bases in intel assessment,
> planning, and diagnosis. I found it VERY difficult to work
> with, and reverted to lisp as soon as I could.
I don't blame you. I read some of the Rosie publications
(which came out around 1980-82), and they looked like
a very interesting, but clumsy way of writing procedures.
I would recommend CNLs as a replacement for declarative
languages such as predicate calculus or SQL. For procedures,
I would prefer something like Petri nets for the control
structures and the option of using any language (including
a CNL, if appropriate) to specify the functions.
JLD> So you suggest that we (some people on the CG list) solve
> the problems of knowledge representation and automated inference
> in a snap?
No. A CNL does not solve any problem that could not be solved
by using some other declarative language. The only thing it
does is to make any proposed solution more readable (and that
can be a big help for domain specialists who are not familiar
with the computer-oriented notations).
I agree with John Velman's description of a typical user:
JV> For some years I was involved with standardization work,
> both in ISO and EIA. In these venues the standards writers,
> by and large, were domain experts but not schooled in or even
> interested in formal systems. In too many cases, they seemed
> to be trying to write undying prose, rather than clear
> unambiguous specifications. A good CNL and a good tool for
> the authors to use could do wonders -- if one could get these
> adopted.
Note two points: (1) some of those standards writers are computer
professionals, but not computer scientists; (2) good tools are
necessary, as Rolf Schwitter has emphasized.
Peter Clark's comment is important:
PC> My point is that when designing a CNL, one can turn the dial
> on how "natural" (permissive of ambiguity) to make the language.
> The few CNLs that are around have typically been very conservative,
> not allowing any (or barely any) ambiguity. But it does not have
> to be like that, and I predict as the field develops more
> sophisticated interpreters, CNLs will gradually become more
> permissive of ambiguity and more "natural".
A point that I often make is that computers are much better than
humans at *detecting* ambiguities, but much worse than humans in
deciding what to do about them. Good tools can do the detecting
and help the humans do the deciding.
I just wanted to make one comment on Murray's note:
MA> I don't have to tell anyone any half-truths about formality
> as I think is commonly done in common sense ontologies.
I believe that many people working on formal ontologies have
a totally unrealistic view of what formalism can do. As I
said in an earlier note, formalism is the *least* important
part of mathematics. Much more important than any proof is
the discovery of an appropriate diagram that captures the
essential idea of the proof. Real creativity in mathematics
involves the invention of good diagrams. Once that has been
done, many mathematicians use tools such as Mathematica to do
the bookkeeping necessary for the formal derivations.
John Sowa