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 beast.
seems like we are starting to come to very similar observations and reach
mappable conclusions in different scientific domains.
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
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
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
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