Re: [lojban] Lojban as a prolog interface ?

[Brook Conner <me@nellardo.com>]

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!