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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Thu, 27 Apr 2006 23:16:26 +0200
Message-ID: <44513485$0$31648$e4fe514c@news.xs4all.nl>

Neo wrote:

>>>>>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.

That's what the designer (former COBOL programmer) said when I commented on his specs - containing phrases like "The file should be opened"
"The corresponding items have to be moved" - you might even agree with him.
Implementation strategies we are comfortable with tend to bias the way we state problems.

> 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?

Except for the 'create' part it is ok with me, that is, indepedendent enough for me for now.

It 'll do. Going off into babble such as this doesn't help:

Establish the fact that a person
by the name of john likes tomato1
What does he like? Is it a type of tomato or are we talking about this one?
Does he like it as food?
Does he like the colour?
Ad infinitum.

That's why IRL I prefer real lists
of, with real explanations by, the people who know what they are keeping track of, and know why they must.

"john likes tomato1" looks like something an amateur cook would like to know when he invites some friends over for dinner. I can make some sense out of it, so it'll do.

> 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.

Agreed.

> In
> this case it might be better called representing or modelling
> things/facts/data.

Not sure. While I collected the prolog clauses it really felt like re-engineering.

>>>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.

Until I see evidence of more prolog knowledge from you I consider this a wild, arrogant, unfounded and unnecessary claim.

>>>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.

Until you show more RM-knowledge ... etc. (Add annoying).

>>>[ 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?

Can you make your statement in a way which is more test-friendly?

>>>>"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.
>>>>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
> of things to represent

I'm not so sure it is (II). Even this sentence is suspect: e.g. "things to represent" - do I want to represent things? Do we have the same concept of "thing"?
I have a hard time seeing a category as a thing.

> (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'll re-ask: for what purpose do you need to know it? Which information need are you satisfying/preempting whith it? This would shed some light on what to record.

>>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:16:26 CDT