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

"Neo" <neo55592_at_hotmail.com> wrote in message news:1146606499.706391.115600_at_v46g2000cwv.googlegroups.com...
>> Nick: Assume that you want to represent the following information:
>>
>> Tony has a dog [named fido] and a bird [named tweetie].
>> Joe has a bird [named polly].
>> Mary has a dog [named barky].
>> Bird owners enjoy a hot bath.
>> Dog owners that are not bird owners enjoy taking long walks.
>> Dog owners prefer cold showers.
>> On Tuesday, dog owners who are also bird owners buy groceries.
>> On all other days, bird owners who are not dog owners buy groceries.

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?

>
> Nick as I look at your "challenge" more closely, I am realizing that it
> combines representation of things with implementation/enforcement of
> constraints. While dbd can store constraints, it does not currently
> implement/enforce user-defined constraints.

I was illustrating facts and rules, not enforcement. Prolog is not particularly good at restricting new data that is asserted into it's data structure either, because it is designed to allow most anything that can be defined. I wasn't trying to ensnare you.

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

> Also I am assuming you are not wanting to
> represent the relationships between adjectives and nouns such as hot
> bath and cold shower.

good assumption. No need to represent that hot and cold are opposites or anything like that.

>
> Below dbd's script models the first 3 lines of your information. Let me
> know your intent on the constraints.
>
> (; Create a person named tony)
> (new 'tony' 'person')
>
> (; Create a person named joe)
> (new 'joe' 'person')
>
> (; Create a person named mary)
> (new 'mary' 'person')
>
> (; Create a dog named fido)
> (new 'fido' 'dog')
>
> (; Create a dog named barky)
> (new 'barky' 'dog')
>
> (; Create a bird named tweetie)
> (new 'tweetie' 'bird')
>
> (; Create a bird named polly)
> (new 'polly' 'bird')
>
> (; Create a verb named owns)
> (new 'owns' 'verb')
>
> (; Create tony owns fido and tweetie)
> (create tony owns fido)
> (create tony owns tweetie)
>
> (; Create joe owns polly)
> (create joe owns polly)
>
> (; Create mary owns barky)
> (create mary owns barky)
>
>
> Note: (new 'tony' 'person') is equivalent to:
> (new)
> (create thing instance (it))
> (create (it) name (findElseAdd word instance 'person'))
>
> (new)
> (create person instance (it))
> (create (it) name (findElseAdd word instance 'tony'))
>

I wanted to answer some questions from the other thread, combined with this one. I hope you don't mind.

>>> Neo: But on a related note, as the original and serveral other posts
>>> indicated, an app/android using dbd can create a new function (ie
>>> createWRR or getRoot) on-the-fly, at run-time simply by adding data to
>>> the db using the existing functions such as create, select, etc. The
>>> app/andriod can then use the new function in yet another new function
>>> and so on, all at run-time. Can Prolog or LISP do similar? Since there
>>> is still a lot of development to do in this area, I can only demo simple
>>> functions at this time.

>> Nick: Yes, Prolog can assert new facts and relationships to allow
>> entirely new

deductions and deduction models.

> Neo: Ok, but can it accept new things (facts, relationship, and functions)
at run time or does one need to update the original source file, recompile and then run?

Prolog can accept new things at run time, without opening up the file and recompiling. (I believe mAsterdam demonstrated this). It is simply the use of the 'assert' predicate. This is one of the key aspects of Prolog because the language was originally designed to be a system for capturing knowledge from unstructured data (like text documents) and be able to produce a logical body of knowledge from it, a body of knowledge that can be queried and consulted. Therefore, the system was designed to 'teach itself' things. The newly learned items were added to the body of knowledge and inference using the 'assert' predicate.

>> Nick: I'm sure that most or all of these items is also quite doable in
>> your db language. The point is that your language does not exceed
>> Prolog.

> Neo: :) And luckily, I never asserted that my language exceeds Prolog. Let
me restate what I have asserted before: dbd provides the most general/flexible/systematic method of representing things.

I'll be honest. I find this confusing. Perhaps I read things differently than others, but the statement 'dbd provides the most X' means that other systems provide less 'X' than dbd. In other words, you have not stated that dbd is 'greater than or equal to' the KR capabilities of Prolog and Lisp. 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.

>> Nick: For that, I applaud you. It is difficult to create a KR mechanism
>> that is flexible.

> Neo: I don't claim to have created a flexible Knowledge Representation
mechanism specifically. I claim dbd's method of representing things is the more general/flexible/systematic compared to Prolog, LISP and RM's.

My original statement was intended as a compliment. :-) That said, regardless of what you claim, you HAVE created a KR system. You have even created some of the mechanisms needed to mine the knowledge, produce deductions, and create conclusions from facts. I mean it when I say that this is impressive, especially without a mathematical foundation for understanding what you are doing. When you say that "dbd's method of representing things..." you are clearly intending to exceed the collection of 'data' and moved into the storage of 'knowledge.'

Now that you have made that leap, into KR (and you have), it is incumbent upon you to stand on the shoulders of the giants of KR. I strongly suggest that you can continue to improve dbd and add capabilities that are not currently captured in your implementation if you evaluate the extensive research that already exists in this area. You are not alone.

> Neo: For example, when the "john like mary" example
was extend twice, each time existing data/structure in Prolog had to be revised but was unaffected in dbd. This characteristics is important

Fascinating assertion. When you 'extended' your examples, you did so knowing that dbd already implemented a particular, quite uncommon, requirement (see other response that rephrases a question from mAsterdam). Had I been aware of this requirement, the first implementation of the Prolog app would not have needed restructuring. That you are able to create an example that shows something to be 'superior' by playing to its strengths, when the person you are discussing the issue with is not aware of those strengths, is a simple game that illustrates very little to me. Now that you have made it clear that you wish for the application to recognize and respond to the 'relators', I can easily create Prolog apps that do this. I let you respond, in the other thread, about why you consider this ability to important.

> 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. Please post Prolog's actual solution so I know more accurately what to represent/query. And again, thanks for engaging in these examples :)

'Not' is part of the logic. These are not queries. They are statements of fact... bits of knowledge that you need to store and retrieve and use for deduction. If you cannot store a relationship that understands 'not', then you may want to revisit your language (or, even better, read about the conceptual foundations of Knowledge Representation, as I continue to urge you to do).

//Tony has a dog and a bird
owns(tony,bird).
owns(tony,dog).

//Joe has a bird
owns(joe,bird).

//Mary has a dog
owns(mary,dog).

//Bird owners enjoy a hot bath
enjoy( Person, hot_bath) :- owns( Person , bird).

// Dog owners prefer cold showers
// there's two choices here. We could say that 'prefer' is intended to mean 'enjoy' or we could
// say that 'prefer' means 'enjoy more greatly than other enjoyment'. We can combine these alternatives
// IF we interpret the first response to the question: what does mary enjoy? to be the thing that mary enjoys
// the most. Therefore, one could view this rule as a modification of 'enjoy' that must return its
// answer before other answers returned. To do so, this rule is moved 'up' in the program.
// if this rule were asserted at realtime, the 'asserta' predicate would be used.
enjoy( Person, cold_shower) :- owns(Person, dog).

//Dog owners that are not bird owners enjoy taking long walks enjoy( Person, long_walk) :- owns(Person, dog), \+ owns(Person, bird).

// On Tuesday, Dog owners who are also bird owners buy groceries buy_groceries(tuesday, Person) :- owns(Person, dog), owns(Person, bird).

// On all other days, bird owners who are not dog owners buy groceries buy_groceries(DOW, Person) :- \+ equals(DOW, tuesday), owns(Person, bird), \+ owns(Person, dog).

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