tip for interfacing ontolingua to graphers

• Mail folder: Ontolingua Mail
• Next message: Wouter Jansweijer: "Shape and spatial relations ontology available?"
• Previous message: Ronny: "multiple inheritance in ontolingua"

Message-id: <199405251001.DAA18368@HPP.Stanford.EDU>
X-Sender: gruber@ksl.stanford.edu (Unverified)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 25 May 1994 03:01:29 -0800
To: ontolingua@HPP.Stanford.EDU
From: Tom Gruber <gruber@HPP.Stanford.EDU>
Subject: tip for interfacing ontolingua to graphers

Several people have inquired about graphers for drawing pictures of
hierarchies and such in ontolingua.  The short answer is, the best place to
couple a grapher or other browsing tools is a representation system or
database; ontolingua is intended to help translate ontologies into those
systems.

However, now that ontolingua performs a documentation service, it might
make sense to generate pretty graphs of binary relations such as
subclass-of, instance-of, subpart-of, etc.

Peter Karp has already announced the grasper system to this list.  It is a
sophisticated UI tool based on graph structures.  If you have grasper, you
can view ontolingua ontologies without any extra coding.  However, some
groups are building their own tool kits, or integrating ontolingua into
existing workbenches.  If that's you, I suggest that you use the GFP access
functions to couple your program to ontolingua, rather than translating
into something like Loom or CLIPS first and then drawing the graphs.  This
is because the generic frame implementation ontolingua is a deliberate
generalization over frame systems and is designed to tolerate KIFishness
(order independence, undefined frames) that specific systems may have
trouble with.  It also offers a migration path to other object systems.

How does one use the GFP access from Ontolingua?
  1. set the implementation to :generic-frame with the command
     (ol:in-implementation ':generic-frame)
     -OR-
     bind the variable ol:*implementation* to ':generic-frame
     while doing the next step.
  2. Load your ontolingua ontologies using OL:ONTO-LOAD (in most
     lisps, LOAD is modified (advised) to be the same as onto-load,
     but onto-load is a sure thing).
     -OR-
This will cause ontolingua to store the ontologies in generic frame format.
  3. GFP functions take a KB argument, which is supposed to be a CLOS
     instance of the GFP::KB class.  Ontolingua's generic frame theories
     are suitable as GFP::KB objects.  To get the GFP KB associated with
     an ontology, call
      (ol:find-theory 'your-theory-name ':generic-frame)


One more piece of information.  On the Loom mailing list, the issue of
graphers also came up.  Here's the advice of someone who has put one
together with Loom.

Date: Sun, 24 Apr 94 22:10:03 PDT
From: rouquett@aig.jpl.nasa.gov (Nicolas Rouquette)
To: loom-forum@ISI.EDU, tar@ISI.EDU, voksarun@cadlips.ece.utexas.edu
Subject: Re:  grapher..

Depending on what you want out of a grapher, you
may try several other options.

- garnet (works on most lisps)
- the lispview grapher (only on Lucid CL + lispview1.1)
- clm (not clim) available from ftp.gmd.de.
- Allegro CL composer (undocumented but is really fast)

Since graphers come and go like ice cream flavors, I recently settled
on the approach of miminal hacking effort to get the functionality I need.
allegro composer is the best return on a short time investment I've
made in that area even though their grapher is undocumented.

-- Nicolas.