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

> > mAsterdam: what, specifically, do you want to
> > know about relator/relationships? Why do you want to know it?
>
> Nick: From this 'droid' who is reading this thread, mAsterdam asked a very valid
> question. In fact, this is not the first time that mAsterdam asked it.
> You have never answered it AFAIK.

Actually I have been demonstrating and stating the answer for several years now but it doesn't register with anyone because it doesn't apply to most people's requirements. One can't know the requirements ahead of time in AI-type apps. Thus one would like a system that is the least impacted in terms of schema/scripts/queries/code by the need to meet future requirements. To achieve this, anything that is represented in a db, should be treated the same as all the other things represented in the db. For example when dbd represents "john like mary", things are represented using the same system. It is systematic. Thus, later, one can add attributes/values to john, just the same as to mary and just the same to like. In Prolog, like becomes a function and john and mary become parameters [ie like(john, mary)]. Like is represented in a different manner than john and mary. This is unsystematic. Now if a droid based on Prolog needs to make a relationship with like or add an attribute to it, it can't, or at least not in a systematic manner. In addition, a Prolog driod cannot determine the relationship between john and mary where as one based on dbd can. For example to find the relator and thus the relationship between john and mary, it does the following (select john * mary) which return like for the *.

In general, Prolog represents things as follows: f(p1, [p2], ...).

A Prolog-based app/droid (whose future requirements are unknown at design-time) is always vulnerable to requiring the equivalent of a schema change in RMDBs (which causes script/queries/code changes), because it may later need to add/delete/modify/relate to f.

Later when one redesigns it as:
f2(p1, f, p2, ...). or similar.

now the same problem occurs with f2. It is an endless problem in Prolog (and RM), but not in dbd.

> Nick: mAsterdam ... showed you how the overly simple prolog program like(john,mary) would have to be written as
relationship(john,like,mary) in order to capture the relator.

Yes, but now if the app/droid needs to
add/delete/modify/select/query/relate to relationship, the same redesign cycle occurs again, but not in dbd. Received on Tue May 09 2006 - 04:27:32 CEST