Re: Declare before use constraint in ontology editor.
Mike Uschold <mfu@aiai.ed.ac.uk>
From: Mike Uschold <mfu@aiai.ed.ac.uk>
Date: Mon, 20 Mar 95 17:24:01 GMT
Message-id: <8354.9503201724@subnode.aiai.ed.ac.uk>
To: rice@hpp.stanford.edu
Subject: Re: Declare before use constraint in ontology editor.
Cc: ontolingua@hpp.stanford.edu
> >I disagree with the design decision to force classes to be created
> >before referring to them.
> 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 agree! A careful, considered, methodological approach to ontology
building is a worthy goal. However, the relationship between this
design decision and this goal is tenuous, and in our case non-existant.
We spent several man-months of effort with many long meetings discussing
countless variations and finally deciding on a set of terms and their
definitions and documented this as a text version of our ontology. We
are now converting it into code.
In our case this design decision had no effect on its intended
aim, which already was achieved; instead it's only role is to
constrain the order in which things get done at the coding stage.
I regard this as a nuisance, preferring to choose when to code things
myself. I whole-heartedly wish to take advantage of the checking that
will go on, my point is that it should take place at certain
check-points, not always.
> >>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_.
Fair point; What I meant was that I want more freedom in what order I do
things.
> Obviously the ontology
> editor is a structure editor, not a text editor. It has the
> benefits associated such editors and the problems.
This is a fair point, you get nothing for nothing. In principle, I
think my suggestion can give the best of both worlds, enforcing the
constraints, but at checkpoints when it *really* matters, instead of
where you hope it will make a positive difference, but where it might
end up a pure nuisance instead.
> >>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.
Actually, I AGREE with you, if there really IS a logical inconsistency
that won't go away when I get around to finishing the ontology.
But that's not what I'm talking about.
Where there IS genuine religious disagreement, if you let people, choose
their own religion, you may have more happy users. People could click a
button at any time, to have the check done and warning messages issued.
Indeed, the system could be doing the checking all the time just as now
keeping track of what it thinks is wrong, and reporting it when asked.
This might be more work, as things would have to be removed when users
completed tasks.
An option in the Edit Preferences section could be added so users could
specify when the checking would take place. The system can choose to
enforce some checking at some key point that the user cannot override.
This would require some thought, to get it right, but should be possible
without undue effort.
> >1. ask user if the class should be created automatically, then and there,
> >in a skeletal manner, at least so the things 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.
Pity about this restriction, but I think it separate from my more
general suggestion to let users choose check points.
> >>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.
I do not see why a half-built ontology has to be viewed as a set of
contradictions! I see no need to worry about inconsistencies that only
arise because it is unfinished.
By all means, give warnings, notes, pointers etc to tell me what the
system things is very likely a potential problem, if left unattended,
but do not force me to do things in any particular order.
Your comment suggests something abut the underlying implementation. Are
you saying that after every command is completed, there exists some
manner of consistent logical theory? While this may have advantages, it
seems inappropriately strong. Why complain about inconsistencies with
something that is known to be unfinished?
Can you give some examples of states/situations where an unfinished
ontology in mid-development has to be logically consistent and if it is
not, then there are problems?
Mike Uschold