Re: [lojban] Lojban as a prolog interface ?

[Invent Yourself <xod@sixgirls.org>]

On Fri, 25 Jan 2002, Brook Conner wrote:

>
> On Friday, January 25, 2002, at 09:23  am, Invent Yourself wrote:
>
> > 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.


0 arguments is a "fact"? What is it a "fact" about?


>
> But again, this is just a computer representation of the parsed lojban
> sentence. It has no intrinsic semantics.


And do we keep these Prolog strings in one long table?



> > 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.



You're thinking about OO programming languages. Nobody would ever consider
modeling reality without multiple inheritance!

Now in terms of the graduation issue, it's true that finding the right
balance between a loose model and a structured model is tricky. It's what
I alluded to before: the loosest of all models would be a Map; nothing but
a bunch of name-value pairs representing the attributes of the object.
Similar to a database tables, but each object gets its own table and they
are related not by foreign key but by inheritance maps drawn without
constraint in meaning or number. You could make a beer bottle be a
triangular type of religion and the model wouldn't inhibit you. A more
structured model tries to impose consistency of meaning but if it does so
poorly, girls can't graduate schools.



-- 
The tao that can be tar(1)ed
is not the entire Tao.
The path that can be specified
is not the Full Path.