ontolingua extension
Tom Gruber <Gruber@sumex-aim.stanford.edu>
Full-Name: Tom Gruber
Message-id: <2870721618-179057@KSL-Mac-69>
Date: Thu, 20 Dec 90 14:40:18 PST
From: Tom Gruber <Gruber@sumex-aim.stanford.edu>
To: ontolingua@sumex-aim.stanford.edu
Cc: Elaine Rich <ai.rich@mcc.com>
Subject: ontolingua extension
Hi,
There has been a bit of disjointed work going on using ontolingua.
Let me encourage you to post ideas and results here. Pang, who is now
somewhere in Singapore doing military service, has written this
somewhat abtuse document about his work, which I will post to this
list when I can find the .tex version.
In what follows, I practice what I preach. Comments are encouraged.
One idea I am considering for a direction to take the ontoligua is to
reify Cyc's notion of "inference features" (or is it "mechanism"?) to
capture, in a system-general way, what inferences will go fast in the
underlying implementation. KB builders (as opposed to knowledge
enterers) need to think about the inferences sanctioned by and ro be
produced by a KB. The keywords like :default-implies and :definition
sort of suggest that the feature is supported; similarly, the
second-order relations are meant to capture schematic inference that
can be special cased by implementations. So the value of the OL would
be to capture these assumptions explicitly. For example, if a KB uses
a second order relation INVERSE, then the writer assumes that inverses
are maintained efficiently and automatically. If a KB uses
:default-implies, then it is assumed that inheritence through
all-instances will work efficiently.
Another, orthogonal extension that I have already prototyped is to
allow :slot-values, :default-slot-values, and :inherited-slot-values
keywords that translate into :definition, :implies, :second-order,
etc. This lets us retain the frame look and feel.
tom