Adrian,
That is the right approach, IMHO. Letting
the DE choose his own words, and letting him use nearly unrestricted syntax, the
DE can concentrate on the knowledge he is recording instead of on the mechanism
he is using to do the recording.
But most DEs just scribble stuff, as someone
mentioned earlier. It isn’t poetry. Then they throw the stuff away
because it is easier to write it up the next time than to look it up in a
directory. In my opinion, knowledge is only worth developing in the developer.
Others may want to listen to the developer’s knowledge, but why in the
world would they want to pay three hours of labor for one hour’s worth of
effective work? Just hire the DE him or herself, and pay the higher rate for
an experienced DE, which ultimately save money, get better results, and not
require organization and storage of technology that will outdated two years in
the future.
The KE concept was fraught with costly
solutions to whatever problem has so far been anointed as “knowledge work”.
It simply isn’t economical to do it that way. The lesson to learn is
that the DE has knowledge that helps him do his job. But nothing that gives
the DE extra work to do, such as training the KE, solves the problem the DE
works to solve.
What in the world is the economic
justification for separating the DE/KE roles?
Back in the early days of KE, the theory
went that you could extract “knowledge” from the DE and transfer it
to a KE, who would record it in a way that even a computer could apply it to
the KE’s role. The payoff would be that you hire cheaper Es to read the
knowledge, practice the skills, and become lower paid DEs thus saving the
investor money in response to the cost of KEing the DE.
The theory is nice, but it just didn’t
work. The E who became a KE just went after the highly paid jobs, leaving the
whole project without an implementation at the investor’s company. It
was great PR for AI for a while though, until companies realized it just didn’t
work as advertised.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Adrian Walker
Sent: Thursday, March 10, 2011
10:38 AM
To: edbark@xxxxxxxx; [ontolog-forum]
Subject: Re: [ontolog-forum] Using
controlled natural languages for ontology
Hi Ed,
You wrote:
In our experience the problem isn't
intelligibility, unless the
expressions become extraordinarily convoluted. The problem is that the
average domain expert naturally _writes_ a different language and takes
some training to learn to write the controlled language. Further, I
would add, the domain expert is usually reluctant to 'waste his/her
time' doing so.
It's mainly for that reason that our Executable English system** is open vocabulary, and largely open
syntax. The domain expert writes using her own words and phrases, and the
system automatically works with that input, rather than trying to control the
largely uncontrollable.
Apologies to folks have seen this before -- but the point seems worth making --
and thanks for comments.
-- Adrian
** Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL and
RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements
Adrian Walker
Reengineering
On Thu, Mar 10, 2011 at 11:58 AM, Ed Barkmeyer <edbark@xxxxxxxx> wrote:
Simon Spero wrote:
> On Sun, Mar 6, 2011 at 11:01 PM, John F. Sowa <sowa@xxxxxxxxxxx
> <mailto:sowa@xxxxxxxxxxx>>
wrote:
>
> On 3/6/2011 10:39 PM, Zhuk, Yefim wrote:
> > I'd think of CNL as an intermediate step towards
ontology...
>
> It's more like an alternate notation for logic that makes
comments
> readable by both the humans and the computer.
>
> A controlled natural language has a formally defined mapping
to
> and from some version of logic. Its main advantage is
that
> it can be read as if it were ordinary language.
>
>
> There may be some small differences in ease of reading between CNL
> and regular NL, but these do not appear to be important.
>
> Tobias Kuhn (until recently a student of Norbert Fuchs) has
some
> interesting results on the understandability of controlled natural
> language in his dissertation (see Chapter 5 in Kuhn (2010) for info).
> Also, as part of his work on ACEWiki Tobias built a native
java
> implementation of ACE, making it easier to use without having to
> install prolog).
>
> Simon
>
> * Tobias Kuhn. /Controlled English for Knowledge
Representation/.
> Doctoral thesis, Faculty of Economics, Business Administration
> and Information Technology of the University of Zurich,
2010.
> [PDF
> <http://attempto.ifi.uzh.ch/site/pubs/papers/doctoral_thesis_kuhn.pdf>|BibTeX
> <http://attempto.ifi.uzh.ch/site/pubs/papers/bibtex/doctoral_thesis_kuhn.bib>]
>
In our experience the problem isn't intelligibility, unless the
expressions become extraordinarily convoluted. The problem is that the
average domain expert naturally _writes_ a different language and takes
some training to learn to write the controlled language. Further, I
would add, the domain expert is usually reluctant to 'waste his/her
time' doing so. So the practice is still knowledge engineer working
with domain expert to create the ontology. The primary advantage of
using the CNL as a means of _expression_ for _most of_ the ontology is
that it allows the domain expert to read, understand and validate that
part. I say 'most of', because there are usually technical
considerations in the formulation of the ontology that the domain expert
should not be expected to understand -- that is the domain of the
knowledge engineer.
[Experts tend to be annoyed when the CNL interpreter complains about
what they wrote, especially since its diagnostics only usually identify
the syntactic point(s) at which it became confused, and its guidance for
what might have been meant is not often helpful. The worst cases,
however, are those in which what the expert writes is unambiguously
parsed by the CNL intepreter, but the interpretation it makes is not at
all what was intended. My favorite recent example was:
The surface must be contained between two planes that are 0.25mm apart.
The CNL interpreter understood the constraint to refer to two distinct
instances of a class of object described as 'plane that is-apart by
0.25mm'! We needed to have the ontology in place to determine that that
interpretation was not comprehensible (there is no such binary
relation). And OBTW, the correct _expression_ of that rule in the CNL was
'extraordinarily convoluted'.]
-Ed
--
Edward J. Barkmeyer
Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive,
Stop 8263 Tel: +1
301-975-3528
Gaithersburg, MD 20899-8263
Cel: +1 240-672-5800
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."