I going to take position that may get me in real trouble on this list;
The need to embrace vague wish lists. (01)
I have a vague wish: I wish users would state their requirements more
precisely. I could even state this as a policy or requirement. Such
vague requirements can cause contracts to be paid or not or could land
you in jail. Of course to the person stating the "wish", it is clear.
It has an intent. It may have authority. (02)
There are multiple things we can do with such wishes; a) We can state
them more precisely (Regardless of the language used to do so). B) We
can create derivative statements (E.G. If you are going to state
requirements better you need to be able to express yourself precisely in
some language). C) We can design tests to see if the wish is being
fulfilled and D) We can create designs proposing to fulfill the wish. (03)
In all cases the additional information is with respect to the Vague
wish - it is still the speech act that, in the speakers mind, started
all this derivative work. This this "fact", as fuzzy as it may be, is a
crucial part of the linage developed in various formalisms or designs.
We can't loose this linage or the intent of the speaker in the context
from which it is stated. So vague wishes have to be integrated as part
of the knowledge base and our formal models traceable to them.
Hopefully our formal expressions can be interpreted in such a way that
they speak to the originator such that they can say "Yes, that is
exactly what I intended to say - thank you for restating it so well". (04)
If our formal expressions can't be interpreted by the casual user as a
better re-statement of their intent we have no feedback loop -
ontologies CAN NOT be buried in the depths of an application, they are
front-and-center expressions of our knowledge about a domain and can
only succeed where they can, at lease, be understood by the domain
expert. (I don't mean read in the raw form, any kind of presentation is
just fine). To be really useful the domain expert should be able to
MAKE statements that are fully precise - because architecture and design
is a participatory sport, the more who participate the better. So our
methods & tools have to help them here, to assist in the process of
precise statement. (05)
This is not to say there is no room for the professional, there is
always room for the great designer who can suck it all in and produce
the great result. There is also always room for the expert able to take
a vague statement and make it precise (in any language, from law to
FOL). But these experts are there to aid in the process, not be the
process - so our tools and methods have to embrace the casual user and
vague statements and help capture these and then more fully develop and
refine them to be more precise and to impact the designs that will
realize them. (06)
So part of the point is that such core intent, no matter how poorly
expressed, are the statements that we are refining, formalizing and
creating designs to satisfy. The vague wishes are part of the knowledge
base. To the person making the statement, all the logics, modeling
languages and other formalisms are just tools to capture what they were
saying all along. (07)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Deborah
MacPherson
Sent: Friday, February 23, 2007 3:41 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] vague wish lists VS formal specifications (08)
There are probably very few really good chief designers then. (09)
Debbie (010)
On 2/23/07, John F. Sowa <sowa@xxxxxxxxxxx> wrote:
> Debbie,
>
> Yes, but it's necessary to know why the user must participate:
>
> > I ... want to emphasize the point is to have the end user >
> participate in the design process.
>
> The users' participation is essential to educate the chief designer,
> who must fully understand the problem.
>
> The users can never discover all the details of what might be possible (011)
> unless they become technologists -- and in most cases, that is not
> practical. Therefore, the chief designer must learn from the user
> (without prefiltering by managers, planners, and requirements
> surveys).
>
> 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
>
> (012)
-- (013)
************************************************* (014)
Deborah MacPherson
www.accuracyandaesthetics.com
www.deborahmacpherson.com (015)
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. (016)
************************************************** (017)
_________________________________________________________________
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 (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)
|