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

Neo wrote:
>
> :) 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,

I don't have the prolog skills to demonstrate it, but from what I've seen my guess is that this is quite easy for a skilled prolog programmer.

> etc. Consider what changes take place if the third fact is not
> known/added until after the first two are known/stored/coded against.

Raising the bar - as usual.

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

ISTM you have a homegrown 'normalize' interpretation.

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

Not by itself - that would be magic. If two names refer to one thing are this should be told or inferrable.

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

I found this: http://gollem.science.uva.nl/SWI-Prolog/Manual/gensym.html Is that what you mean?

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

Neither RM nor prolog have difficulties because people tend to name both cats and people mary.
I can see that it poses a problem to a droid how to distinguish them if someone refers to mary. Heh - I've seen people making mistakes on this one. Context matters.

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

-----------neofunc.pro
like(john, mary).
hate(john, bob).
opposite(like, hate).

Yes
?- current_predicate(neo/2).
No

> 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 Sun Apr 30 2006 - 01:15:35 CEST