but we need a common way to
describe our work allowing the mediation of viewpoints. As our worldviews
differ in scope (what we look at), resolution (detail we are looking at),
and structure (categorization of what we are looking at), these mediations
will not always be loss-free, but that is part of the nature of the
seems like we are starting to come to very similar observations and reach
mappable conclusions in different scientific domains.
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
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
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
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:
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
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.