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

From: Neo <neo55592_at_hotmail.com>
Date: 30 Apr 2006 15:57:45 -0700
Message-ID: <1146437865.371205.65950_at_u72g2000cwu.googlegroups.com>


>>> This would mean ad-hoc 'create' (SQL-DDL.create) is out.
.
>> :) Not necessarily. Two humans can communicate things even if the actual data is stored differently, but the processing algorithms are powerful enough to compensate for this. But yes, the more commonality, the easier it will be to get two driods communicating initially. .
> So, SQL-DDL style 'create' is out.

Not necessarily, see above.

> How does dbd.create cater for structural consequences (= impacting both droids' knowledge, not just the one in the previous version of the scenery)?

When a user interacts with dbd, he does not need to worry about the underlying structure being employed. He simply needs to forms the proper create, select, update, delete expressions. In fact, the same expression submitted to different dbds will probably result in different underlying structures depending on what was already in db before hand.

>>> Neo: Is this possible in Prolog ???
>>> like (john, mary)
>>> hate (john, bob)
>>> opposite (like, hate)

Since above post, I have verified that while the Prolog complier will accept and complile the above statements, there is no way to form a query to retrieve the like in the first statement as Prolog queries can only find function parameters, not the function itself. And apparently function names and atom names can be the same (much like function names and variable names in C) but they seem to be unrelated and probably have different scopes.

>>>> ... two different methods [were used] to relate things [in Prolog solution]:
>>>> opposite (like,hate).
>>>> relationship (john,like,mary).
>>>> relationship (john,hate,bob).

.
>>> Neo, by dismissing implementation strategies for the wrong reasons you piss people off who do know what they are talking about.
.
>> mAsterdam, implementation strategies that are less systematic have less potential in AI-ish applications because the need to represent/process the unknown requires a very systematic method. If the reality of this pisses people off, please have them schedule a conference with God :) .
> Less systematic than what? According to which system?

Prolog's methodology of representing things is less systematic than dbd's and according to app/droid processing the data. Compare the following abridged dbd script with Prolog's above. Notice dbd uses one method while Prolog uses two to represent the same things:

(create like opposite hate)
(create john like mary)
(create john hate bob)

See a few posts down, where extending this example does not cause prior data to be restructured in dbd, where as it will in Prolog.

> In an earlier part of this thread, you left [these] unanswered - maybe an oversight:

[Quoted] I finally got around to answering them in the original post above :) Received on Mon May 01 2006 - 00:57:45 CEST

Original text of this message