Thanks Bill,
The subjective experience, or the
human-factor aspect as you viewed it below, truly is different for everyone,
and wherever a system has slippage for subjective variation, it happens, and variation
gets into the data. The thing that gets hard to work with is the belief
that we should “make people do it right”. The usual reaction
of John Sowa’s “pointy-haired manager” prototype is to tighten
up “the” way employees are told to interpret the data. And
sometimes that can actually work. But only when “the official”
feedback is provided nearly instantly after the action.
I like strong typing because it helps me
keep my programs working with instant feedback from the editor as I type small changes
in source text. Strong typing without an interactive, type-knowledgeable
editor is much less effective. If I don’t get a response until I
hit compile, that slows down the feedback loop and makes me work too hard at simple
details while keeping my grand design idea in mind. Unless an ontology editor
can be that quickly interactive, it won’t help the individual with the
experience, IMHO.
At minimum, an ontology editor should be capable
of correcting my mistakes or at least suggesting among alternatives, based on
my data, taken successfully in situations similar to mine. Having to wait
long for feedback is a stopper.
By the same analysis, the data entry
person (whether that person acts with skill and judgment, or just to earn a
buck putting in text) has a subjective interpretation that has absolutely
nothing to do with “the” ontology. That subjective
interpretation has an ontology all its own, which will have to be mapped to “the”
ontology for correction to “the” objective reality.
JMHO,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Burkett, William [USA]
Sent: Tuesday, October 27, 2009
11:30 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Just
What Is an Ontology, Anyway?
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