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

> Neo: ...keeping in mind that in AI apps, future requirements are unknown:

// We now learn that john likes mary, therefore one might enter: assert(like(john,mary)).

// We now learn that john hates bob, therefore one might enter: assert(hate(john,bob)).

// We now learn that hate is opposite of like // therefore one might enter:
assert(opposite(like,hate)).

We now want to find the person with whom john's relationship is opposite of that with mary. Logically, the query might look like "X(john,mary), opposite(X,Y), Y(john,Z)." However, the problem is that such a query is not [or doesn't seem] possible since it operates on predicates. Now one needs to restructure the orginal data so that the new query is possible. Even after restructuring, the new predicate(s) are not systematically accessible, relatable, etc and this is an endless problem in Prolog. Such does not occur with dbd.

> Markus: One doesn't [need to restructure]. Hints: clause/2, current_predicate/1 and predicate_property/2.

Neo: Since my knowledge of Prolog is very limited and prior responses haven't led to infer that it is possible, could you please post the script "to find the person with whom john's relationship is opposite of that with mary" starting with the above asserts and clause/2, current_predicate/1 and predicate_property/2? This would allow us to evaluate the generic-ness/flexibility/systematic-ness of Prolog and dbd as far as representing things. Received on Mon May 15 2006 - 18:55:08 CEST