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

Hello Neo,

You have a tedious habit of attempting to respond to every sentence, rather than the questions I ask. It makes me wonder if you are actually reading the entire message before responding.

"Neo" <neo55592_at_hotmail.com> wrote in message news:1147287045.580976.224140_at_g10g2000cwb.googlegroups.com...
>>> Tony has a dog [named fido] and a bird [named tweetie]...
> .
>> I find it curious that you chose to implement 'Joe owns Polly' but not
>> 'Joe owns a Bird'. Not sure why. However, it is a moot point. Given
>> what you have illustrated of your language, the query needed to determine
>> that 'Joe owns a bird' is simple, right?
>
> :) I was trying to let you focus on the initial problem and make it
> easier on Prolog since it is unsystematic when dealing with names of
> things. In Prolog, an atom and it's name are basically inseperable.

That Prolog has a different system does not imply that it is unsystematic. Saying so earns you lower credibility. If you wish to actually convince someone of something, you are going to have to work a little to show them that you are worth listening to. That means to carefully earn credibility and respect. You've done little of either in this entire thread. I believe that you are intelligent, but I honestly believe that the greatest inventions are those where a good idea comes from an intelligent person who is able to convince others of its value. You have not been able to convince me of the value of your system at all.

>>> Did you want me to represent the actual constraint "Bird owners enjoy a
>>> hot bath" or the net effect on the data which would be that "Tony and
>>> Joe enjoy hot baths".
>>
>> very much so.
>
> The question had an OR in it, so I still don't understand your
> intention. If you meant both, I can represent the net effect on current
> data and store the constraints but dbd itself does not
> enforce/implement the stored constraints on new data.

My apologies. My response should have read "represent the constraint 'bird owners enjoy a hot bath' in a way where you can determine, through deduction, that 'Tony and Joe enjoy hot baths.' "

>
> First off, when it refers to three different database mechanisms, this
> is unsystematic.

nonsense. Each mechanism is useful for different things.

> Second, if everthing can be done at run time, why does
> anyone first compile and load? Can I just enter your examples at
> run-time? Can I simply run Prolog and enter like(john, mary) using
> assert/clause?

yes. You can load the entire program at run time. Might be difficult to remember what you typed :-), but you can certainly do it. The earliest prolog interpreters, from what I understand, would simply take the input file and call 'assert' on each statement in it.

>> Nick: You have stated that it is 'greater than'. Surely you can see
>> where I drew the conclusion that you were asserting dbd to exceed Prolog.
>
> :) Yes, I can see. I meant it exceeds Prolog in the limited scope of
> representing things, not in processing of whatever is represented.

I would challenge this. Your system is quite good in some ways, exceeding Prolog on a point or two. It is not, however, more able to represent things and the relationships between them. I can now state this for a fact, given the answers you provided to the 'not' question below.

>>> Neo: Also some of your queries use the equivalent of NOT. Currently I
>>> can only find things john likes and not the things john does not like (I
>>> haven't developed such functions). If you could reform the queries
>>> without NOT, that would be great.
>>
>> 'Not' is part of the logic.
>
> Whether NOT is or isn't part of logic, doesn't have much bearing on the
> ability to represent things in a general/flexibile/systematic manner.
>

I disagree.

You have repeatedly illustrated the notion that your system can store a bit of information like "John likes Mary" and "Mary hates Bob". However, you don't appear to have a way to say "Mary does not like John" and "Mary does not hate Bob".

These are not query expressions. They are facts. If you expect to model the world of information in AI-type applications, you cannot pretend that you will always have complete information about all aspects of a 'relationship' between things. The statement "Mary does not like John" doesn't phrase her relationship with John in direct terms, but that may all of the information you are given. You cannot simply reject a bit of information from your model because you have no way to model it. That shows a SERIOUS weakness.

Assume I have a series of facts as follows. Now, I am a detective, trying to solve a mystery. I want to spot the offender. (Think of a TV show like Columbo or Monk).
"At the time of the crime..."
John is in the barn
Mary is in the house
Tom is not in the house
Frank is killed when he is pushed into the well

The query: find the suspect. (This is an overly simplistic sample... I have much harder ones).

If you cannot capture the bit of information "Tom is not in the house" then it would be difficult to 'find the most likely suspect', wouldn't it?

>
>> //Bird owners enjoy a hot bath
>> enjoy( Person, hot_bath) :- owns( Person , bird).
>
> Again, I can store this constraint (and remaining ones), but dbd
> doesn't enforce or implement it. Do you want me to represent the
> constraint or the net effect of the constraint on the current data or
> both?

I want you to represent information in such a way that you can deduce the fact that a bird owner can be expected to enjoy a hot bath.

-- 
--- Nick Malik [Microsoft]
    MCSD, CFPS, Certified Scrummaster
    http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not 
representative of my employer.
   I do not answer questions on behalf of my employer.  I'm just a 
programmer helping programmers.
--