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