From me@nellardo.com Fri Jan 25 11:27:16 2002 Return-Path: X-Sender: me@nellardo.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_0_1_3); 25 Jan 2002 19:27:15 -0000 Received: (qmail 6700 invoked from network); 25 Jan 2002 19:27:15 -0000 Received: from unknown (216.115.97.167) by m9.grp.snv.yahoo.com with QMQP; 25 Jan 2002 19:27:15 -0000 Received: from unknown (HELO mail6.speakeasy.net) (216.254.0.206) by mta1.grp.snv.yahoo.com with SMTP; 25 Jan 2002 19:27:15 -0000 Received: (qmail 25128 invoked from network); 25 Jan 2002 19:27:14 -0000 Received: from unknown (HELO dsl027-135-047.nyc1.dsl.speakeasy.net) ([216.27.135.47]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 25 Jan 2002 19:27:14 -0000 Date: Fri, 25 Jan 2002 14:27:13 -0500 Subject: Re: [lojban] Lojban as a prolog interface ? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) To: lojban@yahoogroups.com Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <88FA3D3F-11C9-11D6-9015-003065B787D6@nellardo.com> X-Mailer: Apple Mail (2.480) From: Brook Conner X-Yahoo-Group-Post: member; u=66018878 X-Yahoo-Profile: nellardo On Friday, January 25, 2002, at 09:23 am, Invent Yourself wrote: > On Fri, 25 Jan 2002, Candide Kemmler wrote: >> I don't know much about prolog, but I think it'd be usefull to have >> prolog parse sentences Representing lojban sentences as a series of Prolog facts is generally straight-forward: lojban - mi klama do prolog - klama(mi, do). lojban - la'i datka cu citka lo nanba (The ducks eat some bread) prolog - la-i(datka). lo(nanba). citka(X, Y) :- la-i(X), lo(Y). There's a nice mapping between the lojban predicate and the prolog predicate and between the lojban arguments and the prolog arguments. I must sound like a broken record, now :-) because that is the easy part. >> and store them in a facts database possibly using >> RDBMS persistence. The stored facts could then be used to infer answers >> to specific questions. > This is a good direction to think in. But relational databases are > suited > for big tables of accounting data; RDBMS's are just fine for these kinds of strings. Consider the following schema: Predicate names - a list of unique strings, one for each predicate. "Facts" are name or gismu Argument lists - a list of pairs: the ID of a predicate and an integer of how many arguments are used. Zero args corresponds to a "fact" Arguments - a list of : the ID of the arg list this arg is for, the position of the arg, and the ID of the predicate making up the argument. But again, this is just a computer representation of the parsed lojban sentence. It has no intrinsic semantics. > what we need is at least an object > database, with classes of real things that have states and inheritance > relationships between them, or even better, build upon one of the > existing > such formats, such as KIF, or something based on RDF. Careful - Once you get into states and inheritance (which you can model just fine on an RDBMS (don't get me wrong - I'm all for OODBMS's)), you start getting into semantics and you'll get into trouble very easily. For one thing, many OO systems allow only single inheritance, making it cumbersome to model a person who is both a woman and a student. Mixins and multiple inheritance deal with this somewhat, but you still end up with classess like FemaleStudent and MaleStudent and FemaleOfficeWorker and MaleOfficeWorker. Furthermore, almost no OO systems allow instances to change their class once created (Self and certain graphics systems being among the few counter-examples). What happens when FemaleStudent graduates? Yes, you can model that by making Student part of the state rather than part of the inheritance, but then you lose the polymorphism of being able to make a Registrar class that only worries about Student. You quickly get into all sorts of ugly patterns like double dispatch and stuff like that. These are simple examples, and you can model around them (just as I modeled around the nature of a RDBMS), but the point is that the semantics (again, broken record) are hairier that they first seem. Brook who doesn't mean to scare people off, just to make sure people have a good heads-up on where the problems show up when designing programming languages and the like. -- Klactovedestene!