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
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