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. (01)
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. (02)
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. (03)
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". (04)
Pat (05)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (06)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Eddy
> Sent: Saturday, September 11, 2010 4:19 PM
> To: [ontolog-forum]
> Subject: [ontolog-forum] Language vs Logic
>
> Matthew -
>
> On Sep 11, 2010, at 3:17 AM, Matthew West wrote:
>
> >> This discussion has been most enlightening... I see language used
> >> in totally chaotic ways with minimal logic & certainly NO universal
> >> logic.
> >
> > MW: Chaotic, yes, but logic is logic whether you use it or not.
>
> I think I finally get that I'm at one end of the spectrum & logic is
> at the other.
>
> What I thought I was looking for in these ontology discussions was the
> ability to determine which of 35+ potential meanings a cryptic "term"
> means within a piece of software or documentation.
>
> When I'm reading an article in the NYTimes there is surrounding
> context in the article to help guess what an unfamiliar word means.
> When I'm read code, a model or technical documentation, there is
> typically NO additional context to help grok what some token actually
> means. Assuming that I've seen a token before & therefore know what
> it means here is clearly one of the FIRST habits you unlearn when
> working in/around systems.
>
> When I'm reading the NYTimes I have the benefit of knowing that if the
> article is written by Paul Krugman, that's one context & if by Eric
> Lichtblau an entirely different context. This sort of context setting
> is typically NOT present in systems.
>
>
> So what is the precise logic in ontologies actually useful for?
>
>
> I picked up on the ontology wave at several Mitre meetings in the 2004
> + period when increasing the interoperability of data between systems
> was getting a lot of attention.
>
> To me this is "simply" a systems maintenance issue. If you know what
> the system is doing & what data it manipulates, then it's (at least
> theoretically) easier to interoperate with other systems.
>
> How do ontologies make this-VERY expensive-process easier?
>
>
>
> I would further observe that software applications have largely
> evolved along a rather chaotic path, particularly when one looks at
> the language used inside the systems to label he data being used. In
> a chaotic environment (e.g a collection of 100s/1000s of applications
> written & maintained over decades for constantly evolving business
> needs) how does applying organized logic (single term, single
> meaning) help with this situation?
>
> I am saying that if I can easily know AMT means "amount" (which also
> carries situational specifics) in Context A & in Context B AMT means
> "Amtrak" that would be a HUGE leap forward.
>
>
>
> >> Most "documents" are stuff written to be read by other humans...
> >> often corrected by highly skilled humans called editors to make
> >> better sense.
> >>
> >> I know this is crazy, but I consider software-Algol, Jovial, COBOL,
> >> Fortran, Java, Objective-C, C, C++, PHP, etc-programs/scripts/code
> to
> >> be documents.
> >>
> >
> > MW: Perfectly reasonable.
>
> Perfectly reasonable what?
>
> Software is NOT a document? Or software IS a document?
>
> I argue that software IS a document. And I know I'm in a minority.
>
> Document management professionals almost universally wrinkle their
> brows when I attempt to argue that software is a document.
>
> ___________________
> 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
> (07)
_________________________________________________________________
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 (08)
|