[seek-kr-sms] GrOWL- Graphic OWL

Rich Williams rwilliams at nceas.ucsb.edu
Tue Jan 27 08:18:09 PST 2004

Here are some issues that jump out at me.  Hopefully this will provoke
further discussion.  In general, OWL has a complex syntax, and many
ontological structures have more than one syntactic expression.  Right now,
ontobrowser is very close to the OWL syntax.  To be a user-friendly tool, it
needs to display commonly used constructs as simply and intuitively as
possible, while retaining the ability to get 'close to OWL' to permit
experienced users to access the full richness of the OWL language.  One way
to facilitate this would be to target GrOWL as a Protege plugin (yes, you've
probably heard me say this before!).  In this environment, GrOWL would
provide a broad overview of the ontology while the very rich Protege user
interface would facilitate detailed editing of OWL classes and properties.

On to issues in the current graph representation:

SLR is defined as the intersection of the Camera class and a restriction on
the value of the viewfinder property.  Without any further interpretation of
this definition, I think the display could be improved by labeling the
restriction class node with 'Restriction' rather than 'Anonymous'.  I think
this relabelling could sensibly apply to every place a restriction is

That being said, some fairly simple interpretation of the OWL code could
result in a clearer graph.  There are two components in the SLR definition
statement, a reference to the Camera class and a restriction.  This could
easily be converted to two subclass statements, one on the Camera class and
one on the restriction.  If this converted structure was displayed, I think
the graph would be more informative.  Note that the Protege OWL plugin
allows the user to move definition statements to subclass or restriction
statements and vice versa.  This reflects the fact that there might be other
circumstances where a class definition based on intersection of various
classes is the way the user is thinking about things.

The commonly used union in domain and range statements needs to be
suppressed from display to the user and instead be implicitly included by
the structure of the graph.  The onProperty part of a restriction
essentially locally extends to domain of the property to the class that the
restriction is subclassed from.  As much as possible, equivalent concepts
should be display equivalently, even when the OWL syntax has multiple
terminologies.  Other examples include the global range of a property and
class-local 'AllValuesFrom' restriction, which I think should look the same,
and the global FunctionalProperty and local cardinality = 1 restriction.

Another UI issue that needs to be addressed is how to display properties
given that a many classes can 'have-a' single property, expressed either
through the property domain statement or the restriction onProperty.  I
think that the property node should be repeated at each class that the
property is attached to.  In many cases, I think the details of the
restriction should be displayed in a 'detail' pane rather than within the
graph itself.  This might be too far outside the ontobrowser idiom of "the
graph is the knowledge model".  On the other hand, the ontobrowser knowledge
model already includes some things within relation nodes, like cardinality,
that are restriction classes (and therefore arguable separate graph nodes)
in OWL.

The physical layout of the graph is heavily influenced by the presence of
the shared nodes (string or float) attached to all the DataTypeProperty
nodes.  I'm not sure that the graph should display the type of
DataTypeProperty nodes.  Instead, these types could be displayed in a
'detail' pane when that node is selected.  If they are displayed in the
graph, I think they should be duplicated rather than shared across nodes.
This would permit some freedom in laying out the graph nodes that could
become more important in large graphs.

I find it hard to trace the class hierarchy, as the hierarchical structure
is not clearly reflected in the placement of the class nodes.  I wonder
whether explicitly including the grounding class (owl:thing) in the class
hierarchy graph would make things clearer.

Class nodes and instance nodes instances look the same.  I think they should
be differentiated by more than the extra : in the is-a link.  Perhaps the
instance nodes should have a different background color.  I also wonder
whether the is-a: and is-a:: is too subtle a distinction, and instead is-a:
should be instance-of or the like.

A minor detail - on my monitor, the combination of blue property node and
black text is hard to read and I couldn't find a way to change it.


  -----Original Message-----
  From: seek-kr-sms-admin at ecoinformatics.org
[mailto:seek-kr-sms-admin at ecoinformatics.org]On Behalf Of Serguei Krivov
  Sent: Friday, January 23, 2004 12:15 PM
  To: seek-kr at ecoinformatics.org
  Subject: [seek-kr-sms] GrOWL- Graphic OWL

  Rich, I, and Ferdinando have started discussing the problem of graphic
format for owl . We came to a set of issues which require wider discussion-
the issues which are of concerns for users, rather then for developers. I
would invite you to download the pre-pre-beta growl editor at:


  Make "growl" directory and unzip the files there. To run, cd to growl
directory and use:

  java -cp

  There is a batch file for Windows. There is one ontology camera.owl which
editor shows as intended. Many complex ontologies it does not show
correctly, no editing supported at this point, but this does not matter. At
this point we need to find a nice format for anonymous cases , unions,
intersections ,and other things. Please compare camera.owl with its graphic
representation and let me know what you think. On Tuesday-Wednsday, or so I
will compile the set of issues we have and then consider the alternatives we
have, so that you all  may advice us to choose the least evil one, or even
find a good one.

  Serguei Krivov, Ph.D. Gund Institute for Ecological Economics, University
of Vermont; 590 Main St. Burlington VT 05405

  phone: (802)-656-2978

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

More information about the Seek-kr-sms mailing list