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