Hi John & Matthew, (01)
What I'm going for is more of a philosophy perhaps. Good design should
be invisible. Someone walks into a building and doors are located and
operate like they should. The details, or the edges, where one
material transitions to or joins another are shown in the construction
drawings. There are few drawings of a long plain continuous wall. Its
the joints. This is also where better specifications come in, better
design, incorporating lessons learned etc. Most building owners or end
users would never notice the transitions and edges the architects and
specifiers are sweating all the time - they see the big wall of glass,
we know it won't leak. The same way a user may work on an ontology
level, the big glass wall within a main field of consistent
information, most of the time. (02)
On point 2 and the inherent disconnect between designer and user, and
leaving it up to the engineer to specify the valves - that is where
I'm looking to create a middle document, or standard. I'll also look
at ISO standard 15926. (03)
In terms of Mac vs PC - I just wish everything could work together,
the data brings its operating instructions alongwith it every where it
goes. Just like the ultra communication document between engineers and
data owners will only really be solved after many MANY projects and
examples, so far, people are still stuck buying one, the other or
both. Too bad and hope this situation and chronic upgrading and
expense after expense after expense can ease up. Public and nonprofit
organizations can't afford it. (04)
Debbie (05)
On 2/23/07, John F. Sowa <sowa@xxxxxxxxxxx> wrote:
> Dear Matthew and Deborah,
>
> The options for creating bugs and incompatibilities are
> open ended and creative new ways for multiplying them are
> being discovered every day:
>
> 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.
>
> But that's not the only problem:
>
> DM> A similar phenomenon happens with architectural design
> > because many customers cannot read plans.
>
> 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.
>
> 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.
>
> I'd like to make two points:
>
> 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.)
>
> 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.
>
> 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.
>
> MW> My experience is that you need to take what the customer says
> > they need, and perform analysis to determine what they really need.
>
> 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:
>
> The chief technical person truly understands the users' problems.
>
> 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.
>
> 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.
>
> 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.
>
> John
>
>
>
> _________________________________________________________________
> 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
>
> (06)
-- (07)
************************************************* (08)
Deborah MacPherson
www.accuracyandaesthetics.com
www.deborahmacpherson.com (09)
The content of this email may contain private
confidential information. Do not forward, copy,
share, or otherwise distribute without explicit
written permission from all correspondents. (010)
************************************************** (011)
_________________________________________________________________
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 (012)
|