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

> ... I thought: /this/ is much easier in prolog.

Prolog is definitely more compact. We will soon see (next extension of example) if it's compactness will allow it to represent anything.

>> 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. It is like calling the local gas attendant a fuel transfer engineer. 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".

> > [ person (john) ] how does one determine the name of the relationship
> > via code?

> "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. A relationship is just another thing that is represented in the db.

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?

> > If "isa (john, person)" and "instance (person, john)" are possible,
> > can I relate isa and instance?
>
> In several ways.

I have doubts that Prolog can.

> > Can I write "opposite (isa, instance)" and "opposite (instance, isa)"?
>
> Not sure what you mean here.

Basically this is the same question as the prior one. Can functions be treated the same as function parameters. Assume following in Prolog:

class (john, person)              implying john's class is person.
instance (person, john)         implying person's instance in john.

See next dbd example doing the above with verbs like and likedBy.

> > Can functions be parameters of other functions?
>
> Yes, second order logic is possible.

I meant the function itself, not the function's results as show above by reciprocal (instance, class).

>>> thing(X):-vegetable(X).
>>
>> Based on my limited knowledge of Prolog,
>> it is not clear if vegetable isa thing.
>
> Not according to this clause. This clause could read as:
> If X is a vegetable, it is a thing.

Then the Prolog example is not representing the same things (including relationships which are also things in dbd). When displayed as a hierarchy, the dbd's class/instance hierarchy would be:

thing

   -instance-

        fruit
            -instance-
                tomato1
        vegetable
            -instance-
                tomato1

Where as Prolog's would be:
thing

   -instance-

       tomato1
fruit

   -instance-

       tomato1
vegetable

   -instance-

       tomato1

The difference being, fruit and vegetables are not classied as things. An app could not determine this based on things represented.

> > isa thing. What does the following return?
> > ?- thing(vegetable).
>
> I would expect prolog to return "No".

And I would too since it did not represent that vegetable is a thing as in the dbd example.

> >How do I express the following query in Prolog:
> > Find a person who likes a fruit and a vegetable.
> > (and (select person instance *)
> > (select * like (and (select vegetable instance *)
> > (select fruit instance *))))
>
> ?- person(P), likes(P, F), likes(P, V), fruit(F), vegetable(V).

I actually expressed what I meant more clearly in the query then in english which was ambigious :( I meant find a person who likes something that is both a vegetable and a fruit.

> > Can one add attributes to "likes" in Prolog?
>
> Did you try?

No I did not. Believe or not developing/implementing a data model more general/flexible than RM takes up a bit of time, so I am going to rely on user who know more than I can gather by briefly browsing over Prolog manuals :)

>> If you (or someone) can update the Prolog example and bring it closer

I'll be posting a new extension of the example (Food Judge Example C) shortly. Received on Thu Apr 27 2006 - 04:05:13 CEST