[Fwd: Re: [seek-kr-sms] ontology/folder UI design in Kepler]

[Serguei Krivov]

After Bertram has clarified the question about ontology related
operations in Kepler it is easy to reason about the GUI.  

Bertram>- Kepler should have mechanisms to *annotate* actors (as a
whole),
their ports, and datasets. This should normally NOT require changes to
the ontology. Rather one would simply *select* concept names from one
of possibly several pre-defined community ontologies (importing
different ontologies into Kepler should be easy)

SK> Coming back to the issues of "folder tree" versus some other
interface to ontologies-  for deciding this issue  it is important to
consider   what information from ontology is relevant during this
annotation process. Let's go down to matrixes and imagine the process: 

User has to select a concept X to annotate a port of an actor A. For
that he/she has to look at ready made ontology  which is already in
Kepler and make a selection. What he/she has to know about a concept in
order to select or not select it?  What "variables" related to concept
are relevant ?
1. Is position of concept in class hierarchy important?
2. Is possible multiple inheritance important?
3. Do roles (properties and properties restriction) come into picture?
Does user  need to know them to make a selection?
4. Does user need to see the set of instances of a given concept?
Other set of questions:
5. Does user have to see the other actors (besides actor A)during
selection process?
6. Does user have to see the semantic type of other actors?

Answers to questions  5 and 6 would dictate if concept selector work as
dialog or as a pane. The answer to   questions 1-4 would dictate the
type of ontology browser/selector. If only #1 has positive answer then
tree control is OK. While advocating to use something as GrOWL in
capacity of "concept selection dialog" (concept selection panel or
buffer) I presumed that answers to the questions 1, 2, 3 are positive.
If they are not positive then my suggestion is void. If they are
positive then what could be another viable alternative to GrOWL as
concept selector? (May be it is hypertext based Sparrow rendering of
assertions pertained to certain concept where user could click on a
concept and get all Sparrow statement related to it assembled in one
place. Perhaps it would be easy to make such dynamic generator of
sparrow statement based on Jena or GrOWL model. I will certainly include
one into GrOWL in a near future.)

In answering to the  questions 1-4 analogy with File selection, Color or
Font selection could be helpful. Is   it surprising that those dialog
become standard and looks almost alike in various C++ and Java
libraries? Perhaps it is not, because the set of "variables" or factors
that drive say file selection is almost always same  and good GUI is
merely a best possible response that allow to expose all these
"variables" to the user during selection. 

serguei