+1 to Leo’s comment.
Amanda is correct that as far as the ontology is concerned, only
the axioms supply the meaning. But:
(1) One can
use human-interpretable labels that avoid at least some of the ambiguity.
For example, CYC (and COSMO) have no concept labeled ‘Book’ because
that may lead users to misinterpret the intended meaning; rather, there are ‘Book-Abstract’
and ‘Book-Physical’ to distinguish the conceptual and linguistic content
from the physical object. And
(2) While
it is true that the ‘meaning’ for any given application depends
only on the source code usage for that application, if the source code usage
violates the constraints provided by the ontology axioms, it means that the
programmer is ignoring the intended meaning, and risking contradictory or
erroneous results. And the logical inferencing of an ontology can be
built in to the application (to greater or lesser extent) to minimize such
programmer errors.
(3) And
if one wants to use the same ontology for more than one application, it is *mandatory*
to be certain that no code contradicts the axioms of the ontology, and *preferable*
to offload as much of the reasoning of a program as possible to logical
inferencing based on the ontology, to be sure that the same meanings are used
in all applications.
Pat
Patrick Cassidy
MICRA Inc.
cassidy@xxxxxxxxx
908-561-3416
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Obrst, Leo
J.
Sent: Sunday, February 26, 2012 5:58 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] What goes into a Lexicon?
The great secret is that concept labels don’t matter, for
machine interpretation. They are what they are for humans to nod over. What
matters is the logic. If you look at mereotopological axioms, for example,
these use labels that are close to words humans would use, e.g., part and
proper-part, connected, etc.
So natural language does matter, and how expressions in NL map
to those concepts do matter. Which is why everyone should use meaningful names
for those labels, even if those labels are only approximate. When I see
“h(X) -> m(X)”, it helps to locally paraphrase it (if
appropriate) as “human(X) -> mammal(X)” – for human
understanding, if not for machine interpretability. It’s better for
debugging.
Yes, concepts via their labels don’t wear their semantics
on their sleeve, so to speak. But when vocabularies need to be mapped to
ontologies by humans, it’s very useful to have ontology nodes
(predicates, individuals, etc.) labelled in approximate natural language.
Humans thereby make fewer errors.
Thanks,
Leo
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Rich Cooper
Sent: Sunday, February 26, 2012 3:54 PM
To: '[ontolog-forum] '
Subject: Re: [ontolog-forum] What goes into a Lexicon?
Dear Amanda and David,
Amanda wrote:
What probably causes the confusion
is that the nodes in an ontology are not "terms" in this sense; they
are NOT bits of language, which may have many meanings, but rather these nodes
are *concepts*, abstracted from the various ways they might be expressed, in
any language or jargon or context or by anyone. It *is* a rule of ontology that
each abstract *concept* must have one formal definition/meaning; that's what makes
it a *specific abstract concept*, and what makes it computable as part of an
ontology. But there may be any number of ways of expressing this concept in
language, symbols, etc., and any particilar bit of language may be associated
with any number of different concepts. In an ontology, what it looks like for
"terms", in the used-language sense, to have multiple meanings is
that those terms are associated with multiple abstract concepts, where each of
those concepts has a single, formal definition/meaning.
It is an abstraction, IMHO, to
call a concept by ANY linguistic term. That is, the concept has such
depth of meaning when you look at how it interlocks with other concepts in the
lattice that the phrases people use to describe the concept are misleading and
even wrong at times – most times it seems.
If concepts had some form of
meaningless index, like a social security number, or other social construction
that did not use English words, I could believe that the concept is different
from the various terms used to describe it. But that is not the practice
used on this forum to date. Concepts have always been described here by
English terms, not by asemantic indexes.
Given an index value, it could be
wikified to show various English terms describing the concept for reference
purposes. Then programmers could click on an index, get a pop up page of
full description, and even search the set of indexes using Google like phrases
to find a list of concept indexes which might be relevant. If that were
done, I could believe that the index designates a set of abstract, language
free concepts.
But current practice is to refer
to a concept with a word or phrase that captures only a tiny portion of the
real semantics of that concept. Therefore David’s point of
subjectivity blinding the philosophy of a concept set is very appropriate to
the ways in which concepts are actually used in software development.
When concepts are named with words
or phrases, they are at least as ambiguous as the words or phrases.
HTH,
-Rich
Sincerely,
Rich
Cooper
EnglishLogicKernel.com
Rich AT
EnglishLogicKernel DOT com
9 4 9 \ 5
2 5 - 5 7 1 2
David,
Actually, I think that you *do* have it wrong. At
least, when you say:
"since as far as I know it's a hard & fast
ontological rule that requires a term to have a single definition/meaning... an
extremely unrealistic constraint for this sort of ugly real world challenge.
[If I've got this wrong, please set me straight.] "
Up to that point, your message seemed to be about
lexicons, terminologies, and other bits of language. And of course, as you
point out, these terminologies vary highly from one context to another, even as
used by a singular person at different points in time.
And you are right that some people have tried,
using various modeling and standardization methods, to fix one
meaning/definition for a term, where "term" = bit of language, word,
phrase, abbreviation, _expression_, the kind of thing you would find in a lexicon
or controlled vocabulary, and then tried and failed to use the result to
represent content across heterogenous sources. Or tried and failed to impose
this, top-down, on all data sources, users, systems, code, etc. Even within an
enterprise with the supposed ability to enforce such uniformity, it fails. That
approach simply doesn't fit with the realities of how people work, how meaning
is bound up with context, how terminology evolves with use and how that local
evolution is part of the development of expertise and efficiency.
With respect to all of that, IMHO, you're
absolutely right.
Where things go wrong is in the bit I quoted above.
It's absolutely NOT a hard & fast rule of ontology that each term have one
definition/meaning, if by "term" you still mean what you meant in
those previous paragraphs: a bit of language, word, phrase, abbreviation,
_expression_, the kind of thing you would find in a lexicon or controlled
vocabulary. In an ontology, each one of those things (e.g., each word, abbreviation,
phrase...) can be associated with many different meanings. You might (or might
not) even capture some relationship between those term-to-meaning associations
and some context factors such as source, business process, localization, etc.,
if this is important for your usage. But even then, there is no restriction to
one meaning per (language) "term" per context.
What probably causes the confusion is that the
nodes in an ontology are not "terms" in this sense; they are NOT bits
of language, which may have many meanings, but rather these nodes are
*concepts*, abstracted from the various ways they might be expressed, in any
language or jargon or context or by anyone. It *is* a rule of ontology that
each abstract *concept* must have one formal definition/meaning; that's what
makes it a *specific abstract concept*, and what makes it computable as part of
an ontology. But there may be any number of ways of expressing this
concept in language, symbols, etc., and any particilar bit of language may be
associated with any number of different concepts. In an ontology, what it looks
like for "terms", in the used-language sense, to have multiple
meanings is that those terms are associated with multiple abstract concepts,
where each of those concepts has a single, formal definition/meaning.
I hope that makes the matter a bit clearer. Where
ontology is successfully used for interoperability, in environments where
multiple meanings per used-language "term" are typical and assumed,
the ontology can help by capturing and providing mappings between the
polysemous used-language "terms" (including data values, field names,
and unstructured or semi-structured text) and whichever, and however many,
single-meaning abstract concepts those used-language terms are used for.
So the used-language "terms" get to keep their many meanings; it's
the abstract and formally defined *concepts* that must have just one.
Again, I hope that clarifies thing a bit. It's made
more confusing by the fact that the linguistic _expression_ "term" is used
for multiple things. In some uses, "term" is used to mean a bit of
used-language; in some uses, "term" is used to mean concept in an
ontology. But despite that bit of typical, confusing polysemy, the fact is that
ontologically, the bits of used-language can be associated with many meanings;
it's the abstract concepts that have to have just one (though they can have
many, and overlapping, used-language expressions).
Best,
Amanda
On Feb 25, 2012 9:41 PM,
"David Eddy" <deddy@xxxxxxxxxxxxx>
wrote:
Rich -
On Feb 25, 2012, at 6:27 PM, Rich Cooper wrote:
> Ontology
> designers that produce a well documented, highly
> learnable and usable ontology (i.e., something
> simple and down in the details of a domain) could
> provide a satisfying brick to many of those first
> time developments.
I am speaking in the context of the legacy software systems that
enable our lives.
The language/lexicon/terminology/slang/whatever already exists in the
applications. Unfortunately it's pretty much been put together with
a single ended one-time pad... & that guy(s) has left the building.
The problem is, unless you have the SME sitting at your side, or lots
& lots of time, the terminology is very difficult to grok. And when
you move to the next assignment, the terminology/lexicon is very
likely to be different, so you have to forget what you just spent 6
months learning.
I would likely argue that this language collection has not been
accumulated with the idea of an organized ontology in mind.
Imposing an organized ontology on this disorganized language
collection probably isn't going be of much help.
But something that quickly shows or records or suggests that in a
particular context "no" actually means "id" (e.g.
soc_sec_no....
social security "number" is not a number, it's an index... a very
different beast)... now that would be useful & likely to be embraced
by the grunts—application owners, analysts, programmers—in the
trenches.
How ontologies could add value, I don't have a clue, since as far as
I know it's a hard & fast ontological rule that requires a term to
have a single definition/meaning... an extremely unrealistic
constraint for this sort of ugly real world challenge. [If I've got
this wrong, please set me straight.]
___________________
David Eddy
deddy@xxxxxxxxxxxxx
_________________________________________________________________
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