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

From: Neo <neo55592_at_hotmail.com>
Date: 27 Apr 2006 07:25:05 -0700
Message-ID: <1146147905.629848.172860_at_g10g2000cwb.googlegroups.com>


>>>> If "likes (john, apple1)" implies "john likes apple1" why isn't "john isa person" written as "isa (john, person)" or is "person (john)" an alternate/equivalent method? .
>>> Re-engineering your program forced me to do some interpretation. .
>> :) I think re-engineering is too strong a word here. .
> Do you have a better word for looking at one implementation and providing another without having an implementation-independent problem-statement?

Implementation-independent problem statements were provided. These statements (in plain english) were provided as comments (preceeded by //) prior to all the dbd script specificing the things to represent. Note in dbd's terminology, things includes relationship between things. Thus, in the following dbd script...

// Create john likes tomato1.
(create john like tomato1)

...the comment "// Create john likes tomato1." is one of the implementation-independent problem statements. If you prefer, I can consolidated all them into a single paragraph rather then being spreadout through out the script. If you feel "Create john likes tomato1" is not implementation-independent, could you restate it, so that it is?

When implementation-independent problem statements are provided, implementing it with a particular methodology (Prolog, LISP, RM, C++, etc) might be best called implementing rather than re-engineering. In this case it might be better called representing or modelling things/facts/data.

> > It is like calling the local gas attendant a fuel transfer engineer.
> Ok. Bitplumbing. :-)

I am not sure why one would call representing things (from implementation-independent specifications) in Prolog bitPlumbing. If you are saying representing things in dbd is like bitPlumbing, I would agree that its more general/systematic method requires more steps. And in Food Judge Example C, we are likely to see that while dbd is able to represent things in a systematic, albeit verbose manner (aka bitPlumbing), Prolog either can't or become impractical, even though its syntax is quite compact and elegant.

> > For example, representing the things is verbose but very systematic with dbd. With Prolog, representing the same things is more compact and there might be several ways. With RM, representing the same things can result in a wide variety of schemas by different "engineers".
.
> This is not a RM-specific phenomenon. Given a protocol (a list of inputs/outputs), the algorithm to get from the input to the output is indetermined: There is an indefine number of algorithms satisfying the protocol.

:) Yes, in RM getting from input to output is less indeterminable making it more difficult to use for AI-ish applications, where as in dbd it is more systematic, albeit verbose. A dbd user doesn't design any schema to represent things where as a RM user must.

>>[ person (john) ] how does one determine the name of the relationship via code? .
> There is no how, because I did not provide a name for this relationship.

It seems there maybe yet another reason. Prolog may not provide a method to determine the function given one set of parameter already specified. Can some experiences Prologer correct me on this?

>>>"person(john)." looked to me as a reasonable prolog representation for "john isa person". It may be that there are some subtleties in "isa" it did not catch. You might provide some tests. .
>> For example in dbd, it is possible for the app to determine the name of that relationship between john and person. .
> Because you provided a name for it. Was that necessary? For what?

First because it was in the implementation-independent specification of things to represent (however, I wasn't expecting anyone to be 100% on their first try, but that they would update it later). Second, so that the Prolog solution could answer the question: what is the relationship between john and person as shown below. Yes, it is blantantly obvious to you. But is not at all obvious to the app (ie an andriod).

> > A relationship is just another thing that is represented in the dbd. The following displays "class": (msgbox (and (select verb instance *) (select john * person))). And the following display "instance": (msgbox (and (select verb instance *) (select person * john))). How would one do this in Prolog?
>
> Why?

So that the Prolog solution could answer the questions: what is the relationship between john and person; and what is the relationship between person and john.

> I have to go now.

mAsterdam, I want to thank you for posting the Prolog solution. Considering that you consider your self to be a novice at Prolog, the solution was surprisingly complete. Received on Thu Apr 27 2006 - 16:25:05 CEST

Original text of this message