Bravo, Rich – this is the first time I’ve heard
anyone in any of these ontology/SUO forums stress so strongly the human-factor
aspect of data semantics. I’ve been trying to argue this
point for years but to most CS-trained individuals it just falls on deaf
ears. I even have a nice little catchy name for the theory: “Data
Is Speech”. As you suggest, there will be multiple
ontologies (or whatever you want to call them) to formally represent different
views of the word and they will need to be quickly adaptable to changing business
requirements . And the one significant missing and way way underserved
ingredient is mapping and translation technology.
Bill
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Rich Cooper
Sent: Monday, October 26, 2009 9:24 PM
To: '[ontolog-forum] '
Subject: Re: [ontolog-forum] Just What Is an Ontology, Anyway?
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
Dave McComb
wrote:
Ontologies, in my mind, offer a way to help sort, categorize and organize the
chaos we've created. We have to integrate the old with the new as we go forward,
but this isn't as hard as it sounds. SOA has given us the general
technological approach, Semantics is adding a layer of rationalization on top.
Nicely stated - I'm still reading Karl Popper's Logic
of Scientific Discovery, which is a dramatic reminder of the subjectivity
we brush aside so easily. Remember that the people who entered all that
data into the database in the first place were each individuals with their own
internal ontologies.
The first problem in any database, even prior to formalizing
“the” ontology or (more effectively, “some” ontologies)
is to find ways to ascertain the meaning of data recorded there. I
described that in detail on my web site at:
www.englishlogickernel.com-Patent-7-209-923-B1.PDF
For example, when a Yes/No answer is mixed with 1/0, 2/1,
T/F, True/False, and MIXTURES of the above (yes, T/1/F/0, 2/1/0 and other
mixtures are possible since people are not consistent systems). Attempts
to force fit the answer into a very precise type of form (T/nil) leads to
frustrated users, GUI programming errors, confused analysts and lots of data
entry errors because most users don't have a real stake in most systems they
deal with.
For a few lucky enterprises, there may have been
"the" enterprise ontology by designers who thought it might be
useful. In my experience, every enterprise system database evolves faster
than the IT staff allocated to manage it. There is too big a loop between
the user with her needs and the developers who make changes.
Meaning is in the eyes of the people who provide the
data, and lots of that meaning is subject to human judgment, valuation
diversity, and just plain old personal preferences. Then there is the
meaning in the perceptions of data analysts who try to make sense of the user
data, or find patterns there, typically not having the original users available
at the analyst's moment of investigation.
But between the data entry person and the analyst, there
may be lots of other users reading, perceiving, populating, editing, and
otherwise in their own eyes "adding" meaning to the data by changing
the original source data cells – all to meet their own individual
ontologies. So the typical enterprise database is full of classes and
properties that shouldn't be there (given “the” ontology), but in
fact they are. Even worse, the variations are the main source of
information in businesses looking for ways to improve profit, service, quality
or other metrics. The changes in data, the variations, contain the most
information.
Education and training of staff to enter data "the
right way" is a hopeful tactic, but almost a waste of time, and users
mostly still do what they think is good on the spur of the moment, just like
the rest of us. People work in our own conceptual ways, we deal with
everyday situations in our own lexicon, grammar and thought processes, and
"education" applied in that way is more appropriately called
"indoctrination". It tries to “fix” the users’
dynamic flow of structural information instead of adapting to that changing
flow by processing a changing ontology with changing projected user ontologies.
So the only conclusion I can reach is that
"the" enterprise ontology, if singular, is a dynamic and variable
entity that is no more fixed than any other specification to be implemented
real soon now. Forget about selecting ONE, and expect multiple
ontologies; the transition sequencing from one to another (the periodic version
update) is likely to become more manageable that way. Expect ontologies
to be iterative and plural, not fixed and singular.
I think every user might some day have her own ontology.
Localizations and personalization can be used to adapt "the"
ontology to a wider range of individual user needs as much as writing
specialized queries in SQL which takes development labor.
Surely a "semantic" application will influence
the user's GUI behaviors in some dynamic way. So if "the"
ontology is dynamic, then "her" ontology must be getting calculated
from "the" ontology either very quickly or very incrementally to meet
GUI performance requirements.
JMHO,
-Rich