frames and logic

• Mail folder: SRKB Mail
• Next message: bwilliam@parc.xerox.com: "Function vs Behavior"
• Previous message: Tom Gruber: "notes from Knowledge Representation Standards Workshop"

Message-id: <2854699377-59887@KSL-Mac-69>
Date: Mon, 18 Jun 90  05:02:57 PDT
From: Tom Gruber <Gruber@sumex-aim.stanford.edu>
To: Summer Ontology Project <shared-kr@sumex-aim.stanford.edu>
Subject: frames and logic

One of the strategies for getting a shareable ontology is to stick to
declarative representations, and keep symbol level organization separate
>From epistemological status.  That's why we're going to try to use the
evolving KIF proposal for encoding the ontology.  (Don't worry about
getting things in KIF format until the ontology and models mature a bit.)

One effect of this is that KIF is not a frame system, so it's missing a
lot of the representational primitives many of us have grown up on.
In this short note I'll describe the types of "terms" that can show up
in the ontology, and offer some guidelines.

CLASSES - logically equivalent to unary predicates (called "object
constants" in KIF and "concepts" in LOOM).  Written as a predicate of
objects; also talked about as a set that has instances.  

     Example: the class "physical-object" is the set of tangible,
concrete things such as pieces of metal, fully-assembled motors, etc.
(but not things like force or energy).  The statement "(physical-object
leftover-Oreo-3)" is true, as is "(=> (cookie x) (physical-object x))".

     Guidelines: Declare a class before using it.  Describe the known
superclasses (supersets) and subclasses (subsets).  If a class is
completely defined -- necessary and sufficient conditions for class
membership are known -- then write them down with the class and mark
them as its definition.  If you know that two classes are mutually
disjoint, or if you can provide a set of classes that completely
partition a superclass, write it down.

RELATIONS - logically equivalent to predicates of arity 2 or more
(called "relation constants" in KIF, "roles" in LOOM for the binary case). 

     Example: "(connected-to funny-bone-2 elbow-2)".  

     Guidelines: If the range or domain a two-place predicate is
restricted to a singleton set, then the same knowledge is represented as
a function.  For instance, one could say the same fact with a function
"(= (biological-father Gilligan) Harry)" or a relation
"(biological-father Gilligan Harry)" The latter allows many-to-many
relationships and makes it possible to represent the the inverse of
biological-father implicitly.  The drawback is that you have to bind
a variable for each "function call".

FUNCTIONS - logical functions, return objects (single values).
("Function constants in KIF", "Roles" or "methods" in LOOM.) 
Functions are of fixed arity.  Functions have domains and ranges that
are classes.  These classes may be defined by expressions or may have
already been named.

     Examples: the function "absolute-value" takes one argument.  It's
domain is the class "number" and its range is the class of the positive
numbers that are > 0.

     Guidelines: Use functions of one argument where you normally think
of slots of objects.  Functions can be defined extensionally (you give
each I/O pair) with forms like "(= (front-fender red-miata-4230)
fender-23423)".  If you use the inverse of the function, just say "(=
(inverse-function '+) '-)" and we'll work out the details.  If you know
whether the function is one-to-one, onto, etc., say so.

METACLASSES, METARELATIONS - heuristic-level organizations of knowledge
about classes and relations.  (KIF has mechanisms for rolling your own
using QUOTE.  I don't know about LOOM, but I bet there's something.  Cyc
has tons of metalevel objects and relations, since every class and
relation is itself an object with slots.  Examples include the genlSlots
and specSlots relations, the "***Type" collections.

     Examples: relation "types" such as part slots, connection slots,
modelled behavior types, slot subsumption.

     Guidelines:  This is still not worked out.  When inventing
relations like "part-of", try to name them as specifically as possible
(e.g., bond-graph-connection) and then say what type of relation it is
(from the shared ontology).  It may be possible to just classify
relations by their domains and ranges.