From: Marc Dzaebel
Subject: Knowledge Representation with CLOS
Date:
Message-ID: <362F3062.4D17027B@rose.de>
Barry Margolin just mentioned two representational constructs:
- IS-A (subclass, kind-of, type-of ...)
- HAS-A (consists-of, comprised, part-of ...)
In my view, it's essential for CLOS programmers to know about how to
model/realise these and more basic relations. Unfortunately, Sonya
E.Keene's book is more a reference on how CLOS works rather than a clear
problem/solution mapping. I think we have to look in the domain of
knowledge representation (also Knowledge Interchange Format) and figure
out what tasks are the most important ones. There are certainly more
typical requirements which should be gathered and extended with solution
approaches. If someone has a proposal on how to organize such a 'Guide'
I would very much like to hear it.
E.g. some constructs from 'Wordnet' are:
is-a-component-part-of, is-a-member-of, is-the-stuff-of ...
E.g. CLOS supports the relation 'dependant-of' etc.
Many research areas like NLP, KR(Ontologies), CYC, LOOM, Conceptual
Graphs etc. may give us input to the obove mentioned questions.
Marc
In article <·················@rose.de>, Marc Dzaebel <····@rose.de> wrote:
> Many research areas like NLP, KR(Ontologies), CYC, LOOM, Conceptual
> Graphs etc. may give us input to the obove mentioned questions.
We use CLOS for KR (at least for now) in our project:
http://www.mcc.com/projects/I3S/
While the details of how our project encodes ontology are proprietary, a
good place to start is with the CLOS back end of OKBC:
http://www-ksl-svc.stanford.edu:5915/doc/release/okbc/index.html
There are back ends to all kinds of KR systems available in various states,
including LOOM, CYC, ... so you can use the OKBC interface initially to a
CLOS representation, and later switch to something that does more
inferencing for you.
--
Bradford W. Miller
(I have a job, but you're talking to me)
Disclaimer: There are no states, corporations, or other pseudo-individuals.
There are only people. Justify your actions without resorting to your
orders.
"Unlike me, many of you have accepted the situation of your imprisonment
and will die here like rotten cabbages."
- Number Six's speech from "Free for All" _The Prisoner_
From: Marc Dzaebel
Subject: Re: Knowledge Representation with CLOS
Date:
Message-ID: <3634662E.6E6FB935@rose.de>
Gorbag wrote:
> We use CLOS for KR (at least for now) in our project:
> http://www.mcc.com/projects/I3S/
As I said in the previous posting, intuitive/adaptable interfaces to
computers are certainly a key to future applications.
> There are back ends to all kinds of KR systems available in various states,
> including LOOM, CYC, ... so you can use the OKBC interface initially to a
> CLOS representation, and later switch to something that does more
> inferencing for you.
>
> Bradford W. Miller
Hi,
Yes, I already know quite a bit about the KSL. Could you give me your
mail address?
Thanks in advance
Marc
Marc Dzaebel <····@rose.de> writes:
> Barry Margolin just mentioned two representational constructs:
>
> - IS-A (subclass, kind-of, type-of ...)
> - HAS-A (consists-of, comprised, part-of ...)
>
> In my view, it's essential for CLOS programmers to know about how to
> model/realise these and more basic relations.
The problem is that object-oriented languages are too wimpy for doing
anything but the most small and trivial knowledge representation
tasks. Trying to cram the knowledge structure into the programming
language structure tends to lead to wacky and useless KR systems.
There a number of reasons for this. I'll use CLOS as an example, but
the same critique applies elsewhere.
o CLOS limits you to two binary relations, instance and class. These
relations is great for implementing concepts like element-of and
subset-of, but a lot more is needed for doing useful KR work. Dzaebel
mentions is-a-component-part-of, is-a-member-of, and is-the-stuff-of.
It goes much further: Almost any transitive verb suggests another
useful relation: to own, to cause, to like, etc.
o It is difficult to express the inverses of relations. Most of the
machinery goes along TYPEP and SUBTYPEP lines. TYPE-OF is a poor
cousin, and there is no analogous SUBTYPE-OF.
o The instance relation is single-level modulo MOPpery.
o You can't express non-binary relations. For example "X gives Y to
Z."
o The class relation is transitive and antisymmetric. It is difficult
to handle intransitive or symmetric relations.
> E.g. some constructs from 'Wordnet' are:
> is-a-component-part-of, is-a-member-of, is-the-stuff-of ...
Wordnet is a good example of using more than just a couple of
relations. It is also a good example of why it is bad to limit the
number of relations a priori and not to allow for multiple
inheritance. For example, Wordnet has "puppy" isa "young mammal."
This is not to say that CLOS is not useful for building KR systems.
Far from it. CLOS is great for building the structures upon which the
system rests: indexing of terms, procedural interactions, etc. It is
just that it is a mistake to try to use the relational infrastructure
directly. The "object-orientedness" of CLOS is not the one to use for
KR systems.
--David Gadbois
From: Marc Dzaebel
Subject: Re: Knowledge Representation with CLOS
Date:
Message-ID: <3634608E.417FD995@rose.de>
David Gadbois wrote:
> Marc Dzaebel <····@rose.de> writes:
> > Barry Margolin just mentioned two representational constructs:
> >
> > - IS-A (subclass, kind-of, type-of ...)
> > - HAS-A (consists-of, comprised, part-of ...)
> >
> > In my view, it's essential for CLOS programmers to know about how to
> > model/realise these and more basic relations.
>
> The problem is that object-oriented languages are too wimpy for doing
> anything but the most small and trivial knowledge representation
> tasks. Trying to cram the knowledge structure into the programming
> language structure tends to lead to wacky and useless KR systems.
Yes, this is certainly true. But we often have problems that are at
least near to KR. In this case it may be profitable to consider tools
like CYC. However, there may be cases where such a powerfull approach is
oversized. For these, we should have some workarounds for the most
important representation tasks.
> There a number of reasons for this. I'll use CLOS as an example, but
> the same critique applies elsewhere.
>
> o CLOS limits you to two binary relations, instance and class. These
> relations is great for implementing concepts like element-of and
> subset-of, but a lot more is needed for doing useful KR work. Dzaebel
> mentions is-a-component-part-of, is-a-member-of, and is-the-stuff-of.
> It goes much further: Almost any transitive verb suggests another
> useful relation: to own, to cause, to like, etc.
May be a concept like 'transitive-verb' could help in all of the obove
mentioned relations? However, your input is very exiting for me as I'm
rather a beginner to KR. What links would you recommend for a good
introduction?
One question, I would think that speed slows down the more general a
system is. Is this true for CYC?
> o It is difficult to express the inverses of relations. Most of the
> machinery goes along TYPEP and SUBTYPEP lines. TYPE-OF is a poor
> cousin, and there is no analogous SUBTYPE-OF.
Can't this simply be done by MOP-functions?
> o The instance relation is single-level modulo MOPpery.
Do you mean that you can't inherit from instances? May be I need an
example.
> o You can't express non-binary relations. For example "X gives Y to
> Z."
You mean e.g. if X,Y,Z are classes/concepts you can't simply put them
together in a superclass-list. You will probably realize it via Schanks
Conceptual Dependancy theory, but this what results in an action-class
with slots: object, action, actor, means etc..
> o The class relation is transitive and antisymmetric. It is difficult
> to handle intransitive or symmetric relations.
Correct.
> > E.g. some constructs from 'Wordnet' are:
> > is-a-component-part-of, is-a-member-of, is-the-stuff-of ...
>
> Wordnet is a good example of using more than just a couple of
> relations. It is also a good example of why it is bad to limit the
> number of relations a priori and not to allow for multiple
> inheritance. For example, Wordnet has "puppy" isa "young mammal."
>
> This is not to say that CLOS is not useful for building KR systems.
> Far from it. CLOS is great for building the structures upon which the
> system rests: indexing of terms, procedural interactions, etc. It is
> just that it is a mistake to try to use the relational infrastructure
> directly. The "object-orientedness" of CLOS is not the one to use for
> KR systems.
>
> --David Gadbois
I think your comment is really remarkable. We definitely need more
intuitive interfaces to programming languages and applications. I would
personally be interested in the basic new modeling concepts of CYC, but
this goes beyond the scope of comp.lang.lisp.
Thanks again for your response
Marc Dzaebel
Marc Dzaebel <····@rose.de> writes:
> [...] But we often have problems that are at least near to KR. In
> this case it may be profitable to consider tools like CYC. However,
> there may be cases where such a powerfull approach is oversized. For
> these, we should have some workarounds for the most important
> representation tasks.
Sure. For things that have a relatively limited ontology like, say, a
window system, then by all means use a simpler modelling system. But
when I hear "KR", I assume bigger fish are being fried.
[...]
> One question, I would think that speed slows down the more general a
> system is. Is this true for CYC?
I'd put it the other way: If you limit the expressiveness of a
system, there are all kinds of optimization tricks you can play to
make some searches go fast. But in any generally useful system, there
will be areas where computations go off into exponential weeds. The
tricks are balancing the expressiveness/speed trade-off and being
ready with clever hacks when the balance inevitably tips to the
expressiveness side.
> > o It is difficult to express the inverses of relations. Most of
> > the machinery goes along TYPEP and SUBTYPEP lines. TYPE-OF is a
> > poor cousin, and there is no analogous SUBTYPE-OF.
>
> Can't this simply be done by MOP-functions?
Well, sure, in some Turing-tarpit sense. Note that I am just making
the simple point that the immediate representation infrastructure in
CLOS is not enough to do heavy-duty KR.
--David Gadbois