Dear Matthew, Pat, Paul, and Doug, (01)
Fundamental principle: Our systems must be able to support diversity,
heterogeneity, and interoperability. That means they must be very
general and flexible. But we also need good tools to support people
at every level from abstruse theoreticians to typical iPhone users. (02)
MW
> That is a "do whatever you like" approach. It's fine for one person, but
> it just leads to chaos if you have say hundreds of people working on the
> development of an ontology. (03)
Pat was trying to say that the underlying formalism must be sufficiently
flexible to support anything that any system might need. But that does
not rule out the option of restricting the flexibility in order to
standardize the choices for a particular system or application. (04)
PT
> ... should we banish all terms that engender argument (as John Sowa
> suggests), or those that fill out the upper levels of a taxonomy or
> require interpretation by a guru (as you [Pat] suggest) (05)
You don't have to banish a term just because somebody raises
a quibble about it. But when you hit a deadlock about some term
with dozens of notes by knowledgeable people and no consensus
among them, you might realize that the term is too vague, ambiguous,
or problematical to be useful. (06)
Re abstruse terms: Many aspects of system design require people
with a high level of expertise. But the user interfaces must
use appropriate terminology designed for the different kinds of
people who use it. (07)
In particular, experts in medicine or geology would use common
terms in their field. They would never use technical terms
in logic or ontology. (08)
DF
> But the human users and developers do not just give an
> ontology to a logic engine and let it have its merry way. (09)
Of course not. You have to design appropriate tools. (010)
As an example, every implementation of SQL since the 1970s
implements a "knowledge compiler" of sorts. The WHERE clause
in SQL uses full FOL, but a simple-minded translation of that
clause to an executable form would be horribly inefficient. (011)
Prolog forces the programmer to do the optimization by
reordering the rules. But you can't expect SQL users to
have the same level of expertise as Prolog users. Therefore,
SQL implementations do the reordering when they translate SQL
to an executable form. (012)
DF
> The programmers use the comment fields (and often term names)
> in order to make such connections between the ontologies and
> the real world. (013)
Yes, but the computer cannot understand the comment fields. (014)
There are tools, some in operational use, that can do much more.
It's a lot cheaper to put some R & D money into developing better
tools than to train domain experts to become knowledge engineers. (015)
John (016)
_________________________________________________________________
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 (017)
|