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

Downloaded and installed Prolog. Now I think I see, why neither Nick nor you were able to solve the problem as systematically as dbd. First observe below how systematically dbd solves progressive more complex problems without impacting existing data in this case.

Problem1: Find the thing with whom john's relationship is opposite that of with mary. Below is dbd's abridged script and query which answers with bob:

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

          (select (select john * mary)
                     opposite
                     *)
          *)

Problem2: Find the thing with which john's relationship is similar to reverse that of with mary. Below is dbd's abridged script which answers with bob:

(create like opposite hate)
(create john like mary)
(create john hate bob)
(create reverse similar opposite)
(select john

          (select (select john * mary)
                     (select reverse similar *)
                     *)
          *)

Now lets take a look at Prolog. Logically, data should be setup as follows to be systematic for an android to process.

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

but instead Nick entered the following (notice two different formats are being used to do basically the same thing):

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

What I found is that Prolog accepted the simpler script, but there doesn't seem to be a way to write the query because one cannot solve for likes because it is the name of the function, not a function parameter. This is why, like was transformed from a function name to a function parameter.

The significance of this is, the app/andriod processing the data cannot determine the relationship between john and mary, if it is entered as follows: likes(john, mary). In fact, it probably can't determine any function name by the function's parameters.

If someone would like to extend Nick's solution to meet Problem2's requirements, they will likely see that it requires restructuring the prior data. This problem parallels that with RM's where new requirements can cause changes in schema, data, script, code, etc. Received on Sun Apr 30 2006 - 07:29:49 CEST