Re: Storing data and code in a Db with LISP-like interface

From: Neo <neo55592_at_hotmail.com>
Date: 29 Apr 2006 14:28:54 -0700
Message-ID: <1146346134.698706.44360_at_g10g2000cwb.googlegroups.com>


>> Food Judge Example C using dbd (db for dummies) follows...
>
> Alvin: ...I will not have the time to provide you with detailed [LISP/]Prolog equivalents. From what I've seen both can easily do the above...

:) OK, I'll just raise my concerns directly rather then verifying them via Example C. Below are items that I am concerned will limit Prolog's ability to represent things in as general/flexible/systematic a manner as dbd for AI-type apps:

  1. Inability to use functions (not function results) as parameters of other functions. For example the following is not possible (or at least no one has demonstated it thus far):

like (john, mary).
hate (john, bob).
opposite (like, hate).

This limitation is very similar to that in RM where new data requirements cause a wave of changes in schema, data, scripts, code, etc. Consider what changes take place if the third fact is not known/added until after the first two are known/stored/coded against.

2) Inability to normalize every thing that is represented. For example, the names of things. In Prolog, an atom and it's name are basically inseperable. Thus:

2a) Multiple names for a thing will not be represented systematically.

2b) A thing with no name will have to be given a name anyway such as no_name. This is similar to the NULL problem in RM. Now the the andriod will think a thing's name is actually no_name unless additional rules are added. If handled as such, what if droid actually encounters something named no_name? And how to handle additional unnamed things? no_name2, no_name3, ...?

2c) Two atoms can't have the same name so the atoms for cat and person named mary might be mary_cat and mary_person and this leads to redundant data as shown below. I won't explain the pitfalls of redundancy as volumes have been written on it already with respect to data mgmt.

cat (mary_cat).
person (mary_person).

2d) It does not appear to me (or actually I didn't get to verify this via the example), that the name of an atom is not stored in Prolog's fundamental data representation methodology.

In comparsion when dbd represents a person named john, consider what it actually does:

  1. Creates a thing to represent the string 'john' where elements of the string reference the one an only instance of each symbol in db. Things to represent each symbols are entered in db by dbms when file is first opened.
  2. Creates a thing to represent a word. The word is related to the string created above.
  3. Creates a thing to represent the person john. It is related to the word created above.

Thus when one sees the "john" in dbd script, it is translated to approximatley the following query:

(first (select (first (select (select 'j' 'o' 'h' 'n') symbolizes *)) nameOf *)) Received on Sat Apr 29 2006 - 23:28:54 CEST

Original text of this message