[seek-kr-sms] growl issues

[Rich Williams]

Serguei's questions:

1) Would it be more intuitive to use a separate color for datatypes , data
properties and data property restriction , so that user does not confuse
them with classes, object properties, object property restrictions

Ideally, colors will be configurable.  The question is how much granularity
to give the users when choosing colors.  I think it'd be good to separate
nodes into groups like you suggest, and so at least allow different colors
for "object nodes" (classes, object properties, etc) and "data nodes"
(types, data properties etc).

2) How to render relations with no explicit domain and/or range? The current
version does not show them at all and this may be not the best idea. Should
we use owl:Thing node as a default domain, range when explicit definition is
absent? Should we show naked relation node with no domain and/or no range?

When editing, you create a property and then set its domain and range by
drawing links.  Seems like if someone saves when a property exists but has
no domain or range set, you want to be able to reload that file and allow
them to continue editing where they left off.  And to set the domain and
range, they need to be able to see the property.  So I vote for showing the
property even if it has no domain or range.

3) In current version the format of restriction is as follows
PropertyName.RestrictionSpecification. where RestrictionSpecification. Could
be universal or existential quantor or cardinality constraint. May be we
should put it the other way  RestrictionSpecification.PropertyName so that
it looks similar to DL notations?

 I could go either way on this, not being particularly attached to any
particular DL notation.


On the question of a table view - I think we should experiment with the
idea.  The graph view will certainly be a problem if there are a lot of
instances.

Finally, here are more extensive comments in response to Serguei's main
question of "What prevents you from using GrOWL as your only OWL editor?"



I see the current version of GrOWL as an interesting prototype and proof of
concept.  For it to become my ontology editor of choice, significant user
interface improvements are needed when both browsing and editing.  In its
current incarnation, sometimes it provides a very helpful display of an
ontology (or part of one), while at other times I find it utterly confusing.

Ontology Browsing



The current GrOWL is basically unusable with the large ontologies that I
have been developing.  I find that I am better able to get an overview of
the class hierarchy using Protégé’s expandable/collapsible indented list of
classes than with the GrOWL class view.  I find navigating a large ontology
very difficult.  A “GoTo” command with an alphabetical class list might be
useful.  Having a hierarchical or alphabetical class list in a pane next to
the graph view might be useful.



Here are a few layout and navigation comments and ideas:



1)      Allow more control over which nodes are shown and which are not than
the current “radius from selected node” idiom

2)      Have the ability to expand along paths through the graph without
changing the current selected node, which acts as the “rendering focus”.

3)      Have options to display using “radius from node” or “along a path”
in which the directionality of the links is considered and so expansion only
moves along “upstream” or “downstream” links.

4)      Have the ability to have more than one “rendering focus”

5)      When there is more than one “rendering focus”, have the ability to
search for paths between the different sections of the ontology.

6)      Allow the class hierarchy to be grounded (connected to owl:Thing) to
it doesn’t display as multiple disconnected subgraphs

7)      Improve Touchgraph’s behavior when there are multiple disconnected
subgraphs

8)      Have multiple layout options for the graph – for example a tree-like
layout sometimes makes a class hierarchy clearer.

9)      Experiment with hierarchical layout algorithms in which for example
a class tree is produced with one algorithm and then fixed in place while a
different algorithm is used to add the properties, restrictions and axioms
to the class hierarchy



Ontology Editing


Serguei touched on the idea of allowing links to be dragged from existing
nodes into empty space.  I think that we can considerably simplfy the user
interface by making extensive use of this idiom..  In general, the idiom
will allow a relation node, a new object node and the connections between
them to be created with a single user operation.   I think these operations
can co-exist with the existing user interface, as they cause actions that
currently do nothing to perform an operation.  Here are a few examples:



Creating a subclass of an existing class


Current UI:



1)      Click on “Create class” tool

2)      Click on canvas to create a class (the eventual subclass)

3)      Click on base class

4)      Click and drag from base class to subclass



Proposal



1)      Click “Create Subclass relation” tool

2)      Click and drag from base class to open space– a subclass of the
selected class is created



Creating a class instance


Current UI:



1)      Click on “Create individual” tool

2)      Click on canvas to create individual

3)      Click on base class

4)      Click and drag from base class to individual



Proposal



1)      Click “Create Individual” tool

2)      Click and drag from a class into open space – an instance of the
selected class is created



Creating a Class Axiom About Two Classes


Current UI:



1)      Select class axiom tool (“Classes are disjoint” etc)

2)      Click on canvas to create class axiom node

3)      Click and drag from axiom node to first disjoint class

4)      Click and drag from axiom node to second disjoint class



Proposal



1)      Click on “Classes are disjoint” tool

2)      Click and drag from one class to another or click and drag from one
class to open space (in which case a class list pops up and the user must
select a class)



A few other UI issues/ideas:



When dragging from property to class to set range, if the property already
has a range of a single class, the UI could automatically create the “union”
node instead of just not allowing the second link to be drawn.  (The same is
true of domains).



Require restriction and object property value nodes to refer to an existing
property.  The user could be prompted for the property name during the
creation of the node.  The UI would allow the user to select the property
from a sorted list or type in a name.  If the user types the name of a
non-existent property, prompt the user and offer to create the property for
them.



I'm sure many other refinements will come to light as the UI is used more.



Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040826/f4d561da/attachment.htm