Below is an example script for an experimental db (in development) that
can store both data and code.
Unlike typical databases, data is not stored using a table/record
methodology, but via nodes where each node can connect to any other
node, in a manner similar to neurons in the human brain.
Unlike typical databases which use an SQL interface, the experimental
db has a LISP-like interface. In general each expression or statement
starts with "(" and end with ")". Within the parenthesis there can be
any number of elements. The first element is the command or function.
The remaining elements are function parameters. The core functions
currently are create, select, delete and update. Any element can itself
be itself be a sub expression and elements of the sub expression can
also be a sub expression and so on forever (theorectically).
The db assumes that anything can have 0 to many names. And a name can
have 0 to many representations such as a string of ascii symbols,
chinese symbols, sounds, etc (only ascii symbols are implemented
currently).
Because of the high degree of separation between the logical and
physical layers and the extreme flexibility of the db, the amount of
memory and processing power required are limiting factors (currently).
The script below (best viewed in fixed size font) creates some cars and
people. The first function (stored in db) loops thru things that john
likes. The second function displays instances of class specified as a
parameter. Functions can create local variables which are stored on a
"stack" which is also in the db and functions (system or user-defined)
are re-entrant.
Any constructive comments appreciated.
// ----------------------------------------------------
// SIMPLE CAR EXAMPLE
// Create car named rx7.
// Create a new name with symbols 'car'
(create name instance (new))
(create (it) symbol (create 'c' 'a' 'r'))
// Create a new type named car.
(create type instance (new))
(create (it) name (and (select name instance *)
(select * symbol (select 'c' 'a' 'r'))
)
)
// Create a new name with symbols 'rx7'.
(create name instance (new))
(create (it) symbol 'rx7') // Note: 'rx7' is a shortcut.
// Create a new car named rx7.
(create car instance (new))
(create (it) name (select * symbol 'rx7'))
// Create a new car named accord.
(create car instance (new))
(create (it) name (findElseCreate name instance 'accord'))
// ------------------------------------------------------
// Create code that will create a car named neon.
// Uncheck "Execute Expression Immediately" from Tool Menu
// before submitting below expressions.
// Thus, each expression is stored and not executed
// until user selects appropriate tree node
// and then issues execute code command from Tool Menu.
// Create a new car named neon.
(block
// Create new name with symbols 'neon'
(create name instance (new))
(create (it) symbol (create 'n' 'e' 'o' 'n'))
// Create new car with above name
(create car instance (new))
(create (it) name (and (select name instance *)
(select * symbol (select 'n' 'e' 'o' 'n'))
)
)
)
// Now select appropiate node in db and select execute from Tools Menu.
// --------------------------------------------------------------
// EXAMPLE with john, mary and a cat named mary also.
// --------------------------------------------------------------
// Create type gender.
(create type instance (new))
(create (it) name (findElseCreate name instance 'gender'))
// Create gender male.
(create gender instance (new))
(create (it) name (findElseCreate name instance 'male'))
// Create gender female.
(create gender instance (new))
(create (it) name (findElseCreate name instance 'female'))
// Create type person.
(create type instance (new))
(create (it) name (findElseCreate name instance 'person'))
(create dir item (it))
// Create a person named John whose gender is male.
(create person instance (new))
(create (it) name (findElseCreate name instance 'john'))
(create (it) gender (findElseCreate gender instance 'male'))
// Create a person named Mary whose gender is female.
(create person instance (new))
(create (it) name (findElseCreate name instance 'mary'))
(create (it) gender (findElseCreate gender instance 'female'))
// Create a person named Sue.
(create person instance (new))
(create (it) name (findElseCreate name instance 'sue'))
// Create verb like.
(create verb instance (new))
(create (it) name (findElseCreate name instance 'like'))
// Create verb hate.
(create verb instance (new))
(create (it) name (findElseCreate name instance 'hate'))
// Create John like Mary.
(create john like mary)
// Create John like Sue.
(create john like sue)
// What does John like that is a person and female?
// Ans: Mary the person.
(msgbox (and (select john like *)
(select person instance *)
(select * gender female)
)
)
// Create type cat.
(create type instance (new))
(create (it) name (findElseCreate name instance 'cat'))
(create dir item (it))
// Create a cat named Mary.
(create cat instance (new))
(create (it) name (findElseCreate name instance 'mary'))
(create (it) gender female)
// Create John like the cat named Mary.
(create john like (and (select cat instance *)
(select * name (select * symbol 'mary'))
)
)
// What does john like that is female?
// Ans: Mary the person and Mary the cat.
(msgbox (and (select john like *)
(select * gender female)
)
)
// Create Mary the cat hates all persons (John and Mary).
// Note: Currently following only creates relation to John.
// Code should also make relation to person Mary, but doesn't.
(create (and (select cat instance *)
(select * name (select * symbol 'mary'))
)
hate
(select person instance *)
)
// What does Mary the cat hate?
// Ans: Persons named John [and Mary].
(msgbox (select (and (select cat instance *)
(select * name (select * symbol 'mary'))
)
hate
*
)
)
// If John like Mary
// Then print true
// Else print false
(if (select john like mary)
(msgbox true)
(msgbox false)
)
// If John equals Mary,
// Then print true
// Else print false
(if (equal john mary)
(msgbox true)
(msgbox false)
)
// If John equals first instance of person who is male,
// Then print true
// Else print false
(if (equal john
(and (select person instance *)
(select * gender male)
)
)
(msgbox true)
(msgbox false)
)
// If Sue equals last instance of person,
// Then print true
// Else print false
(if (equal sue
(lastNode (select person instance *))
)
(msgbox true)
(msgbox false)
)
// Change gender of things named Mary from female to male.
// In effect, changes the gender of Mary the person and the cat to
male.
(update (select (select * name (select * symbol 'mary'))
gender
female
)
male
)
// Change person Mary's gender from male to female.
(update (select (and (select person instance *)
(select * name (select * symbol 'mary')))
gender
male
)
female
)
// -----------------------------------------------------------
// Below script creates a function named func1
// to find things that john likes and displays them in a msgbox.
// Function func1 is stored in db.
// Create func1.
(create function instance (new))
(create (it) name (findElseCreate name instance 'func1'))
// Disable expr execution from Tools Menu.
(func1 code
(block
(createVar 'myQ1')
(create (selectVar 'myQ1') refersTo (qryStore (select john
like *)))
(createVar 'var1')
(create (selectVar 'var1') refersTo (qryGetNext (qryRecall
(selectVarVal 'myQ1'))))
(while (selectVarVal 'var1')
(block
(msgbox (selectVarVal 'var1'))
(delete (select (selectVar 'var1') refersTo))
(create (selectVar 'var1')
refersTo
(qryGetNext (qryRecall (selectVarVal
'myQ1'))))
)
)
)
)
// Enable expression execution from Tools Menu and execute func1.
// Note that func1 can now be invoked just like system functions
// such as create, select, delete and update.
(func1)
//--------------------------------------------------
// Create a function named displayInstances which has a parameter.
// The parameter specifies which class's instances to display in
msgbox.
(create function instance (new))
(create (it) name (findElseCreate name instance 'displayInstances'))
(create (it) parameter 'class')
// Disable expr execution from Tools Menu.
(displayInstances
code
(block
(create (createVar 'myQry')
refersTo
(qryStore (select (selectVarVal 'class') instance *)))
(create (createVar 'instX')
refersTo
(qryGetNext (qryRecall (selectVarVal 'myQry'))))
(while (selectVarVal 'instX')
(block
(msgbox (selectVarVal 'instX'))
(delete (select (selectVar 'instX') refersTo))
(create (selectVar 'instX')
refersTo
(qryGetNext (qryRecall (selectVarVal
'myQry'))))
)
)
)
)
// Enable expression execution from Tools Menu
// and execute function with a parameter.
(displayInstances person) // Displays john, mary, sue.
(displayInstances cat) // Displays Mary.
(displayInstances car) // Displays rx7, accord, neon.
// NOTES
---------------------------------------------------------------
In scripts, (it) refers to the thing created by last (new) in current
scope.
When a script containing 'xyz' is processed, str 'xyz' is created it in
db, even if it does not exist.
This is done to reduce length/complexity of scripts that occurs in
script for car named neon.
'xyz' => (select 'x' 'y' 'z')
xyz => (firstNode (select *
name
(firstNode (and (select name instance *)
(select * symbol 'xyz')
)
)
)
)
(findElseCreate name instance 'bob') =>
(if (and (select name instance *)
(select * symbol 'bob')
)
// Then
(return (select * symbol 'bob'))
// Else
(block
(create name instance (new))
(create (it) symbol (create 'b' 'o' 'b'))
(return (it))
)
)
// Creates a variable on the stack for current instance of
block/function.
(createVar 'var1') => (block
(create (new) name (findElseCreate name
instance 'var1'))
(create (select stackPtr refersTo *) variable
(it))
)
// Selects a variable on the stack for current instance of
block/function.
(selectVar 'var1') => (and (select (select stackPtr refersTo *)
variable *)
(select * name (select * symbol 'var1'))
)
// Selects the "value" of a variable on the stack.
(selectVarVal 'var1') => (select (selectVar 'var1') refersTo *)
Neo wrote:
> Below is an example script for an experimental db (in development) that
> can store both data and code.
>
> Unlike typical databases, data is not stored using a table/record
> methodology, but via nodes where each node can connect to any other
> node, in a manner similar to neurons in the human brain.
"We learn from history that we learn nothing from history."
vc wrote:
> Neo wrote:
> > Below is an example script for an experimental db (in development) that
> > can store both data and code.
> >
> > Unlike typical databases, data is not stored using a table/record
> > methodology, but via nodes where each node can connect to any other
> > node, in a manner similar to neurons in the human brain.
>
>
> "We learn from history that we learn nothing from history."
I used to store snippets of code or subroutine calls in the database
during my ExBase days. Generally they were refered to as "control
tables":
http://www.geocities.com/tablizer/cntrl1.htm
However, it is best to have a dynamically-typed RDB for such, and only
SqLite comes close to this feature that I know of.
But, what is wrong with tables such that the Lisp proponent does not
want to use them? The only legit complaint I've ever heard is lack of
dynamic column allocation, which is an implemention issue (and arguably
not needed).
-T-
From: Ken Tilton
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <RZwWf.763$FA6.251@fe12.lga>
topmind wrote:
> vc wrote:
>
>>Neo wrote:
>>
>>>Below is an example script for an experimental db (in development) that
>>>can store both data and code.
>>>
>>>Unlike typical databases, data is not stored using a table/record
>>>methodology, but via nodes where each node can connect to any other
>>>node, in a manner similar to neurons in the human brain.
>>
>>
>>"We learn from history that we learn nothing from history."
>
>
> I used to store snippets of code or subroutine calls in the database
> during my ExBase days. Generally they were refered to as "control
> tables":
>
> http://www.geocities.com/tablizer/cntrl1.htm
>
> However, it is best to have a dynamically-typed RDB for such, and only
> SqLite comes close to this feature that I know of.
>
> But, what is wrong with tables such that the Lisp proponent does not
> want to use them?
The world is not columns and rows, so you are forcing an unnatural
representation onto your data. Bad DBA, bad!
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton wrote:
> topmind wrote:
> > vc wrote:
> >
> >>Neo wrote:
> >>
> >>>Below is an example script for an experimental db (in development) that
> >>>can store both data and code.
> >>>
> >>>Unlike typical databases, data is not stored using a table/record
> >>>methodology, but via nodes where each node can connect to any other
> >>>node, in a manner similar to neurons in the human brain.
> >>
> >>
> >>"We learn from history that we learn nothing from history."
> >
> >
> > I used to store snippets of code or subroutine calls in the database
> > during my ExBase days. Generally they were refered to as "control
> > tables":
> >
> > http://www.geocities.com/tablizer/cntrl1.htm
> >
> > However, it is best to have a dynamically-typed RDB for such, and only
> > SqLite comes close to this feature that I know of.
> >
> > But, what is wrong with tables such that the Lisp proponent does not
> > want to use them?
>
> The world is not columns and rows, so you are forcing an unnatural
> representation onto your data. Bad DBA, bad!
The world is a big tangled graph/network. There is no inherent lasting
sureshot order to it. However, when we model it, it is tough for humans
to deal with it as a big tangled string blob. Thus, we impose
organizational abstractions to model stuff yet be able to grok our
models as humans. Hierarchies are another example of just such an
artificial construct. Why do we put all our documents in tree-shaped
folders and when the world is generally not tree-shaped? Answer:
because we would go nuts without some kind of ordering.
If you can propose something better than relational tables for
organizing stuff, I am all ears. But remember:
1. It must be flexible
2. It must be fairly easy for humans to grok (understand, manage, sift)
(Trees tend to fail #1. They cannot easily deal with lots of orthogonal
categories and relative/custom views.)
>
> :)
>
> ken
>
>
-T-
topmind wrote:
> Ken Tilton wrote:
> >
> > The world is not columns and rows, so you are forcing an unnatural
> > representation onto your data.
>
> The world is a big tangled graph/network.
Neither of these is true. The world is an approximate sphere
with an outer silicate solid crust, a highly viscous mantle, a
liquid outer core that is much less viscous than the mantle,
and a solid inner core. The liquid outer core gives rise to a
weak magnetic field due to the convection of its electrically
conductive material.*
Nowhere in the physical world will you find a mathematical
object. Directly comparing anything physical to anything
mathematical is invalid.
The question of what kind of mathematical structure is best
suited for a particular task is a good one. The question
of which one is most like "the Real World(tm)" or "the
way the Human Mind works" is not useful, and won't get
you anywhere.
Marshall
* http://en.wikipedia.org/wiki/Earth%27s_core
Marshall Spight wrote:
> topmind wrote:
> > Ken Tilton wrote:
> > >
> > > The world is not columns and rows, so you are forcing an unnatural
> > > representation onto your data.
> >
> > The world is a big tangled graph/network.
>
> Neither of these is true. The world is an approximate sphere...
It is actually a half of sphere that is based on four elephants.
Mikito Harakiri wrote:
> Marshall Spight wrote:
>
>>topmind wrote:
>>
>>>Ken Tilton wrote:
>>>
>>>>The world is not columns and rows, so you are forcing an unnatural
>>>>representation onto your data.
>>>
>>>The world is a big tangled graph/network.
>>
>>Neither of these is true. The world is an approximate sphere...
>
>
> It is actually a half of sphere that is based on four elephants.
>
Viewed by four blind men.
Marshall Spight wrote:
>
> Nowhere in the physical world will you find a mathematical
> object. Directly comparing anything physical to anything
> mathematical is invalid.
>
It's astounding how poorly the real world models mathematics.
Joe Marshall wrote:
> Marshall Spight wrote:
>
>>Nowhere in the physical world will you find a mathematical
>>object. Directly comparing anything physical to anything
>>mathematical is invalid.
>>
>
>
> It's astounding how poorly the real world models mathematics.
LOL :-)
Marshall Spight wrote:
> topmind wrote:
>
>>Ken Tilton wrote:
>>
>>>The world is not columns and rows, so you are forcing an unnatural
>>>representation onto your data.
>>
>>The world is a big tangled graph/network.
>
>
> Neither of these is true. The world is an approximate sphere
> with an outer silicate solid crust, a highly viscous mantle, a
> liquid outer core that is much less viscous than the mantle,
> and a solid inner core. The liquid outer core gives rise to a
> weak magnetic field due to the convection of its electrically
> conductive material.*
This goes to universe of discourse. Yours (geological?)
is appearantly another than OP's (ontological?).
>
> Nowhere in the physical world will you find a mathematical
> object. Directly comparing anything physical to anything
> mathematical is invalid.
>
> The question of what kind of mathematical structure is best
> suited for a particular task is a good one. The question
> of which one is most like "the Real World(tm)" or "the
> way the Human Mind works" is not useful, and won't get
> you anywhere.
> * http://en.wikipedia.org/wiki/Earth%27s_core
Marshall Spight wrote:
> topmind wrote:
> > Ken Tilton wrote:
> > >
> > > The world is not columns and rows, so you are forcing an unnatural
> > > representation onto your data.
> >
> > The world is a big tangled graph/network.
>
> Neither of these is true. The world is an approximate sphere
> with an outer silicate solid crust, a highly viscous mantle, a
> liquid outer core that is much less viscous than the mantle,
> and a solid inner core. The liquid outer core gives rise to a
> weak magnetic field due to the convection of its electrically
> conductive material.*
And here I thought that all the world's a stage.
> Nowhere in the physical world will you find a mathematical
> object. Directly comparing anything physical to anything
> mathematical is invalid.
>
> The question of what kind of mathematical structure is best
> suited for a particular task is a good one. The question
> of which one is most like "the Real World(tm)" or "the
> way the Human Mind works" is not useful,
I'll agree with the first, although using such terms can be a shortcut.
I definitely disagree with the latter. When we are talking about
humans modeling data or any aspect of software, it makes a lot of sense
to ask how the human mind works. It is a good idea to ask whether we
are using an approach that renders an obscure specification that is
likely to be misinterpreted by another software developer in the
future, for example. We are not designing software for mathematics but
for people. Attempting to understand how people think is very much
part of what we need to do from beginning to end in software
development. This is not only the case for the "user interface" but
for every aspect of software with which a human being (even if a
software developer) might interact in the future. Human cognition
should not be dismissed.
Another aspect that is related to "the way the Human Mind works" is
language. Yes, I think asking about mathematical structure is
important, but looking at how language and the human brain are related
to mathematical structures is also important. You have made statements
about how easy lists are for people. That is not a mathematical
statement.
Cheers! --dawn
> and won't get
> you anywhere.
>
>
> Marshall
>
> * http://en.wikipedia.org/wiki/Earth%27s_core
dawn wrote:
> Marshall Spight wrote:
> >
> > The question of what kind of mathematical structure is best
> > suited for a particular task is a good one. The question
> > of which one is most like "the Real World(tm)" or "the
> > way the Human Mind works" is not useful,
>
> I'll agree with the first, although using such terms can be a shortcut.
> I definitely disagree with the latter. When we are talking about
> humans modeling data or any aspect of software, it makes a lot of sense
> to ask how the human mind works.
I think I know what you mean, but I have to disagree with what
you said. We just don't *know* how the mind works. We have
scratched the surface, but we don't really know anything
substantive.
> It is a good idea to ask whether we
> are using an approach that renders an obscure specification that is
> likely to be misinterpreted by another software developer in the
> future, for example.
Sure. But what you're describing is usability, user interface,
whatever. It's categorically not "how the mind works."
There are people who will assert things as crazy as saying
that their brain is object-oriented, by which they mean
not that they find it easy or useful thinking in object oriented
terms, but that they actually believe there are representations
of objects inside their heads. Or lists, or imperative code,
or whatever it is. Not just metaphorically, but actually. There
are also people who will assert that physics or the natural
world is implicitly imperative, or ordered, or unordered, or
whatever. They are the CS equivalent of biblical literalists.
They are nuts of course.
Looking at good design, usability, etc. is a good thing. Believing
that one's thoughts are *implemented* in one's favorite
programming paradigm is a mild form of mental illness.
Marshall
Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
> > >
> > > The question of what kind of mathematical structure is best
> > > suited for a particular task is a good one. The question
> > > of which one is most like "the Real World(tm)" or "the
> > > way the Human Mind works" is not useful,
> >
> > I'll agree with the first, although using such terms can be a shortcut.
> > I definitely disagree with the latter. When we are talking about
> > humans modeling data or any aspect of software, it makes a lot of sense
> > to ask how the human mind works.
>
> I think I know what you mean, but I have to disagree with what
> you said. We just don't *know* how the mind works. We have
> scratched the surface, but we don't really know anything
> substantive.
If I am understanding you correctly, since we create mathematics (yes,
we discover patterns and use human logic, but people still create
mathematics), we can know the answer to questions we ask. We can prove
things within the bounds of a particular mathematical system. We do
not have this luxury with the brain, however. While we can gather some
emperical data about brains, we do not know how they work. So, the
question of how the human mind works, since has not been found to be
answerable, is not a good question to ask. Is that your position?
If I got that right, then I'll grant you your position, although I
disagree and find the question to be a good one even if the answer is
not forthcoming because we can advance in our knowledge by asking it.
Other possible questions that you might accept are:
1) To what extent does the interface between the underlying software
(e.g. dbms) and the software developer who is using this software
facilitate the development of software including quality, speed,
maintainability and other quality requirements?
2) To what extent does the interface between the underlying software
(e.g. dbms) and the software developer who is using this software
encourage the design of software that enhances the end-user's job,
including the quality of data gathered and the efficiency and
effectiveness of the resulting systems?
I'm sure I could wordsmith those down to fewer words if I took the
time, but these are two questions that relate to how human minds work,
but do not insist that we know precisely how they do work.
> > It is a good idea to ask whether we
> > are using an approach that renders an obscure specification that is
> > likely to be misinterpreted by another software developer in the
> > future, for example.
>
> Sure. But what you're describing is usability, user interface,
> whatever. It's categorically not "how the mind works."
Yes, the two questions I posed are about 1) usability for those
developing software applications and 2) usability for end-users.
Usability is definitely related to how the mind works, even if it is
not a statement that tells us precisely how the mind works.
> There are people who will assert things as crazy as saying
> that their brain is object-oriented, by which they mean
> not that they find it easy or useful thinking in object oriented
> terms, but that they actually believe there are representations
> of objects inside their heads. Or lists, or imperative code,
> or whatever it is. Not just metaphorically, but actually. There
> are also people who will assert that physics or the natural
> world is implicitly imperative, or ordered, or unordered, or
> whatever. They are the CS equivalent of biblical literalists.
Laughing. I'll grant that we don't know how our own minds work, nor
how our thought processes compare to those of others. However, there is
significant research on usability that we tend to apply to "end-users"
and would do well to apply to our own tools too. The research about
user interfaces could also apply to API's and computer languages. This
research is not definitive, however. It is based on how people think
and function and we don't have all of the answers. It includes
questions about organization and beauty, for example.
I like mathematics too, where you can give precise answers to
questions. Software development is not simply applied mathematics,
however, any more than clothing development is applied mathematics.
Certainly there are many aspects that can be modeled using mathematical
models. For those we can and should employ the appropriate mathematics
to get the job done properly. But there is an aspect of beauty and
pragmatics or functionality that isn't properly modeled with
mathematics.
I could get into Chomsky and mathematical models for language too, but
I would be wandering too far afield, I suspect.
> They are nuts of course.
I'll grant that if someone says their brain is OO, they are surely
speaking metaphorically even if they suggest otherwise. However, even
anecdotal information about how people perceive their minds to work can
help when working on issues of usability. I gave anecdotes on how the
term "computer science" doesn't resonate with me and how verbs,
relationships, and movement often work better for me than nouns. I
suggested that there was a bigger percentage of women in the travel
industry than the auto industry and suggested something analogous in
computing. I don't KNOW that my brain works this way. I don't KNOW
that this is a reason why there has been a decrease in women in
computing since moving from terms like "data processing" to "computer
science." I could be way off course. I'm not starting with any axioms
and deriving conclusions from them. But there are good questions to
ask in these fuzzy areas and we can get better and better
approximations to facts over time, I would think.
> Looking at good design, usability, etc. is a good thing. Believing
> that one's thoughts are *implemented* in one's favorite
> programming paradigm is a mild form of mental illness.
I would suggest that it is more likely a way of speaking loosely when
someone is reflecting and trying to interpret their own
thought-processes, at least that is how my brain works in interpreting
such statements ;-) --dawn
"Nowhere in the physical world will you find a mathematical
object. Directly comparing anything physical to anything
mathematical is invalid."
And how do I compare something without math? ? ?
topmind wrote:
> Ken Tilton wrote:
>
>>topmind wrote:
>>
>>>vc wrote:
>>>
>>>>Neo wrote:
>>>>
>>>>>Below is an example script for an experimental db (in development) that
>>>>>can store both data and code.
>>>>>
>>>>>Unlike typical databases, data is not stored using a table/record
>>>>>methodology, but via nodes where each node can connect to any other
>>>>>node, in a manner similar to neurons in the human brain.
>>>>
>>>>"We learn from history that we learn nothing from history."
>>>
>>>I used to store snippets of code or subroutine calls in the database
>>>during my ExBase days. Generally they were refered to as "control
>>>tables":
>>>
>>>http://www.geocities.com/tablizer/cntrl1.htm
>>>
>>>However, it is best to have a dynamically-typed RDB for such, and only
>>>SqLite comes close to this feature that I know of.
>>>
>>>But, what is wrong with tables such that the Lisp proponent does not
>>>want to use them?
>>
>>The world is not columns and rows, so you are forcing an unnatural
>>representation onto your data. Bad DBA, bad!
>
> The world is a big tangled graph/network. There is no inherent lasting
> sureshot order to it. However, when we model it, it is tough for humans
> to deal with it as a big tangled string blob. Thus, we impose
> organizational abstractions to model stuff yet be able to grok our
> models as humans. Hierarchies are another example of just such an
> artificial construct. Why do we put all our documents in tree-shaped
> folders and when the world is generally not tree-shaped? Answer:
> because we would go nuts without some kind of ordering.
>
> If you can propose something better than relational tables for
> organizing stuff, I am all ears. But remember:
>
> 1. It must be flexible
> 2. It must be fairly easy for humans to grok (understand, manage, sift)
>
> (Trees tend to fail #1. They cannot easily deal with lots of orthogonal
> categories and relative/custom views.)
Me to's may be frowned upon, I know. Yet, yes! Trees tend to
effect: first come first serve. When you have a vision not
fitting the hierarchy of the status quo you are out of luck.
mAsterdam <·········@vrijdag.org> writes:
> topmind wrote:
> > (Trees tend to fail #1. They cannot easily deal with lots of
> > orthogonal
> > categories and relative/custom views.)
Neither can a table. Indeed, they are typically even worse at this.
> Me to's may be frowned upon, I know. Yet, yes! Trees tend to
> effect: first come first serve. When you have a vision not
> fitting the hierarchy of the status quo you are out of luck.
A single table is just as bad in this respect.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> mAsterdam <·········@vrijdag.org> writes:
>
>
>>topmind wrote:
>>
>>>(Trees tend to fail #1. They cannot easily deal with lots of
>>>orthogonal
>>>categories and relative/custom views.)
>
>
> Neither can a table. Indeed, they are typically even worse at this.
>
>
>
>>Me to's may be frowned upon, I know. Yet, yes! Trees tend to
>>effect: first come first serve. When you have a vision not
>>fitting the hierarchy of the status quo you are out of luck.
>
>
> A single table is just as bad in this respect.
How so?
(This may be professionally biased:)
Tables tend to come in herds.
Then the world is more like a relational database . There are no real
connections between objects we make them up as we need them (like
joining) probably some properties of the object define the
relationship. I am very philosophical today :)
"The world is not columns and rows, so you are forcing an unnatural
representation onto your data. Bad DBA, bad!
:)"
The world is not bits and bytes so what am i doing behind my computer
reading this on such a nice sunny free day bad me bad ;-)
Neo wrote:
> Below is an example script for an experimental db (in development) that
> can store both data and code.
Hey, Neo, been a long time. How you doing? Reading up on Lisp
I see. Always good to do.
Marshall
> Reading up on Lisp I see. Always good to do.
There is something very interesting about LISP. I didn't ever start off
with the intention of making the db scripting language like LISP. In
fact, it started off closer to SQL. But it is turning out that a LISP
like syntax is a natural fit because it, like the db, is based heavily
on recursion.
"Neo" <········@hotmail.com> wrote in message
·····························@i40g2000cwc.googlegroups.com...
> Below is an example script for an experimental db (in development) that
> can store both data and code.
[snip]
> Any constructive comments appreciated.
>
> // ----------------------------------------------------
> // SIMPLE CAR EXAMPLE
> // Create car named rx7.
>
> // Create a new name with symbols 'car'
> (create name instance (new))
> (create (it) symbol (create 'c' 'a' 'r'))
[snip snip snipsnipsnip]
I will gnaw my legs off before I will write code like that to earn a living!
(And at this point I don't care what benefits you imagine it confers, so I
don't mind that you haven't bothered to explain.)
Roy
Roy Hann wrote:
> "Neo" <········@hotmail.com> wrote in message
> ·····························@i40g2000cwc.googlegroups.com...
> > Below is an example script for an experimental db (in development) that
> > can store both data and code.
>
> [snip]
>
> > Any constructive comments appreciated.
> >
> > // ----------------------------------------------------
> > // SIMPLE CAR EXAMPLE
> > // Create car named rx7.
> >
> > // Create a new name with symbols 'car'
> > (create name instance (new))
> > (create (it) symbol (create 'c' 'a' 'r'))
> [snip snip snipsnipsnip]
>
> I will gnaw my legs off before I will write code like that to earn a living!
> (And at this point I don't care what benefits you imagine it confers, so I
> don't mind that you haven't bothered to explain.)
Yes.
Why does car have to be written 'c' 'a' 'r'?
Why not
(create (it) symbol (create "car"))
And it could probably be simpler than that.
Also I find it easier to read if keywords inside a form begin with
colons.
Roy Hann wrote:
> "Neo" <········@hotmail.com> wrote in message
> ·····························@i40g2000cwc.googlegroups.com...
> > Below is an example script for an experimental db (in development) that
> > can store both data and code.
>
> [snip]
>
> > Any constructive comments appreciated.
> >
> > // ----------------------------------------------------
> > // SIMPLE CAR EXAMPLE
> > // Create car named rx7.
> >
> > // Create a new name with symbols 'car'
> > (create name instance (new))
> > (create (it) symbol (create 'c' 'a' 'r'))
> [snip snip snipsnipsnip]
>
> I will gnaw my legs off before I will write code like that to earn a living!
> (And at this point I don't care what benefits you imagine it confers, so I
> don't mind that you haven't bothered to explain.)
'L' 'o' 'o' 'k' 's' ' ' 'f' 'i' 'n' 'e' ' ' 't'o' ' ' 'm' 'e' :-)
-T-
>
> Roy
>> (create (it) symbol (create 'c' 'a' 'r'))
>
> I will gnaw my legs off before I will write code like that to earn a living!
:) Yes, I agree the "beauty" of the above simple but highly recursive
syntax "(func param1 param2 ...)" where any element itself can be (func
param1 ...) and so on until eternity is difficult to appreciate.
> (And at this point I don't care what benefits you imagine it confers,
> so I don't mind that you haven't bothered to explain.)
I will try to explain with an analogy (realizing that each analogy can
be bended to any end). Imagine a mechanic with fixed-size wrenches of
sizes from 1 to 10. Nearly all the nuts he has to deal with are sizes
between 1 to 10. An odd size comes up once in a blue moon, but for the
most part his tool set is nearly perfect for his universe of tasks. Now
another mechanic comes along with a prototype of an adjustable wrench
and it supposedly can handle any nut size from 0.1 to 20. Upon initial
inspection of the new tool, the first mechanic says, I will gnaw my
legs off before using this new fangled tool. I don't see any benefit to
it. It is heavier and takes longer to setup and use. An that is exactly
true for nut sizes 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10. But now I offer
you a nut that is an off size of 12.34. I would like you (or other
mechanics) to use their current tools to create a function that can
find the root, given any specified hierarchy and given any specific
thing in that hierarchy. An important things is, the function should
work not only for data entered before writing the function, but also
for data (new hierarchies and things) entered after the function is
created. Below example demos this scenario.
// This example creates a number of persons
// and puts them in a bi-directional parent/child hierarchy.
// Then it creates a function (stored in db)
// that finds the root (in either direction)
// given a heirarchy and a person as parameters.
// Next the same persons are put in second boss/empolye hierarchy.
// The same function created earlier, without modification,
// finds the root of new hierarchies.
// While not necessary, the function uses recursion to find root.
// Create a type named person.
(create type instance (new))
(create (it) name (findElseAdd name instance 'person'))
// Create a person named god.
(create person instance (new))
(create (it) name (findElseAdd name instance 'god'))
// Create a person named adam.
(create person instance (new))
(create (it) name (findElseAdd name instance 'adam'))
// Create a person named eve.
(create person instance (new))
(create (it) name (findElseAdd name instance 'eve'))
// Create a person named abraham.
(create person instance (new))
(create (it) name (findElseAdd name instance 'abraham'))
// Create a person named issac.
(create person instance (new))
(create (it) name (findElseAdd name instance 'issac'))
// Create a person named ishmael.
(create person instance (new))
(create (it) name (findElseAdd name instance 'ishmael'))
// Note: the verbs parent/child are not created
// as they already exist in a default database.
// Create following parent/child hierarchy:
// god (root parent)
// adam & eve
// abraham
// issace & ishmael
(create god child adam)
(create adam parent god)
(create god child eve)
(create eve parent god)
(create adam child abraham)
(create abraham parent adam)
(create eve child abraham)
(create abraham parent eve)
(create abraham child issac)
(create issac parent abraham)
(create abraham child ishmael)
(create ishmael parent abraham)
// Create a function named getRoot with 2 parameters.
// Param1 indicates a hierarchy.
// Param2 indicate a person.
// Note: the function recurses.
(create function instance (new))
(create (it) name (findElseAdd name instance 'getRoot'))
(create (it) parameter 'hierarchy')
(create (it) parameter 'person')
// Switch to save script in db mode via GUI.
(getRoot
code
(block
(createVar 'higherPerson')
(create (getVar 'higherPerson')
refersTo
(firstNode (select (getVarVal 'person')
(getVarVal 'hierarchy')
*
)
)
)
(if (getVarVal 'higherPerson')
// Then
(return (getRoot (getVarVal 'hierarchy')
(getVarVal 'higherPerson')
)
)
// Else
(return (firstNode (getVarVal 'person')
)
)
)
)
)
// Switch back to execute script mode via GUI.
// Get root parent of various persons.
// Displays god.
(msgbox (getRoot parent god))
(msgbox (getRoot parent adam))
(msgbox (getRoot parent eve))
(msgbox (getRoot parent abraham))
(msgbox (getRoot parent issac))
(msgbox (getRoot parent ishmael))
// Get root child of various persons.
// Displays issac.
// Note: Should also display ishmael, but simple function doesn't.
(msgbox (getRoot child issac))
(msgbox (getRoot child abraham))
(msgbox (getRoot child eve))
(msgbox (getRoot child adam))
(msgbox (getRoot child god))
// Place above persons in a new boss/employe hierarchy.
// Create a verb named boss.
(create verb instance (new))
(create (it) name (findElseAdd name instance 'boss'))
// Create a verb named employe.
(create verb instance (new))
(create (it) name (findElseAdd name instance 'employe'))
// Create following boss/employe hierarchy:
// issac & ishmael (root boss)
// abraham
// adam
// eve
(create issac employe abraham)
(create abraham boss issac)
(create ishmael employe abraham)
(create abraham boss ishmael)
(create abraham employe adam)
(create adam boss abraham)
(create adam employe eve)
(create eve boss adam)
// Get root boss for various persons using function created earlier.
// Displays issac.
// Note: Should also display ishmael, but simple function doesn't.
(msgbox (getRoot boss issac))
(msgbox (getRoot boss abraham))
(msgbox (getRoot boss adam))
(msgbox (getRoot boss eve))
// Get root employe for various persons.
// Displays eve.
(msgbox (getRoot employe eve))
(msgbox (getRoot employe adam))
(msgbox (getRoot employe abraham))
(msgbox (getRoot employe issac))
(msgbox (getRoot employe ishmael))
// EXPERIMENTAL DB DESCRIPTION ----------------------------------------
The experimental db can store both data and code.
Unlike typical databases, data is not stored using a table/record
methodology, but via nodes where each node can connect to any other
node in a manner similar to neurons in the human brain.
The experimental db has a LISP-like interface. In general each
expression
starts with "(" and ends with ")". Within the parentheses there can be
any number of elements which are typically seperated by a space.
The first element is the function.
The remaining elements are function parameters.
Expression elements can themselves be a sub expression
and elements of the sub expression can
also be a sub expression and so on forever (theoretically).
Thus, a typical expression might be:
(func1 param1 param2 param3 ...)
where any element be a sub expression, ie:
(func1 (func2 param1 param2 ...) param2 param3 ...)
and so on:
(func1 (func2 param1 (func3 param1 ...)) param2 param3 ...)
also can be rearranged as:
(func1 (func2 param1
(func3 param1
...
)
...
)
param2
param3
...
)
Because of the number of parentheses,
script can be made more legibile by
1) using fixed font
2) lining up corresponding parentheses.
Note, that the db's "schema" is such that anything can have 0 to many
names.
And a name can have 0 to many representations
such as a string of ascii symbols, chinese symbols, phonetics, etc
(only ascii symbols are implemented currently).
Functions can create local variables which are stored on a
"stack" which is also in the db and functions (system or user-defined)
are re-entrant.
// CONVENTIONS, SHORTCUTS, COMMON FUNCTIONS
------------------------------
In scripts, comments begin with two forward slashes "//" (as in C/C++).
(new) create a new node to represent something.
(it) refers to the thing created by last (new) in current scope.
When a script containing 'xyz' is processed, str 'xyz' is created it in
db, even if it does not exist.
This is done to reduce length/complexity of scripts.
// An element enclosed by single quote is equivalent to:
'xyz' => (select 'x' 'y' 'z')
// An element not enclosed by quotes (ie xyz) is equivalent to
// finding the first thing whose first name's first symbols string is
as specified (ie 'xyz).
xyz =>
(firstNode (select *
name
(firstNode (and (select name instance *)
(select * symbol 'xyz')
)
)
)
)
// Function findElseAdd finds the instance of specified class
// whose name has the specified symbol string.
(findElseAdd name instance 'bob') =>
(if (and (select name instance *)
(select * symbol 'bob')
)
// Then
(return (select * symbol 'bob'))
// Else
(block
(create name instance (new))
(create (it) symbol (create 'b' 'o' 'b'))
(return (it))
)
)
// Function createVar creates a variable (on the stack in current
scope).
// whose name's has the specified symbol string.
(createVar 'var1') =>
(block
(create (new) name (findElseAdd name instance 'var1'))
(create (select stackPtr refersTo *) variable (it))
)
// Function getVar selects a variable (on the stack in current scope)
// whose name's has the specified symbol string.
(getVar 'var1') =>
(and (select (select stackPtr refersTo *) variable *)
(select * name (select * symbol 'var1'))
)
// Function getVarVal selects the "value" of a variable
// (on the stack in current scope)
// whose name's has the specified symbol string.
(getVarVal 'var1') =>
(select (getVar 'var1') refersTo *)
"Neo" <········@hotmail.com> wrote in message
····························@e56g2000cwe.googlegroups.com...
> Now
> another mechanic comes along with a prototype of an adjustable wrench
> and it supposedly can handle any nut size from 0.1 to 20. Upon initial
> inspection of the new tool, the first mechanic says, I will gnaw my
> legs off before using this new fangled tool.
Your "analogy" proposes a good solution to a problem. But your so-called
analogy is not an analogy. Had it involved a large, truck-mounted,
diesel-powered hydraulic-actuated wrench, requiring a skilled specialist
operator and a maintenance budget that would make the military blush, it
would have been much more apt.
Roy
> ... your so-called analogy is not an analogy. Had it involved a large,
> truck-mounted, diesel-powered hydraulic-actuated wrench,
> requiring a skilled specialist operator and a maintenance budget that
> would make the military blush, it would have been much more apt.
:) Yes, you are correct in that when initially seeing a monotonous
interface having the structure "(func par1 par2 ...)" where any
element (function or parameter) within the parentheses can itself have
a similar structure, and so on forever, it must seem like "a large,
truck-mounted, diesel-powered hydraulic-actuated wrench, requiring a
skilled specialist operator ...". However, I assert the reverse is true
for the problem presented. To prove or disprove this assertion, I need
you (or anyone else) to post an equivalent solution using your
preferred tool.
Breifly stated, create a function that given a hierarchy and a thing in
the hierarchy returns the root. Not only should the function work for
data entered prior to writing the function but also for new data
entered after the function is written. I have already posted a solution
using the experimental db with a LISP-like interface (which is in its
embryonic stage of development). Please post your solution so that we
can make a comparison.
> ... Not only should the function work for data entered
> prior to writing the function but also for new data
> entered after the function is written.
Below script provides a further example of the above. Suppose we now
add a new person who doesn't have a name but his color is purple. And
we make him an employe of ishmael. Will the original db, schema and
user-defined function still work? See below:
// Create a new person with no name but his color is purple
// and make him an employe of ishmael.
(create type instance (new))
(create (it) name (findElseAdd name instance 'color'))
(create person instance (new))
(create (it) color (findElseAdd color instance 'purple'))
(create (it) boss ishmael)
(create ishmael employe (it))
// Get root boss of the person whose color is purple.
// Displays ishmael !!!
(msgbox (getRoot boss
(and (select person instance *)
(select * color purple)
)
)
)
Notice above, the second parameter to the getRoot function, which in
prior examples has been a simple parameter such as adam, eve, abraham
.... has been substituted by a sub-expression which resolves to the
purple-colored person without a name.
From: lin8080
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <442E26A5.47493B5A@freenet.de>
Neo schrieb:
> > ... Not only should the function work for data entered
> > prior to writing the function but also for new data
> > entered after the function is written.
Does
(shared-initialize)
do the job?
See HyperSpec for more.
stefan
> > ... Not only should the function work for data entered
> > prior to writing the function but also for new data
> > entered after the function is written.
>
> Does (shared-initialize) do the job? See HyperSpec for more.
Thanks for the suggestion. I am not familiar with
"(shared-initialize)", so I can't say for sure, however the central
issue is related to starting off with a general enough schema prior to
entering data and writing a general enough function such that they
don't need to be modified later to incorporate new things and
relations. I have demonstrated several times in the past (in c.d.t.)
that while RM is an excellent tool (for nut sizes 1-10) it is more
susceptible to schema changes, data migration overhead and code/query
rewrites for some non-mainstream/AI-type cases (ie nut size 12.34).
If someone knows how to address the above issue using
"(shared-initialize)" and apply it to the hierarchy example, could they
post it?
> ... Not only should the function work for data entered
> prior to writing the function but also for new data
> entered after the function is written.
Below script provides a further example of the above. Suppose we want
the name whose symbol string is currently 'employe' to also have the
symbol string 'employee' (note the additional 'e' at end). Will the
original db, schema and user-defined function still work? See below:
// Allow existing name whose symbol string is 'employe'
// to have a second symbol string 'employee'.
(create (and (select name instance *)
(select * symbol 'employe')
)
symbol
'employee'
)
// Verify getRoot function works with employe and employee.
// Both of the following display eve !!!
(msgbox (getRoot employe adam))
(msgbox (getRoot employee adam))
Note that in the above expressions, employe is translated by parser
into:
(firstNode (select * name (firstNode (select * symbol (select 'e' 'm'
'p' 'l' 'o' 'y' 'e')))))
And employee is translated by parser into:
(firstNode (select * name (firstNode (select * symbol (select 'e' 'm'
'p' 'l' 'o' 'y' 'e' 'e')))))
Both of the above queries find the same verb instance whose name has
two similar symbol strings.
From: Bill Atkins
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <8764ltja1v.fsf@rpi.edu>
"Neo" <········@hotmail.com> writes:
>> ... Not only should the function work for data entered
>> prior to writing the function but also for new data
>> entered after the function is written.
>
> Below script provides a further example of the above. Suppose we want
> the name whose symbol string is currently 'employe' to also have the
> symbol string 'employee' (note the additional 'e' at end). Will the
> original db, schema and user-defined function still work? See below:
>
> // Allow existing name whose symbol string is 'employe'
> // to have a second symbol string 'employee'.
> (create (and (select name instance *)
> (select * symbol 'employe')
> )
> symbol
> 'employee'
> )
Use standard style - don't put closing parentheses on their own lines
and use hyphens instead of the accursed camel case.
> // Verify getRoot function works with employe and employee.
> // Both of the following display eve !!!
> (msgbox (getRoot employe adam))
> (msgbox (getRoot employee adam))
>
> Note that in the above expressions, employe is translated by parser
> into:
> (firstNode (select * name (firstNode (select * symbol (select 'e' 'm'
> 'p' 'l' 'o' 'y' 'e')))))
Does this even compile? If you want to refer to a specific character,
use #\x where x is the character. But the question remains: why are
you passing in each character of a word separately?
> And employee is translated by parser into:
> (firstNode (select * name (firstNode (select * symbol (select 'e' 'm'
> 'p' 'l' 'o' 'y' 'e' 'e')))))
>
> Both of the above queries find the same verb instance whose name has
> two similar symbol strings.
Your code is not very idiomatic, and is downright baffling at times, e.g.:
(create (it) name (findElseCreate name instance 'accord'))
I have no idea what this means (and to be perfectly frank, no real
interest in finding out).
> Use standard style - don't put closing parentheses on their own lines
Since some expressions involve sub expressions to a large depth (like
the ones shown earlier), it is easier for me to verify proper number
and placement of parentheses by lining them up vertically in a
fixed-font editor. But I think you are correct that after such
verfication, the closing parenthesis could be moved to the prior line
to make the script more compact and conserve veritcal space.
// Thus the following is less preferrable ...
(func1 param1
(func2 param1
param2
...
)
param3
...
)
// ... than the below (according to "standard style").
(func1 param1
(func2 param1
param2
...)
param3
...)
I haven't formed a standard style for writting expressions in the
LISP-like interface to the experimental db, thus you see the lack of
it, in my postings.
> and use hyphens instead of the accursed camel case.
I had no I idea what that meant, so I googled around. It seems you are
saying to use "get-root" instead of "getRoot" to identify the function.
My choice of capitalizing the first letter of subsequent words and
concatenating together is now hardWired in my brain from having
programmed in C for a while (which does not allow a dash). Since this
is not a limitation in the LISP-like interface, I will have to
re-evaluate my personal preference. From the few posts that I googled,
it seems the dash is preferred to the underscore which is preferred to
camelCase (get-root > get_root > getRoot). At the moment, get-root
makes me think of subtracting root from get. Also, the dash in get-root
makes me think it is multi-worded modifier of the next word as in
hot-blooded male, hard-wired memory, make-it-happen thinking, etc. Also
some word processors, like that in google, will split get-root over two
lines, if it appears near the end of a long sentence :)
>> (firstNode (select * name (firstNode (select * symbol (select 'e' 'm'
>> 'p' 'l' 'o' 'y' 'e')))))
>
> Does this even compile?
It would depend on your definition of "compile" and in reference to who
or what. But in general, the parser doesn't compile it in the sense of
converting high-level instructions to a list of values executable by
the CPU.
> If you want to refer to a specific character, use #\x where x is the character.
:) you are probably correct (the db interface is LISP-like, not LISP).
> But the question remains: why are you passing in each character of a word separately?
I was showing what a simple element of an expression actually
translates into by the LISP-like parser.
> Your code is not very idiomatic, and is downright baffling at times, e.g.:
:)
>> (create (it) name (findElseCreate name instance 'accord'))
>
> I have no idea what this means
In simple terms names a thing with an existing name. If the name does
not exist, creates it. The approximate equivalent in a relational
database would be:
First there exists a table named T_Symbols with a row for each symbol
(ie a, b, c ...).
Insert a record in T_String.
Insert 6 records in T_String_Symbol_Map,
which relates the new record in T_String with records for 'a', 'c',
'c', 'o', 'r', 'd' in T_Symbols.
Insert a record in T_Name.
Insert a record in T_Name_String_Map,
which relates the new record in T_Name with the new record in T_String.
Insert a record in T_Thing.
Insert a record in T_Thing_Name_Map,
which relates the new record in T_Thing with the new record in T_Name.
> .. and to be perfectly frank, no real interest in finding out).
That is ok. However I would be interested in seeing a LISP solution (or
any other methodoloy's) to the original problem. I'll restate it
breifly here.
Create a function that given a hierarchy and a thing in the hierarchy
returns the root. In C, it might look like: getRoot(hierarchy, thing)
or getRoot(parent, adam) or getRoot(child, god). Each thing can be in
any number of other hierarchies. Not only should the function work for
things/hierarchies entered (in db or something roughly equivalent)
prior to writing the function but also for the same or new things in
new hierarchies specified after the function is written! (I have
already posted such a solution using the experimental db with LISP-like
interface)
The initial data included the following persons in a parent/child
hierarchy:
god (root parent)
__adam & eve
____abraham
______issace & ishmael
See earlier posts for details.
From: John Landahl
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <87lkunk29s.fsf@mobile.landahl.org>
In which we see some of the disadvantages of more people glomming onto
that cool Lisp thing: neophytes who think they're wizards, having
skipped over learning any of the basic elements of the Lisp Way.
"Neo" <········@hotmail.com> writes:
[...]
> But I think you are correct that after such verfication, the closing
> parenthesis could be moved to the prior line to make the script more
> compact and conserve veritcal space.
[...]
> I haven't formed a standard style for writting expressions in the
> LISP-like interface to the experimental db, thus you see the lack of
> it, in my postings.
One doesn't form one's own "standard style". You'll offend people
with this attitude, and at the very least people looking at your code
are going to say "ugh, newbie code" and stop there. But your code has
*much* bigger problems than just this...
>> and use hyphens instead of the accursed camel case.
>
> I had no I idea what that meant, so I googled around. It seems you
> are saying to use "get-root" instead of "getRoot" to identify the
> function. My choice of capitalizing the first letter of subsequent
> words and concatenating together is now hardWired in my brain from
> having programmed in C for a while (which does not allow a dash).
Consider fixing your brain rather than expecting an entire programming
community to forget decades of practice and style, or at least don't
be surprised when you get strong negative reactions to your work. You
had to google for this? Have you actually read any Lisp code?
> :) you are probably correct (the db interface is LISP-like, not
> LISP).
Smiley?
This is what's really wrong with your code, and why it evokes such
strong negative reactions. It's not Lisp, it's not even "Lisp-like".
Macros are there for a reason: among other things, they can turn
hideous code like this interface of yours into simple and elegant
constructs that people will actually want to use.
>> Your code is not very idiomatic, and is downright baffling at
>> times, e.g.:
>
> :)
Smiley?
Well-written, idiomatic code is a must -- the bare minimum -- for
anything you intend anyone else to use. Beyond that it should
simplify a task, *not* make it more complex.
>>> (create (it) name (findElseCreate name instance 'accord'))
>>
>> I have no idea what this means
>
> In simple terms names a thing with an existing name. If the name does
> not exist, creates it. The approximate equivalent in a relational
> database would be:
>
> First there exists a table named T_Symbols with a row for each symbol
> (ie a, b, c ...).
> Insert a record in T_String.
> Insert 6 records in T_String_Symbol_Map,
> which relates the new record in T_String with records for 'a', 'c',
> 'c', 'o', 'r', 'd' in T_Symbols.
You *do* realize that Lisp already has symbol tables, don't you? And
that you can create packages to hold symbols? What on earth are you
doing here? And why should the string "accord" require a separate
record for each character?!
>> .. and to be perfectly frank, no real interest in finding out).
>
> That is ok. However I would be interested in seeing a LISP solution (or
> any other methodoloy's) to the original problem. I'll restate it
> breifly here.
>
> Create a function that given a hierarchy and a thing in the hierarchy
> returns the root. In C, it might look like: getRoot(hierarchy, thing)
> or getRoot(parent, adam) or getRoot(child, god).
This is trivial to do with CLOS objects, or any of a number of other
ways for that matter, and macros can provide a very simple interface
for creating objects and setting their relationships.
You're not doing a very good job of communicating the problem or set
of problems that you're trying to solve. It *seems* that you want
something like a combination of LISA <http://lisa.sourceforge.net/>
and CL-Prevalence <http://common-lisp.net/project/cl-prevalence/> or
Elephant <http://common-lisp.net/project/elephant/> or even CLSQL
<http://clsql.b9.com/>. Anyone who feels the need for something like
LISA would go there first, and use it with whichever database back-end
suits them.
One thing you mentioned in your original post seems to hint at why you
want to punish people who use your database:
> The db assumes that anything can have 0 to many names. And a name
> can have 0 to many representations such as a string of ascii
> symbols, chinese symbols, sounds, etc (only ascii symbols are
> implemented currently).
If this is really necessary (you haven't explained why), it's
something that can be hidden away in the back-end, perhaps by allowing
any object to have 0..** associated "representation" objects (or
whatever you want to call them). Functions and macros can make it
simple to add these objects when needed, without requiring your users
to work with such an amazingly contorted interface 99% of the time.
You might try looking at the three libraries mentioned above for
examples of non-sadistic storage APIs.
Some rather important things you haven't mentioned are transaction
support, ACID compliance, two-phase commit, and the like. Without
those you don't have much of a database, at least not one that anyone
will actually use. But hey, cheers.
--
John Landahl <····@landahl.org> "_jpl_"
http://landahl.org/john
> > Create a function that given a hierarchy and a thing in the hierarchy
> > returns the root. In C, it might look like: getRoot(hierarchy, thing)
> > or getRoot(parent, adam) or getRoot(child, god). Each thing can be in
> > any number of other hierarchies. Not only should the function work for
> > things/hierarchies entered (in db or something roughly equivalent)
> > prior to writing the function but also for the same or new things in
> > new hierarchies specified after the function is written!
> > The initial data included the following persons in a parent/child
> > hierarchy:
> > god (root parent)
> > __adam & eve
> > ____abraham
> > ______issace & ishmael
> > See earlier posts for details.
> This is trivial to do with CLOS objects ...
Thanks for the constructive comments. Could you post your actual
solution/code. This would be helpful in fixing my brain.
From: Bill Atkins
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <87acb3z8kd.fsf@rpi.edu>
"Neo" <········@hotmail.com> writes:
>> Use standard style - don't put closing parentheses on their own lines
>
> Since some expressions involve sub expressions to a large depth (like
> the ones shown earlier), it is easier for me to verify proper number
> and placement of parentheses by lining them up vertically in a
> fixed-font editor. But I think you are correct that after such
Stop! Use Emacs, with Paredit. If you still haven't gotten past
counting parentheses, what makes you think that that you know enough
about Lisp to write.... whatever it is that you're writing?
> verfication, the closing parenthesis could be moved to the prior line
> to make the script more compact and conserve veritcal space.
>
> // Thus the following is less preferrable ...
> (func1 param1
> (func2 param1
> param2
> ...
> )
> param3
> ...
> )
>
> // ... than the below (according to "standard style").
> (func1 param1
> (func2 param1
> param2
> ...)
> param3
> ...)
>
> I haven't formed a standard style for writting expressions in the
> LISP-like interface to the experimental db, thus you see the lack of
> it, in my postings.
>
>> and use hyphens instead of the accursed camel case.
>
> I had no I idea what that meant, so I googled around. It seems you are
> saying to use "get-root" instead of "getRoot" to identify the function.
> My choice of capitalizing the first letter of subsequent words and
> concatenating together is now hardWired in my brain from having
> programmed in C for a while (which does not allow a dash). Since this
> is not a limitation in the LISP-like interface, I will have to
> re-evaluate my personal preference. From the few posts that I googled,
> it seems the dash is preferred to the underscore which is preferred to
> camelCase (get-root > get_root > getRoot). At the moment, get-root
> makes me think of subtracting root from get. Also, the dash in get-root
> makes me think it is multi-worded modifier of the next word as in
> hot-blooded male, hard-wired memory, make-it-happen thinking, etc. Also
> some word processors, like that in google, will split get-root over two
> lines, if it appears near the end of a long sentence :)
>
>>> (firstNode (select * name (firstNode (select * symbol (select 'e' 'm'
>>> 'p' 'l' 'o' 'y' 'e')))))
>>
>> Does this even compile?
>
> It would depend on your definition of "compile" and in reference to who
> or what. But in general, the parser doesn't compile it in the sense of
> converting high-level instructions to a list of values executable by
> the CPU.
It doesn't really depend on my definition of anything - your code's
not valid Lisp, unless you introduced a new readtable somewhere
outside of the code you posted. READ will fail when fed this code.
>> If you want to refer to a specific character, use #\x where x is the character.
>
> :) you are probably correct (the db interface is LISP-like, not LISP).
>
>> But the question remains: why are you passing in each character of a word separately?
>
> I was showing what a simple element of an expression actually
> translates into by the LISP-like parser.
>
>> Your code is not very idiomatic, and is downright baffling at times, e.g.:
>
> :)
>
>>> (create (it) name (findElseCreate name instance 'accord'))
>>
>> I have no idea what this means
>
> In simple terms names a thing with an existing name. If the name does
> not exist, creates it. The approximate equivalent in a relational
> database would be:
>
> First there exists a table named T_Symbols with a row for each symbol
> (ie a, b, c ...).
> Insert a record in T_String.
> Insert 6 records in T_String_Symbol_Map,
> which relates the new record in T_String with records for 'a', 'c',
> 'c', 'o', 'r', 'd' in T_Symbols.
> Insert a record in T_Name.
> Insert a record in T_Name_String_Map,
> which relates the new record in T_Name with the new record in T_String.
> Insert a record in T_Thing.
> Insert a record in T_Thing_Name_Map,
> which relates the new record in T_Thing with the new record in T_Name.
>
>> .. and to be perfectly frank, no real interest in finding out).
>
> That is ok. However I would be interested in seeing a LISP solution (or
> any other methodoloy's) to the original problem. I'll restate it
> breifly here.
>
> Create a function that given a hierarchy and a thing in the hierarchy
> returns the root. In C, it might look like: getRoot(hierarchy, thing)
> or getRoot(parent, adam) or getRoot(child, god). Each thing can be in
> any number of other hierarchies. Not only should the function work for
> things/hierarchies entered (in db or something roughly equivalent)
> prior to writing the function but also for the same or new things in
> new hierarchies specified after the function is written! (I have
> already posted such a solution using the experimental db with LISP-like
> interface)
>
> The initial data included the following persons in a parent/child
> hierarchy:
> god (root parent)
> __adam & eve
> ____abraham
> ______issace & ishmael
>
>
> See earlier posts for details.
????
> Use standard style - don't put closing parentheses on their own lines
Since some expressions involve sub expressions to a large depth (like
the ones shown earlier), it is easier for me to verify proper number
and placement of parentheses by lining them up vertically in a
fixed-font editor. But I think you are correct that after such
verfication, the closing parenthesis could be moved to the prior line
to make the script more compact and conserve veritcal space.
// Thus the following is less preferrable ...
(func1 param1
(func2 param1
param2
...
)
param3
...
)
// ... than the below (according to "standard style").
(func1 param1
(func2 param1
param2
...)
param3
...)
I haven't formed a standard style for writting expressions in the
LISP-like interface to the experimental db, thus you see the lack of
it, in my postings.
> and use hyphens instead of the accursed camel case.
I had no I idea what that meant, so I googled around. It seems you are
saying to use "get-root" instead of "getRoot" to identify the function.
My choice of capitalizing the first letter of subsequent words and
concatenating together is now hardWired in my brain from having
programmed in C for a while (which does not allow a dash). Since this
is not a limitation in the LISP-like interface, I will have to
re-evaluate my personal preference. From the few posts that I googled,
it seems the dash is preferred to the underscore which is preferred to
camelCase (get-root > get_root > getRoot). At the moment, get-root
makes me think of subtracting root from get. Also, the dash in get-root
makes me think it is multi-worded modifier of the next word as in
hot-blooded male, hard-wired memory, make-it-happen thinking, etc. Also
some word processors, like that in google, will split get-root over two
lines, if it appears near the end of a long sentence :)
>> (firstNode (select * name (firstNode (select * symbol (select 'e' 'm'
>> 'p' 'l' 'o' 'y' 'e')))))
>
> Does this even compile?
It would depend on your definition of "compile" and in reference to who
or what. But in general, the parser doesn't compile it in the sense of
converting high-level instructions to a list of values executable by
the CPU.
> If you want to refer to a specific character, use #\x where x is the character.
:) you are probably correct (the db interface is LISP-like, not LISP).
> But the question remains: why are you passing in each character of a word separately?
I was showing what a simple element of an expression actually
translates into by the LISP-like parser.
> Your code is not very idiomatic, and is downright baffling at times, e.g.:
:)
>> (create (it) name (findElseCreate name instance 'accord'))
>
> I have no idea what this means
In simple terms names a thing with an existing name. If the name does
not exist, creates it. The approximate equivalent in a relational
database would be:
First there exists a table named T_Symbols with a row for each symbol
(ie a, b, c ...).
Insert a record in T_String.
Insert 6 records in T_String_Symbol_Map,
which relates the new record in T_String with records for 'a', 'c',
'c', 'o', 'r', 'd' in T_Symbols.
Insert a record in T_Name.
Insert a record in T_Name_String_Map,
which relates the new record in T_Name with the new record in T_String.
Insert a record in T_Thing.
Insert a record in T_Thing_Name_Map,
which relates the new record in T_Thing with the new record in T_Name.
> .. and to be perfectly frank, no real interest in finding out).
That is ok. However I would be interested in seeing a LISP solution (or
any other methodoloy's) to the original problem. I'll restate it
breifly here.
Create a function that given a hierarchy and a thing in the hierarchy
returns the root. In C, it might look like: getRoot(hierarchy, thing)
or getRoot(parent, adam) or getRoot(child, god). Each thing can be in
any number of other hierarchies. Not only should the function work for
things/hierarchies entered (in db or something roughly equivalent)
prior to writing the function but also for the same or new things in
new hierarchies specified after the function is written! (I have
already posted such a solution using the experimental db with LISP-like
interface)
The initial data included the following persons in a parent/child
hierarchy:
god (root parent)
__adam & eve
____abraham
______issace & ishmael
See earlier posts for details.
> ... Not only should the function work for data entered
> prior to writing the function but also for new data
> entered after the function is written.
Below script provides a further example of the above. Suppose we want
the existing verb whose name's symbol string is 'boss' to have a second
name whose symbol string will be 'employer'. Will the original db,
schema and user-defined function still work? See below:
// Allow existing verb whose name's symbol string is 'boss'
// to have a second name whose symbol string is 'employer'.
(create (and (select name instance *)
(select * symbol 'boss')
)
name
(findElseAdd name instance 'employer')
)
// Verify getRoot function works with boss and employer.
// Both of the following display issac !!!
(msgbox (getRoot boss abraham))
(msgbox (getRoot employer abraham))
One might wonder if it is necessary to model things differently from
their names differently from their symbols strings differerently from
their symbols. It just depends on a particular application's
requirements. It would be an overkill for most applications.
> Below is an example script for an experimental db (in development) that
> can store both data and code.
> Unlike typical databases, data is not stored using a table/record
> methodology, but via nodes where each node can connect to any other
> node, in a manner similar to neurons in the human brain.
This is actually very similar to GemStone/S, an OODB based on the
Smalltalk language http://www.gemstone.com/products/smalltalk. Since
Smalltalk methods are just objects they are stored in the database just
like any other object. When Java came on the scene, GemStone
introduced Facets http://www.facetsodb.com/web/index.html. With Facets
the classes are not stored directly in the database (to match the Java
conventions of having the code in a classpath).
Both GemStone/S and Facets are "active object" databases, providing
transparent persistence by reachability and directly executing the
methods on the persistent objects without having to explicitly fetch or
store instances.
Bob
["Followup-To:" header set to comp.lang.lisp.]
Neo <········@hotmail.com> wrote:
> Below is an example script for an experimental db (in development) that
> can store both data and code.
>
> Unlike typical databases, data is not stored using a table/record
> methodology, but via nodes where each node can connect to any other
> node, in a manner similar to neurons in the human brain.
Congratulations, you've re-invented the Network database model which is
more than 30 years old: http://en.wikipedia.org/wiki/Network_model
> Any constructive comments appreciated.
Have a look at the datastore component of bknr and at the existing Lisp
libraries for accessing relational databases.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
> Congratulations, you've re-invented the Network database model
> which is more than 30 years old. Have a look at the
> datastore component of bknr and at the existing Lisp libraries
> for accessing relational databases.
It has been my experience that the relational model isn't able to offer
practical solutions to the kind of applications (somewhat AI-ish,
odd-size 12.34) that I am interested in; so I am not sure how adding a
layer on top it (LISP or other) would be helpful. But if you can post a
RM solution that is as flexible as the getRoot function created with
the experimental db, you will have restored my faith :) See responses
to Roy Hann for details.
From: Dmitry Gorbatovsky
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <e0eta3$547$1@emma.aioe.org>
Neo wrote:
> Because of the high degree of separation between the logical and
> physical layers and the extreme flexibility of the db, the amount of
> memory and processing power required are limiting factors (currently).
>
I am not kind of DB or Lisp guru ,
so it is unclear for me what kind of
problem you solving. I mean what the benefits
aside from "memory and processing power required"
from such structured information .
I would be glad to discuss it constructively.
Regards
--
*Once you understand how to write a program get someone
else to write it.
> > Neo: ... experimental db that can store both data and code ...
>
> Lahman: My push back has to be: Why?
:) To approach the type of processing capability displayed by humans.
While I will not achieve anything like that in my life time,
manipulating code just like data allows solutions for some niche
applications (AI-ish) that are impractical with existing tools.
> Lahman: Commercial DBMSes already provide storage and execution
> of stored procedures. RAD IDEs already store everything in the DB.
> Source control systems already exist for managing code
> without requiring the tediousness of your example code.
Let me qualify what I mean by "storing code in a db". The code must be
stored in its elemental form (not as a chunk or blob) and can be
created, selected, updated, deleted, etc just as any other data. In
addition, code should be normalized just like regular data. The real
test, can one store code that can either modify itself or create new
code (which can itself create new code, and so on) using its standard
Data Manipulation Language (DML)? While I can't fully accomplish this
yet, I can show a crude example that creates and modifies a one line
query/code to determine if john's color is blue, as shown below:
// Assume person john has already been entered into db
// and his color is blue.
// Create a variable named 'myVar' which will refer to a query/code.
(create variable instance (new))
(create (it) name (findElseAdd name instance 'myVar'))
// Create query/code to verify john's color is blue
(select john color blue)
// Let myVar refer to above query/code.
(create myVar
refersTo
(select (select (select * name (select * symbol 'select')))
john
color
blue))
// Execute above query/code and display result.
// Displays "john color blue" meaning db stores this fact.
(msgbox (execute (select myVar refersTo *)))
// Modify above query/code to find "john's color is pink".
(update (select (select (select * name (select * symbol 'select')))
john
color
blue)
pink)
// Execute modified query/code.
// Displays nothing because the modified query
// does not return anything.
(msgbox (execute (select myVar refersTo *)))
Also, if one were to change the string related to the name of the type
color from the 'color' to 'colour', the original query (select john
color blue) would still function in the experimental db, where as it
probably would not in RM. Someone would need to manually, update the
spelling in stored procedures and recompile them.
From: John Landahl
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <87y7ynhs5q.fsf@mobile.landahl.org>
"Neo" <········@hotmail.com> writes:
[...]
> manipulating code just like data allows solutions for some niche
> applications (AI-ish) that are impractical with existing tools.
You're trying to tell this to the readers of comp.lang.lisp??? What
rock did you just crawl out from under?
[...]
> In addition, code should be normalized just like regular data.
Really?
> The real test, can one store code that can either modify itself or
> create new code (which can itself create new code, and so on) using
> its standard Data Manipulation Language (DML)? While I can't fully
> accomplish this yet, I can show a crude example that creates and
> modifies a one line query/code to determine if john's color is blue,
> as shown below:
[...]
You keep taking those blue pills, Neo, and let us know if you ever
make it out of the matrix.
--
John Landahl <····@landahl.org> "jpl"
http://landahl.org/john
> > > > Neo: ... experimental db that can store both data and code ...
> > >
> > > Lahman: My push back has to be: Why?
> >
> > Neo: manipulating code just like data allows solutions for some niche
> > applications (AI-ish) that are impractical with existing tools.
>
> Lahman:You're trying to tell this to the readers of comp.lang.lisp???
No, it was a response to your question above.
> > Neo: In addition, code should be normalized just like regular data.
>
> Lahman: Really?
Yes, really. For example if two functions contain the same expression
[ie (select john like *)] that expression is normalized (automatically
by db engine) as are it's sub elements down to the level of symbols.
> You keep taking those blue pills, Neo, and let us know if you ever
> make it out of the matrix.
:) Actually, it is you who is in the matrix. The proof is the lack of
your post showing an alternate solution that is as flexible as the one
I have posted for finding the root of things in the various
hierarchies. So please post one using your preferred set of tools. I'll
like to make it a constructive thread comparing solutions rather than
exchanging insults.
Neo wrote:
>
> ... if two functions contain the same expression
> [ie (select john like *)] that expression is normalized (automatically
> by db engine) as are it's sub elements down to the level of symbols.
>
Should be interesting to see how you deal with lexical scopes. :-)
--
Dan Muller
> > ... if two functions contain the same expression
> > [ie (select john like *)] that expression is normalized (automatically
> > by db engine) as are it's sub elements down to the level of symbols.
> >
>
> Should be interesting to see how you deal with lexical scopes. :-)
If the db contains like as an emotion and like as a comparator, the
user would need to use an appropriate expression that specifies like an
emotion, like a comparator, or both or the first one entered in the db.
Below I show how to do each (which assumes appropriate data has been
entered beforehand).
// Select john like (an emotion) something.
(select john
(and (select emotion instance *)
(select * name (select * symbol 'car')))
*)
// Select john like (a comparator) something.
(select john
(and (select comparator instance *)
(select * name (select * symbol 'car')))
*)
// Select john like (emotion or comparator) something.
(select john
(select * name (select * symbol 'car'))
*)
// Select john like (first like entered in db) something.
(select john like *)
Note that, as described in earlier posts expression element "like" is
translated by parser into following (firstNode (select * name
(firstNode (select * symbol (select 'c' 'a' 'r'))))) which roughly
means select the first thing whose name's first symbol string is 'car'.
Can you PLEASE take this out of comp.databses?
this seems to fit comp.databases.theory and maybe the other AI and
object groups, so it is overkill to cross post here.
Thanks
Neo wrote:
[]
Ed
(If you reply from those other groups, please remove comp.databases.
THANKS.)
Neo wrote:
> > > Neo: ... experimental db that can store both data and code ...
> >
> > Lahman: My push back has to be: Why?
>
> :) To approach the type of processing capability displayed by humans.
[snip]
This makes me cringe somewhat. There is little evidence to suggest that
humans cognitive processes correspond to graph structures _at all_, and
indeed research seems to point to much the opposite of what you propose
here. I'd also change your login_name. I find it very hard to take
someone who's called themself neo seriously (and I say that in all
sincerity).
> There is little evidence to suggest that humans cognitive processes correspond
> to graph structures _at all_, and indeed research seems to point to much
> the opposite of what you propose here.
I haven't (or didn't mean to) assert that human cognitive process
corresponds entirely or mostly to graph structures. The graph-like
example (getRoot/hierarchies) is just one small speed bump that is not
modelled/manipulated in a systematic enough manner in traditional
methodologies (in particular RM) to allow me to reach the level of
recursiveness that I believe is necessary on the road to more
human-like computing.
> ... and indeed research seems to point to much the opposite
> of what you propose here.
Out of curiosity, what would be the opposite of graph structures in
this case?
> I'd also change your login_name. I find it very hard to take
someone who's called themself neo seriously (and I say that in all
sincerity).
Thanks for your sincerity JOG, what name would you suggest such that
you would take me more seriously.
Neo wrote:
> > There is little evidence to suggest that humans cognitive processes correspond
> > to graph structures _at all_, and indeed research seems to point to much
> > the opposite of what you propose here.
>
> I haven't (or didn't mean to) assert that human cognitive process
> corresponds entirely or mostly to graph structures. The graph-like
> example (getRoot/hierarchies) is just one small speed bump that is not
> modelled/manipulated in a systematic enough manner in traditional
> methodologies (in particular RM) to allow me to reach the level of
> recursiveness that I believe is necessary on the road to more
> human-like computing.
I have absolutely no idea what you are referring to by "human-like"
computing.
>
> > ... and indeed research seems to point to much the opposite
> > of what you propose here.
>
> Out of curiosity, what would be the opposite of graph structures in
> this case?
semantic networks died in the 70/80's as far as AI is concerned. As I
advised you before, if you are really interested in improving the
subject area, look into situatedness and related aspects of nouvelle
AI.
>
> > I'd also change your login_name. I find it very hard to take
> someone who's called themself neo seriously (and I say that in all
> sincerity).
>
> Thanks for your sincerity JOG, what name would you suggest such that
> you would take me more seriously.
Obviously your real name.
Neo,
I do have to wonder why you crosspost this to comp.databases, when
staying in comp.databases.theory should be all you need.
thanks,
ed
Neo wrote:
> > > Neo: ... experimental db that can store both data and code ...
> >
> > Lahman: My push back has to be: Why?
>
> :) To approach the type of processing capability displayed by humans.
> While I will not achieve anything like that in my life time,
> manipulating code just like data allows solutions for some niche
> applications (AI-ish) that are impractical with existing tools.
>
From: Dmitry Gorbatovsky
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <e0rfha$flm$1@emma.aioe.org>
Neo wrote:
>> > Neo: ... experimental db that can store both data and code ...
Once again. Please.
I beg for just a small explanation , to some one not-so-smart.
Could You please express - WHAT IS THE PROBLEM you trying to solve.
Not HOW TO do certain something.
cheers
--
"You do not really understand something unless you can
explain it to your grandmother." ? Albert Einstein.
From: Nick Malik [Microsoft]
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <NNqdnbwLXNFYLKHZRVn-tw@comcast.com>
"Neo" <········@hotmail.com> wrote in message
····························@u72g2000cwu.googlegroups.com...
>> > Neo: ... experimental db that can store both data and code ...
>>
>> Lahman: My push back has to be: Why?
>
> :) To approach the type of processing capability displayed by humans.
> While I will not achieve anything like that in my life time,
> manipulating code just like data allows solutions for some niche
> applications (AI-ish) that are impractical with existing tools.
>
Hi Neo,
Aren't you basically reinventing Prolog or one of its variants? The notion
of code in a database where the code modifies itself as part of the data
management is fundamental to Prolog.
How is this different?
--
--- 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.
--
Nick Malik [Microsoft] wrote:
> "Neo" <········@hotmail.com> wrote in message
> ····························@u72g2000cwu.googlegroups.com...
> >> > Neo: ... experimental db that can store both data and code ...
> >>
> >> Lahman: My push back has to be: Why?
> >
> > :) To approach the type of processing capability displayed by humans.
> > While I will not achieve anything like that in my life time,
> > manipulating code just like data allows solutions for some niche
> > applications (AI-ish) that are impractical with existing tools.
>
> Aren't you basically reinventing Prolog or one of its variants? The notion
> of code in a database where the code modifies itself as part of the data
> management is fundamental to Prolog.
Prolog? Didn't you mean Lisp, or some other functional programming
language that allows you to manipulate functions? I wouldn't
immediately associate Prolog with "manipulate code as data". Could be
me, of course. :-)
-- Jan Hidders
> Aren't you basically reinventing Prolog or one of its variants?
Possibly and probably.
> The notion of code in a database where the code modifies
> itself as part of the data management is fundamental to Prolog.
> How is this different?
At the core, the difference is the data model used to represent things.
LISP uses linked listed which can be nested. ProLog also seems to have
lists, but I am unsure of its fundamental data methodology. My
LISP-like interface (still in early dev) is built on top of a data
model that more similar to RM in terms of functionality.
From: Nick Malik [Microsoft]
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <YcqdnYf0ROCuf6PZRVn-gA@comcast.com>
"Neo" <········@hotmail.com> wrote in message
····························@v46g2000cwv.googlegroups.com...
>> Aren't you basically reinventing Prolog or one of its variants?
>
> Possibly and probably.
>
>> The notion of code in a database where the code modifies
>> itself as part of the data management is fundamental to Prolog.
>> How is this different?
>
> At the core, the difference is the data model used to represent things.
> LISP uses linked listed which can be nested. ProLog also seems to have
> lists, but I am unsure of its fundamental data methodology. My
> LISP-like interface (still in early dev) is built on top of a data
> model that more similar to RM in terms of functionality.
>
There is nothing novel about this. Prolog also uses linked lists which can
be nested. In addition, you can place structures in the list, and the
structures can contain atoms and lists and "lists of lists" and "lists of
lists and atoms," etc. There is no 'program.' The system is an ordered
database of assertions. You start the logic engine by asking a question.
The engine attempts to answer the question using the information in the
database, matching as it goes, using a depth-first tree search. The
underlying math is predicate calculus and horn clauses. Primitives in the
language allow you to assert data into the database, thus modifying the
'program'. This allows the system to learn.
Much of the work on semantic machine learning was done in Prolog in the
1980s. The problem that Prolog faced was that it was fairly easy, with
early engines, to create perfectly legal programs that failed to evaluate
because the logic engine wasn't sophisticated enough to prune the tree
efficiently. This was solved by researchers at SUNY in New York with the
XSB prolog system. http://www.cs.sunysb.edu/~sbprolog/xsb-page.html
Versions of Prolog exist now for a wide array of platforms, including a
version of Prolog that compiles to the .Net Framework called P#.
http://www.dcs.ed.ac.uk/home/stg/Psharp/
This allows you to associate P# directly with Oracle and SQL Server.
--
--- 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.
--
> Prolog also uses linked lists which can be nested. In addition, you can place structures in the list, and the structures can contain atoms and lists and "lists of lists" and "lists of lists and atoms," etc. There is no 'program.' The system is an ordered database of assertions. You start the logic engine by asking a question. The engine attempts to answer the question using the information in the database, matching as it goes, using a depth-first tree search. The underlying math is predicate calculus and horn clauses. Primitives in the language allow you to assert data into the database, thus modifying the 'program'. This allows the system to learn.
.
Thanks for the above info. It seems the focus of Prolog and my db (with
LISP-like interface) are quite different (at least at this time). While
Prolog's primary focus seems to be deducing answering based on
questions and data stored in linked lists; the focus of the
experimental db is to provide the most flexible method of representing
things. I believe I have already surpassed RM. And as far as I can
tell, linked-lists are not even as flexible as RM. IMO, all else is
built upon the ability to store/recall things. Any
weakness/inflexibility at the foundation eventually leads to
limitations in applications built on top of it. This is the case with
RM/SQL. This will also be the case with LISP and Prolog. However, I am
sure currently and for years to come, Prolog/LISP will have better
algorithm for processing whatever data it can store/recall from linked
lists.
Below is a simple example that stores a person named John who likes
Mary and then finds who John likes. Could you or someone familiar with
Prolog show how to do this. Later I would like to extend the example to
distill Prolog's fundamental forte (and possible weakness in
representing things).
// Create type person.
(create type instance (new))
(create (it) name (findElseAdd name instance 'person'))
// Create a person named John.
(create person instance (new))
(create (it) name (findElseAdd name instance 'john'))
// Create a person named Mary.
(create person instance (new))
(create (it) name (findElseAdd name instance 'mary'))
// Create verb instance like.
(create verb instance (new))
(create (it) name (findElseAdd name instance 'like'))
// Create John likes Mary.
(create john like mary)
// Who does John like?
// Displays mary.
(msgbox (select john like *))
Neo wrote:
>>Prolog also uses linked lists which can be nested. In addition, you can place structures in the list, and the structures can contain atoms and lists and "lists of lists" and "lists of lists and atoms," etc. There is no 'program.' The system is an ordered database of assertions. You start the logic engine by asking a question. The engine attempts to answer the question using the information in the database, matching as it goes, using a depth-first tree search. The underlying math is predicate calculus and horn clauses. Primitives in the language allow you to assert data into the database, thus modifying the 'program'. This allows the system to learn.
>
> .
> the focus of the experimental db is to provide the most flexible
> method of representing things. I believe I have already surpassed RM.
Idiot. Complexity of structure is not a worthy or useful goal in data
management.
Bob Badour wrote:
> Neo wrote:
> >
> > the focus of the experimental db is to provide the most flexible
> > method of representing things. I believe I have already surpassed RM.
>
> [...] Complexity of structure is not a worthy or useful goal in data
> management.
Without necessarily endorsing Bob's general style of diction, I have
to agree with him on this point. The easy part of data management
is designing structures. The hard parts are maintaining integrity and
providing useful manipulations. Flexibility in some ways is the
opposite
of structure; both provide benefits, but there is a significant degree
of tension between the two. Simply maximizing flexibility doesn't lead
to good design--that necessarily abandons all the value that structure
provides. One way this manifests in Neo's design is the kind of code
he has to write to do retrieval; it's quite complicated, resembling
more
a turing-complete procedural language than a query language.
Marshall
>>> Neo: method of representing things ... surpass[ing] RM.
.
>> Bob: Complexity of structure is not a worthy or useful goal in data management.
> Marshall: Without necessarily endorsing Bob's general style of diction, I have to agree with him on this point.
Marshall, I haven't asserted that complexity of structure is a worthy
or useful goal in data management.
> The easy part of data management is designing structures.
In depends on the application. For some apps, it isn't easy to design
the structures. For an app where the data isn't known until run-time,
please show the structures which allows the data to be stored and yet
be queried/manipulated in a systematic manner (hint: it is possible,
but highly impractical in RMDB). In this case, the app is something
like an android.
> The hard parts are maintaining integrity and providing useful manipulations.
In the experimental db, referential integrity is automatic. All the
LISP-like scripts that I have been posting, create non-redundant
representation of thing in the db. Would you like to verify this?
Currently user-defined constraints (all besides ref integrity) can be
represented in db like any other data, but app code is responsible for
enforcing them (sometime later, maybe some basic user-defined
constraints may be executed by db engine itself).
> Flexibility in some ways is the opposite of structure; both provide benefits, but there is a significant degree of tension between the two. Simply maximizing flexibility doesn't lead to good design--that necessarily abandons all the value that structure provides.
Yes, I realize typically flexibility and structure are
counter-balancing characteristics. And this is one of the reasons why
the experimental db is revolutionary. It provides such flexibility that
nothing the equivalent of a schema ever need be specified; yet at the
same time allows querying and manipulation (a bit weak currently) of
things as if data was highly structured!!! This is easy to verify. Look
at the scripts and see that while no schema is specified, the queries
(near the end of scripts) still work!
> One way this manifests in Neo's design is the kind of code he has to write to do retrieval; it's quite complicated, resembling more a turing-complete procedural language than a query language.
Ah yes, the "sledgehammer" analogy that no one has been able to verify
by posting an RM solution that models the equivalent data and queries.
If somebody ever does, it will be obvious that the "sledgehammer"
actually applies to RM! Or will you be the first to prove your
assertion? Is it my imagination that no one has post any solution using
another methodology in nearly 100 posts! Marshall, are you willing to
post SQL script for some of my examples and proceed to verify things?
Neo wrote:
> > One way this manifests in Neo's design is the kind of code he has to write to do
> > retrieval; it's quite complicated, resembling more a turing-complete procedural language
> > than a query language.
>
> Ah yes, the "sledgehammer" analogy that no one has been able to verify
> by posting an RM solution that models the equivalent data and queries.
> If somebody ever does, it will be obvious that the "sledgehammer"
> actually applies to RM! Or will you be the first to prove your
> assertion? Is it my imagination that no one has post any solution using
> another methodology in nearly 100 posts! Marshall, are you willing to
> post SQL script for some of my examples and proceed to verify things?
I find it very strange that you don't do this yourself in order to
convince everyone. You are of course under no obligation to do so, but
given that it would immediately dispel these 'misconceptions' that your
query syntax is horrifically verbose, I see no reason why you would not
take the bull by the horns as it were.
> I find it very strange that you don't do this yourself in order to convince everyone. You are of course under no obligation to do so, but given that it would immediately dispel these 'misconceptions' that your query syntax is horrifically verbose, I see no reason why you would not take the bull by the horns as it were.
:) Because then my threads would be exactly one post long and the
unfamiliarity with the db + LISP-like script + the even longer amount
of SQL script with mind-numbing number of joins would never be read
past a few lines, especially since I am an idiot talking about some
NULL-less, auto-normalizing, no schema required, yet queryable, AI-ish
db that fits on a floppy thingy!
Actually if you search old posts, you will see at times I have done
exactly that when the model/implementation was less developed. I didn't
get much feedback. To realize what is going on, one has to go thru some
steps. I am trying to take someone thru those steps. I didn't arrive
where I am overnight. It was a slow process of many years just focusing
on this problem night and day and you want to get it all in one post.
Is there anything to which I claim or have I simply gone crazy :)
>> Nick Malik [Microsoft]: Prolog also uses linked lists which can be nested. In addition, you can place structures in the list, and the structures can contain atoms and lists and "lists of lists" and "lists of lists and atoms," etc...
>> Neo: focus of the experimental db is to provide the most flexible method of representing things
> Bob Badour: Idiot. Complexity of structure is not a worthy or useful goal in data management.
Bob, thanks for the complement; however, I cannot accept it this time
because I haven't asserted that complexity of structure is a worthy or
useful goal in data management. The portion referring to structure is
from Nick's post, not mine :)
"Bob Badour" <·······@pei.sympatico.ca> wrote in message
····························@ursa-nb00s0.nbnet.nb.ca...
> Neo wrote:
>>>Prolog also uses linked lists which can be nested. In addition, you can
>>>place structures in the list, and the structures can contain atoms and
>>>lists and "lists of lists" and "lists of lists and atoms," etc. There is
>>>no 'program.' The system is an ordered database of assertions. You
>>>start the logic engine by asking a question. The engine attempts to
>>>answer the question using the information in the database, matching as it
>>>goes, using a depth-first tree search. The underlying math is predicate
>>>calculus and horn clauses. Primitives in the language allow you to
>>>assert data into the database, thus modifying the 'program'. This allows
>>>the system to learn.
>>
>> .
> > the focus of the experimental db is to provide the most flexible
> > method of representing things. I believe I have already surpassed RM.
>
> Idiot. Complexity of structure is not a worthy or useful goal in data
> management.
Hi Bob,
The first quote, above, is an excerpt from my post, not Neo's post. So you
are clearly calling one of us an idiot. Not sure who. :-)
I agree that complexity of structure is not a worthy goal. Never said it
was. Nor, to the best of my knowledge, did Neo. On the other hand, if the
data itself is complex, it's representation should be a simple as possible,
but no simpler. I've seen overnormalization ruin a perfectly good database.
Prolog is not an inherently type-safe language. There is no SQL language to
assert the data into Prolog's database. These are probably weaknesses,
although I'm not sure I've experienced them as such, because the 'database'
in a Prolog system is the database of rules that drive the engine, and that
database should change slowly, and in a very controlled manner. Don't
confuse logic management with data management. That would be a mistake on
par with making complexity of structure into a worthy goal.
--
--- 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.
--
> ... calling one of us an idiot. Not sure who. :-)
Well if you don't want the compliment, I'll take it :)
> Prolog is not an inherently type-safe language ...
This is slightly off-topic, but I am curious about your view:
1) What is the proper name of the relationship between person and John,
person and Mary, fruit and apple, fruit and banana, etc. Ie, fill the
verb in: person ____ john.
2) What is the proper name of the reverse relationship between John and
person, Mary and person, apple and fruit, banana and fruit, etc. Ie,
fill the verb in: john ___ person.
3) Just as John and Mary "are" persons, and apple and banana "are"
fruits, what are person and fruit?
4) Supposing the answer to question 3 is xyz, what is the proper name
of the relationship between xyz and person, xyz and fruit, etc?
5) Supposing the answer to question 3 is xyz, what is the proper name
of the reverse relationship between person and xyz, fruit and xyz, etc?
From: Nick Malik [Microsoft]
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <1cGdnfANts6ZSdjZRVn-ig@comcast.com>
"Neo" <········@hotmail.com> wrote in message
····························@i39g2000cwa.googlegroups.com...
>> ... calling one of us an idiot. Not sure who. :-)
>
> Well if you don't want the compliment, I'll take it :)
LOL
>
>> Prolog is not an inherently type-safe language ...
>
> This is slightly off-topic, but I am curious about your view:
These are good questions, but I'm not sure if you are asking me about my
views on relational data management or on logical rules management. The
difference is simple. Relational describes relationships like 'is a' and
'has a' and 'is defined by' while logical rules management simply states
'the relationship is what you define it to be'.
It has been well over a decade since I wrote Prolog code, so if someone
reading this newsgroup knows Prolog and they see this, my sincere apologies.
The concept is what I'm trying to convey.
I will answer your questions with statements that are (or resemble) Prolog.
>
> 1) What is the proper name of the relationship between person and John,
> person and Mary, fruit and apple, fruit and banana, etc. Ie, fill the
> verb in: person ____ john.
named_instance(john,person).
named_instance(mary,person).
subtype(apple,fruit).
subtype(banana,fruit).
>
> 2) What is the proper name of the reverse relationship between John and
> person, Mary and person, apple and fruit, banana and fruit, etc. Ie,
> fill the verb in: john ___ person.
? named_instance(john, A )
(to which the system responds)
A = person
(I skipped your question. The answer to the logic of your question is: I
would consider john to be a named instance of the noun 'person').
>
> 3) Just as John and Mary "are" persons, and apple and banana "are"
> fruits, what are person and fruit?
person is a noun. fruit is a noun. In Prolog, they are atoms. They have
no 'meaning' except as defined by their relationship with john and banana.
(You will notice that I use lower case, even for proper names. In Prolog,
lower case tokens are 'atoms' while a token that begins with a capital
letter is a variable).
>
> 4) Supposing the answer to question 3 is xyz, what is the proper name
> of the relationship between xyz and person, xyz and fruit, etc?
not a sensible question in Prolog context. There is no notion of subtype or
supertype. Only expression. Imagine that we are talking about Boolean
logic. A or B. Is A a variable? If we say "A is a B and B is a C,
therefore A is a C," we have defined the transitive property of 'is a'.
Before making the statement, the verb 'is a' had no such property. The
scope of this property may be quite limited. Prolog assumes this. Most
data management languages have a great many meta-rules. Prolog does too,
but they are not based on the data. They are, instead, based on the logic.
>
> 5) Supposing the answer to question 3 is xyz, what is the proper name
> of the reverse relationship between person and xyz, fruit and xyz, etc?
>
See above.
Let's say, in Prolog, you want to express the transitive nature of
'contains'. It could look like this:
contains(A, B) :- contains(A, X), contains(X, B).
Now let's establish some facts.
contains(cup, coin).
contains(bucket, cup).
contains(box, bucket).
contains(truck, box).
contains(ship, truck).
We are saying that the coin is in the cup is in the bucket is in the box is
in the truck is in the ship.
Now, ask the question: is the coin in the truck?
? contains(truck, coin)
to which the system responds:
yes.
(or 'true.' Not sure anymore ;-).
It does it by comparing the predicate contains/2 to each of the rules in the
system. There are six matching rules. One is an expression. The rest are
facts. The comparison doesn't match one of the facts, so the expression is
invoked. The expression says: any item is inside another item if you can
find an intermediary where the item is in the intermediary and the
intermediary is in the other item... RECURSIVE. Using a depth-first search,
the system quickly finds that the coin is in a cup where a cup is in a
bucket where a bucket is in a box where a box is in a truck, therefore the
coin is in the truck.
The entire program is in this post. There is nothing else.
HTH,
--
--- 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.
--
>> Neo: What is the proper name of the relationship between ...
.
> Nick: answer your questions with statements that are (or resemble) Prolog
Thanks for little Prolog tutorial. Based on your post, I gathered that
you might arrange the "class hierarchy" as follows. Note that I
understood you to imply that person and fruit are atoms.
atom
-named_instance/ named_Instance_of-
person
-named_instance/ named_Instance_of-
john
mary
fruit
-subType-
apple
banana
Now, suppose I wanted to classify an actual tomato (tomato1) as both a
fruit and a vegetable, where would I add it to the above "class
hierarchy"? (You don't need to show me actual Prolog, just adjust above
tree)
> Now, suppose I wanted to classify an actual tomato (tomato1) as both a
> fruit and a vegetable, where would I add it to the above "class
> hierarchy"? (You don't need to show me actual Prolog, just adjust above
> tree)
>
Prolog is a graph, not a tree. To illustrate it as a tree misses the point.
Humans <categorize> in trees, but our brains <think> in graphs. We freely
associate things as they need to be, with relationships that cannot be
categorized with a single taxonomy. Multiple overlapping taxonomies are
required. Prolog simply removes the requirement for a single taxonomy.
To solve the problem I posed, I placed the entire prolog program below, with
the two facts you provided (Tomato is both a fruit and a vegetable).
You could just as easily have asked "Why the Tomato is both a fruit and a
vegetable," and with the addition of attributes and decision criteria, you
could have the Prolog app reply that a Tomato is, in fact, both but that an
Apple is both a fruit and a computer. :-) If you tell me what you would
consider those criteria to be, I'll be happy to update the app to reflect.
Note: the verb 'named instance' and 'subtype' are invented. I invented them
for this example. They could just as easily have been 'foo' and 'bar'.
named_instance(john,person).
named_instance(mary,person).
subtype(apple,fruit).
subtype(banana,fruit).
subtype(tomato, fruit).
subtype(tomato, vegetable).
--
--- 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.
>> Now, suppose I wanted to classify an actual tomato as both a fruit and a vegetable, where would I add it to the above "class hierarchy"? (You don't need to show me actual Prolog, just adjust above tree).
.
> Prolog is a graph, not a tree.
> To illustrate it as a tree misses the point.
> Humans <categorize> in trees, but our brains <think> in graphs.
Yes, I think displaying graphs in tree might mislead some people into
believing the underlying capabilities are limited to trees; and
sometimes it is better to display it as a list of statements as Prolog
does.
> To solve the problem posed, I placed the entire prolog program below, with
the two facts you provided (Tomato is both a fruit and a vegetable).
> named_instance(john,person).
> named_instance(mary,person).
> subtype(apple,fruit).
> subtype(banana,fruit).
> subtype(tomato, fruit).
> subtype(tomato, vegetable).
Ok, I see. Suppose we start with the following:
subtype(doctor, human).
subtype(engineer, human).
named_instance(john, doctor).
named_instance(mary, doctor).
And now comes along an alien named bob, who has all the major
characteristics of a doctor, but he is not a human. How do I handle
this situation?
"Neo" <········@hotmail.com> writes:
>>> Now, suppose I wanted to classify an actual tomato as both a fruit and a vegetable, where would I add it to the above "class hierarchy"? (You don't need to show me actual Prolog, just adjust above tree).
> .
>> Prolog is a graph, not a tree.
>> To illustrate it as a tree misses the point.
>> Humans <categorize> in trees, but our brains <think> in graphs.
>
> Yes, I think displaying graphs in tree might mislead some people into
> believing the underlying capabilities are limited to trees; and
> sometimes it is better to display it as a list of statements as Prolog
> does.
>
>> To solve the problem posed, I placed the entire prolog program below, with
> the two facts you provided (Tomato is both a fruit and a vegetable).
>
>> named_instance(john,person).
>> named_instance(mary,person).
>> subtype(apple,fruit).
>> subtype(banana,fruit).
>> subtype(tomato, fruit).
>> subtype(tomato, vegetable).
>
> Ok, I see. Suppose we start with the following:
>
> subtype(doctor, human).
> subtype(engineer, human).
> named_instance(john, doctor).
> named_instance(mary, doctor).
>
> And now comes along an alien named bob, who has all the major
> characteristics of a doctor, but he is not a human. How do I handle
> this situation?
By not being dumb, and by modelizing correctly the universe!
doctor is a role, not a human being.
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
From: Nick Malik [Microsoft]
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <p8ydnSNwfeLq3c_ZRVn-rA@comcast.com>
"Neo" <········@hotmail.com> wrote in message
·····························@g10g2000cwb.googlegroups.com...
>
> Ok, I see. Suppose we start with the following:
>
> subtype(doctor, human).
> subtype(engineer, human).
> named_instance(john, doctor).
> named_instance(mary, doctor).
>
> And now comes along an alien named bob, who has all the major
> characteristics of a doctor, but he is not a human. How do I handle
> this situation?
>
If this is true, then an alien can be a doctor and Bob can be an alien.
Therefore, we can no longer say, for certain, that 'just because john is a
doctor, therefore he is human,' because there are now alien doctors. The
ruleset change is small.
subtype(doctor, alien).
subtype(doctor, human).
subtype(engineer, human).
named_instance(john, doctor).
named_instance(mary, doctor).
named_instance(bob, doctor).
--
--- 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.
--
Neo wrote:
> .
> Thanks for the above info. It seems the focus of Prolog and my db (with
> LISP-like interface) are quite different (at least at this time). While
> Prolog's primary focus seems to be deducing answering based on
> questions and data stored in linked lists; the focus of the
> experimental db is to provide the most flexible method of representing
> things.
Hi Neo,
Prolog is not based on linked lists, it is based on something very
different namely "facts" and "rules" these give rise to incredible
flexibility and power.
I encourage you to at least take a good look at Prolog and LISP. You
may be able to get off to a flying start by begining with one of them
and extending? They'll at least give you some very interesting ideas
and I reckon you'll have fun - I know I did.
They both have some real limitiations like being memory based and
Prolog lacks procedural abilities to bail it out of trouble (as we do
with SQL when we use some procedural language with it) but for
flexibility Prolog and LISP win.
> I believe I have already surpassed RM. And as far as I can
> tell, linked-lists are not even as flexible as RM.
I agree linked-lists aren't as powerful as the RM but LISP and Prolog
are not merely about lists.
Both Prolog and LISP can represent information and indeed knowledge
well beyond the RM, that's why they are popular with the ai community!
> IMO, all else is
> built upon the ability to store/recall things. Any
> weakness/inflexibility at the foundation eventually leads to
> limitations in applications built on top of it. This is the case with
> RM/SQL. This will also be the case with LISP and Prolog. However, I am
> sure currently and for years to come, Prolog/LISP will have better
> algorithm for processing whatever data it can store/recall from linked
> lists.
>
> Below is a simple example that stores a person named John who likes
> Mary and then finds who John likes. Could you or someone familiar with
> Prolog show how to do this. Later I would like to extend the example to
> distill Prolog's fundamental forte (and possible weakness in
> representing things).
>
> // Create type person.
> (create type instance (new))
> (create (it) name (findElseAdd name instance 'person'))
>
> // Create a person named John.
> (create person instance (new))
> (create (it) name (findElseAdd name instance 'john'))
>
> // Create a person named Mary.
> (create person instance (new))
> (create (it) name (findElseAdd name instance 'mary'))
>
> // Create verb instance like.
> (create verb instance (new))
> (create (it) name (findElseAdd name instance 'like'))
>
> // Create John likes Mary.
> (create john like mary)
>
> // Who does John like?
> // Displays mary.
> (msgbox (select john like *))
To do this in Prolog you need these 2 lines of code:-
1. likes(john,mary).
2. ?- likes(john,X).
It answers
X=mary
Line 1 is a fact clause and 2 is a goal which solves for "X".
To match your example more closely we could have:-
1. person(john).
2. person(mary).
3. likes(john,mary).
4. likes(X,Y) :- person(Y).
This says john and mary are person's and when one likes they must like
a person but those lines (1,2,4) are probably superflous.
In Prolog you can easily add more facts and rules about all sorts of
stuff:-
# Facts
likes(john,mary)
likes(bill,mary).
likes(jim,mary).
likes(jack,mary).
likes(mary,peter).
studies(mary,ai).
studies(john,ai).
studies(jones,piano).
teaches(jones,ai).
teaches(brown,math).
course(ai,fun).
course(art,funky).
parent(mary,jodie).
parent(mai,mary).
parent(granny,mai).
grandparent(X,Z) :- parent(X,Y), parent(Y,Z).
..more simple rules and facts ...
Now you can have pretty complex relationships and ask all sorts of
queries. Who likes who, who studies what, who teaches what, who is
who's parent/grandparent ...
IMHO I think you owe it to yourself to take a closer look at Prolog and
LISP.
HTH,
Cheers.
Alvin Ryder wrote:
> Neo wrote:
>
>>I believe I have already surpassed RM. And as far as I can
>>tell, linked-lists are not even as flexible as RM.
>
> I agree linked-lists aren't as powerful as the RM but LISP and Prolog
> are not merely about lists.
>
> Both Prolog and LISP can represent information and indeed knowledge
> well beyond the RM, that's why they are popular with the ai community!
Given the standard definitions of information and knowledge, that's a
rather astounding claim. Do you have anything that might back it up?
[binary relations snipped]
> Now you can have pretty complex relationships and ask all sorts of
> queries. Who likes who, who studies what, who teaches what, who is
> who's parent/grandparent ...
Can it handle n-ary relations? Like "John bought 10 apples each at
10cents" ?
Bob Badour wrote:
> Alvin Ryder wrote:
> > Neo wrote:
> >
> >>I believe I have already surpassed RM. And as far as I can
> >>tell, linked-lists are not even as flexible as RM.
> >
> > I agree linked-lists aren't as powerful as the RM but LISP and Prolog
> > are not merely about lists.
> >
> > Both Prolog and LISP can represent information and indeed knowledge
> > well beyond the RM, that's why they are popular with the ai community!
>
> Given the standard definitions of information and knowledge, that's a
> rather astounding claim. Do you have anything that might back it up?
Prolog models a greater subset of predicate logic than relational
theory due to its inclusion of negation and disjunction. As such it has
been traditional popular in classic-AI as the basis of inference
engines. Whether this allows it to offer a better representation of
'knowledge' is up for debate.
JOG wrote:
> Bob Badour wrote:
>
>>Alvin Ryder wrote:
>>
>>>Neo wrote:
>>>
>>>
>>>>I believe I have already surpassed RM. And as far as I can
>>>>tell, linked-lists are not even as flexible as RM.
>>>
>>>I agree linked-lists aren't as powerful as the RM but LISP and Prolog
>>>are not merely about lists.
>>>
>>>Both Prolog and LISP can represent information and indeed knowledge
>>>well beyond the RM, that's why they are popular with the ai community!
>>
>>Given the standard definitions of information and knowledge, that's a
>>rather astounding claim. Do you have anything that might back it up?
>
>
> Prolog models a greater subset of predicate logic than relational
> theory due to its inclusion of negation and disjunction. As such it has
> been traditional popular in classic-AI as the basis of inference
> engines. Whether this allows it to offer a better representation of
> 'knowledge' is up for debate.
It would be a short debate. The standard definitions define data as that
subset of information represented suitably for machine processing,
making knowledge that subset of information lacking such suitable
representation.
I direct you to Dijkstra's famous quote regarding submarines.
Are you suggesting that NOT is not negation or that OR is not
disjunction? I am curious what basis you think you have for the
astounding statement: "Prolog models a greater subset of predicate logic
than relational theory due to its inclusion of negation and disjunction."
Bob Badour wrote:
> JOG wrote:
>
> > Bob Badour wrote:
> >
> >>Alvin Ryder wrote:
> >>
> >>>Neo wrote:
> >>>
> >>>
> >>>>I believe I have already surpassed RM. And as far as I can
> >>>>tell, linked-lists are not even as flexible as RM.
> >>>
> >>>I agree linked-lists aren't as powerful as the RM but LISP and Prolog
> >>>are not merely about lists.
> >>>
> >>>Both Prolog and LISP can represent information and indeed knowledge
> >>>well beyond the RM, that's why they are popular with the ai community!
> >>
> >>Given the standard definitions of information and knowledge, that's a
> >>rather astounding claim. Do you have anything that might back it up?
> >
> >
> > Prolog models a greater subset of predicate logic than relational
> > theory due to its inclusion of negation and disjunction. As such it has
> > been traditional popular in classic-AI as the basis of inference
> > engines. Whether this allows it to offer a better representation of
> > 'knowledge' is up for debate.
>
> It would be a short debate. The standard definitions define data as that
> subset of information represented suitably for machine processing,
> making knowledge that subset of information lacking such suitable
> representation.
>
Yes, and the debate between _us_ would be short to non-existent.
However this would not be the case with others in the AI/SemWeb
community who have already been debating for decades.
> I direct you to Dijkstra's famous quote regarding submarines.
That would be preaching to the converted.
>
> Are you suggesting that NOT is not negation or that OR is not
> disjunction?
Of course not. I am sure this is a rhetorical question but I cannot
ascertain its point - I think you are referring to relational algebra,
but this is not the same as the use of negation in explicit
declarations such as P(x) || ¬Q(y) (for instance). In RM the user has
to remember this predicate. In Prolog, the program memorises it for
you, for good or for bad. To compare the two is hence comparing apples
and oranges.
> I am curious what basis you think you have for the
> astounding statement: "Prolog models a greater subset of predicate logic
> than relational theory due to its inclusion of negation and disjunction."
I am regurgitating from memory - I think it _may_ have been Codd
speaking of the active decision on his part to use the subset of
predicate logic that he did, but I will have to dig it out in the piles
of papers I have.
Either way, prolog is a dwindling language anyhow:
(http://www.tiobe.com/tpci.htm)
JOG wrote:
> Bob Badour wrote:
>
>>JOG wrote:
>>
>>>Bob Badour wrote:
>>>
>>>>Alvin Ryder wrote:
>>>>
>>>>>I agree linked-lists aren't as powerful as the RM but LISP and Prolog
>>>>>are not merely about lists.
>>>>>
>>>>>Both Prolog and LISP can represent information and indeed knowledge
>>>>>well beyond the RM, that's why they are popular with the ai community!
>>>>
>>>>Given the standard definitions of information and knowledge, that's a
>>>>rather astounding claim. Do you have anything that might back it up?
>>>
>>>Prolog models a greater subset of predicate logic than relational
>>>theory due to its inclusion of negation and disjunction. As such it has
>>>been traditional popular in classic-AI as the basis of inference
>>>engines. Whether this allows it to offer a better representation of
>>>'knowledge' is up for debate.
>> [snip]
>>Are you suggesting that NOT is not negation or that OR is not
>>disjunction?
>
>
> Of course not. I am sure this is a rhetorical question but I cannot
> ascertain its point - I think you are referring to relational algebra,
> but this is not the same as the use of negation in explicit
> declarations such as P(x) || �Q(y) (for instance). In RM the user has
> to remember this predicate. In Prolog, the program memorises it for
> you, for good or for bad. To compare the two is hence comparing apples
> and oranges.
The point is the relational model basically supports both with the one
small requirement that one must specify one's universe. I do not
understand what you mean by 'has to remember this predicate'.
>>I am curious what basis you think you have for the
>>astounding statement: "Prolog models a greater subset of predicate logic
>>than relational theory due to its inclusion of negation and disjunction."
>
>
> I am regurgitating from memory - I think it _may_ have been Codd
> speaking of the active decision on his part to use the subset of
> predicate logic that he did, but I will have to dig it out in the piles
> of papers I have.
Somehow, I doubt Prolog returns many infinite sets.
> Either way, prolog is a dwindling language anyhow:
> (http://www.tiobe.com/tpci.htm)
I don't see where you established it is dwindling. Other than the fact
it might be included in the first 50 languages, I doubt it ever occupied
a spot in the top 50.
Bob Badour wrote:
> JOG wrote:
>
> > Bob Badour wrote:
> >
> >>JOG wrote:
> >>
> >>>Bob Badour wrote:
> >>>
> >>>>Alvin Ryder wrote:
> >>>>
> >>>>>I agree linked-lists aren't as powerful as the RM but LISP and Prolog
> >>>>>are not merely about lists.
> >>>>>
> >>>>>Both Prolog and LISP can represent information and indeed knowledge
> >>>>>well beyond the RM, that's why they are popular with the ai community!
> >>>>
> >>>>Given the standard definitions of information and knowledge, that's a
> >>>>rather astounding claim. Do you have anything that might back it up?
> >>>
> >>>Prolog models a greater subset of predicate logic than relational
> >>>theory due to its inclusion of negation and disjunction. As such it has
> >>>been traditional popular in classic-AI as the basis of inference
> >>>engines. Whether this allows it to offer a better representation of
> >>>'knowledge' is up for debate.
> >> [snip]
> >>Are you suggesting that NOT is not negation or that OR is not
> >>disjunction?
> >
> >
> > Of course not. I am sure this is a rhetorical question but I cannot
> > ascertain its point - I think you are referring to relational algebra,
> > but this is not the same as the use of negation in explicit
> > declarations such as P(x) || ¬Q(y) (for instance). In RM the user has
> > to remember this predicate. In Prolog, the program memorises it for
> > you, for good or for bad. To compare the two is hence comparing apples
> > and oranges.
>
> The point is the relational model basically supports both with the one
> small requirement that one must specify one's universe. I do not
> understand what you mean by 'has to remember this predicate'.
>
I don't agree, but we may be talking at cross purposes - let me explain
with a trivial example. Take the relation: { (clothing:coat,
weather:sunny), (clothing:sunglasses, weather:raining) }
I am storing propositions of the nature that if Frank, say, is not
wearing a coat it is sunny, and if he's is not wearing sunglasses then
it must be raining (Frank's a bit of a fashion victim). The predicate
behind the relation is: [¬clothing -> weather], and anyone interacting
with the db must be aware of this in order to reform my original
propositions, and so draw appropriate conclusions.
In prolog, however I can state this explicitly and another user will
not require any external knowledge of the relationship:
weather(sunny) :- /+ clothing(coat)
weather(rainy) :- /+ clothing(sunglasses)
And there my limited knowledge of logical programming is exhausted.
JOG wrote:
> Bob Badour wrote:
>
>>JOG wrote:
>>
>>
>>>Bob Badour wrote:
>>>
>>>
>>>>JOG wrote:
>>>>
>>>>
>>>>>Bob Badour wrote:
>>>>>
>>>>>
>>>>>>Alvin Ryder wrote:
>>>>>>
>>>>>>
>>>>>>>I agree linked-lists aren't as powerful as the RM but LISP and Prolog
>>>>>>>are not merely about lists.
>>>>>>>
>>>>>>>Both Prolog and LISP can represent information and indeed knowledge
>>>>>>>well beyond the RM, that's why they are popular with the ai community!
>>>>>>
>>>>>>Given the standard definitions of information and knowledge, that's a
>>>>>>rather astounding claim. Do you have anything that might back it up?
>>>>>
>>>>>Prolog models a greater subset of predicate logic than relational
>>>>>theory due to its inclusion of negation and disjunction. As such it has
>>>>>been traditional popular in classic-AI as the basis of inference
>>>>>engines. Whether this allows it to offer a better representation of
>>>>>'knowledge' is up for debate.
>>>>
>>>>[snip]
>>>>Are you suggesting that NOT is not negation or that OR is not
>>>>disjunction?
>>>
>>>
>>>Of course not. I am sure this is a rhetorical question but I cannot
>>>ascertain its point - I think you are referring to relational algebra,
>>>but this is not the same as the use of negation in explicit
>>>declarations such as P(x) || �Q(y) (for instance). In RM the user has
>>>to remember this predicate. In Prolog, the program memorises it for
>>>you, for good or for bad. To compare the two is hence comparing apples
>>>and oranges.
>>
>>The point is the relational model basically supports both with the one
>>small requirement that one must specify one's universe. I do not
>>understand what you mean by 'has to remember this predicate'.
>
> I don't agree, but we may be talking at cross purposes - let me explain
> with a trivial example. Take the relation: { (clothing:coat,
> weather:sunny), (clothing:sunglasses, weather:raining) }
>
> I am storing propositions of the nature that if Frank, say, is not
> wearing a coat it is sunny, and if he's is not wearing sunglasses then
> it must be raining (Frank's a bit of a fashion victim). The predicate
> behind the relation is: [�clothing -> weather], and anyone interacting
> with the db must be aware of this in order to reform my original
> propositions, and so draw appropriate conclusions.
>
> In prolog, however I can state this explicitly and another user will
> not require any external knowledge of the relationship:
>
> weather(sunny) :- /+ clothing(coat)
> weather(rainy) :- /+ clothing(sunglasses)
>
> And there my limited knowledge of logical programming is exhausted.
Okay, I think I see what you mean. Thank you for explaining it to me.
With all this brain power between you and JOG, would either one of you
be willing to demonstrate it by using RM to represent the data in the
Judge example posted earlier in this thread using the experimental db?
From: Bill Atkins
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <87hd4l1rb2.fsf@rpi.edu>
"Neo" <········@hotmail.com> writes:
> With all this brain power between you and JOG, would either one of you
> be willing to demonstrate it by using RM to represent the data in the
> Judge example posted earlier in this thread using the experimental db?
>
Neo,
I appreciate your enthusiasm for your database, but why don't you stop
cross-posting this to comp.lang.lisp? This thread has nothing to do
with Lisp any more and the only relevance to Lisp it might ever have
claimed was that your database uses a sexp-based notation for
commands.
--
"...and when, another time, I discovered that he considered not
unworthy of reflection in one of those mirrors of absolute truth which
were his writings a remark similar to one which I had had occasion to
make about our friend M. Legrandin, ...then it was suddenly revealed
to me that my own humble existence and the realms of the true were
less widely separated than I had supposed, that at certain points they
actually collided, and in my newfound confidence and joy, I had wept
upon his printed page as in the arms of a long-lost father."
On Sat, 22 Apr 2006 12:57:37 -0400, Bill Atkins
<············@rpi.edu> wrote:
>
>I appreciate your enthusiasm for your database, but why don't you stop
>cross-posting this to comp.lang.lisp? This thread has nothing to do
>with Lisp any more and the only relevance to Lisp it might ever have
>claimed was that your database uses a sexp-based notation for
>commands.
The same regarding Prolog.
A.L.
> I appreciate your enthusiasm for your database, but why don't you stop cross-posting this to comp.lang.lisp? This thread has nothing to do with Lisp any more and the only relevance to Lisp it might ever have claimed was that your database uses a sexp-based notation for commands.
I will remove LISP and Prolog from future posts in this thread. (I
would have liked to seen a LISP/Prolog solution to the Judge Example.
If someone cares to post it, please join back in via c.d.t.)
Neo wrote:
> > I appreciate your enthusiasm for your database, but why don't you stop cross-posting this to comp.lang.lisp? This thread has nothing to do with Lisp any more and the only relevance to Lisp it might ever have claimed was that your database uses a sexp-based notation for commands.
>
> I will remove LISP and Prolog from future posts in this thread. (I
> would have liked to seen a LISP/Prolog solution to the Judge Example.
> If someone cares to post it, please join back in via c.d.t.)
Do those sissy lisp and prolog forims have cranks, oops I mean
educationally challenged persons who post long drivels that nobody else
appears excited to read? c.d.t. has at least 2 active ones, and quite
many dormant. This elevates c.d.t to the level of sci.math and
sci.physics!
Bill Atkins wrote:
> "Neo" <········@hotmail.com> writes:
>
>
>>With all this brain power between you and JOG, would either one of you
>>be willing to demonstrate it by using RM to represent the data in the
>>Judge example posted earlier in this thread using the experimental db?
>
> Neo,
>
> I appreciate your enthusiasm for your database, but why don't you stop
> cross-posting this to comp.lang.lisp? This thread has nothing to do
> with Lisp any more and the only relevance to Lisp it might ever have
> claimed was that your database uses a sexp-based notation for
> commands.
Sadly, it's not relevant to any of the other newsgroups either.
From: David Cressey
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <DBr2g.1837$Ze.1810@trndny06>
"Neo" <········@hotmail.com> wrote in message
·····························@t31g2000cwb.googlegroups.com...
> With all this brain power between you and JOG, would either one of you
> be willing to demonstrate it by using RM to represent the data in the
> Judge example posted earlier in this thread using the experimental db?
>
Neo,
Speaking from practical experience, conversion from one solution to a
solution in a different framework is much harder than starting from
requirements, and designing a solution within a specified framework.
Therefore, I reject the fundamental premise behind the challenges that you
have been making for several years now. I'm speaking of your challenge that
one of us should reimplement an example that you have posted using your
experimental db. The idea behind your challenge is that, in the absence of
a response, your experimental db stands unchallenged. I reject that.
From my point of view, reimplementing the judge example or any other using
the RM, or any product purportedly derived from the RM, would be a lot of
work, and a waste of time. It's rather up to you to demonstrate for this
newsgroup that your db fills a gap in our accustomed toolset, and to
describe that gap adequately for us.
Another Dijkstra classic:
"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers they
are mentally mutilated beyond hope of regeneration."
> JOG: Another Dijkstra classic: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Wow! Now I understand why people exposed to RM can't understand
anything past it or do you consider it sufficient at representing
things and more importantly are willing you to verify this rather than
make derogatory remarks? (You are slipping back into your bad habits as
in other threads like "Data Model")
Bob Badour wrote:
> Alvin Ryder wrote:
> > Neo wrote:
> >
> >>I believe I have already surpassed RM. And as far as I can
> >>tell, linked-lists are not even as flexible as RM.
> >
> > I agree linked-lists aren't as powerful as the RM but LISP and Prolog
> > are not merely about lists.
> >
> > Both Prolog and LISP can represent information and indeed knowledge
> > well beyond the RM, that's why they are popular with the ai community!
>
> Given the standard definitions of information and knowledge, that's a
> rather astounding claim. Do you have anything that might back it up?
>
I'm sorry I don't have anything formal, the comment is simply based on
the notion that the RM can capably deal with entities and relationships
whereas LISP and Prolog can do that and much more.
In addition to RM like representations they can also represent
knowledge for rule based expert systems, frame based reasoning, case
based reasoning, various abstract data types, graphs, natural language
grammers, machine learning ...
Of course RDBMS provide many industrial grade features but the original
poster's concern was about flexibility and the kinds of problems
described appear to have already been solved by Prolog/LISP.
>
> [binary relations snipped]
>
> > Now you can have pretty complex relationships and ask all sorts of
> > queries. Who likes who, who studies what, who teaches what, who is
> > who's parent/grandparent ...
>
> Can it handle n-ary relations? Like "John bought 10 apples each at
> 10cents" ?
Yes.
Cheers.
Alvin Ryder wrote:
> In addition to RM like representations they [prolog and lisp] can also represent
> knowledge for rule based expert systems, frame based reasoning, case
> based reasoning, various abstract data types, graphs, natural language
> grammers, machine learning ...
Wow, a tool that excels at so many things! There must be something
wrong with the industry that have seen puny adoption of both.
Mikito Harakiri wrote:
> Alvin Ryder wrote:
> > In addition to RM like representations they [prolog and lisp] can also represent
> > knowledge for rule based expert systems, frame based reasoning, case
> > based reasoning, various abstract data types, graphs, natural language
> > grammers, machine learning ...
>
> Wow, a tool that excels at so many things! There must be something
> wrong with the industry that have seen puny adoption of both.
Yes that's right lisp and prolog do excel at so many things.
As for adoption, when I did my post grad studies, which included ai, I
could not get away from them they were everywhere but in commercial
enterprise I rarely see them.
The games sector keenly wants ai but many programmers appear to be
re-inventing the wheel by ignoring vast volumes and decades of ai
research, they do so at their loss.
One major game studio I know of has developed their own LISP
environment for the Sony Playstation, I guess they take their ai more
seriously than most.
Game engines are most written in C++ but games scripts and ai can be
implemented in higher level languages. I'd hate to do any ai in C++ and
I'd much rather LISP for it.
Cheers ;-)
On 21 Apr 2006 08:58:26 -0700, Mikito Harakiri wrote:
> Alvin Ryder wrote:
>> In addition to RM like representations they [prolog and lisp] can also represent
>> knowledge for rule based expert systems, frame based reasoning, case
>> based reasoning, various abstract data types, graphs, natural language
>> grammers, machine learning ...
>
> Wow, a tool that excels at so many things! There must be something
> wrong with the industry that have seen puny adoption of both.
No need to be sarcastic. It shares its "wrong something" with RM - there is
no universal search strategy. Though you might be able to represent
knowledge, that alone does not imply that you will be able to use it.
Or, to put it otherwise, it is the old dilemma imperative vs. declarative,
non-constructive vs. constructive.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Dmitry A. Kazakov wrote:
> It shares its "wrong something" with RM - there is
> no universal search strategy.
Never heard of "universal search strategy". Is it the thingy that
universal turing machine does? As for "wrong something" you forgot the
most often cited RM defect: "flat" relations.
On 21 Apr 2006 13:48:12 -0700, Mikito Harakiri wrote:
> Dmitry A. Kazakov wrote:
>> It shares its "wrong something" with RM - there is
>> no universal search strategy.
>
> Never heard of "universal search strategy". Is it the thingy that
> universal turing machine does?
Different languages / paradigms call it different. It might be "inference",
"optimization", "fitting", "search." Turing machine does not do it. That is
the problem. You cannot write an implementation of Prolog or of RDBMS which
would solve *each* problem in a close to optimal way. Specialized programs
written in universal purpose languages outperform integrated engines by
margin. What is worse, to achieve a better performance people start to hack
design breaking otherwise nice abstraction. In the end one has neither
clean maintainable code, nor performance.
> As for "wrong something" you forgot the
> most often cited RM defect: "flat" relations.
There wasn't much work on components either for languages like Prolog, or
for SQL. So it actually is difficult to say if with more advanced languages
based on same paradigms one could have composable abstractions. One concern
is that abstractions seem tend to be hierarchical (like values -> types ->
classes -> sets of types in OOPL.) But that is an observation from the
opposite camp, it might be wrong.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Dmitry A. Kazakov wrote:
>
> There wasn't much work on components either for languages like Prolog, or
> for SQL. So it actually is difficult to say if with more advanced languages
> based on same paradigms one could have composable abstractions.
Yes, this has been on my mind lately as well. The abstraction
facilities
in SQL are poor to nonexistent, and I really wonder what a relational
language with a modern set of abstraction facilities would look like.
Perhaps even hygenic macros could be considered.<gasp>
> One concern
> is that abstractions seem tend to be hierarchical (like values -> types ->
> classes -> sets of types in OOPL.) But that is an observation from the
> opposite camp, it might be wrong.
I think I know what you mean, but I'm not sure. SQL/prolog is about
relational operations, rather than tree operations, so maybe a module
system (or whatever) should be organized relationally, rather than
hierarchically? I am currently leaning away from this idea. I think
that some kind of relational parametric polymorphism is a better
answer.
Marshall
From: Sasa
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <e2bfqh$mng$1@sunce.iskon.hr>
take a look at
http://www.paulgraham.com/avg.html
"During the years we worked on Viaweb I read a lot of job descriptions.
A new competitor seemed to emerge out of the woodwork every month or so.
The first thing I would do, after checking to see if they had a live
online demo, was look at their job listings. After a couple years of
this I could tell which companies to worry about and which not to. The
more of an IT flavor the job descriptions had, the less dangerous the
company was. The safest kind were the ones that wanted Oracle
experience. You never had to worry about those. You were also safe if
they said they wanted C++ or Java developers. If they wanted Perl or
Python programmers, that would be a bit frightening-- that's starting to
sound like a company where the technical side, at least, is run by real
hackers. If I had ever seen a job posting looking for Lisp hackers, I
would have been really worried."
Mikito Harakiri wrote:
> Alvin Ryder wrote:
>
>>In addition to RM like representations they [prolog and lisp] can also represent
>>knowledge for rule based expert systems, frame based reasoning, case
>>based reasoning, various abstract data types, graphs, natural language
>>grammers, machine learning ...
>
>
> Wow, a tool that excels at so many things! There must be something
> wrong with the industry that have seen puny adoption of both.
>
Sasa wrote:
> take a look at
> http://www.paulgraham.com/avg.html
>
> "During the years we worked on Viaweb I read a lot of job descriptions.
> A new competitor seemed to emerge out of the woodwork every month or so.
> The first thing I would do, after checking to see if they had a live
> online demo, was look at their job listings. After a couple years of
> this I could tell which companies to worry about and which not to. The
> more of an IT flavor the job descriptions had, the less dangerous the
> company was. The safest kind were the ones that wanted Oracle
> experience. You never had to worry about those. You were also safe if
> they said they wanted C++ or Java developers. If they wanted Perl or
> Python programmers, that would be a bit frightening-- that's starting to
> sound like a company where the technical side, at least, is run by real
> hackers. If I had ever seen a job posting looking for Lisp hackers, I
> would have been really worried."
And if they were asking Maple or Mathematica he would be really freaked
out? I don't understand what technical excellence has in common with
success on marketplace. That is assuming that "hacking Lisp let alone
Perl" has anything to to with technical excellence.
Mikito Harakiri wrote:
> And if they were asking Maple or Mathematica he would be really freaked
> out?
Probably not. Neither would be a very good fit for the problem, and
neither is widely used by serious programmers to implement general
purpose programs. They are less "geeky" than Perl or Python or Lisp, in
the common parlance of those that Graham considers "hackers". In fact,
in that parlance, they are probably less geeky than Visual Basic.
>I don't understand what technical excellence has in common with
> success on marketplace. That is assuming that "hacking Lisp let alone
> Perl" has anything to to with technical excellence.
Graham is describing an unusual situation: that in which technical
excellence is likely to be a dominant factor. He is suggesting that
young programmers with an entrepreneurial bent find that situation and
compete there.
Most software is produced in a different space, one in which it is hard
to compete against entrenched producers. If I sat down with 50 of my
closest friends and produced a better OS than Windows, it wouldn't be
worth spit, I don't think, even if it was far superior to anything from
Redmond.
But there is always an uncharted frontier in software, where new
applications are competing, largely based on their merits. Graham was
able to make quite a bit of money by competing in that space, based on
not much more than being better at the tech side of things, at least
according to Graham ;). Remember that Viaweb was a fairly early
commercial web app, and that a lot of what we now consider routine was
first charted at that time.
From: Sasa
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <e2cfii$nqn$1@sunce.iskon.hr>
Have you read the entire article? They had reasons for choosing lisp.
Concerning technical excellence - while I am convinced that technical
excellence doesn't guarantee success, nor does success always come
because of technical excellence - I would still reckon that with
knowledge one should increase his odds.
Now personally I have only some basic knowledge of Prolog and know
almost nothing about lisp, however I do believe there is more to life
than OOP and RM and I've been planning for months to learn lisp (being
very lazy - it's still in the plans queue, but that's another story).
Alvin has given some nice reasoning and provided some simple yet
effective examples. Personally, I was impressed about a year ago when I
found out that mathematical expression parser (basic four opperations,
precedence and parentheses included, syntax check + result evaluation)
amounts to 9 lines of code in Prolog.
Mikito Harakiri wrote:
>
>
> And if they were asking Maple or Mathematica he would be really freaked
> out? I don't understand what technical excellence has in common with
> success on marketplace. That is assuming that "hacking Lisp let alone
> Perl" has anything to to with technical excellence.
>
Sasa wrote:
> take a look at
> http://www.paulgraham.com/avg.html
>
> "During the years we worked on Viaweb I read a lot of job descriptions.
> A new competitor seemed to emerge out of the woodwork every month or so.
> The first thing I would do, after checking to see if they had a live
> online demo, was look at their job listings. After a couple years of
> this I could tell which companies to worry about and which not to. The
> more of an IT flavor the job descriptions had, the less dangerous the
> company was. The safest kind were the ones that wanted Oracle
> experience. You never had to worry about those. You were also safe if
> they said they wanted C++ or Java developers. If they wanted Perl or
> Python programmers, that would be a bit frightening-- that's starting to
> sound like a company where the technical side, at least, is run by real
> hackers. If I had ever seen a job posting looking for Lisp hackers, I
> would have been really worried."
How disappointing! Someone posted an anecdote about the superiority of
lisp in a cross-posted thread I was in several years ago, and it was the
same anecdote!
Has nobody taken the advice? Or have they simply failed to reproduce the
results?
From: Nick Malik [Microsoft]
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <gr6dna6YR42E9tfZRVn-pw@comcast.com>
"Mikito Harakiri" <···················@yahoo.com> wrote in message
·····························@e56g2000cwe.googlegroups.com...
> Alvin Ryder wrote:
>> In addition to RM like representations they [prolog and lisp] can also
>> represent
>> knowledge for rule based expert systems, frame based reasoning, case
>> based reasoning, various abstract data types, graphs, natural language
>> grammers, machine learning ...
>
> Wow, a tool that excels at so many things! There must be something
> wrong with the industry that have seen puny adoption of both.
>
The problem, I believe, is not with the language. It is with the fact that
it is an outgrowth of trying to solve problems that researchers find
interesting, rather than solving problems that business and industry find
interesting. Few systems have made the leap from one to the other.
As an Enterprise Architect, I work with business systems that do things like
track items in the supply chain and manage billing in a way that enforces
policy or encourages the behavior of the most productive partners. Simple
stuff with complex rules that business folks have been doing for decades.
The most interesting problems are operational concerns: make it work
efficiently for tens of thousands of things.
Prolog is more appropriate for design problems, not operational problems
(although a great deal of passion surrounds the concepts for combining the
two, little has happened). My guess: the design problems are the ones that
people would rather do, and not give away to their computer.
So it is a powerful language that does things that people don't want it to
do, but doesn't do things that people want computers to do. It is not
dead, but it is not exactly thriving either.
I'm convinced that the greatest future for Prolog is in framework
implementations like P#, where the prolog language can be used by C# and can
use C# objects, which gives you access to all of the features of an
object-oriented language that is closely allied with commercial RDBMS and
XML heirarchical data models, and all the geeky stuff that we talk about in
programming forums. That way, you can use Prolog for the things that it
does well, but for the rest of the problem, use C#, and through C#, use all
the other stuff.
--
--- 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.
--
Nick Malik [Microsoft] wrote:
> "Mikito Harakiri" <···················@yahoo.com> wrote in message
> ·····························@e56g2000cwe.googlegroups.com...
>
>>Alvin Ryder wrote:
>>
>>>In addition to RM like representations they [prolog and lisp] can also
>>>represent
>>>knowledge for rule based expert systems, frame based reasoning, case
>>>based reasoning, various abstract data types, graphs, natural language
>>>grammers, machine learning ...
>>
>>Wow, a tool that excels at so many things! There must be something
>>wrong with the industry that have seen puny adoption of both.
>
> The problem, I believe, is not with the language. It is with the fact that
> it is an outgrowth of trying to solve problems that researchers find
> interesting, rather than solving problems that business and industry find
> interesting. Few systems have made the leap from one to the other.
That's really odd, because just as Sasa posted a link suggesting the
strategic importance of Lisp in some spheres, I recall someone posting
in a consulting forum in the early 1990's how as a prolog consultant he
was able to deliver information of strategic importance to his clients.
Whether it took the computer a week to churn through everything and spit
out an answer didn't matter because the answers spit out where otherwise
not available at all or not available until after months or years of
hindsight. Allegedly the resulting insights gave such important
market-leading insights that clients happily paid him lots of money to
create the prolog models and run them.
Of course, 90% of what one reads online is complete BS. But perhaps he
was in the other 10%.
What I don't understand is how suggesting that introducing a much
lower-level language will improve things. It seems rather like
suggesting one should embed assembly language in a C# program.
That strikes me as wrong-headed. Like the suggestions we need to cripple
relational dbmses to avoid impedance mismatch with much lower-level
languages instead of suggesting to improve the programming languages.
Nick Malik [Microsoft] wrote:
> "Mikito Harakiri" <···················@yahoo.com> wrote in message
> ·····························@e56g2000cwe.googlegroups.com...
> > Alvin Ryder wrote:
> >> In addition to RM like representations they [prolog and lisp] can also
> >> represent
> >> knowledge for rule based expert systems, frame based reasoning, case
> >> based reasoning, various abstract data types, graphs, natural language
> >> grammers, machine learning ...
> >
> > Wow, a tool that excels at so many things! There must be something
> > wrong with the industry that have seen puny adoption of both.
> >
>
> The problem, I believe, is not with the language. It is with the fact that
> it is an outgrowth of trying to solve problems that researchers find
> interesting, rather than solving problems that business and industry find
> interesting. Few systems have made the leap from one to the other.
>
> As an Enterprise Architect, I work with business systems that do things like
> track items in the supply chain and manage billing in a way that enforces
> policy or encourages the behavior of the most productive partners. Simple
> stuff with complex rules that business folks have been doing for decades.
> The most interesting problems are operational concerns: make it work
> efficiently for tens of thousands of things.
>
> Prolog is more appropriate for design problems, not operational problems
> (although a great deal of passion surrounds the concepts for combining the
> two, little has happened). My guess: the design problems are the ones that
> people would rather do, and not give away to their computer.
>
> So it is a powerful language that does things that people don't want it to
> do, but doesn't do things that people want computers to do. It is not
> dead, but it is not exactly thriving either.
>
> I'm convinced that the greatest future for Prolog is in framework
> implementations like P#, where the prolog language can be used by C# and can
> use C# objects, which gives you access to all of the features of an
> object-oriented language that is closely allied with commercial RDBMS and
> XML heirarchical data models, and all the geeky stuff that we talk about in
> programming forums. That way, you can use Prolog for the things that it
> does well, but for the rest of the problem, use C#, and through C#, use all
> the other stuff.
>
Hi Nick,
P# sounds very interesting, I'll check it out. Extending, integrating
or otherwise assimilating prolog is what I had in mind. Prolog seems to
do the kinds of things Neo talks about but of course it has its own
problems, if all goes well P# plus C# would be the best of both worlds.
Cheers.
> --
> --- 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.
> --
From: Sasa
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <e2e1rh$pl1$1@sunce.iskon.hr>
Nick Malik [Microsoft] wrote:
> I'm convinced that the greatest future for Prolog is in framework
> implementations like P#, where the prolog language can be used by C# and can
> use C# objects, which gives you access to all of the features of an
> object-oriented language that is closely allied with commercial RDBMS and
> XML heirarchical data models, and all the geeky stuff that we talk about in
> programming forums. That way, you can use Prolog for the things that it
> does well, but for the rest of the problem, use C#, and through C#, use all
> the other stuff.
>
Exactly! It's about "synergy" of various paradigms, languages and
technologies. It's happening already (e.g. OOP+RDBMS or HTML + JScript +
OOP) and I think it's the way languages should be treated - not as a
single development platform, but rather as a technology to solve part of
the problem in the entire solution which is comprised of more languages.
Sasa wrote:
> Nick Malik [Microsoft] wrote:
>
>> I'm convinced that the greatest future for Prolog is in framework
>> implementations like P#, where the prolog language can be used by C#
>> and can use C# objects, which gives you access to all of the features
>> of an object-oriented language that is closely allied with commercial
>> RDBMS and XML heirarchical data models, and all the geeky stuff that
>> we talk about in programming forums. That way, you can use Prolog for
>> the things that it does well, but for the rest of the problem, use C#,
>> and through C#, use all the other stuff.
>
> Exactly! It's about "synergy" of various paradigms, languages and
> technologies. It's happening already (e.g. OOP+RDBMS or HTML + JScript +
> OOP) and I think it's the way languages should be treated - not as a
> single development platform, but rather as a technology to solve part of
> the problem in the entire solution which is comprised of more languages.
I am not sure what newsgroup you post from, but in almost all cases,
OOP+RDBMS is a regression to network model. It loses a lot without any gain.
Bob Badour <·······@pei.sympatico.ca> writes:
> Can it handle n-ary relations? Like "John bought 10 apples each at
> 10cents" ?
Of course:
bought(john,10,apple,10,cent).
How many apple did john buy?
?- bought(john,HowMany,apple,_price,_money).
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Pascal Bourguignon wrote:
> Bob Badour <·······@pei.sympatico.ca> writes:
>
>>Can it handle n-ary relations? Like "John bought 10 apples each at
>>10cents" ?
>
>
> Of course:
>
> bought(john,10,apple,10,cent).
>
> How many apple did john buy?
>
> ?- bought(john,HowMany,apple,_price,_money).
Thank you, that's much more revealing than 100 binary relations.
Does prolog summarize the results? Or does it list each individual purchase?
Consider:
bought(john,10,apple,10,cent).
bought(john,3,apple,15,cent).
?- bought(john,HowMany,apple,_price,_money).
Bob Badour wrote:
> Pascal Bourguignon wrote:
>
> > Bob Badour <·······@pei.sympatico.ca> writes:
> >
> >>Can it handle n-ary relations? Like "John bought 10 apples each at
> >>10cents" ?
> >
> >
> > Of course:
> >
> > bought(john,10,apple,10,cent).
> >
> > How many apple did john buy?
> >
> > ?- bought(john,HowMany,apple,_price,_money).
>
> Thank you, that's much more revealing than 100 binary relations.
>
But those snipped relationships are the kinds of things the original
poster was talking about ;-)
> Does prolog summarize the results? Or does it list each individual purchase?
>
Straight out of the can it doesn't summarize the results, it stops when
one solution to a goal is found. You enter ; and it seeks another
solution.
But anything that can represent a Rubix cube and solve it in about 600
lines of code can be made to do all sorts of clever things.
OTOH if you're searching for things Prolog cannot do you're right,
there are many apparently easy things it can't do, that's why I
originally spoke of possibly extending it.
> Consider:
>
> bought(john,10,apple,10,cent).
> bought(john,3,apple,15,cent).
>
> ?- bought(john,HowMany,apple,_price,_money).
Bob Badour <·······@pei.sympatico.ca> writes:
> Pascal Bourguignon wrote:
>
>> Bob Badour <·······@pei.sympatico.ca> writes:
>>
>>>Can it handle n-ary relations? Like "John bought 10 apples each at
>>>10cents" ?
>> Of course:
>> bought(john,10,apple,10,cent).
>> How many apple did john buy?
>> ?- bought(john,HowMany,apple,_price,_money).
>
> Thank you, that's much more revealing than 100 binary relations.
>
> Does prolog summarize the results? Or does it list each individual purchase?
>
> Consider:
>
> bought(john,10,apple,10,cent).
> bought(john,3,apple,15,cent).
>
> ?- bought(john,HowMany,apple,_price,_money).
Perhaps it's time you download a prolog implementation and browse a
prolog tutorial ;-)
I'd advise swi-prolog: http://www.swi-prolog.org/
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best." -- Frank Zappa
"Alvin Ryder" <········@telstra.com> wrote in message
·····························@i40g2000cwc.googlegroups.com...
> Neo wrote:
>> .
>> Thanks for the above info. It seems the focus of Prolog and my db (with
>> LISP-like interface) are quite different (at least at this time). While
>> Prolog's primary focus seems to be deducing answering based on
>> questions and data stored in linked lists; the focus of the
>> experimental db is to provide the most flexible method of representing
>> things.
>
> Hi Neo,
>
> Prolog is not based on linked lists, it is based on something very
> different namely "facts" and "rules" these give rise to incredible
> flexibility and power.
>
> I encourage you to at least take a good look at Prolog and LISP. You
> may be able to get off to a flying start by begining with one of them
> and extending? They'll at least give you some very interesting ideas
> and I reckon you'll have fun - I know I did.
>
<<snip>>
It is good to see someone else who understands Prolog.
It is one of the most fun languages you can use. I have to say that I
learned more about knowledge representation, information theory, and
deductive analysis while coding in Prolog than in any other activity in my
life.
I'm thinking of teaching Prolog to my middle-school-aged kids so they can
get a head-start on understanding how knowledge representation drives
association and deduction.
--
--- 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.
--
From: Nick Malik [Microsoft]
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <D6qdnX2y2JCWHtfZRVn-sQ@comcast.com>
"Neo" <········@hotmail.com> wrote in message
·····························@z34g2000cwc.googlegroups.com...
> Below is a simple example that stores a person named John who likes
> Mary and then finds who John likes. Could you or someone familiar with
> Prolog show how to do this. Later I would like to extend the example to
> distill Prolog's fundamental forte (and possible weakness in
> representing things).
Get ready for a really long program!
likes(john, mary).
That's it.
The query looks like this:
?- likes(john, Who)
the response is:
Who = mary
Not much to it really.
I guess it is only interesting in the fact that your language takes about 30
lines to do what Prolog does in, what, one?
--
--- 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.
--
From: Nameless
Subject: Re: Storing data and code in a Db with LISP-like interface
Date:
Message-ID: <q2N2g.9820$zc1.3391@amstwist00>
"Nick Malik [Microsoft]" <·········@hotmail.nospam.com> wrote in
message ···························@comcast.com...
> "Neo" <········@hotmail.com> wrote in message
> ·····························@z34g2000cwc.googlegroups.com...
>
>> Below is a simple example that stores a person named John who
>> likes Mary and then finds who John likes. Could you or someone
>> familiar with Prolog show how to do this. Later I would like
>> to extend the example to distill Prolog's fundamental forte
>> (and possible weakness in representing things).
>
> Get ready for a really long program!
>
> likes(john, mary).
>
> That's it.
>
> The query looks like this:
>
> ?- likes(john, Who)
>
> the response is:
>
> Who = mary
>
>
> Not much to it really.
> I guess it is only interesting in the fact that your language takes about
> 30 lines to do what Prolog does in, what, one?
Then that language must be particularly verbose; the size
of a Prolog program is generally considered to be 10% that
of a comparable imperative one (C, Pascal etc.).
--
Mail sent to this email address is deleted unread
on the server. Please send replies to the newsgroup.
> > Below is a simple example that stores a person named John who likes
> > Mary and then finds who John likes. Could you or someone familiar with
> > Prolog show how to do this. Later I would like to extend the example to
> > distill Prolog's fundamental forte (and possible weakness in
> > representing things).
> Get ready for a really long program! likes(john, mary). That's it.
> The query looks like this: ?- likes(john, Who)
> the response is: Who = mary
> Not much to it really. I guess it is only interesting in the fact that
> your language takes about 30 lines to do what Prolog does in, what, one?
:) The number of lines to do something isn't particular a good way to
evaluate more important aspects. Here dbd (db for dummies) does the 30
lines in two too! It creates a new thing named john who is a person and
person is a thing; a new thing named like which is a verb which is a
thing; a new thing named mary who is a person and a doctor which are
things; and creates the relationship "john like mary", all in one line.
(create (new 'john' 'person') (new 'like' 'verb') (new 'mary' 'person'
'doctor'))
(select john like *)
Now you are ready for the Food Judge Example C posted above!
Nick Malik [Microsoft] wrote:
> Much of the work on semantic machine learning was done in Prolog in the
> 1980s. The problem that Prolog faced was that it was fairly easy, with
> early engines, to create perfectly legal programs that failed to evaluate
> because the logic engine wasn't sophisticated enough to prune the tree
> efficiently. This was solved by researchers at SUNY in New York with the
> XSB prolog system. http://www.cs.sunysb.edu/~sbprolog/xsb-page.html
>
> Versions of Prolog exist now for a wide array of platforms, including a
> version of Prolog that compiles to the .Net Framework called P#.
> http://www.dcs.ed.ac.uk/home/stg/Psharp/
Cool. I see that P# was based on a similar Prolog to Java compiler
called Prolog Cafe.
I wonder how close to compatible the two are?
>> [some complex apps will never be practical using RMDBs]
.
> [complex?] What is an example?
The example like the one in the post that you just responded to that
creates the equivalent of tables, attributes and values of
various/multiple new types at run-time. The example like the one given
in response to Roy Hann earlier in this thread which creates a
parent/child hierarchy with multiple things, then creates a function
named getRoot(hier, thing) stored in db itself, then creates a second
boss/employe hierarchy using some of the same things in parent/child
hierarchy and then verifies getRoot still works with both hierarchies;
and even works after adding a person without a name in the hierarchy;
and still works when we allow the name employe to have a second
spelling 'employee'; and still works when boss is given an alternate
name employer; ALL AT RUN-TIME, without the user ever having to specify
a schema, IDs, referential intergrity constraints or normalizing data,
yet the db is fully normalized and NULL-less!!!
In general, the complexity starts to become apparent when one tries to
create an initial RM schema that will allow it to store any data, whose
structure is unknown at design-time and only known at run-time and all
data is to be normalized, NULL-less and have referential integrity
enforced. Please see recent thread titled "Multiplicity, Change and MV"
which discusses a similar topic.
>> dynamic [stuff] impractical to implement in the context of RM.
.
> Why is that?
The right wrench (schema) is hard to pick in advance for a nut (data)
whose size (structure) is unknown until encountered out in the field
(run-time) at the tippy-top of a tall antenna tower in Timbuktu. With
RM, the service man (developer) has to return to the workshop
(design-time) to get the right size wrench (new schema) for the job. My
data model allows the equivalent of an adjustable wrench which adapts
to the nut encountered in the field.
TopMind, you understandably have some misperceptions about the
experimental db. The best and sometimes the only way to clarify them is
to actually represent some things and compare the process and results.
Would you be willing go thru this process with me? It requires you to
post SQL script to represent some things and perform some queries. It
isn't my goal to embarass anyone, but simply to compare the two
methodologies, each of which have strong points and weakness that make
them appropriate for different scopes. I am not concerned about trivial
matters such as naming conventions\, punctuation, style, obvious
omissions, simple errors, etc. I am able to email you a small zip file
(200Kb, 1/7th of a floppy) for verification, if requested. It contains
the script to create db, db file and db executable. The program
requires no installation. Just double-click to run. Throw in trash when
done.
During the pask week, I have posted the following examples:
1) People in multiple matrix hierarchies and getRoot function.
2) Judges, bailiffs, clerks, etc in various parts of court building.
(see thread titled "Data Model")
3) Foods that a john likes.
Would you be wishing to proceed with the last example which the
simplest?
Below I have answered your questions, which can lead to you asking even
more questions, and so on forever! So I prefer you engage in a simple
example which will begin to answer your questions more clearly and
definitively.
> I find that trees don't model real organizations very well. Having multiple bosses is fairly common. (Known as "a matrix organization" in some co's)
First, I am not using the hierarchal methodology to represent things. I
have not ever clearly described my data model (nor do I want to at this
time). For now, you will only be able to judge by the ability of a
particular implementation of that model (which is difficult to achieve
completely because ideally it needs massive memory and a massively
multi-processor system, similar to the brain).
Second there is a difference between
a) representing things using a methodology
b) and displaying some limited view of those things in a GUI control.
For example, while I can display things in text, grids and tree
controls, all of these only provide a limited view of the actual data.
I would like to display things in a control that can draw nodes and
link with labels, however I currently do not have such a control that
is common and preferrably from Microsoft. (If someone knows one, please
suggest it).
To be clear, I haven't asserted that hierarchal methodolgy is ideal for
representing organizations with multiple parents. In fact, I assert
that while it is theoretically possible to use the hierarchal
methodology to model hierachies that have things with multiple parents,
it is mostly impractical (and probably can't be normalized).
In the example I gave, the hierarchy does have things with multiple
parents. For example, abraham has two parents, adam and eve. If you
would like to specify a more "matrix-like" hierarchy, please describe
and I will represent it, but note that I can only display that
hierarchy/matrix in a grid or tree control at this time. Also, among
other means, by displaying the ID of nodes in the tree control, one can
verify that even though a thing appears multiple times in the tree
control, the underlying data is not redundant as they all have the same
IDs.
Also in the example I gave, some of the things are in multiple
hiearchies. For example, not only are adam and eve in the parent/child
hierarchy, but also in the boss/employee hierarchy.
Also in the example I gave, the hierarchy going "up" is independent of
the hierarchy going "down". While not appropriate for the parent/child
hierarchy, it is possible for thing A to be the "parent" of thing B
while thing B is not a "child" of thingA. While not commonly desired,
this level of flexibility requires extra complexity in RM. This is
partially what allows the getRoot function to work in either direction.
> If you want flexibility, then have a many-to-many Boss (or ReportsTo) table.
This is true IF one is using RM. To realize how easy/systematic it is
to represent a complex matrix with the experimental db, one needs to
actually model the same matrix with an RMDB. Please try to model that
which I already have, using RM (or as a 2nd option, please specify a
new matrix of similar complexity).
> > and even works after adding a person without a name in the hierarchy; and still works when we allow the name employe to have a second spelling 'employee'; and still works when boss is given an alternate name employer; ALL AT RUN-TIME, without the user ever having to specify a schema, IDs, referential intergrity constraints or normalizing data, yet the db is fully normalized and NULL-less!!!
.
> If the user can change the schema willy-nilly, ...
First I need to know the exact definition of schema. Unfortunately, the
one you are probably thinking of is in context to RM. So it becomes
something like a car mechanic asking a jet mechanic where are the
pistons? It seems to me that when generalized to correspond with the
experimental data model, schema is actually a set of user-defined
constriants that limit what data can be entered (partially for the
benefit of the poor programmer who has to implement the data model).
Rather than saying whether there is a schema (piston) or not and if it
changes, it is better for me to describe the functionality (of the jet
engine). And that is, the db is capable of storing, recalling, querying
and manipulating representations of things without the user specifying
something the equivalent of a schema in RM.
> ... then there is no way on earth technology can enforce normalizaton (short of AI)
And yet the experimental db does exactly this! I woundn't exactly call
it AI but it lays the ground for AI-ishness later. However I am trying
to no longer user the term normalization because it's definition is
specific/limited to RM. In the experimental db, each thing is
represented only once. There are no redundant representations of things
in the experimental db. Among other methods, this can be verified by
seeing the ID of a thing is the same no matter how many times it
appears in a view.
> because it cannot know if two things with a different name are really the same thing in practice. It would have to have common sense.
??? I think you mis-stated what you intended. If you have two things,
then they are different, regardless of the names of the two things.
If you meant, how can the experimental db knows if two things with the
same name are really different, it is not because it has common sense,
but because enough data was given to it and the query is selective
enough.
If you meant, how can the experimental db knows if two names really
identify the same thing, it is not because it has common sense, but
because enough data was given to it and the query is selective enough.
Your puzzlement of how the db does this, should cue you to the
possibility that more is going on than appears initially. Best way to
find out is to engage in an example and actually submit those queries
to the experimental db.
> Further, a Lisp DB cannot be shared with other languages. One of the advantages of a RDBMS is that different languages and tools can all use the *same* database.
The experiment db is NOT a LISP DB! The data resides in a file. To
interface to that file, one must use the provided DLL which implements
the db engine (50KB). The DLL provides a low-level and a high-level
interface to the data. The low-level interface consists of functions
which provide more power/flexibility than the high-level interface. The
high-level interface is LISP-like. To utilize the LISP-like interface,
one calls a function with the preformed string such as "(create john
like mary)" or "(select john like *)". Also an executable is provided
which has the DLL embedded in it. The executable provides a tree, grid
and text based interface. For example, one can submit LISP-like
expression via the edit box. For example, one can
view/add/delete/modify data via the tree control. For example, one can
view and add certain data via the grid control. The DLL is best
interfaced to languages like C/C++ and Delphi but can also be called by
Visual Basic.
> Unless you want to turn Lisp into a query language (ick!), that won't happen.
Actually it turns out that LISP-like syntax is appropriate for the
experimental db. If you were to actually create the equivalent queries
in SQL and compare it with some of the queries for the experimental db,
you would begin to realize why that is. You will not realize how
complex a simple looking query like "(select john like *)" really is
until you attempt to implement the equivalent things/flexibility in
RMDB.
> Nulls are a vendor-specific idea, not inherent to relational.
I would disagree. NULLs have almost nothing to do with vendors.
In the case one wants to add a tuple without having a value for every
attribute defined by the relation's schema, he can:
1) not choose to insert that tuple (not always acceptable) thus
avoiding NULLs.
2) choose to insert the tuple anyways and incurr NULLs for the missing
values which can be filled with masking values either of which result
in three-valued logic.
3) redesign the db schema (add more relations and links) to enter the
data without NULLs. This can impact existing scripts, queries, code and
GUI.
The experimental db can never incur NULLs in the above manner as it has
no constraints equivalent to schema (but an application can represent
the constriants in the db and enforce them via code, if desired).
> This battle was already faught between Charles Bachman and Dr. Codd in the 70's when navigational fought with relational. Bachman wanted ad-hoc "pointers" to build databases, while Codd felt that tables added more discipline to databases.
All I can say is that, I want you to evaluate based on actual results.
When using the high-level interface, the user doesn't deal with IDs or
pointers. You won't see either in the scripts also.
> As far as dynamic schemas, you have yet to back your claim that they are inharently inefficient.
I think it may be better for people who think dynamic schemas are
practical in RM to implement it, than it is for me to explain further
why it is impractical.
> It is a trade-off to weigh against patterns of change.
My primary concern isn't about memory requirements, processing time, or
asthetics. It is to implement the most general/flexible method of
representing things.
> The idea of a "multiple paradigm database" can basically have one big dynamic table
The experimental db isn't a multiple-paradigm database. It has a single
methodology that is so general that it is capable of doing what other
paradigms can, albeit not as efficiently in the scope of a particular
paradigm which become more and more impractical the further they get
outside their scope.
> but it is essentially a navigational database in relational clothing: A navigational database is like a shanty town: no guidence and no rules. Yes, it is flexible because if you need something, you simply hammer it on. However, it is a mess to navigate and manage.
You are now making assertions that are false. If you model the data
with similar flexiblities and post the SQL queries that are equivalent
to the experimental db's, this will be disprove your assertion.
> No database paradigm will make changes in quantities-of-relationships
easy.
I not exactly sure what you mean, but maybe you can show this when
engaging in an actual example.
> For example, if a relationship changes from one-to-many into many-to-many, this will be a mess regardless of whether you use Bachman's techique or relational.
It isn't in my methodology where the db is solely responsible for
representing thing, not for implementing user-defined constraints.
TopMind, it is easier to clear up some of the misconceptions if you
engage in an actual example.
Neo wrote:
> TopMind, you understandably have some misperceptions about the
> experimental db. The best and sometimes the only way to clarify them is
> to actually represent some things and compare the process and results.
> Would you be willing go thru this process with me? It requires you to
> post SQL script to represent some things and perform some queries. It
> isn't my goal to embarass anyone, but simply to compare the two
> methodologies, each of which have strong points and weakness that make
> them appropriate for different scopes. I am not concerned about trivial
> matters such as naming conventions\, punctuation, style, obvious
> omissions, simple errors, etc. I am able to email you a small zip file
> (200Kb, 1/7th of a floppy) for verification, if requested. It contains
> the script to create db, db file and db executable. The program
> requires no installation. Just double-click to run. Throw in trash when
> done.
>
> During the pask week, I have posted the following examples:
> 1) People in multiple matrix hierarchies and getRoot function.
> 2) Judges, bailiffs, clerks, etc in various parts of court building.
> (see thread titled "Data Model")
My version is at:
http://www.c2.com/cgi/wiki?CourtRoomSchemaExample
[....]
> > This battle was already faught between Charles Bachman and Dr. Codd in the 70's when navigational fought with relational. Bachman wanted ad-hoc "pointers" to build databases, while Codd felt that tables added more discipline to databases.
>
> All I can say is that, I want you to evaluate based on actual results.
> When using the high-level interface, the user doesn't deal with IDs or
> pointers. You won't see either in the scripts also.
>
It is admittedly difficult to articulate why navigational structures
are difficult to use. Let me try to put it this way: Knowing the
"quantity of relationships" between the "nouns", most designers will
come up with pretty much the same relational schema if they go to
3rd-normal-form. The differences will usually be minor between
designers. The same is not true of navigational structures and thus
there is no consistency. There are too many ways to do the same thing.
They "work", but it takes a while to get your head around them because
each has a different flavor and feel, often depending on the needs of a
given app, whereas relational schemas (ideally) reflect information
normalization, not usage patterns.
Navigational structures are the "Goto's" of attribute structures: they
"work", but are difficult to follow and inconsistent.
> > As far as dynamic schemas, you have yet to back your claim that they are inharently inefficient.
>
> I think it may be better for people who think dynamic schemas are
> practical in RM to implement it, than it is for me to explain further
> why it is impractical.
>
I would suggest giving a scenario that would allegedly be slower than
yours.
-T-
> > The best and sometimes the only way to clarify [misperceptions] is to actually represent some things and compare the process and results. Would you thru this process [with example] Judges, bailiffs, clerks, etc in various parts of court building. (see thread titled "Data Model")
> My version is at: http://www.c2.com/cgi/wiki?CourtRoomSchemaExample
I will go over the provided link with greater focus, as soon as I can.
Will it be ok, to copy the script from there into Google for
discussion?
TopMind, thanks in advance for your patience. I am just crawling out of
bed and wanted to make a quick post acknowledging yours. I am assuming
we will initially try to create a RM solution similar to the one I have
already posted which includes sample data, queries; tree/grid views
from exe; and admittedly is biased. Below I have copied over exp db's
solution originally posted in thread titled "Data Model". Please excuse
grandiose statements made in original post to OP.
> Abbreviated description of problem posed by OP of thread titled "Data Model".
> There are many Judges.
> There are many Buildings.
> There are many Locations inside buildings (such as floors).
> Each judge must reside at exactly one location.
> A staff member has a name, phone number, and email.
> Each judge has [5] staff members, one of each type:
> Clerk, Assistant Clerk, Coordinator, Bailiff and Court Reporter.
The script [much later below] populates [the] exp db with the following
persons: Judge Judy (phone# 333-5555, email ····@aol.com &
·········@law.com) who has following staff members: Clerk Clark (who
has Assistant Ashley), Coordinator Colby, Bailiff Brandy and
Court-Reporter Courtney each with various properties. Building
CourtHouse1 has two floors. The first floor has room1. The second floor
has room1 and room2. Various persons are placed in different parts of
CourtHouse1. The sample query (near end of script, [bottom of this
post]) finds a staff member of a judge whose assistant has a certain
phone#. Data can be easily navigated when viewed in a tree just by
clicking nodes (even though the underlying data doesn't necessarily
have a tree structure); where as in RM, it will require one to join
multiple tables. If requested, I can email the populated db/exe (188 kb
zip file) so one can see for themselves. Note, it is a prototype so
other features may not work. Note, I did not make bi-directional
relationships (ie ····@aol.com emailOf judy) to keep the example
simple. One effect of creating bi-directional relationships would have
been to allow user to effectively "walk up" any [heirarchy] while
expanding tree nodes [in down direction]. Note, script expressions
become more elaborate when dealing with multiple things with the same
name.
Unlike RMDBs, where one must first design a schema/structure to hold
anticipated data, no schema is required before entering data in the
experimental db. The reason is, it already starts with a very general
schema that is capable of modelling most anything in a normalized
manner. This is partially why unanticipated types of data can be added
on the fly during execution without a design/compile phase. Db
automatically normalizes data and maintains referential integrity.
Other constraints, such as each person must have a phone number or 6
staff members, need to be implemented at code level [currently and for
a while] where as RMDBs can implement such basic constriants at db
level.
Because the script [much later below is foreign looking], I will
[first] show how [some of] the data appears when viewed in the db's
grid and tree views. The grid view below only shows instances of
person. The tree view below, on the other hand, shows most of the
relevant things... In essence, the tree nodes display sentences in
Subject-verb-Object format. In order to describe the tree view [in
Google vs the actual db exe], I have adopted some conventions. Tree
nodes representing subjects and objects are capitalized where as verbs
are not. [Verbs are prefixed and suffixed by a dash]. Also the object
of the initial sentence becomes the subject of the subsequent sentence
and so on. For example, the sentences "Building instance CourtHouse1"
and "CourtHouse1 has Floor1" is displayed as the following sequence of
nodes: Building, -instance-, CourtHouse1, -has-, Floor1, etc. Also a
"+" symbol after a node indicates that it can be expanded to that shown
else where in the tree. [While the tree view displays thing
redundantly, the underlying data is not, and one way of verifying this
is by displaying each nodes ID]. Thus the user (even a child) can
easily navigate to all the details of various things no matter what
tree path is taken, without anybody having to join tables (and there
will eventually be many). All this is much easier to see, just by
clicking around in the small db/exe which fits on a floppy.
[Below is the] Grid View of Person Instances. Note, grid only shows
first value of an attribute. [Switch to fixed fonts for columns to line
up]
ID name phone# email staffMember
-- --------- -------- ------------- -----------
# judy 333-5555 ····@aol.com clark
# clark 737-5588
# ashley 737-5588
# colby ····@msn.com
# brandy 919-9945
# courtney 203-9898 ····@gov.org
[Below is the] Tree View of Relevant Things: Notice that the tree can
show multiple values of an attribute. Notice that a person can be
located in a building, on a floor or in a room. Ask the RMDB experts
how they would achieve this in a normalized, NULL-less manner.
Dir
|-item-
|-Building
| |-instance-
| |-CourtHouse1
| |-has-
| |-Floor1+
| |-Floor2+
| |-Courtney+
|
|-Floor
| |-instance-
| |-Floor1
| | |-has-
| | |-Room1+
| | |-Ashley+
| |
| |-Floor2
| |-has-
| |-Room1+
| |-Room2+
|
|-Room
| |-instance-
| |-Room1 (of Floor1)
| | |-has-
| | |-Clark+
| |
| |-Room1 (of Floor2)
| |
| |-Room2 (of Floor2)
| |-has-
| |-Judy+
|
|-Person
| |-instance-
| |-Judy
| | |-phone#-
| | | |-333-5555
| | | |-JDG-JUDY
| | |
| | |-email-
| | | ····@aol.com
| | | ······@law.com
| | |
| | |-staffMember-
| | |-Clark+
| | |-Ashley+
| | |-Colby+
| | |-Brandy+
| | |-Courtney+
| |
| |-Clark
| | |-phone#-
| | | |-737-5588
| | |
| | |-assistant-
| | |-Ashley+
| |
| |-Ashley
| | |-phone#-
| | |-737-5588
| |
| |-Colby
| | |-email-
| | ·······@msn.com
| |
| |-Brandy
| | |-phone#-
| | |-919-9945
| |
| |-Courtney
| |-phone#-
| | |-203-9898
| |
| |-email-
| ····@gov.org
|
|-Judge
| |-instance-
| |-Judy+
|
|-StaffMember
| |-instance-
| |-Clark+
| |-Ashley+
| |-Colby+
| |-Brandy+
| |-Courtney+
|
|-Clerk
| |-instance-
| |-Clark+
| |-Ashley+
|
|-Assistant
| |-instance-
| |-Ashley+
|
|-Coordinator
| |-instance-
| |-Colby+
|
|-Bailiff
| |-instance-
| |-Brandy+
|
|-CourtReporter
| |-instance-
| |-Courtney+
|
|-Phone#
| |-instance-
| |-333-5555
| |-JDG-JUDY
| |-737-5588
| |-919-9945
| |-203-9898
|
|-Email
|-instance-
····@aol.com
·····@law.com
······@msn.com
····@gov.org
// **** START OF LISP-LIKE SCRIPT TO CREATE DB ****
// Create a type named building.
(create type instance (new))
(create (it) name (findElseAdd name instance 'building'))
(create dir item (it))
// Create a type named floor.
(create type instance (new))
(create (it) name (findElseAdd name instance 'floor'))
(create dir item (it))
// Create a type named room.
(create type instance (new))
(create (it) name (findElseAdd name instance 'room'))
(create dir item (it))
// Create a type named person.
(create type instance (new))
(create (it) name (findElseAdd name instance 'person'))
(create dir item (it))
// Create a type named judge.
(create type instance (new))
(create (it) name (findElseAdd name instance 'judge'))
(create dir item (it))
// Create a type named staffMember.
(create type instance (new))
(create (it) name (findElseAdd name instance 'staffMember'))
(create dir item (it))
// Create a type named clerk.
(create type instance (new))
(create (it) name (findElseAdd name instance 'clerk'))
(create dir item (it))
// Create a type named assistant.
(create type instance (new))
(create (it) name (findElseAdd name instance 'assistant'))
(create dir item (it))
// Create a type named coordinator.
(create type instance (new))
(create (it) name (findElseAdd name instance 'coordinator'))
(create dir item (it))
// Create a type named bailiff.
(create type instance (new))
(create (it) name (findElseAdd name instance 'bailiff'))
(create dir item (it))
// Create a type named courtReporter.
(create type instance (new))
(create (it) name (findElseAdd name instance 'courtReporter'))
(create dir item (it))
// Create a type named phone#.
(create type instance (new))
(create (it) name (findElseAdd name instance 'phone#'))
(create dir item (it))
// Create a type named email.
(create type instance (new))
(create (it) name (findElseAdd name instance 'email'))
(create dir item (it))
// Create a verb instance named has.
(create verb instance (new))
(create (it) name (findElseAdd name instance 'has'))
// Create a person/judge named Judy.
(create person instance (new))
(create judge instance (it))
(create (it) name (findElseAdd name instance 'judy'))
(create (it) phone# (findElseAdd phone# instance '333-5555'))
(create (it) phone# (findElseAdd phone# instance 'JDG-JUDY'))
(create (it) email (findElseAdd email instance ····@aol.com'))
(create (it) email (findElseAdd email instance ····@law.com'))
// Create a person/staffMember/clerk named Clark.
(create person instance (new))
(create staffMember instance (it))
(create clerk instance (it))
(create (it) name (findElseAdd name instance 'clark'))
(create (it) phone# (findElseAdd phone# instance '737-5588'))
// Create a person/staffMember/clerk/assistant named Ashley.
(create person instance (new))
(create staffMember instance (it))
(create clerk instance (it))
(create assistant instance (it))
(create (it) name (findElseAdd name instance 'ashley'))
(create (it) phone# (findElseAdd phone# instance '737-5588'))
// Create a person/staffMember/coordinator named Colby.
(create person instance (new))
(create staffMember instance (it))
(create coordinator instance (it))
(create (it) name (findElseAdd name instance 'colby'))
(create (it) email (findElseAdd email instance ······@msn.com'))
// Create a person/staffMember/bailiff named Brandy.
(create person instance (new))
(create staffMember instance (it))
(create bailiff instance (it))
(create (it) name (findElseAdd name instance 'brandy'))
(create (it) phone# (findElseAdd phone# instance '919-9945'))
// Create a person/staffMember/courtReporter named Courtney.
(create person instance (new))
(create staffMember instance (it))
(create courtReporter instance (it))
(create (it) name (findElseAdd name instance 'courtney'))
(create (it) phone# (findElseAdd phone# instance '203-9898'))
(create (it) email (findElseAdd email instance ····@gov.org'))
// Create judge judy's staffMembers.
(create judy staffMember clark)
(create judy staffMember ashley)
(create judy staffMember colby)
(create judy staffMember brandy)
(create judy staffMember courtney)
// Create Clark's assistant Ashley
(create clark assistant ashley)
// Create a building instance named CourtHouse1.
(create building instance (new))
(create (it) name (findElseAdd name instance 'courtHouse1'))
// Create a floor instance named floor1
// and make it part of courtHouse1.
(create floor instance (new))
(create (it) name (findElseAdd name instance 'floor1'))
(create courtHouse1 has (it))
// Create room instances named room1
// and make it part of floor1.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room1'))
(create floor1 has (it))
// Create a floor instance named floor2.
// and make it part of courtHouse1.
(create floor instance (new))
(create (it) name (findElseAdd name instance 'floor2'))
(create courtHouse1 has (it))
// Create room instances named room1
// and make it part of floor2.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room1'))
(create floor2 has (it))
// Create room instances named room2
// and make it part of floor2.
(create room instance (new))
(create (it) name (findElseAdd name instance 'room2'))
(create floor2 has (it))
// Create CourtHouse1's has reporter Courtney.
(create courtHouse1 has courtney)
// Create CourtHouse1's floor1's has Ashley.
(create (relElem (select courtHouse1 has floor1))
has
ashley)
// Create CourtHouse1's floor1's room1 has Clark.
(create (relElem (select (relElem (select courtHouse1 has floor1))
has
room1))
has
clark)
// Create CourtHouse1's floor2's room2's has Judge Judy.
(create (relElem (select (relElem (select courtHouse1 has floor2))
has
room2))
has
judy)
// Find a staff member of a judge
// whose assistant has phone# 737-5588.
// Displays clerk Clark.
(msgbox (and (select (select judge instance *) staffMember *)
(select * assistant (select * phone# 737-5588))))
>> Partial Grid View of Person Instances:
>> ID name phone# email staffMember
>> -- --------- -------- ------------- -----------
>> # judy 333-5555 ····@aol.com clark
>> # clark 737-5588
>>
>> Partial Tree View of Person Instances:
>> -Person
>> |-instance-
>> |-Judy
>> | |-phone#-
>> | | |-333-5555
>> | | |-JDG-JUDY
>> | |
>> | |-email-
>> | | ······@aol.com
>> | | ······@law.com
>> | |
>> | |-staffMember-
>> | |-Clark+
>> | |-Ashley+
>> | |-Colby+
>> | |-Brandy+
>> | |-Courtney+
>> |
>> |-Clark
>> | |-phone#-
>> | | |-737-5588
>> | |
>> | |-assistant-
>> | |-Ashley+
>
> This is a typical structure of a "navigational" or "hierarchical" database. They are fine for particular specific uses, but over time people found they grew into messes and are hard to query for unforseen questiones. Dr. Codd was working with stuff like this when he felt there should be a better way.
Dr. Codd was right. The Relation Data Model is more general/flexible
than the Hierarchal Data Model. The advantage of a more
general/flexible method (RM) is that its scope it larger. The advantage
of a more specialized/limited method (HM) is that it is more efficient
within its smaller scope. (This might sound familiar as I have been
repeating this for several years now :)
However, to assume the underlying data model based on a particular view
is unreliable. In hierarchal model, it is impossible to represent a
thing with more than one parent without redundancy. If you were to
click around in exp db's tree view, with option to display each thing's
ID enabled, you would see that while a thing is a child in multiple
hierarchies, it still has the same ID. For example, most of the persons
in the example have multiple classifications, yet when one drills down
Person, StaffMember or Clerk instances, Clark has the same ID! The same
can be verified with this thread's original example where Adam is in
the parent/child and boss/employee hierarchy. If you change Clark's or
Adam's attributes or atribute values in one hierarchy, it shows up in
the other hierarchies as well, without the db engine having
synchronized data in multiple places. (Note that tree nodes in GUI may
need to be refreshed by closing/opening its parent tree node)
Neo wrote:
> >> Partial Grid View of Person Instances:
> >> ID name phone# email staffMember
> >> -- --------- -------- ------------- -----------
> >> # judy 333-5555 ····@aol.com clark
> >> # clark 737-5588
> >>
> >> Partial Tree View of Person Instances:
> >> -Person
> >> |-instance-
> >> |-Judy
> >> | |-phone#-
> >> | | |-333-5555
> >> | | |-JDG-JUDY
> >> | |
> >> | |-email-
> >> | | ······@aol.com
> >> | | ······@law.com
> >> | |
> >> | |-staffMember-
> >> | |-Clark+
> >> | |-Ashley+
> >> | |-Colby+
> >> | |-Brandy+
> >> | |-Courtney+
> >> |
> >> |-Clark
> >> | |-phone#-
> >> | | |-737-5588
> >> | |
> >> | |-assistant-
> >> | |-Ashley+
> >
> > This is a typical structure of a "navigational" or "hierarchical" database. They are fine for particular specific uses, but over time people found they grew into messes and are hard to query for unforseen questiones. Dr. Codd was working with stuff like this when he felt there should be a better way.
>
> Dr. Codd was right. The Relation Data Model is more general/flexible
> than the Hierarchal Data Model.
"Navigational" is a superset of hierarchical. Generally there is the
Network model and Hierarchical model. Yours is a kind of hybrid, but so
were most (originally) hierarchical DB's in the 60's and 70's. IBM's
hierarchical IMS had cross-links, and some file systems also have cross
links, for example. Charles Bachman's databases were more
network-based.
-T-
> The advantage of a more
> general/flexible method (RM) is that its scope it larger. The advantage
> of a more specialized/limited method (HM) is that it is more efficient
> within its smaller scope. (This might sound familiar as I have been
> repeating this for several years now :)
>
> However, to assume the underlying data model based on a particular view
> is unreliable. In hierarchal model, it is impossible to represent a
> thing with more than one parent without redundancy. If you were to
> click around in exp db's tree view, with option to display each thing's
> ID enabled, you would see that while a thing is a child in multiple
> hierarchies, it still has the same ID. For example, most of the persons
> in the example have multiple classifications, yet when one drills down
> Person, StaffMember or Clerk instances, Clark has the same ID! The same
> can be verified with this thread's original example where Adam is in
> the parent/child and boss/employee hierarchy. If you change Clark's or
> Adam's attributes or atribute values in one hierarchy, it shows up in
> the other hierarchies as well, without the db engine having
> synchronized data in multiple places. (Note that tree nodes in GUI may
> need to be refreshed by closing/opening its parent tree node)
Neo wrote:
> >> Partial Grid View of Person Instances:
> >> ID name phone# email staffMember
> >> -- --------- -------- ------------- -----------
> >> # judy 333-5555 ····@aol.com clark
> >> # clark 737-5588
> >>
> >> Partial Tree View of Person Instances:
> >> -Person
> >> |-instance-
> >> |-Judy
> >> | |-phone#-
> >> | | |-333-5555
> >> | | |-JDG-JUDY
> >> | |
> >> | |-email-
> >> | | ······@aol.com
> >> | | ······@law.com
> >> | |
> >> | |-staffMember-
> >> | |-Clark+
> >> | |-Ashley+
> >> | |-Colby+
> >> | |-Brandy+
> >> | |-Courtney+
> >> |
> >> |-Clark
> >> | |-phone#-
> >> | | |-737-5588
> >> | |
> >> | |-assistant-
> >> | |-Ashley+
> >
> > This is a typical structure of a "navigational" or "hierarchical" database. They are fine for particular specific uses, but over time people found they grew into messes and are hard to query for unforseen questiones. Dr. Codd was working with stuff like this when he felt there should be a better way.
>
> Dr. Codd was right. The Relation Data Model is more general/flexible
> than the Hierarchal Data Model.
"Navigational" is a superset of hierarchical. Generally there is the
Network model and Hierarchical model. Yours is a kind of hybrid, but so
were most (originally) hierarchical DB's in the 60's and 70's. IBM's
hierarchical IMS had cross-links, and some file systems also have cross
links, for example. Charles Bachman's databases were more
network-based.
(It should be pointed out that the DB's back then were not as dynamic
as the newer incarnations, such as DOM.)
-T-
> The advantage of a more
> general/flexible method (RM) is that its scope it larger. The advantage
> of a more specialized/limited method (HM) is that it is more efficient
> within its smaller scope. (This might sound familiar as I have been
> repeating this for several years now :)
>
> However, to assume the underlying data model based on a particular view
> is unreliable. In hierarchal model, it is impossible to represent a
> thing with more than one parent without redundancy. If you were to
> click around in exp db's tree view, with option to display each thing's
> ID enabled, you would see that while a thing is a child in multiple
> hierarchies, it still has the same ID. For example, most of the persons
> in the example have multiple classifications, yet when one drills down
> Person, StaffMember or Clerk instances, Clark has the same ID! The same
> can be verified with this thread's original example where Adam is in
> the parent/child and boss/employee hierarchy. If you change Clark's or
> Adam's attributes or atribute values in one hierarchy, it shows up in
> the other hierarchies as well, without the db engine having
> synchronized data in multiple places. (Note that tree nodes in GUI may
> need to be refreshed by closing/opening its parent tree node)
> > > This is a typical structure of a "navigational" or "hierarchical" database. They are fine for particular specific uses, but over time people found they grew into messes and are hard to query for unforseen questiones. Dr. Codd was working with stuff like this when he felt there should be a better way.
.
> > Dr. Codd was right. The Relational Data Model is more general/flexible than the Hierarchal Data Model.
.
> "Navigational" is a superset of hierarchical.
It appears you are stating the above as a negative. Before I can
counter it, I need to determine if the exp db is guilty of. Please
precisely define what is "navigational" (with respect to representing
things in a non-redundant manner in computers) and what is its
disadvantage/limitation which the exp db should exhibit?
> Generally there is the Network model and Hierarchical model. Yours is a kind of hybrid,
Again, this is incorrect. It is not a hybrid (it's not the elephant's
trunk + ears + tail, its the entire elephant). The exp's data model is
more general than all the data representation
methodogies/implementations including Hierarchal, Network, Relational,
etc that can be used to create a db (ie runs on computers where the
data is non-redundant, thus allowing for efficient data mgmt). This
allows the exp db to accomplish what each of the less general
methodologies/implementation can however not as efficiently within
their practical scope. It can also do that which is outside the total
combined scope of Hierarchal, Network and Relational Data Models.
The Hierarchal Data Model's significant limitation is, its inability to
model things in multiple hierarchies without redundancy, which I have
stated is not case in the exp db, since it can represent a thing in
multiple hierarchies without reduncancy and have offered several ways
to verify this including viewing a thing's ID in various hierarchies,
etc.
Some limitations of the Relational Model are it forces constriants that
are not always desirable for some apps (ie AI-ish). Believe it or not
but requiring a schema and relation header prior to entering data are
hardware-driven, data model-driven, user, app, etc constriants. Notice
with exp db, not having these constraints does not prevent it from
normalizing data (at run-time!) and from performing high level queries
similar to SELECT statements found in SQL. In the exp db, constriants
such as schemas and relation headers, if desired, can be stored in db
like any other data, and can be enforced by the app (dbms will probably
implement some basic/common constraints later).
Now the Network Data Model is a hybrid. Hybrid models ultimately suffer
from complexity of implementation, usage, etc. Personally, the Network
Data Model is a misnamed. It is more accurately named
Hierarchal/Relational Hybrid Data Model.
One can hypothesize until end of eternity, but I prefer to
prove/disprove things with actual implemetations. If one asserts that
the exp db is a hybrid, please also try to specify a method that would
verify such an assertion. I don't believe one is in a good position, to
even make such assertions, until first demonstrating how to just model
data (ie judge example) that can stored in the exp db with current
methodogies which they feel are more general/flexible. Or have you
already conceded this for RM? If the original data is too complex for
RM to model practically, we can simplified it and continue with other
considerations.
> but so were most (originally) hierarchical DB's in the 60's and 70's. IBM's hierarchical IMS had cross-links, and some file systems also have cross links, for example. Charles Bachman's databases were more network-based. (It should be pointed out that the DB's back then were not as dynamic as the newer incarnations, such as DOM.
If you believe DOM is more general/flexible than exp db, would you be
able to verify this by actually representing/querying things (ie judge
example).
(Sorry for the semi-duplicate post; it was unintentional)
Neo wrote:
> > > > This is a typical structure of a "navigational" or "hierarchical" database. They are fine for particular specific uses, but over time people found they grew into messes and are hard to query for unforseen questiones. Dr. Codd was working with stuff like this when he felt there should be a better way.
> .
> > > Dr. Codd was right. The Relational Data Model is more general/flexible than the Hierarchal Data Model.
> .
> > "Navigational" is a superset of hierarchical.
>
> It appears you are stating the above as a negative. Before I can
> counter it, I need to determine if the exp db is guilty of. Please
> precisely define what is "navigational" (with respect to representing
> things in a non-redundant manner in computers) and what is its
> disadvantage/limitation which the exp db should exhibit?
>
> > Generally there is the Network model and Hierarchical model. Yours is a kind of hybrid,
>
> Again, this is incorrect. It is not a hybrid (it's not the elephant's
> trunk + ears + tail, its the entire elephant). The exp's data model is
> more general than all the data representation
> methodogies/implementations including Hierarchal, Network, Relational,
> etc that can be used to create a db (ie runs on computers where the
> data is non-redundant, thus allowing for efficient data mgmt).
How does one objectively measure "general"? They are all potentially
representionally equivalent.
> This
> allows the exp db to accomplish what each of the less general
> methodologies/implementation can however not as efficiently within
> their practical scope. It can also do that which is outside the total
> combined scope of Hierarchal, Network and Relational Data Models.
Example?
>
> The Hierarchal Data Model's significant limitation is, its inability to
> model things in multiple hierarchies without redundancy, which I have
> stated is not case in the exp db, since it can represent a thing in
> multiple hierarchies without reduncancy and have offered several ways
> to verify this including viewing a thing's ID in various hierarchies,
> etc.
>
> Some limitations of the Relational Model are it forces constriants that
> are not always desirable for some apps (ie AI-ish). Believe it or not
> but requiring a schema and relation header prior to entering data are
> hardware-driven, data model-driven, user, app, etc constriants.
Please clarify. Dynamic relational is possible, as already pointed out.
> Notice
> with exp db, not having these constraints does not prevent it from
> normalizing data (at run-time!) and from performing high level queries
> similar to SELECT statements found in SQL. In the exp db, constriants
> such as schemas and relation headers, if desired, can be stored in db
> like any other data, and can be enforced by the app (dbms will probably
> implement some basic/common constraints later).
>
> Now the Network Data Model is a hybrid. Hybrid models ultimately suffer
> from complexity of implementation, usage, etc. Personally, the Network
> Data Model is a misnamed. It is more accurately named
> Hierarchal/Relational Hybrid Data Model.
I would characterize it as a graph of nodes (records or maps), although
in practice it does tend to have a mix of trees and tables tendencies,
perhaps because people relate to tables and trees better than random
graphs.
>
> One can hypothesize until end of eternity, but I prefer to
> prove/disprove things with actual implemetations. If one asserts that
> the exp db is a hybrid, please also try to specify a method that would
> verify such an assertion. I don't believe one is in a good position, to
> even make such assertions, until first demonstrating how to just model
> data (ie judge example) that can stored in the exp db with current
> methodogies which they feel are more general/flexible. Or have you
> already conceded this for RM? If the original data is too complex for
> RM to model practically, we can simplified it and continue with other
> considerations.
>
> > but so were most (originally) hierarchical DB's in the 60's and 70's. IBM's hierarchical IMS had cross-links, and some file systems also have cross links, for example. Charles Bachman's databases were more network-based. (It should be pointed out that the DB's back then were not as dynamic as the newer incarnations, such as DOM.
>
> If you believe DOM is more general/flexible than exp db, would you be
> able to verify this by actually representing/querying things (ie judge
> example).
Unfortunately, there are not objective metrics, except perhaps
redundancy measurements. I could concede that it is purely a personal
choice. I like tables because they offer a consistency of design that
the other approaches don't. Tables are easy to visualize and
relational math is based on set theory.
Similar debates came up when Go To was challenged. The only things I
can come up with to describe the superiority of nested blocks is visual
cues (indentation) and more developer-to-developer consistency. Perhaps
if somebody documented "go-to patterns", they could have better defened
them. As it stands, visual-ness and consistency are the same reasons I
prefer relational over the other attribute-structuring techniques.
By the way, what would a query language look like for your suggestion?
Lisp?
-T-
> > Neo: Judges, Bailiffs, etc in Court Building Example
>
> TopMind: http://www.c2.com/cgi/wiki?CourtRoomSchemaExample
I will make some general comments based on the assumption that the RMDB
solution will be similar to exp db solution (except in terms of
constraints, which rmdb can handle much better). Currently the simpler
RM schema consists of approximately the following tables (I have
modified some names slightly to make the comparison easier, if this is
disruptive, let me know).
T_Person (personID, role, name, phone#, email)
T_Building (bldgID, name)
T_Location (locID, name)
T_Person_Loc_Map (personID, locID)
While the exp db doesn't have "tables" (unless modelled), it is similar
to having the following tables:
T_Building, T_Floor, T_Room,
T_Person, T_Judge, T_StaffMember, T_Clerk,
T_Assistant, T_Coordinator, T_Bailiff, T_CourtReporter
T_Phone, T_EMail,
T_Name
And the equivalent of following hierarchy tables:
T_HasHierarchy - This allows buildings to have floors to have room and
any of those things to have a person and so on (basically anything can
have/contain/bePartOf something else as in a BOM).
T_StaffMemberHierarchy - This allows a judge to have staff members and
any of them to have their own staff members and so on. Note: there is
an error in my example, "Clark -assistant- Ashley" should have been
"Clark -staffMember- Ashley".
Also, since the exp db's solution allows each thing to have 0-to-many
"attributes", and each attribute to have 0-to-many "values" to avoid
NULLs, to do the same in RM one would need the following tables just
for persons' emails' addresses.
T_Person_Email_Map
T_Email_Address_Map
or some how all of them could be generalized to:
T_Thing, T_Attrib, T_Value
T_Thing_Attrib_Map
T_Attrib_Value_Map
> Website: The [rmdb] schema does not enforce six ...
Since the exp db doesn't enforce any app-specific constraints, the rmdb
solution shouldn't either, to keep the comparison simple.
> Website: Some might propose a different table per employee or person "type", such as a Judge table, Bailiff table, etc. I never liked such approaches. For one, people can and do change roles and it is easier to flip a role flag than delete and re-add. Plus, "types" often results in having to use verbose UNION queries to do the same thing to the different employee types, which is ugly, inefficient, and repetitive.
> It is also possible in practice for a person to have multiple roles, such as after budget cuts. Further, a given person may be say a Clerk in one room and an Assistant in another. For simplicity sake, I am ignoring that possibility in [above] schemas; but to implement it, [move the [field] Role from the T_Person to new additional tables T_Group and T_Loc_Group_Map(personID, groupID)]
First, think in general where any combination of the following is
possible:
1) a thing can have 0-to-many types.
2) a thing can have 0-to-many roles with not only different things, but
to the same thing.
Because the exp db treats types and roles in a similar manner, there is
only one case to handle:
1) a thing can have 0-to-many relationships with not only different
things, but to the same thing.
Thus the exp db handles "types", "roles" and other relationships in
exactly the same manner, where as in RM, typing, roles and their
cardinality affect implementation, and if changed, propogate a wave of
changes thru the schema, data, queries, code, etc.
When one starts dealing with specific types of things (ie persons),
some combination of typing/roles/cardinalities are more likely than
others and some not possible or we haven't experienced it yet. These
are app-specific constraints which the exp db engine doesn't implement.
Consider following examples:
1) Judy is a person.
2) Judy is a person, judge and dentist.
3) Clark's clerk Judge Judy (just on Clark's birthday).
4) Harris County judge is Judy.
5) Judy is a retired judge.
6) Judge Judy clerk Judge Judy (Judge was her own clerk when Clark was
absent).
7) CourtHouse1 receptionist Judge Judy (Judy will fill any role!)
My selection of types and roles of various persons (app-specific
constraints) were probably incorrect; however, its primary goal was to
demo flexibility. Limiting all person to one classification and one
role wouldn't demo it. I am not sure how you want to handle this as you
realize this would require more tables and joins.
> Website: In such designs, one is often faced with the tradeoff of short-term versus long-term. Satisfying immediate needs may make development simpler up front, but in the longer run somebody 12 years down the road will cuss their heads off at you if you take the short road and stick them with the kludgy patchwork needed to make static slots or category-specific tables into a more flexible system.
> (The originator of the problem has since confirmed that the complexity has increased and the more flexible approaches, such as many-to-many tables, proved useful.)
Along those lines, it was the process of repeatedly having to update
schema, data, queries, code and GUI to handle new application
requirements that made me wonder if there existed a schema so general
that it would handle anything.
Currently the gap between the initial rmdb schema and that required is
enough to prevent a meaningul comparison. And there is still more which
I haven't expressed and isn't evident. How do you want to proceed?
"Neo" <········@hotmail.com> wrote in message
·····························@e56g2000cwe.googlegroups.com...
>> > Neo: Judges, Bailiffs, etc in Court Building Example
>>
>> TopMind: http://www.c2.com/cgi/wiki?CourtRoomSchemaExample
>
> I will make some general comments based on the assumption that the RMDB
> solution will be similar to exp db solution (except in terms of
> constraints, which rmdb can handle much better). Currently the simpler
> RM schema consists of approximately the following tables (I have
> modified some names slightly to make the comparison easier, if this is
> disruptive, let me know).
>
> T_Person (personID, role, name, phone#, email)
> T_Building (bldgID, name)
> T_Location (locID, name)
> T_Person_Loc_Map (personID, locID)
>
> While the exp db doesn't have "tables" (unless modelled), it is similar
> to having the following tables:
> T_Building, T_Floor, T_Room,
> T_Person, T_Judge, T_StaffMember, T_Clerk,
> T_Assistant, T_Coordinator, T_Bailiff, T_CourtReporter
> T_Phone, T_EMail,
> T_Name
>
<clip>
yep. I was right. You've reinvented Prolog. Not that it needed
reinventing. Don't feel bad. In 1983, I decided, while in college, to
invent a language and write a compiler for it. I wrote the compiler in
Pascal. Just after I finished the compiler, one of my class mates asked me
why I didn't write my compiler in C. My response: I didn't know C. He
said, and I'm not kidding, "of course you do... this is a C compiler."
The language I invented was, essentially, C. I was about 15 years(?) too
late, of course. Kernigan and Richie had beat me to it long before. But
there you have it... great minds and all that.
So, in your quest for a flexible logic management schema, you've reinvented
Prolog.
Congratulations.
--
--- 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.
--
> In 1983, I decided, while in college, to invent a language and write a compiler for it. I wrote the compiler in Pascal. Just after I finished the compiler, one of my class mates asked me why I didn't write my compiler in C. My response: I didn't know C. He said, and I'm not kidding, "of course you do... this is a C compiler." The language I invented was, essentially, C. I was about 15 years(?) too late, of course. Kernigan and Richie had beat me to it long before. But there you have it... great minds and all that.
LOL (and may be I shouldn't be, without looking a bit harder in the
mirror).
> Yep. I was right. You've reinvented Prolog. Not that it needed reinventing. Don't feel bad. So, in your quest for a flexible logic management schema, you've reinvented Prolog. Congratulations.
I guess I'll have to add another feather to my cap :)
Think of me as having committed a crime, but each witness accuses me of
a different crime. So far, I have been accused of re-inventing:
1) Hierarchal data model
2) Network data model
3) Mult-Variable data model
4) XML
5) Prolog
6) LISP
7) And one very screwed-up word proccesor!
Usually no one accuses me of re-inventing the Relational Model as that
is the current golden standard, therefore I must be guilty of a lesser
crime.
There is one minor difference from your story; while you were unaware
of the existence of C when re-inventing it, I was well aware of RM
before starting. Thus my folly will be a magnitude funnier :) or :(
TopMind, while I wait for an updated RM schema, I am responding to
earlier comments.
>>>> Neo: ... [exp] data model allows the equivalent of an adjustable wrench which adapts to the nut encountered in the field.
.
>>> TopMind: This battle was already faught between Charles Bachman and Dr. Codd in the 70's when navigational fought with relational. Bachman wanted ad-hoc "pointers" to build databases, while Codd felt that tables added more discipline to databases.
.
>> Neo: All I can say is that, I want you to evaluate based on actual results. When using the high-level interface, the user doesn't deal with IDs or pointers. You won't see either in the scripts also.
.
> TopMind: It is admittedly difficult to articulate why navigational structures are difficult to use. Let me try to put it this way: Knowing the "quantity of relationships" between the "nouns", most designers will come up with pretty much the same relational schema if they go to 3rd-normal-form. The differences will usually be minor between designers. The same is not true of navigational structures and thus there is no consistency. There are too many ways to do the same thing. They "work", but it takes a while to get your head around them because each has a different flavor and feel, often depending on the needs of a given app, whereas relational schemas (ideally) reflect information normalization, not usage patterns. Navigational structures are the "Goto's" of attribute structures: they "work", but are difficult to follow and inconsistent.
I think my response "All I can say ...", led you to believe that I
agreed with Bachman/pointers over Codd/relational; when I really meant
I don't have much knowledge or opinion on that topic. Now most people,
when they hear that one of the exp db's interface is a tree view, they
automatically think it is based on the hierarchal data model and
therefore uses pointers. The exp db is not based on the hierarchal data
model. It is based on a data model so general/flexible that it can do
what the hierarchal model does (only not as efficiently within HM's
smaller scope). Also I haven't discussed how the exp data model is
implemented (and don't want to currently). Personally, the more one can
abstract hardware dependencies, the better.
>>>>> Neo: Below I show how the experimental db can create the equivalent of tables, columns, and values of various
types dynamically at run-time. The same script can be created/executed
by C at run-time...
.
>>>> TopMind: Relational does not *have to* be static: www.geocities.com/tablizer/dynrelat.htm
.
>>> Neo: blog's author is voicing his gripe against the static nature of RMDBs and wishes they were more dynamic ... what he doesn't realize is that those wishes are mostly impractical to implement...
.
>>> TopMind: As far as dynamic schemas, you have yet to back your claim that they are inharently inefficient.
.
>> Neo: I think it may be better for people who think dynamic schemas are practical in RM to implement it, than it is for me to explain further why it is impractical.
.
> TopMind: I would suggest giving a scenario that would allegedly be slower than yours.
It isn't a matter of speed as much as first figuring out how to make
RMDBs dynamic at run-time. Currently, if an application is presented
with certain new types of data at run-time, it is impractical to make
the the app or rmdb smart enough to design the new appropriate schema,
change existing schema with data, shift relevant data from existing
tables to new tables and update related queries and code. With the exp
db, the app simply stores the new type of data with less or no impact
on existing queries and code!
topmind wrote:
> Neo wrote:
> But the benefit is freedom from pure chaos. Nothng makes all changes
> easier. Relational just makes the net cost of change easier in the
> longer run. A shanty town may have fewer "change spikes" because it
> changes incrementally.
That would make more sense if shanty towns were not so easily destroyed
by a strong wind.
JOG wrote:
> topmind wrote:
>
>>Nulls are a vendor-specific idea, not inherent to relational.
>
> While I agree with much of your post, nulls now appear to me to be
> essential to the relational model (whatever their rights and wrongs).
> If one fully normalizes a database then it is likely a join will
> require the use of null to pad the resulting virtual relation. Just
> because these relations are not persisted on disk, makes them no less
> 'relations' in the sense of Codd's algebra. As such i am currently
> struggling with how one can be against nulls (as per Date's perfectly
> justified view) but pro-RM from a completely theoretical standpoint.
With all due respect, is it possible you confound NULL with missing
information?
Obviously, missing information is a difficult problem no matter what
data model one uses. We currently have no theory regarding missing
information which means we have no theory to overcome the practical
problem in any data model.
In fact, missing information is rather anathema to science. Take
interpolation for example: We either use sampling theory and error
analysis to decide whether it is valid to interpolate, or we interpolate
predictively as a method to falsify an hypothesis. Neither use accepts
truly missing information as fact. Ditto for extrapolation.
In my opinion, Date and Darwen and others have demonstrated serious
problems with NULL, 3-VL, 4-VL and "n-VL as n approaches infinity" even
when applied consistently. The inconsistent mess of SQL just makes a bad
situation worse.
Regardless whether one prefers NULL or systematized default values or no
implicit 'support for missing information', which is what I prefer,
one's choice will not really satisfy entirely.
I prefer 'no implicit support' in commercial systems on the Principle of
Cautious Design. Give me adequate domain support (ie. type support) and
I will model whatever is appropriate given the requirements. Accepting
my choice, I must also accept that the modelling through the type system
is work that must still get done when necessary.
I certainly commend Dr. Codd for attempting to tackle the problem, but I
consider NULL the 'clay knapsack' of his work. Unlike the religious
'clay feet' from the Book of David, one can set NULL aside and the
remainder of Codd's mathematics still stands on its own.
Bob Badour wrote:
> JOG wrote:
> > topmind wrote:
> >
> >>Nulls are a vendor-specific idea, not inherent to relational.
> >
> > While I agree with much of your post, nulls now appear to me to be
> > essential to the relational model (whatever their rights and wrongs).
> > If one fully normalizes a database then it is likely a join will
> > require the use of null to pad the resulting virtual relation. Just
> > because these relations are not persisted on disk, makes them no less
> > 'relations' in the sense of Codd's algebra. As such i am currently
> > struggling with how one can be against nulls (as per Date's perfectly
> > justified view) but pro-RM from a completely theoretical standpoint.
>
> With all due respect, is it possible you confound NULL with missing
> information?
An excellent point. The fact that SQL NULLs sometimes behave
like "an unknown value" and sometimes not makes the situation
all the worse.
> Obviously, missing information is a difficult problem no matter what
> data model one uses. We currently have no theory regarding missing
> information which means we have no theory to overcome the practical
> problem in any data model.
Well, I would propose that we understand cardinality-0 relations
pretty well, and I think that provides a lot of value as far as
a theoretical basis goes. (This doesn't help us when using SQL,
though.)
> In my opinion, Date and Darwen and others have demonstrated serious
> problems with NULL, 3-VL, 4-VL and "n-VL as n approaches infinity" even
> when applied consistently. The inconsistent mess of SQL just makes a bad
> situation worse.
Agreed.
> I certainly commend Dr. Codd for attempting to tackle the problem, but I
> consider NULL the 'clay knapsack' of his work. Unlike the religious
> 'clay feet' from the Book of David, one can set NULL aside and the
> remainder of Codd's mathematics still stands on its own.
Agreed.
Marshall
Marshall Spight wrote:
> Bob Badour wrote:
>
>>JOG wrote:
>>
>>>topmind wrote:
>>>
>
>>Obviously, missing information is a difficult problem no matter what
>>data model one uses. We currently have no theory regarding missing
>>information which means we have no theory to overcome the practical
>>problem in any data model.
>
> Well, I would propose that we understand cardinality-0 relations
> pretty well, and I think that provides a lot of value as far as
> a theoretical basis goes. (This doesn't help us when using SQL,
> though.)
I think you overstate the value of empty sets. The closed world
assumption limits the usefulness of empty sets with respect to missing
information.
The most common situation where people demand NULL is the situation
where we know a true statement exists for some value of an attribute,
but we do not know for which value.
One proposed solution for modelling such a situation is to replace the
simple valued attribute that is possibly unknown with a relation valued
attribute having an empty candidate key. Then, when the value is known,
the relation valued attribute will have a single tuple with the known
value, and when the value is unknown, the relation valued attribute will
have zero tuples.
But if we accept the closed world assumption, the cardinality-0 relation
says we know that no instances of the predicate are true. This, of
course, contradicts the initial condition where we know some value
satisfies the predicate, but we do not know which value.
And if we use this trick to model the missing information, how do we
distinguish it from the situation where we genuinely know that no value
satisfies the predicate?
I really see no way around knowing all of the requirements and
reluctantly choosing the least among evils for each individual
situation. I admit this is ad hoc and risky, but I find it less risky
and no more ad hoc than the known alternatives.
Bob Badour wrote:
> Marshall Spight wrote:
> >>Obviously, missing information is a difficult problem no matter what
> >>data model one uses. We currently have no theory regarding missing
> >>information which means we have no theory to overcome the practical
> >>problem in any data model.
> >
> > Well, I would propose that we understand cardinality-0 relations
> > pretty well, and I think that provides a lot of value as far as
> > a theoretical basis goes. (This doesn't help us when using SQL,
> > though.)
>
> I think you overstate the value of empty sets. The closed world
> assumption limits the usefulness of empty sets with respect to missing
> information.
>
> The most common situation where people demand NULL is the situation
> where we know a true statement exists for some value of an attribute,
> but we do not know for which value.
>
> One proposed solution for modelling such a situation is to replace the
> simple valued attribute that is possibly unknown with a relation valued
> attribute having an empty candidate key. Then, when the value is known,
> the relation valued attribute will have a single tuple with the known
> value, and when the value is unknown, the relation valued attribute will
> have zero tuples.
Yes; this is a fine technique. In fact, to me this technique is one of
the prime motivations for RVAs.
> But if we accept the closed world assumption, the cardinality-0 relation
> says we know that no instances of the predicate are true. This, of
> course, contradicts the initial condition where we know some value
> satisfies the predicate, but we do not know which value.
>
> And if we use this trick to model the missing information, how do we
> distinguish it from the situation where we genuinely know that no value
> satisfies the predicate?
If we have a requirement to distinguish between
exists-but-we-don't-know
and doesn't-exist, then the cardinality-0 model is insufficient. But
there
are also cases where we won't need to so distinguish, and cases
where doesn't-exist is not a possibility. In those cases, I would
propose that cardinality-0 is often a better choice than SQL's NULL.
I don't think it's a complete solution, though. I think some kind of
sum type, as in SML, is also quite desirable. This lets the
modeller create special values according to the requirements
of the domain.
> I really see no way around knowing all of the requirements and
> reluctantly choosing the least among evils for each individual
> situation. I admit this is ad hoc and risky, but I find it less risky
> and no more ad hoc than the known alternatives.
I agree.
To clarify, I am certainly *not* proposing that there is any
shortcut for doing the hard work of building a good model
for the domain in question.
Marshall
Marshall Spight wrote:
> Bob Badour wrote:
>
>>Marshall Spight wrote:
>>
>>But if we accept the closed world assumption, the cardinality-0 relation
>>says we know that no instances of the predicate are true. This, of
>>course, contradicts the initial condition where we know some value
>>satisfies the predicate, but we do not know which value.
>>
>>And if we use this trick to model the missing information, how do we
>>distinguish it from the situation where we genuinely know that no value
>>satisfies the predicate?
>
>
> If we have a requirement to distinguish between
> exists-but-we-don't-know
> and doesn't-exist, then the cardinality-0 model is insufficient. But
> there
> are also cases where we won't need to so distinguish, and cases
> where doesn't-exist is not a possibility. In those cases, I would
> propose that cardinality-0 is often a better choice than SQL's NULL.
Yes, well, you are not putting the bar very high. Now, are you? Besting
SQL's NULL for handling missing information is rather like tripping over
a shoelace.
The closed world assumption is going to bite you more often than you
seem to suppose. Presumably, if you have a relation valued attribute,
you intend to use the relational algebra or calculus on it. However, the
closed world assumption is central to both which means they will yield
incorrect results in many cases unless the user takes extraordinary
measures to account for the not-quite-closed nature of the model's world.
One must consider those consequences when considering relation valued
attributes as a means to describe missing information.
Considering that the method basically uses the relation type generator
to inject a new type for the attribute, I can imagine other type
generators that would provide a more appropriate set of operations for
the resulting type.
> I don't think it's a complete solution, though. I think some kind of
> sum type, as in SML, is also quite desirable. This lets the
> modeller create special values according to the requirements
> of the domain.
I could not find a comprehensive enough reference for SML online to
decypher what you are saying above. Is a sum type similar to a union
type of some sort?
I would certainly like the ability to model new type generators, and SML
looks like it has some nice features for doing that. (Based on the very
brief look I took at what documentation I could find.)
>>I really see no way around knowing all of the requirements and
>>reluctantly choosing the least among evils for each individual
>>situation. I admit this is ad hoc and risky, but I find it less risky
>>and no more ad hoc than the known alternatives.
>
>
> I agree.
>
> To clarify, I am certainly *not* proposing that there is any
> shortcut for doing the hard work of building a good model
> for the domain in question.
Okay. I apologize if your brief comments led me to believe you were more
enthused by relation valued attributes than warranted. Missing
information requires hard work and difficult tradeoffs.
Bob Badour wrote:
> Marshall Spight wrote:
>
> >
> > If we have a requirement to distinguish between
> > exists-but-we-don't-know
> > and doesn't-exist, then the cardinality-0 model is insufficient. But
> > there
> > are also cases where we won't need to so distinguish, and cases
> > where doesn't-exist is not a possibility. In those cases, I would
> > propose that cardinality-0 is often a better choice than SQL's NULL.
>
> Yes, well, you are not putting the bar very high. Now, are you? Besting
> SQL's NULL for handling missing information is rather like tripping over
> a shoelace.
>
> The closed world assumption is going to bite you more often than you
> seem to suppose. Presumably, if you have a relation valued attribute,
> you intend to use the relational algebra or calculus on it. However, the
> closed world assumption is central to both which means they will yield
> incorrect results in many cases unless the user takes extraordinary
> measures to account for the not-quite-closed nature of the model's world.
>
> One must consider those consequences when considering relation valued
> attributes as a means to describe missing information.
I do not disagree, but I'm not sure if I'm seeing all the consequences
you refer to. I agree that how the algebra behaves is important.
Lame example:
Given a Persons relation with an Age attribute. (I know it is better
to have a Birthdate attribute, but for this artifical example, this
will
suffice.) The Age attribute is an RVA of a single int attribute with
an empty key (that is, it is either an int or empty, indicating we
don't
know the age.) If we wanted to calculate the average age of
Persons, and we took sum(Age) / count(Age), (waving my hands
around the nest/unnest issue), then it would seem to me that
what you would most likely want to know is, of the people for whom
the age is known, what is the average, which is exactly what
I'd expect the RVA-Age schema to give you.
> Considering that the method basically uses the relation type generator
> to inject a new type for the attribute, I can imagine other type
> generators that would provide a more appropriate set of operations for
> the resulting type.
Yes. I propose that there ought to be a wider set of choices for
attribute types, including RVAs, the subcase of RVAs that you
described as having an empty key, which is sometimes called
"option types", and tagged unions or "sum types" which I mentioned.
I think that although these add complexity, they also add a lot
of value, and that this value will *improve* (but not *solve*) the
problem of dealing with missing information. As you say, simply
improving the current situtation is not necessarily setting the
bar all that high.
> > I don't think it's a complete solution, though. I think some kind of
> > sum type, as in SML, is also quite desirable. This lets the
> > modeller create special values according to the requirements
> > of the domain.
>
> I could not find a comprehensive enough reference for SML online to
> decypher what you are saying above. Is a sum type similar to a union
> type of some sort?
Yes; specifically a tagged union, unlike the untagged C union.
Here's a decent article:
http://en.wikipedia.org/wiki/Tagged_union
> Missing
> information requires hard work and difficult tradeoffs.
Agreed.
Marshall
Marshall Spight wrote:
> Bob Badour wrote:
>
>>Marshall Spight wrote:
>>
>>
>>>If we have a requirement to distinguish between
>>>exists-but-we-don't-know
>>>and doesn't-exist, then the cardinality-0 model is insufficient. But
>>>there
>>>are also cases where we won't need to so distinguish, and cases
>>>where doesn't-exist is not a possibility. In those cases, I would
>>>propose that cardinality-0 is often a better choice than SQL's NULL.
>>
>>Yes, well, you are not putting the bar very high. Now, are you? Besting
>>SQL's NULL for handling missing information is rather like tripping over
>>a shoelace.
>>
>>The closed world assumption is going to bite you more often than you
>>seem to suppose. Presumably, if you have a relation valued attribute,
>>you intend to use the relational algebra or calculus on it. However, the
>>closed world assumption is central to both which means they will yield
>>incorrect results in many cases unless the user takes extraordinary
>>measures to account for the not-quite-closed nature of the model's world.
>>
>>One must consider those consequences when considering relation valued
>>attributes as a means to describe missing information.
>
> I do not disagree, but I'm not sure if I'm seeing all the consequences
> you refer to. I agree that how the algebra behaves is important.
>
> Lame example:
> Given a Persons relation with an Age attribute. (I know it is better
> to have a Birthdate attribute, but for this artifical example, this
> will
> suffice.) The Age attribute is an RVA of a single int attribute with
> an empty key (that is, it is either an int or empty, indicating we
> don't
> know the age.) If we wanted to calculate the average age of
> Persons, and we took sum(Age) / count(Age), (waving my hands
> around the nest/unnest issue), then it would seem to me that
> what you would most likely want to know is, of the people for whom
> the age is known, what is the average, which is exactly what
> I'd expect the RVA-Age schema to give you.
Your example works exactly as NULL does, and I consider the result
incorrect. The average age of the entire cohort is unknown, and it is
misleading to pretend otherwise.
Consider the situation where one also has a (possibly unknown) Weight
attribute. If one queries for average Age, one gets a numeric answer. If
one queries for average Weight, one gets a numeric answer. If one
queries for average Age and average Weight, one gets two numeric answers
that may not equal the answers above.
This sort of thing has been a source of many errors I have been asked to
correct. Basically, it breaks the identity: SUM(A) + SUM(B) = SUM(A+B)
Some folks get really antsy when the numbers don't balance.
>>>I don't think it's a complete solution, though. I think some kind of
>>>sum type, as in SML, is also quite desirable. This lets the
>>>modeller create special values according to the requirements
>>>of the domain.
>>
>>I could not find a comprehensive enough reference for SML online to
>>decypher what you are saying above. Is a sum type similar to a union
>>type of some sort?
>
> Yes; specifically a tagged union, unlike the untagged C union.
> Here's a decent article:
>
> http://en.wikipedia.org/wiki/Tagged_union
Yes, I agree. That would be very useful.
> missing information is rather anathema to science ... Date and Darwen and others have demonstrated serious problems with NULL, 3-VL, 4-VL and "n-VL as n approaches infinity" even when applied consistently.
They are correct.
> ... missing information is a difficult problem no matter what data model one uses. We currently have no theory regarding missing information which means we have no theory to overcome the practical problem in any data model.
In the experimental data model (which I haven't described in any detail
and not inclined to do so currently), a NULL can not occur for missing
information. This can be verified with the actual experimental db
executable. If someone would like to verify this, please post the
situation under which you think it would and we can test it. (And if
one thinks this is because the data is stored willy-nilly, we can
verify it isn't by performing some queries).
Bob Badour wrote:
> JOG wrote:
>
> > topmind wrote:
> >
> >>Nulls are a vendor-specific idea, not inherent to relational.
> >
> > While I agree with much of your post, nulls now appear to me to be
> > essential to the relational model (whatever their rights and wrongs).
> > If one fully normalizes a database then it is likely a join will
> > require the use of null to pad the resulting virtual relation. Just
> > because these relations are not persisted on disk, makes them no less
> > 'relations' in the sense of Codd's algebra. As such i am currently
> > struggling with how one can be against nulls (as per Date's perfectly
> > justified view) but pro-RM from a completely theoretical standpoint.
>
> With all due respect, is it possible you confound NULL with missing
> information?
Quite possibly Bob, and if so I stand corrected. I was referring to
fill values generated via outer joins, which are of course not
synonomous with the black holes that are SQL NULLS. I presonally avoid
external joins as much as possible, but they seem prevalent enough that
(if I recall correctly) they figure in Date and Darwen's D.
>
> Obviously, missing information is a difficult problem no matter what
> data model one uses. We currently have no theory regarding missing
> information which means we have no theory to overcome the practical
> problem in any data model.
>
> In fact, missing information is rather anathema to science. Take
> interpolation for example: We either use sampling theory and error
> analysis to decide whether it is valid to interpolate, or we interpolate
> predictively as a method to falsify an hypothesis. Neither use accepts
> truly missing information as fact. Ditto for extrapolation.
>
Tell me about it. I'm of the view that if my data is missing and I
can't satisfy the required predicate, I shouldn't be entering it into
the damn extension at all. What can you do - I shut my eyes and type it
in. I'm not convinced its an intractable issue yet, but I certainly
have no solution. Inapplicable attributes I draw the line at - but you
wouldn't believe the general state of data management in scientific
fields that your forced to work with (in the name of diplomacy).
Finances are prioritized for new hardware rather than corresponding
informatics development that could double productivity. There was a
recent editorial in Nature about this very bottleneck, but to be
honest, I doubt much will change any time soon.
> In my opinion, Date and Darwen and others have demonstrated serious
> problems with NULL, 3-VL, 4-VL and "n-VL as n approaches infinity" even
> when applied consistently. The inconsistent mess of SQL just makes a bad
> situation worse.
Yes, Date and Darwens arguments are incontrovertible as far as I'm
concerned. I spoke at a degree-level database class recently and was
pleasantly suprised that they were actually marked down if columns were
not specifed NOT NULL, and encouraged to decompose if missing values
for an attribute was a likelihood.
>
> Regardless whether one prefers NULL or systematized default values or no
> implicit 'support for missing information', which is what I prefer,
> one's choice will not really satisfy entirely.
>
> I prefer 'no implicit support' in commercial systems on the Principle of
> Cautious Design. Give me adequate domain support (ie. type support) and
> I will model whatever is appropriate given the requirements. Accepting
> my choice, I must also accept that the modelling through the type system
> is work that must still get done when necessary.
>
> I certainly commend Dr. Codd for attempting to tackle the problem, but I
> consider NULL the 'clay knapsack' of his work. Unlike the religious
> 'clay feet' from the Book of David, one can set NULL aside and the
> remainder of Codd's mathematics still stands on its own.
This area always reminds me of Rumsfeld's quote on intelligence in the
middle east:
"Reports that say that something hasn't happened are always interesting
to me, because as we know, there are known knowns; there are things we
know we know. We also know there are known unknowns; that is to say we
know there are some things we do not know. But there are also unknown
unknowns -- the ones we don't know we don't know."
He should have cited Date.
JOG wrote:
> Bob Badour wrote:
>
>>JOG wrote:
>>
>>
>>>topmind wrote:
>>>
>>>
>>>>Nulls are a vendor-specific idea, not inherent to relational.
>>>
>>>While I agree with much of your post, nulls now appear to me to be
>>>essential to the relational model (whatever their rights and wrongs).
>>>If one fully normalizes a database then it is likely a join will
>>>require the use of null to pad the resulting virtual relation. Just
>>>because these relations are not persisted on disk, makes them no less
>>>'relations' in the sense of Codd's algebra. As such i am currently
>>>struggling with how one can be against nulls (as per Date's perfectly
>>>justified view) but pro-RM from a completely theoretical standpoint.
>>
>>With all due respect, is it possible you confound NULL with missing
>>information?
>
> Quite possibly Bob, and if so I stand corrected. I was referring to
> fill values generated via outer joins, which are of course not
> synonomous with the black holes that are SQL NULLS. I presonally avoid
> external joins as much as possible, but they seem prevalent enough that
> (if I recall correctly) they figure in Date and Darwen's D.
I suspect, where people currently use outer joins, they generally would
prefer a relation valued attribute in any case.