[seek-kr-sms] property restrictions in growl

[Serguei Krivov]

> In a graphical editor such as GrOWL, I don't think as a user, I would
> want to necessarily have to follow OWL to construct a model. If I draw
a
> line between two classes, name it, and give the property restrictions,
> then that should both create the property and the restriction ... or
> maybe I am missing something. Also, some "restrictions" are defined at
> the property-level and some per class -- but as a user, you shouldn't
> have to worry about these two "modes".
>

Shawn is raising a very important user interface issue.  Right now, the
user
interface of GrOWL, like the Protege OWL plugin, is very close to OWL.
Typically, one operation creates one OWL entity, so you create a
property as
one operation, and a restriction on the property as another operation.
Shawn gives an example in which a series of operations that create
multiple
objects in the graph model could usefully be combined into a single user
action.  One future step in developing GrOWL should be to identify
sequences
like this and represent them as primitive operations in the user
interface.
I think of the current user interface as analogous to programming in
assembly language.  It is useful and a necessary step on the way to a
higher-level user interface, rather than the final word on OWL browsing
or
editing.


Rich, I agree that current growl closely reflects owl syntax and I
certainly far from thinking that current growl is the last word on
browsing in editing and perhaps something could be made easier. As one
example - we can allow defining restrictions without drawing node for a
property- which we were basically discussing.  But could we bring up one
or two more examples where we could pack  more then two owl constructs
in one graphic operation which would allow us to eliminate some
elementary operations in gui??   Personally I would be happy to see a
high level editing primitive to which current growl is  like an assembly
language for C, but frankly, I doubt that any   simplifications on this
scale could be done. Something could be made easier. In some cases we
could use graphic maps about which Ferdinando and I were thinking for
sometimes, but those maps will simplify only editing of a specific
domain ontologies - say ontologies that describe stock-flow models.  For
other domains we need other maps. But, none of the maps would  make
existing operation redundant.  I apologize for my skepticism and you may
also understand that it is natural, since I spent a lot just for
thinking on how to make the simplest possible gui. But on the other hand
I also hope that when other people give a fresh look on current gui,
they may find the way to simplify it, besides suggesting better icons.
Please try!

Cheers,
serguei