>>>> Neo to mAsterdam: Enter the following in Prolog: like(john, mary). Now there is no way to determine the relationship between john and mary. This is because queries in Prolog find function parameters not the function itself. Here is how to do it in dbd (abridged script):
(create john like mary)
(select john * mary) // displays like
...The Prolog examples you gave were fine, however none of them showed
the ability to determine the relationship between things.
[For example, when he entered has_parent(johnny, john), he did not show
how to determine has_parent if given johnny and john. For example when
he entered has_boyfriend(sally, john), he did not show how to determine
the relationship has_boyfriend, if given sally and john. Basically what
I am saying is, in Prolog the data represented in the function's name
is not represented as systematically/flexible/generically in dbd.]
>>> mAsterdam: I'll re-ask: for what purpose do you need to know it?
.
>> Neo: The significance of knowing the relationship between two things is too basic for me to want to explain :)
> Nick: I'm sorry, Neo. But it is not.
:) Ok let see if I can explain it. The purpose of a methodology that
represents things is to represent things. John is a thing to represent.
Mary is a thing to represent. Like a thing to represent. The
relationship "john like mary" is a thing to represent. Ah, may be I see
the confusion now. When I showed dbd solves for the * in "john * mary",
I should be saying, show how to determine the relator or the verb
instead of the relationship.
Let me try to keep things focused. I assert that dbd's methodology is
the most general/systematic/flexible. I do not assert it is the
fastest, smallest, most user friendly, least resource hungry, most
popular, etc.
> If you expect intelligent people to hold a discourse with you, you have to treat us with enough respect to back away from rampant superiority to think about the question.
Sorry, but I took mAsterdam question to mean: what is the significance
of representing things, which in this case was the relator/verb (which
I was calling relationship) as shown in the "john like mary" example.
> You have assumed that it is valid to create a relationship between two things and to want to know what that relationship is. I have SHOWN you how Prolog would do this, by identifying the relationship as one of the items in the tuple.
Sorry, I meant the thing being represented in the function's name.
Please show how that data is represented as
systematically/flexibly/generically as in dbd.
> Prolog and Lisp are knowledge representation systems. Relational databases are primarily data representation systems, but if you look at the schema, you can quite frequently ascertain the business rules that existed at the time of design. Perhaps this is a bad place to code business rules. Perhaps not. I think that there are arguments both ways. Regardless, knowledge is represented both in the form of facts and in the form, in the case of Lisp and Prolog, in deductions.
I have no opinion on the above, but I still assert that dbd provides
the most general/systematic/flexible way to represent things. For
instance, dbd does not represent the data in Prolog's function any
differently than other data. For instance, dbd does not represent the
name of an atom any differently than other data. And I have and can
show again examples to demonstrate these points.
> Therefore it is absolutely incumbent upon you to explain why you would want to choose a knowledge representation that does not collect a bit of information and then assert that the mining of that information is so fundamental to the requirements as to be beneath you to explain it.
Excuse me? Both the dbd and Prolog examples represented approximately
same things.
In dbd: (create john like mary)
In Prolog: like(john, mary)
I then showed how to get like (relator/verb) when provided john and
mary with the following query: (select john * mary). Please show how to
do it as systematically in Prolog.
Received on Tue May 02 2006 - 19:21:05 CEST
