NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/ai/4982

Internet Message Format | 1993-01-24 | 5.5 KB

Path: sparky!uunet!olivea!hal.com!decwrl!ads.com!marcel
From: [e-mail] (Marcel Schoppers)
Newsgroups: comp.ai
Subject: subsumption code
Summary: free source code wanted
Message-ID: <[e-mail]>
Date: 24 Jan 93 00:45:05 GMT
Sender: Marcel Schoppers
Distribution: na
Organization: Advanced Decision Systems, Mtn. View, CA [phone]
Lines: 109

This message contains two parts:

1. a request for info about FREE or PUBLIC DOMAIN source code in C or C++
   for terminological (subsumption, KL-ONE) reasoning ?  I don't need a
   complete system, just the classification/subsumption code would do.

2. answers received to my previous request for such capabilities in PROLOG:


> From [e-mail] (Adrian Mueller)
>
> E-S (Entity-Situation) KRS, impl. by CIOC-CNR, has T-Box, A-Box, realizer
> runs un Quintus, ESIL's, PROLOG-2 or C-Prolog.  Contact (Adress 2 years old):
> Stefano Lodi, [e-mail]
>
> ITL, by LADSEB-CNR, has term. reasoning and relat. KB, runs under
> LPA-MacPROLOG.  Contact (again, 2 years ..) :  Nicola Guarino,
> [e-mail]


> From: [e-mail] (Ron Brachman)
> ...  People at Unisys once upon a time had a system called KNET that was
> implemented in Prolog - Martha Palmer was one of the key people on this.
> However, Martha has gone off to Singapore, and I believe the whole group
> doing this work moved to a new part of Unisys called Paramax.  You could
> try getting in touch with, for instance, Don McKay.  His net address appears
> to be [e-mail].
>
> Alternately, you could contact people at DFKI in Germany (e.g., Franz Baader)
> about the KRIS system.  This is a complete, tableau-based inference system
> based on a pretty general description/terminological logic.  I am pretty sure
> it is implemented in Prolog.


> From: "Ullrich Hustadt" <[e-mail]>
> We have implemented an knowledge base system called MOTEL based on the
> concept language KRIS [BaaderHollunder90] here at the Max-Planck-Institute
> for Computer Science. The system itself is implemented in PROLOG (Quintus
> Prolog, SICStus Prolog). It takes some knowledge base and translates it into
> PROLOG clauses.  All reasoning (subsumption, ...) is done using the query
> answering mechanism of PROLOG.  Although it an prototypical implementation,
> it might be interesting for you.
>
> MOTEL is available via anonymous ftp from mpii02000.ag2.mpi-sb.mpg
> (139.19.20.1):/pub/tools/motel.tar.Z
>
> This compressed tar-file contains the MOTEL sources (one PROLOG file) and the
> user manual (one dvi file). If you have any problems getting the system or any
> questions concerning MOTEL you can send me an e-mail message.


> From: Barbara Di Eugenio <[e-mail]>
>
> Hi Marcel. Here are some notes on what I find frustrating about BACK: I
> haven't found any real major flaws, but mainly an unfriendly interface, plus
> some shortcomings. ...  I contrast it with CLASSIC, which has been developed
> at AT&T in Lisp.
>
> 1) From an expressivity point of view, it doesn't have SAME-AS restrictions
> on role paths like CLASSIC, which I find very useful because I need to
> express coreference. I am using Jackendoff's Conceptual Structures for
> Lexical Semantics of verbs. For example, he uses a primitive "GO" that is
> modified by semantic fields such as "Spatial, Control, Possession". "GO" has
> as an argument a "path": paths are concepts in themselves and analogously to
> "GO" can be of semantic type "Spatial" etc. Now, when I define a "GO", I want
> to say that the filler for the "semantic-field" on "GO" is the same as the
> filler for the "semantic-field" on the filler of the "path-role" on "GO".
> This doesn't seem to be possible in BACK.
>
> 2) One (minor, I think) flaw I found: BACK doesn't distinguish between roles
> that are not defined on a certain concept, and roles that are defined, but
> left unspecified on the instances of that concept. For example, suppose we
> have defined a role "manner" on the concept "action", which is disjoint from
> "animate" and "inanimate".  If now we give the query "give me the pairs
> <entity-manner>", which is as follows:
>
> | ?- aa(T = [self,rf(manner)] for getall entity).
>
> we get something like
>
> T = [[bob,_13102],[s1,_13082],[a1,cc],[a2,cc],[a3,_12892]]
>
> where "bob" is a "human", "s1" a "screw", and a1, a2, a3 are actions.
> CLASSIC instead would give a warning for "bob" and "s1".
>
> I think the flaw is minor in the sense that it is simply the search procedure
> on the individuals that doesn't filter out the individuals on which "manner"
> is not defined.
>
> 3) From the point of view of interacting with the system, there is no real
> manual --- there are several Tech. Reports which describe the TBox and Abox
> Tell and Ask Languages, but the precise syntax of several commands has to be
> "discovered" on the fly. The manual was supposed to come out last fall, but I
> got no news of it, and no reply to my message asking about it.
>
> The user interface is bad. For example, the query to the T-Box for the
> description of a concept is
>
> tbox_ask(describe(concept-name,Var))
>
> but the query to the ABox for the description of an individual  is
>
> abox_ask(Var = describe individual-name)
>
> Clearly this is not a major problem, and not one that couldn't be easily
> solved by writing a little routine.  However, I wish *they* had written the
> routine!!! and in general had adopted a more transparent syntax for their
> commands.  Sometimes the syntax of the queries is somewhat baroque, as the
> query above about "manner" shows.