|
Rich, Ed, John and Mike,
I take umbrage (ok slight exaggeration) with the claim that it doesn't make sense to separate the role of the knowledge engineer and the subject matter/domain expert, or that the latter is always better qualified to create a computational formal ontology. Perhaps in particular cases this is true, but for any large enterprise or organization which consists of many domain experts with overlapping but distinct areas of expertise, I think clarifying and designating someone as the knowledge champion (with deep knowledge of the tools and technologies available) is not only beneficial but required.
Isn't it often the case that when one is trying to develop a non-trivial computational ontology for a domain, there might be no single SME with an accurate model of the whole domain? Aren't the real world cases such that each stakeholder has only a partial view / model / conceptualization of the complex socio-technical system in which they are located? I would expect that a well trained, competent Knowledge Engineer would be able to develop and implement the framework where each fragment of the domain comes together to form a coherent whole (or views / perspectives that are appropriate for varying contexts, or variations thereof). I'm not sure a domain expert would be qualified to do this.
You don't have nuclear engineers design the user interface for the control room of a nuclear power plant, nor similarly for an oil refinery or oil extraction facility. These systems are simply too large and complicated for any single SME to have an accurate let alone complete understanding of the entire domain. Indeed, human factors engineers or ecological interface designers are brought in to consult with the various stakeholders, documentation, relevant non-plant physics experts etc, to develop a robust interface for the task at hand (making sure the system continues working). While there are notable differences, the development of a computational formal ontology is very similar.
It makes a lot of sense to me to have a Knowledge Engineer (or whatever you want to call it) role separate from the SME. Similarly, an ontologist or knowledge engineer ought have a deep understanding of the type of commitments a particular computational / formal representation makes, and how each of these fragment / subdomains fit together, and how to accurately accommodate or resolves conflicting conceptualizations. I believe there was a Seed opinion piece ( http://seedmagazine.com/content/article/on_education1/ ) calling for more generalists, I occasionally like to think that ontologists specialize in generalizing - insofar that knowledge representation, information flows and inference cut across all domains (well, except maybe post-modernism :P).
==
Regarding unrestricted syntax and vocabulary, might this not introduce ambiguity in a computational interpretation? While it certainly makes it easier for the human to write down their intuitions, it makes it that much harder for any parser to convert it into machine readable form. Similarly, my experiences with controlled languages is that for complicated formulae or axioms, they quickly become verbose and cumbersome. Adam's idea as a tool to help edify and increase the precision of comments seems like the right balance.
I'm also rather surprised that all this focus, work and effort is being expended on trying to develop more "accessible" logical syntaxes. There is a large untapped, but potentially more useful (and at worst complementary) avenue of capturing SME knowledge via examples (i.e. Tarski models rendered in SME readable form). This approach, is of course in its infancy, but is possibly far more reasonable for (and accessible to) wider audiences, than variations on trying to make the syntax and language of logic more accessible.
Best, Ali On Thu, Mar 10, 2011 at 2:00 PM, Rich Cooper <rich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
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
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."
_________________________________________________________________
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
-- www.reseed.cawww.pinkarmy.org(•`'·.¸(`'·.¸(•)¸.·'´)¸.·'´•) .,.,
_________________________________________________________________
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 (01)
|