[Top] [All Lists]

Re: [ontolog-forum] vague wish lists VS formal specifications

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Doug Holmes <dholmes@xxxxxxx>
Date: Fri, 23 Feb 2007 16:47:52 -0800
Message-id: <C69E1D5C-640E-461B-A761-62113761460C@xxxxxxx>
How about, for a start, something like design patterns.  That idea has been effective in software engineering.   Aldo Gangemi described an approach to this idea at Galway [1]  and, although I haven't seen much activity result, it still  seems like a very good idea to me. I think a small set of design patterns for ontology might help a lot of projects [including some Web 2.0 ideas] start well and maybe provide some basis for agreement - or at least productive discussion - in some basic ideas. 

 [1] Ontology Design Patterns for Semantic Web Content. Musen et al. (eds.): Proceedings of the Fourth International Semantic Web Conference, Springer, 2005

On Feb 23, 2007, at 3:07 PM, Cory Casanave wrote:

Marketing hype aside I am very encouraged by the "web 2.0" style of
community involvement.  If we see our knowledge base as a community
resource that evolves with the participation of all the stakeholders and
as it does so captures, refines and expands their knowledge - we have
that humanistic coloring book you seem to be calling for.  If we can
then ground that community resource, wherever possible, in well founded
theory we can start to bring together the hard-edges of formal methods
with wide-scale involvement.  One thing we have been working on lately
is trying to express architectures more in this way - like a resource
and, sometimes, like a "wiki" that is part of the communities body of
knowledge.  We can sometimes get caught up in our notations and theories
and in doing so obscure the essential information.

One thing I have learned about languages and tools is that they are not
sufficient, they need to be seeded with well developed starting places
and parts that can be used, refined and integrated.  This is the
attraction of resources like Cyc, Dolce or Wordnet - we don't have to
start from a blank page.  Add to this the body of knowledge in
architectures, models and domain ontologies and we have a lot to draw
from - a very rich heritage.  Unfortunately the resources are very tied
to their formalism and not so easily reused across that boundary.

Perhaps we need to find a way to focus on the concepts (as understood by
real people) that are then formalized in multiple ways, rather than
assuming life starts with a particular logic/model/theory/design?  

Perhaps this also suggests contracting and design is less of a
"procedure" and more of a culture?  How can we encourage and enable that


-----Original Message-----
Sent: Friday, February 23, 2007 5:31 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] vague wish lists VS formal specifications

Every single one of these reasons below is driving my own vague wish for
a standardized contracting and design procedure.

What if the chief designer is out sick for a month?

It can be difficult and tedious to fill in blanks and answer questions
outside your area of expertise but its better for users to go through
some anxiety before the engineers start designing/specifying.

Just a guess and I could be wrong, but maybe everyone is starting out
with blank sheets and arguing about the same words again every time.
It needs to be more like a coloring book/dictionary - some lines, nodes,
and definitions already in place.


On 2/23/07, Cory Casanave <cory-c@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
I going to take position that may get me in real trouble on this list;

The need to embrace vague wish lists.

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.

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.

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
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".

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.

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.

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.

-----Original Message-----
Sent: Friday, February 23, 2007 3:41 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] vague wish lists VS formal specifications

There are probably very few really good chief designers then.


On 2/23/07, John F. Sowa <sowa@xxxxxxxxxxx> wrote:

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 

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 


Shared Files: http://ontolog.cim3.net/file/ Community Wiki:



Deborah MacPherson

The content of this email may contain private confidential
Do not forward, copy, share, or otherwise distribute without explicit 
written permission from all correspondents.


Shared Files: http://ontolog.cim3.net/file/ Community Wiki:

Shared Files: http://ontolog.cim3.net/file/ Community Wiki: 



Deborah MacPherson

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.


Shared Files: http://ontolog.cim3.net/file/ Community Wiki:


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    (01)

<Prev in Thread] Current Thread [Next in Thread>