Re: Declare before use constraint in ontology editor.

James Rice <rice@HPP.Stanford.EDU>
Date: Wed, 15 Mar 1995 13:42:59 -0800 (PST)
From: James Rice <rice@HPP.Stanford.EDU>
Sender: rice@HPP.Stanford.EDU
Reply-To: rice@HPP.Stanford.EDU
Subject: Re: Declare before use constraint in ontology editor.
To: m.uschold@ed.ac.uk
cc: ontolingua@HPP.Stanford.EDU
In-Reply-To: m.uschold@ed.ac.uk's message of Wed, 15 Mar 1995 11:27:25 -0800: <199503151927.LAA18097@hpp-ss10-8.Stanford.EDU>
Message-id: <XLView.795305706.5759.rice@hpp-ss10-1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

[Mike sent this comment to us from within the ontology editor, but
 this is really a topic that is worthy of more general discussion.]

<m.uschold@ed.ac.uk> writes:
>>I disagree with the design decision to force classes to be created
>>before referring to them.

This was a concious design decision, mostly vociferously supported
by Wanda Pratt (says he smearing the blame out as far as possible).
Wanda, though her work with Cyc has far more experience than I with
good ontological engineering style.

I'm not very religious about it, but I think I broadly agree with
this behaviour.  I suspect that Adam Farquhar (somewhat) disagrees
with it.  The idea is that we think (we're not sure, but it's a
hunch) that the process of ontology development is very different
from that of just editing frames in some KB.  We suspect that it's
very important to think about it _before_ you go around creating
things rather than using the "oh, I reckon it'll end up being a
subclass of something like FOO, I'll get to it some time" strategy.

We'd like to encourage every definition that gets into the system to
be as complete as possible.  Allowing forward references would allow
people to create definitions that have no substance other than their
names, no doc string or anything like that.  We think that that's
probably bad practice.

>>I think it VERY restrictive, inappropriate
>>and a hindrance to my work I may well know what classes I want, and
>>that I will have to define them eventaully, but I do not yet know what
>>sub-ontologies they will all be in, nor their details.

Yes, it's supposed to be restrictive (this may or may not be a good
idea, I'm more than prepared to be convinced one way or the other).
I think that Wanda would claim that if you don't know what ontology
the definition is supposed to be in then you probably haven't thought
about it enough.  Anyway, you can always move a definition to a
different ontology if you get it wrong.

>>Even if I DID know all that, I do not want to be forced to
>>do everything bottom up.

I don't agree with what you are implying here.  I don;t want to do
things bottom-up either, the ontology editor forces you to built
everything _top-down_, not _bottom-up_.  You cannot (easily) create
a subclass until you have created its superclass.  This seems like
a desirable property to me given your point of view.  The "Create"
menu explicitly captures the clich\'e of wanting to create
subclasses of the current class with the "Create Subclass" command.
Setting your user preferences will let you have access to even more
commands at random times that will let you get around any need to
pop up to the ontology to create random classes, relations and such.

>>This restriction is analogous to a too-clever LaTeX mode, say in emacs
>>complaining when you hit the return key after typing:
>>"\begin{itemize}"
>>
>>that there is no \end{itemize} command and no items defined.
>>Obviously, not useful. The time to complain, is when you run Latex.

I don't agree with this analogy.  Obviously the ontology
editor is a structure editor, not a text editor.  It has the
benefits associated such editors and the problems.  To use your
analogy, it will in fact allow you to create a \begin{itemize}...
\end{itemize} pair, it just discourages you from creating random
items at the top-level without putting them inside an itemize
construct.  Actually, that's better, but still not right.  I guess
I think that the analogy just can't be bent into being right.

>>Similarly, the time to be restrictive and pernickity is when the user
>>asks needs to DO anything with the ontology, not during its incremental
>>development.

This is a religious issue.  _I_'d much rather be told about
constraint violations when I attempt to violate the constraint
rather than later on trying to fix up the damage I have done.
I don't claim to have the moral high ground on this one, but I
can certainly assert that there exists at least one person who
has a diametrically opposed opinion to your's on this issue.

>>I think it much better to send a warning message indicating it is not
>>defined, and do one of:

>>1. ask user if theclass should be created automatically, then and there,
>>in a skeletal manner, at least so the thigns exists.

Modal dialogues like this are a big problem in html (they can't be done,
you have to fake it somehow).  There are lots of things that would
be better with a pop-up mouse-y-or-n-p, but you can't do that.  This
is the price we pay for using HTML as out delivery medium.  We're
content with this design decision.  There are lots of cons, and lots
of pros.

>>2. put it on a list of things TODO that the user has access to.

But what if the constraint you are violating causes the underlying
system to be unable to make any more inferences?  I don't think
that it's too hard to envisage a state where you've asserted so many
contradictions that the system is so screwed up that it can't even
give you any good hints about how to fix things up.




Rice.