Amanda,
Thanks for some clarity on this. From the perspective of the
business practitioners, it has been very important to get these
distinctions right, starting from what were my instructions when I
first undertook to create a business ontology for the financial
services industry: "Keep the philosophy out of sight!"
The industry had reached an awareness that, while they might argue
forever about the meanings of words, they could quickly reach
agreement on what are the individual meaningful concepts, and then
agree to attach different synonyms to those. This all came from the
business, without any academic influence, and while they use the
word "term" quite flexibly, it became clear that what they needed,
after various false starts involving XML standards, common data
models and so on, was some resource in which each meaning was
defined once.
This is what we called an ontology, as long as we agreed not to use
that word in front of the business people.
Now that we have this, the industry is ready to embrace formal
approaches that deal with how to relate the multiple vocabularies or
lexicons that different parts of the business use, to the single
meaningful "Terms" in the ontology (this corresponds to what the
business folks usually mean by "Term" e.g. "We want terms,
definitions and synonyms please", but others have more precise
technical meanings for the term Term, as we have seen). Now that we
have sets of single, meaningful concepts with synonyms, it is
possible to try and create a layer on top of this which deals with
the trickier question of single words with heterographs and all the
other nyms, i.e. the lexical or vocabulary related questions. This
might use the work developed in ISO 1087, for example the SBVR
standard.
Any time I see a thing which is written in OWL in which there are
OWL "Equivalent Class" relationships within the same OWL file, it
seems to me that this is a vocabulary which happens to be in a
language which causes many people to refer to it as an "ontology"
(confusing syntax with semantics). It should be a compliance rule
that if something is intended to be an ontology, we should not see
this relationship other than between concepts in different
namespaces.
So we had to wean the industry off its dependence on words by
educating them about how to capture common meanings without being
too distracted by the labels. By and large they got it. Now we can
go back to them with the science required to adequately deal with
the vocabularies or lexicons of the different business units.
Mike
On 19/02/2012 16:49, Amanda Vizedom wrote:
Many, many ontologists would say that the sense of
"lexicon" that Matthew put forward is local to purely
logic-oriented conversation, but as with other expressions from
the many fields that contribute to applied ontology, using
"lexicon" this way within the broader practice of applied ontology
only creates confusion.
Rather, when we are talking about applied ontologies that
include both logical and natural-language elements, "lexicon"
usually refers specifically to the natural language elements.
And the lexicon is most certainly *not* governed by a
restriction to one lexical _expression_ per concept. In fact, in
many usages, a significant benefit of using ontologies instead
of some other model type is that the structures and distinctions
empowered by ontological abstraction, and by many ontology
technologies, support the clear and emphatic distinction between
the lexical and the conceptual. The most successful approaches,
in real usages full of polysemy, make this distinction. The
lexical and the conceptual are mapped; they are not the same.
Understanding and implementing this distinction allows a
logically precise ontology with unique concepts in which
ambiguity is avoided *and* a rich representation of natural
language expressions. A concept may have any number of labels
(lexical mappings to words); a natural language _expression_ may
be a label for any number of concepts.
Ontology projects that do not make and implement this
distinction might work on a very small, or narrow-domain, or
controlled environment, project. Beyond that, they will get
bogged down in totally unnecessary efforts to settle on unique
labels, or to choose between different concepts that share an
_expression_. If they understood and leveraged the distinction,
they wouldn't have to do any of that. Represent the different
concepts separately, define each one appropriately (as you
should anyway, as the label is not the definition, especially
from a machine-usability standpoint), and map the _expression_ as
a label for each of the concepts.
There are many ways to do this, with varying levels of detail
captured regarding the contexts in which expressions map to
concepts. Depending on the usage, there are also varying levels
of processing that can be implemented for the lexical
information. For NL parsing and generation, and for text
analysis and entity extraction and semantic indexing and
retreival, there will typically be considerable lexical
information captured and used by the NL processing engine(s).
Note that this processing follows different principles, and uses
different (overlapping) portions of the ontology, than does the
inference engine, because *lexical information and logical
information are not the same*. For many usages, a good ontology
must incorporate both kinds of information, and treat them
appropriately.
Amanda
On Sun, Feb 19, 2012 at 10:41, David
Eddy <deddy@xxxxxxxxxxxxx>
wrote:
Matthew -
On Feb 19, 2012, at 10:18 AM, Matthew West
wrote:
I
would have expected you to support them in
this from your remarks, rather than be
critical.
"Different perspective" would be my preferred term.
If the world of ontology would clearly & openly
state: "An ontology is useful for this & not for
that" I'd be far happier & less acrid.
If logic would help with the maintenance &
design of software systems, I'd be all for it. But if
logic hobbles the use of terms to a single meaning,
then clearly logic isn't much use in
maintaining/developing systems. The context of my
view is commercial business systems, not life
sciences. I don't know if geology is closer to a life
science.
As always I revert to my favorite, oft-repeated
example... a life insurance company that found 70
different names for the core business concept (term?)
"policy number." In a business environment where
product lines are bought & sold, systems are
custom built by different teams & packages are
bought, the reality is there will be many (illogical)
names for the same thingy.
At one point I entertained delusions that
ontologies would help with this issue (one conceptual
label = many physical labels). Obviously I no longer
hope in that direction.
_________________________________________________________________
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
_________________________________________________________________
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
--
Mike Bennett
Director
Hypercube Ltd.
89 Worship Street
London EC2A 2BF
Tel: +44 (0) 20 7917 9522
Mob: +44 (0) 7721 420 730
www.hypercube.co.uk
Registered in England and Wales No. 2461068
|
_________________________________________________________________
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 (01)
|