Adrian and David,
A thread worth pursuing: here I am replying to Adrian's post, later some
comments in response to David E. (01)
----------------- (02)
I agree with you and John Sowa that using controlled English (of which I
consider Executable English one variant) is a good idea. I myself like to
use a variant of KIF that allows putting the relation in an assertion as the
second element, so that sentences can be more English-like without modifying
the basic logical mechanism a simple translation converts such logical
assertions to the normal KIF form). I think these tactics can help a lot
to make ontology development easier and more accurate. But that still
doesn't substitute for good natural-language documentation. Although the
computer can only interpret the axioms that specify meanings of ontology
terms, the ontologist, programmer, or database developer who has to decide
what ontology to use and how its elements relate to the entities of interest
to their applications *must* properly understand the meanings of the terms.
As I said, people are (at least I am) really bad at following long chains of
logical inference that are specified by the axioms, and need to rely for
their understanding on other parts of the documentation. I find the
inclusion of examples and counterexamples of types or of usage of relations
to be very helpful to resolve ambiguities. (03)
If you want some simple examples of how tough it can be to follow a chain
of inference mentally, get hold of some "difficult" "sudoku" puzzles, where
the proper numbers in the boxes cannot be resolved by simple number
exclusion on rows, columns, and boxes. This is really simple logical
inference, but for the tough puzzles, one may have to make a guess for one
number and follow the consequences for a couple of dozen inferences before
reaching a contradiction (which will happen at least half the time). I
find that for myself, it is very hard to go beyond a dozen inferences and
recall the locations of all the numbers that were deduced. (04)
For ontology elements, there may be significant logical consequences that
require a lot more than a dozen inferences. IF the ontology developer has
done the testing thoroughly, s/he will have caught many of the errors that
are not obvious from simple inspection of the axioms for the ontology
elements. Correcting the errors and explaining the potential ambiguities
and how they were resolved will be done in the natural language
documentation. (05)
An ontology is a lot like software, and like software, ontologies may have
"bugs" that are not obvious to the developer, and even do not show up in
early resting or usage. Adam Pease, in our OOR telecon this past week
described how, even after many many hours of consistency checking of SUMO,
there still were some inconsistencies that were caught when a new faster
reasoner was turned on the project. Like software, ontologies may have bugs
that only show up under unusual circumstances. Even logical consistency
doesn't guarantee that the ontology (or program) will always do what the
developer intended. (06)
If you think that ontologies are perfect, and that the axioms always capture
the intended meanings of the ontology developer, and that a reader can
discern those intended meanings adequately from an inspection of the
axioms, then additional documentation beyond the controlled English
specification is unnecessary, I don't believe that any of those things are
true except for the simplest of ontologies. (07)
I expect that eventually the largest practical uses of ontologies will be
with databases, and I do not expect the database developers to look at the
axioms of the associated ontology and do some mental inferencing when
deciding how the ontology elements relate to the database elements. For
these users, I think that good documentation beyond the axioms, even in
controlled English, will be critical. (08)
Good documentation allows the original develop of an ontology (or module) to
state what was intended by the elements. If others use it and discover that
there are logical consequences in new applications that are inconsistent
with the stated intended meaning, that provides an opportunity to alert the
original developer and other users that further logical refinement is needed
to properly capture the intended meaning. This provides a mechanism for
incremental evolutionary improvement of ontologies. If an ontology is
going to be used by more than just a few tightly coordinated users, I would
be very reluctant to use any that is not well documented unless it is such a
small module that the logical meanings of elements are very easy to
understand from the axioms alone. (09)
Pat (010)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (011)
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Adrian Walker
Sent: Sunday, September 12, 2010 10:22 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Language vs Logic (012)
Hi Patrick -- (013)
You wrote (014)
Figuring out precisely what a term in an ontology is supposed to mean has
three aspects: what the person developing the ontology intends it to mean;
what the person reading the documentation interprets it to mean, and what
the computer executing a program using the ontology interprets it to mean.
Ideally, the they will be the same, but they may differ. (015)
Here's how you can get the meanings much closer together. (016)
1. Have the person "developing the ontology" write it in executable English (017)
2. Have the person "reading the documentation" read the executable English (018)
3. Have the computer program directly execute the executable English,
guided by an underlying (and hidden) logical model theory. (019)
4. Have English explanations of the results available (020)
The above capability is live online and usable from a browser [1]. It is
of course a different paradigm from the (021)
machine-notation-ontology + documentation + application-program-in-java (022)
approach that the community is hacking away at. One way to think of the
different paradigm is as "executable documentation", or as "computing with
comments as the code". (023)
-- Adrian (024)
[1] 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 (025)
Adrian Walker
Reengineering (026)
On Sat, Sep 11, 2010 at 11:19 PM, Patrick Cassidy <pat@xxxxxxxxx> wrote:
David,
Figuring out precisely what a term in an ontology is supposed to mean has
three aspects: what the person developing the ontology intends it to mean;
what the person reading the documentation interprets it to mean, and what
the computer executing a program using the ontology interprets it to mean.
Ideally, the they will be the same, but they may differ. For the person
using the ontology, a lot depends on the documentation; although the meaning
in an executed implementation is *only* what the logical axioms state,
people are not good at following inferences very far, and really bad at
following multiple inference paths, so good documentation is critical for
ontologies intended to be used by more than a small tightly connected group.
Unfortunately, such good documentation is the exception rather than the
rule. The CYC ontology generally has good documentation, and in the COSMO I
try to make the documentation as unambiguous as necessary for ordinary users
to understand. For me, good documentation means to state what one intends
the ontology element to mean, and provides where appropriate, for a given
type, examples of instances, along with potential borderline cases that are
or are not included in the intended meaning, and also references to other
ontology elements that might be suggested by the name of the ontology
element. These notes are included in the 'comments' section of each
ontology element in the ontology itself. For small specialized ontologies
this kind of documentation may not be hard to grasp. For a foundation
ontology like CYC Bas KB, SUMO, or COSMO, it can take considerable effort -
because these ontologies have close to the expressivity of a human language,
they will be at least as hard as a human language to master - harder,
probably, because they are used differently from human languages, and that
needs some practice to get used to. That is the price of developing an
ontology that can be reused by many other diverse users. (027)
I sympathize with the frustration of those who wish using ontologies were
easier. Learning other human languages is a common endeavor, but for most
human languages there is a large community of users and a large literature
base that make the effort clearly worthwhile. For ontologies, the number of
applications using ontologies whose internals are available for public
inspection and edification of learners is extremely small, almost vanishing.
We are still at an early stage and examples of effective ontology use in
practical applications are only beginning to be developed. There is not
much off-the-shelf that can be used at home by oneself for practical
purposes, except for just organizing data and simple search of large
databases, in effect a slightly souped-up database. To some extent,
learning to use a logic-based ontology is similar to learning to use a new
object-oriented programming language, but programming languages usually come
with a library of immediately useful applications as learning examples. We
haven't reached that point yet in the technology of ontology creation and
dissemination. (028)
I am also frustrated because I expected, twenty years ago when I started
looking at ontologies as a tool for language understanding, that the
community would make progress a lot faster. In part the slow progress is
due, as with other AI projects, to the unexpected complexity of the problem,
but there is also what I think of as a pre-scientific attitude among many
ontology builders. The notion that it is perfectly acceptable for people to
develop their own ontologies without reference to prior work on fundamental
ontology elements (i.e. foundation ontologies) makes integration, when
people realize it is useful and necessary, a total nightmare. The
technology of logical representation and inference has developed well among
a community of scientists who share results and methods, and the results
have been in general impressive and often superb. But for "meanings", the
logical primitives agreed to by the developers of theorem provers contain
only a few of the several thousand primitives that are needed to express
most of the ideas that are used in computer programs and databases. I think
that we also need a community of ontology content developers that will adopt
an experimental, scientific approach to the task of expressing meanings of
complex concepts that can be widely used by ordinary database developers for
varied practical purposes. Some of that task is being approached by those
who are developing small specialized ontology modules, but those still only
cover a small fraction of what is needed, and may have serious problems in
being used in combination. In short, the science of logical inference has
developed impressively in the past twenty years, but the science of ontology
content (i.e. "meaning" for computers) is still straining to be born. (029)
For the time being, I look first at the logical axioms associated with a
term in an ontology, then at the documentation (usually contained in the
"comments' section of an ontology element) to determine if the developer is
serious about explaining to others what was intended. If the axioms are
missing and the documentation is scarce, I take it as a sign that not much
thought has been given to the meanings of the ontology elements, and to me
that is a strong warning "caveat utilitor". (030)
Pat (031)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (032)
*****
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Eddy
> Sent: Sunday, September 12, 2010 4:41 PM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] Language vs Logic
>
> Pat -
>
> On Sep 12, 2010, at 12:19 AM, Patrick Cassidy wrote:
>
> Context for the group... & reminding Pat, since he's probably
> forgotten he said this...
>
> I am holding Pat to his statement at a SICoP meeting in approx 2005
> where he said (approximately) that unless "this magic" (e.g.
> ontologies, etc.) was somehow delivered & made accessible to folks in
> the trenches who have zero knowledge, interest or education in
> ontologies, ontologies would be nothing more than an interesting
> academic exercise.
>
>
>
> CONTEXT... I am interested in the potential use of ontology for the
> development/maintenance of software applications.
>
> I am increasingly coming to the conclusion that ontologies are simply
> NOT relevant to this task.
>
> Please tell me I'm using the wrong lance to tilt at the wrong
> windmill. It won't hurt my feelings.
>
>
>
> > Figuring out precisely what a term in an ontology is supposed to
> > mean has
> > three aspects: what the person developing the ontology intends it
> > to mean;
> > what the person reading the documentation interprets it to mean,
> > and what
> > the computer executing a program using the ontology interprets it
> > to mean.
> > Ideally, the they will be the same, but they may differ.
>
> I would argue that since these are highly likely to be three
> different people, with all the differing experiences, perspectives &
> languages that humans tote around as life baggage, "they WILL differ"
> not may.
>
> Granted my interest in systems development & maintenance may be too
> narrow, I would also argue there are far more people wrestling with
> systems development/maintenance language challenges than people
> building ontologies.
>
>
>
> > so good documentation is critical for
> > ontologies intended to be used by more than a small tightly
> > connected group.
>
> My money is on the ONLY accurate documentation is the source code
> (assuming, of course, you can find the correct version). In
> commercial applications, what paper documentation exists may have
> been accurate at one point, but if the system has been in use the
> code is the only accurate record. [I'd like to think weapons systems
> & nuclear power plants hold to a higher standard, but I have no
> experience here.]
>
> This is in fact one of the great language challenges... as a system
> transitions from paper specifications & documentation through
> development into production and on to new teams of project managers &
> developers (whose native language is likely NOT English), the intent
> of the original language begins to mutate since there is no formal
> process to ensure subsequent generations of maintainers (project
> managers & coders) continue to use the same language & meanings.
>
> Whereas the compiler will force you to use correct VERBS, there is no
> such constraint on the NOUNS... which is why organizations end up
> with literally hundreds of names/nouns for the same thing.
>
> The CD/CDE (as abbreviation for CODE) example is from just such an
> experience. The original IMS DBA enforced CD as the single correct
> abbreviation for several years in the initial system building phase.
> She left & a new DBA took over. A new segment was added & he
> evidently liked to abbreviate CODE as CDE. There was no automated
> mechanism like a compiler to ensure or "encourage" him to use CD
> rather than CDE. The problem comes when one searches for "-CD
> " (note the space suffix, since CD was used as a suffix in data
> element names) you will NEVER find "-CDE ". The devil is in the
> details.
>
> In a system that adheres to "good names" one learns that the name of
> something & what it is are in fact the same. In the physical world
> there a multiple forces-the dairy, the food inspectors, the grocery
> store-to ensure a jug labeled "milk" actually contains milk. We
> haven't quite learned this lesson yet in systems.
>
>
>
> > For me, good documentation means to state what one intends the
> > ontology element to mean,
>
> The way you present this I interpret as saying the ontology needs to
> be done BEFORE the system.
>
> This is, of course, not acceptable since the vast majority of systems
> are up & running & have been built/maintained without any
> consideration at all to an ontology(s).
>
> I don't consider reverse engineering ontologies from existing systems
> to be practical. Primary argument... since the system owner does not
> consider it cost effective to maintain accurate, current
> documentation, they're certainly not going to spend money/time on
> reverse engineering an ontology. I also factor in that the "reality"
> I look at is a small organization of 10,000 people, with 900
> systems. Last year ComputerWorld said IBM, with 400,000 people had
> 4,500 "applications" (same as/different from systems? ...who knows).
>
> I am at pains to point out that each one of these
> "applications" (whatever an application is) was built by different
> people at different times for different objectives. Then maintained
> by different people... all these actors bringing different language
> to the task.
>
>
>
> > To some extent,
> > learning to use a logic-based ontology is similar to learning to
> > use a new
> > object-oriented programming language, but programming languages
> > usually come
> > with a library of immediately useful applications as learning
> > examples. We
> > haven't reached that point yet in the technology of ontology
> > creation and
> > dissemination.
>
>
> Long, long ago I was beginning to work on my last programming
> assignment. I angered the architect (not a word in use then) by
> telling him I did not want to LEARN CICS (at that point a HOT
> language), rather I wanted to USE it. Took about 10 years, but he
> finally came around to understanding what I was saying. His
> templates (what we'd call frameworks today) were absolutely
> brilliant. From a standing start (e.g. knowing absolutely nothing
> about CICS) I was able to take his templates & get 17 CICS programs
> working in 2 weeks.
>
> Twenty years later I was looking at a cross platform development
> tool... and was astonished to find a template/framework tool for
> $350. The earlier templates probably cost the client $500,000+.
>
> This is the standard I hold an ontology tool to... it better not be
> any more complex than a spell checker/dictionary. Clearly there's a
> ways to go.
>
>
>
> > For the time being, I look first at the logical axioms associated
> > with a
> > term in an ontology, then at the documentation (usually contained
> > in the
> > "comments' section of an ontology element)
>
> You keep using words that are difficult to grok...
> "documentation"? "comments"? They are outside my experience. :-)
>
>
> Here's what I consider to be documentation...
>
> a = b * c
>
> Totally accurate & not very useful. More precisely... USELESS!
> Unfortunately there's a lot of this.
>
> The same logical statement:
>
> wkly-pay = hrs-wkd * rate-pay
>
> Is now potentially comprehensible.
>
> If I can determine this is code is in a payroll module then I'm going
> to assume that "pay" is likely a dollar & cents amount. If I can
> deduce this from just the name without needed to ask someone or fish
> around in some questionable documentation, then I'm a happy camper.
>
> But what I would really like is the ability to hot-key/right click on
> these variables & see what they mean. I think this look-up facility
> is possible in modern editors like Eclipse... but someone has to dig
> up what the words mean in the context of their specific use... which
> may or may not say anything about their meaning somewhere else in the
> system.
>
> ___________________
> David Eddy
> deddy@xxxxxxxxxxxxx
>
> 781-455-0949
>
>
> _________________________________________________________________
> 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
> (033)
_________________________________________________________________
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 (034)
|