Re: Storing data and code in a Db with LISP-like interface
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. :-)
> > 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.
>>[ 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.
>>>"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).
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.
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