Dear Matthew and Deborah, (01)
The options for creating bugs and incompatibilities are
open ended and creative new ways for multiplying them are
being discovered every day: (02)
MW> Two implementations of the same system (same version)
> can embody different ontologies and be incompatible.
> I know 'cos we've done it thinking that using the same
> system would solve the problem. (03)
But that's not the only problem: (04)
DM> A similar phenomenon happens with architectural design
> because many customers cannot read plans. (05)
A plan may look very nice on paper, but the finished building
may look horrible when viewed in context with its surroundings.
Even if it looks good, the various ways in which the building
will be used by its residents and visitors might not be
considered. The best architects try to anticipate all those
issues, but many consider the obvious issues and forget the
minor ones, which can, over time, become major annoyances. (06)
DM> More plain language, checklists, and simple diagrams are
> needed for untrained customers that envision or need idealized
> data transactions and interpretations to communicate their needs
> and explain the information or knowledge they are caring for to
> engineers. We the untrained do not know exactly which elements
> and processes are essential in a "good" ontology. (07)
I'd like to make two points: (08)
1. It is possible to have humanly readable notations that are
just as precise and formal as any notation for logic. The
primary notations for logic since Aristotle were stylized
natural languages (originally Greek and Latin) supplemented
with diagrams. Type hierarchies, called the tree of Porphyry,
were first recorded in the 3rd century AD, but they may have
been used much earlier. (The words "above" and "below" were
used for supertypes and subtypes for centuries, and they may
have been more than just metaphors.) (09)
2. But the point that "people don't know what they want" involves
more than just the notations. The people with the problems
aren't aware of what technologies are available to solve them,
and the people who know the technology rarely understand the
users' problems in sufficient detail to choose the appropriate
technology. (010)
Some time ago, there was a study to determine what kinds of
methodologies, managerial styles, "best practices", or working
conditions lead to successful innovations. After many interviews
with executives and developers, it became clear that no single
methodology or managerial style was significantly better than
any other in promoting successful innovation. (011)
MW> My experience is that you need to take what the customer says
> they need, and perform analysis to determine what they really need. (012)
Yes. That is important, but the designers must go beyond what the
customers say and look at what they do. There is one factor that
is present in all of the most successful innovations: (013)
The chief technical person truly understands the users' problems. (014)
It isn't sufficient for the chief manager, salesman, or planner to
understand the users' problems. The primary requirement is that the
chief designer understands both: the technology and the problem. (015)
Asking the users is not sufficient for one simple reason: they have
no idea what kind of technology might be appropriate to their needs.
Even if the developers give them what they thought they wanted, they
ask for something else as soon as they see that the technology can do
things they had not thought to ask for. (016)
In fact, that's the difference between Steve Jobs and Bill Gates.
Jobs thinks like a user, and he comes up with successful innovations.
Gates thinks like a technologist, and all of his innovations are
flops. But Gates has the persistence to copy and mass produce the
successful innovations by people like Jobs. Unfortunately, Gates
always throws in too much innovation (i.e., "bloatware") that the
users definitely do not need or want -- he lacks good taste. (017)
John (018)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (019)
|