[seek-kr-sms] GrOWL- Graphic OWL

Tue Feb 3 08:35:35 PST 2004

Rich,
Thanks for your extensive set of remarks. The following were specially
valuable for me:
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 Protégé 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.  

OK , this leads to an important revelation:
In context of conventional OOP (F-Logic) the following is very
"Plain Notation":

Class SLR (
  is subclassOf Camera
  Attribute  viewfinder hasValue  ThroughTheLens
)

Instead of saying this that plain OWL user has to use either
UglinesType#1:

Class SLR (
  is subclassOf Camera
  is subclassOF Restriction(         //some anonymous class that has
    Attribute  viewfinder hasValue  ThroughTheLens
  )
)

or UglinesType#2:
Class SLR (
 is SameAS
 Intersection(
   Class Camera
   Restriction(
        Attribute  viewfinder hasValue  ThroughTheLens
   )
  )
)

I do not really understand why OWL designers found it so necessary to
resort to such ugliness. Probably it was a way to keep track of DL
semantics. But result is that Intersection, just as SubclassOf has been
widely misused in OWL as the complex way to say the things which are
extremely plain in conventional OOP such as F-Logic! OK then, if GrOWL
already converts UglinesType#1 to the "Plain Notation" (see attr body of
LargeFormat class)  then it can also convert the equivalent
UglinesType#2 to the "Plain Notation". This would get rid of many
intersection signs which presently appear in rendering of something like
wine ontology. They will still appear in those places when they are used
rather then misused.  And I think this idea was already proposed in
previous Rich's mail, but it took me a week to just realized that
intersection operator has been commonly misused in owl, and hence it
really need special, non regular treatment to make it's meaning clear
when it is misused. 

serguei

Serguei Krivov, Ph.D. Gund Institute for Ecological Economics,
University of Vermont; 590 Main St. Burlington VT 05405
phone: (802)-656-2978

-----Original Message-----
From: seek-kr-sms-admin at ecoinformatics.org
[mailto:seek-kr-sms-admin at ecoinformatics.org] On Behalf Of Rich Williams
Sent: Tuesday, January 27, 2004 11:18 AM
To: seek-kr at ecoinformatics.org
Subject: RE: [seek-kr-sms] GrOWL- Graphic OWL

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 defined.

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 Protégé 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.

Rich
-----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:
http://ecoinformatics.uvm.edu/dmaps/growl/growl.zip

Make “growl” directory and unzip the files there. To run, cd to growl
directory and use: 
java -cp
GrOWLBrowser.jar;api.jar;impl.jar;logger.jar;rdfapi.jar;rdfparser.jar
org.ecoinformatics.seek.growl.editor.GrowlEditor

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