why hierarchy?
JOG
standpoint (nevermind the processing overhead of using an XML parser
within any even vaguely time critical application). Well I wanted to
highlight why I made the statement. Below are 4 examples of recent
quotes concerning XML databases from academia, nevermind the business
world:
"XML is capable of holding information that is far richer in structure
than the rows and columns of a relational database. If you don't feel
that rows-and-columns are constraining you then either you don't really
need XML at all, or you've become locked into a way of thinking that
because tables are the only thing you can store, tables must be what
users want."
- Michael Kay, xsl-list mailing list
"In the wild (that is, in documents, reports, and program data
structures as they are encountered in daily life), information takes
forms rather different from third normal form. XML arose from efforts
to represent documents in a device- and application-independent way,
and it reflects the complexity of documents and their stubborn refusal
to fit into tabular form."
- C. M. Sperberg-Mcqueen, ACM Queue 2005
"The popular schema languages are generally too simplistic to model the
increasingly complex and dynamic information structures. Because of
this mismatch, in some cases, even if schemas exist, the result is
unfortunately the same as in the previous cases: "rich structure" often
translates in practice to "no structure." For example, the commonly
used relational and object-oriented schema languages lack adequate
support for describing alternative structures (e.g., authors or editors
for books), and for conditional and correlated structures."
- Daniela Florescu, ACM Queue 2005
"In XML, data can have an elaborate and intricate structure that is
significantly richer and more complex than a table of rows and columns.
Calling this semi-structured is misleading, just as it would be to
describe DNA molecules as semi-structured because they are less simply
regular than those of table salt. XML seeks to make possible capturing
and expressing the structure of the data as we understand it, without
forcing it into a too-simple structure."
- C. M. Sperberg-Mcqueen, ACM Queue 2005
The last 3 are from a top notch publication, and I find this return of
focus to hierarchical models since 1995 extremely frustrating.
Bob Badour
These are not the first idiots who managed to get published by a
'respectable' publication. Heck, that idiot Won Kim was the ACM SIGMOD
Chair, which tells me that ACM is no less prone to chase dayflies than
any other organization.
Addressing the idiocy above, the complexity and richness of the data are
inherent to the data remaining with it no matter the representation.
Increasing the complexity of the representing structures only increases
complexity without adding any 'richness' at all. 'Richness' comes from
the available operations for manipulating data represented in those
structures, which are greatly reduced as the structural complexity
increases.
paul c
> I spoke in a recent thread of my distaste for XML from a theoretical
> standpoint (nevermind the processing overhead of using an XML parser
> within any even vaguely time critical application).
Yeah, here's something Chamberlin about an early presentation Codd gave:
"Codd had a bunch of ...fairly complicated queries," Chamberlin said.
"And since I'd been studying CODASYL (the language used to query
navigational databases), I could imagine how those queries would have
been represented in CODASYL by programs that were five pages long that
would navigate through this labyrinth of pointers and stuff. Codd would
sort of write them down as one-liners. ... (T)hey weren't complicated at
all. I said, 'Wow.' This was kind of a conversion experience for me. I
understood what the relational thing was about after that."
I believe even the CODASYL fans could see that tagging every value in a
positional way would result in highly-redundant 'structures' and they
were aware that network structure without defined operators is more or
less useless. An application that interests me is family trees. We
know everybody has a grandfather but sometimes the only other thing we
know is that the grandfather must have been born before the father.
Having recorded a partial tree, we might discover that two nominal
grandfathers were in fact the same person. I'd rather try to deal with
that change using RT. It makes me think that network schemes are
nothing more than representations of more fundamental relationships, the
latter being what RT deals with.
(I thought the other quotes were pretty sneaky like implying that DNA
can be unlocked by XML. The one about "increasingly complex ...
structures" was also funny - the complexity seems to have been
introduced by XML itself, not the problems it claims to handle - it was
news to me that RT can't handle a books database!)
p
Neo
>
> Addressing the idiocy above, the complexity and richness of the data are inherent to the data remaining with it no matter the representation. Increasing the complexity of the representing structures only increases complexity without adding any 'richness' at all. 'Richness' comes from the available operations for manipulating data represented in those structures, which are greatly reduced as the structural complexity increases.
Could someone demonstrate the advantages of XML or RM at representing
the simple example shown at www.dbfordummies.com/example/ex007.asp
This example represents John and Mary in two hierarchies (without
redundancy). In the first hierarchy, John and Mary are children of Adam
and Eve who are children of God. In the second hierarchy, John and Mary
are part of Mars and Venus respectively which are part of the Universe.
To verify which method's underlying data model is more general, one can
observe the impact on existing schema/data/query when meeting future
unknown data requirements (to be proposed by someone else). Would
someone be willing to engage in this trivial example?
paul c
It does seem trivial. One hiearchy is talking about ancestors of
persons, the other about origins of persons. The hierarchies record the
persons twice. Relations would record them once and record ancestors
once and record origins once. Many problems with hierarchies - here's
one: if a user is aware of only one hierarchy and discovers that there
is no such person as John and 'deletes' him, the other hierarchy is now
wrong, as is the DB.
p
Neo
> "Codd had a bunch of ...fairly complicated queries," Chamberlin said. "And since I'd been studying CODASYL (the language used to query navigational databases), I could imagine how those queries would have been represented in CODASYL by programs that were five pages long that would navigate through this labyrinth of pointers and stuff. Codd would sort of write them down as one-liners. ... (T)hey weren't complicated at all. I said, 'Wow.' This was kind of a conversion experience for me. I understood what the relational thing was about after that."
Could someone demonstrate this experience by replicating the Food
Judging Example at www.dbfordummies.com/example/ex039.asp with RM?
To verify which method's underlying data model is more general, one can
observe the impact on existing schema/data/query when meeting future
unknown data requirements (to be proposed by someone else). Would
someone be willing to engage in this example?
paul c
The question is patently impossible/ridiculous. Only a mystic can
predict the 'future unknown'. (Some of us will disagree and say that
even mystics are incapable of such predictions. Codd should have added a
fourteenth rule - "the first thirteen rules don't apply to mystical db's".)
p
Joe Kesselman
designed for maximum simplicity. By all means, if you want to manipulate
the data, you should load it from the XML into whatever representation
makes most sense -- which may be relational rather than hierarchical, or
may be some other approach entirely, depending on the needs of the
application. Don't confuse syntax, semantics, and implementation.
On the other hand, IBM's new XML support in DB2 demonstrates that a
direct representation of the XML infoset can indeed deliver good
performance, if you're careful about coding it.
(I'm pointing this back to comp.databases.theory, since arguments about
syntaxes other than XML really aren't relevant to comp.text.xml, and
since you *can* represent relational data in XML if you want to do so.)
Marshall
>
> Could someone demonstrate the advantages of XML or RM at representing
> the simple example shown at www.dbfordummies.com/example/ex007.asp
> This example represents John and Mary in two hierarchies (without
> redundancy). In the first hierarchy, John and Mary are children of Adam
> and Eve who are children of God. In the second hierarchy, John and Mary
> are part of Mars and Venus respectively which are part of the Universe.
No, I don't think anyone will. You've used up quite a good deal of
good will.
If you wish to proceed in your endevour, I would propose that it
is your job to do these comparisons. Learn SQL well enough to
write credible DDL, queries, and DML. Construct examples
drawn from the real world. If you have insufficient experience
to do so, find respected books and draw your examples from
them. (Although I have noticed the quality of your examples
improving over time, you still regularly lapse back into
meaningless ones like the above.)
Once you have done so, you can construct queries yourself,
in SQL and your language, and you can compare them.
> To verify which method's underlying data model is more general, one can
> observe the impact on existing schema/data/query when meeting future
> unknown data requirements (to be proposed by someone else).
You first have to have a definition of generality. As I understand
the term, the SQL data model is fully general, as is the RM.
If you care specifically about change management, you need
to come up with a framework for describing the different kinds
of changes. Then you can compare what the effect is of
each kind of change.
Since you seem to be proposing not using a schema at all,
you have to show what the downside of that is as well as the
upside. Think typos.
And as you construct these examples, you have to do as
good a job as possible with the SQL part. Everyone will
assume you're using your own designs well; if you don't
do a great job with the thing you are contrasting with,
everyone will assume you are just making a bogus
comparison.
Marshall
paul c
> Reminder: XML is intended as an interchange syntax, and therefore was
> designed for maximum simplicity. By all means, if you want to manipulate
> the data, you should load it from the XML into whatever representation
> makes most sense -- which may be relational rather than hierarchical, or
> may be some other approach entirely, depending on the needs of the
> application. Don't confuse syntax, semantics, and implementation.
>
> On the other hand, IBM's new XML support in DB2 demonstrates that a
> direct representation of the XML infoset can indeed deliver good
> performance, if you're careful about coding it.
I think that should read "IF you're careful about coding it". I
remember a Scientific American article by one or more of the XML
originators where he admitted its redundancy and fobbed that off by
suggesting compression techniques under the covers (ever wonder why
people with older PC's are slow to uptake OpenOffice?). Golf patriots
have a moral "play the ball where it lies". A data model moral might be
"record facts/tags once".
> (I'm pointing this back to comp.databases.theory, since arguments about
> syntaxes other than XML really aren't relevant to comp.text.xml, and
> since you *can* represent relational data in XML if you want to do so.)
Well, at least it is admitted that XML is a mere syntax.
p
Neo
>
> One hiearchy is talking about ancestors of persons, the other about origins of persons. The hierarchies record the persons twice.
I can't speak for other methodologies, but dbd doesn't record things
redundantly in the db, regardless of how many hierarchies they are in.
> Relations would record them once and record ancestors once and record origins once.
True, if the proper schema is used.
> Many problems with hierarchies - here's one: if a user is aware of only one hierarchy and discovers that there is no such person as John and 'deletes' him, the other hierarchy is now wrong, as is the DB.
I can't speak for other methodologies, but this problem does not occur
in dbd as things are only represented once, even if they are in
multiple hierarchies. Deleting John deletes him from both hierarchies
in db.
> > To verify which method's underlying data model is more general, one can observe the impact on existing schema/data/query when meeting future unknown data requirements (to be proposed by someone else). Would someone be willing to engage in this trivial example?
>
> It does seem trivial.
Could you post the script for the initial data/queries so that we can
observe the impact on them when meeting future unknown data
requirements (to be proposed by someone else)? The more general
methodology will be impacted the least. Below is dbd's script. Lines
starting with "(;" are comments.
(; Create a class directory item and name it age)
(new)
(create clsDir item (it))
(create (it) name (word+ 'age))
(; Create a main directory item and name it god)
(new)
(create dir item (it))
(create (it) name (word+ 'god))
(; Create a class directory item and name it person)
(new)
(create clsDir item (it))
(create (it) name (word+ 'person))
(; Create a person named adam)
(new)
(create person instance (it))
(create (it) name (word+ 'adam))
(; Create a person named eve)
(new)
(create person instance (it))
(create (it) name (word+ 'eve))
(; Create a person named john whose age is 35)
(new)
(create person instance (it))
(create (it) name (word+ 'john))
(create (it) age (val+ '35))
(; Create a person named mary whose age is 25)
(new)
(create person instance (it))
(create (it) name (word+ 'mary))
(create (it) age (val+ '25))
(; Create god's children hierarchy)
(; Note: verbs parent/child are system verbs)
(createWRR god child adam)
(createWRR god child eve)
(createWRR adam child john)
(createWRR adam child mary)
(createWRR eve child john)
(createWRR eve child mary)
(; Create a main directory item and name it universe)
(new)
(create dir item (it))
(create (it) name (word+ 'universe))
(; Create a class directory item and name it planet)
(new)
(create clsDir item (it))
(create (it) name (word+ 'planet))
(; Create planet mars)
(new)
(create planet instance (it))
(create (it) name (word+ 'mars))
(; Create planet venus)
(new)
(create planet instance (it))
(create (it) name (word+ 'venus))
(; Create universe's part hierarchy)
(; Note: verbs asm/part are system things)
(createWRR universe part mars)
(createWRR universe part venus)
(createWRR mars part john)
(createWRR venus part mary)
(; Find eve's children)
(; Finds john and mary)
(select eve child *)
(; Find john's parents)
(; Finds adam and eve)
(select john parent *)
(; Find adam's children that are part of mars)
(; Finds john)
(and (select adam child *)
(select mars part *))
(; Find eve's children that are part of a planet)
(; Finds john and mary)
(and (select eve child *)
(select (select planet instance *) part *))
(; Find god's grandchildren that are part of a planet)
(; Finds john and mary)
(; Note: they are found twice since each has two parents)
(and (select (select god child *) child *)
(select (select planet instance *) part *))
Tony D
version of Godwin's Law ?
[ horror snipped ]
Bob Badour
> Reminder: XML is intended as an interchange syntax, and therefore was
> designed for maximum simplicity.
If that was a design criterion, they failed miserably.
paul c
>>> example/ex007.asp
>> One hiearchy is talking about ancestors of persons, the other about origins of persons. The hierarchies record the persons twice.
>
> I can't speak for other methodologies, but dbd doesn't record things
> redundantly in the db, regardless of how many hierarchies they are in.
>
>> Relations would record them once and record ancestors once and record origins once.
>
> True, if the proper schema is used.
>
>> Many problems with hierarchies - here's one: if a user is aware of only one hierarchy and discovers that there is no such person as John and 'deletes' him, the other hierarchy is now wrong, as is the DB.
>
> I can't speak for other methodologies, but this problem does not occur
> in dbd as things are only represented once, even if they are in
> multiple hierarchies. Deleting John deletes him from both hierarchies
> in db.
>
>>> To verify which method's underlying data model is more general, one can observe the impact on existing schema/data/query when meeting future unknown data requirements (to be proposed by someone else). Would someone be willing to engage in this trivial example?
>> It does seem trivial.
>
> Could you post the script for the initial data/queries so that we can
> observe the impact on them when meeting future unknown data
> requirements (to be proposed by someone else)? The more general
> methodology will be impacted the least. Below is dbd's script. Lines
> starting with "(;" are comments.
I'm not interested in what a "main directory item" might be, nor about
all the other loose lingo. Looks like all you are talking about is
syntax, not any kind of precise definition of a data theory. If I were
really concerned, I'd rather know what's involved to add God's father to
the db.
p
Neo
Assuming god's father is a person named bob, it would be:
(new 'bob 'person)
(createWRR god parent bob)
The above is equivalent to below:
(new)
(create person instance (it))
(create (it) name
(block
(new)
(create word instance (it))
(create (it) symbolizedBy (create 'b 'o 'b))
(return (it))
)
)
(create god parent bob)
(create bob child god)
Andy Dingley
Joe Kesselman wrote:
> Reminder: XML is intended as an interchange syntax,
XML is intended as an interchange syntax that's also a slashed-down
SGML.
That's had more effects on its design than any amount of DB theory.
Yes, we _know_ most of XML is wrong. It's just where you end up if you
start from where XML started from.
paul c
>> ... I'd rather know what's involved to add God's father to the db.
>
> Assuming god's father is a person named bob, it would be:
I didn't mention bob, only God's father.
p
ps: If 'symbolizedBy' signifies some kind of operation, I'd say verbs
and relationships are being mixed up. If it is instead some kind of
assertion, I'd say facts and syntax are being mixed up.
JOG
Yes, and purely as an interchange syntax it is adequate-ish (or as I
mentioned poor if one has to use it in any time critical app). The
issue is however when it is used to store information at a logical
level, as opposed to just being used for packaging for couriering, at
which point it becomes woeful. Unfortunately it is this latter use that
has gained prevalence, despite the woeful hierarchical query bias, and
complete lack of powerful manipulation mechanism.
And yes I realise it is not purely hierarchical if one throws items
such as xlink/xpointer into the mix but as an old friend once told me
referring to the world wide web, "sure, you can glue arms and legs onto
a hamburger, but at the end of the day it is still a hamburger."
JOG
Yes, I'm in agreeance with Doug Engelbart - the peer review mechanism
can often be of debatable merit.
> Addressing the idiocy above, the complexity and richness of the data are
> inherent to the data remaining with it no matter the representation.
> Increasing the complexity of the representing structures only increases
> complexity without adding any 'richness' at all. 'Richness' comes from
> the available operations for manipulating data represented in those
> structures, which are greatly reduced as the structural complexity
> increases.
The comments on XML being able to handle information "Richness" that a
predicate based model (such as the RM) could not annoyed me more than
anything else in the quotations. I can only think that the term is used
by XML proponents due to its ambiguity.
Neo
In dbd, it isn't necessary to relate god or universe to the main
directory. The example does, so that they are visible in the db's
visual interface which first displays a node for the main directory. A
database like MS Access or SQL Server does approximately the same thing
but user doesn't specify it (or have control over it). For example, in
SQL, "CREATE TABLE color" creates a table named color AND relates it to
the equivalent of the main directory which in Access is the initial
window which lists tables, queries, forms, etc.
> Looks like all you are talking about is syntax, not any kind of precise definition of a data theory.
Unlike RM's, dbd's isn't obvious from its various interfaces (ie
high-level scripts, GUI or API).
Marshall
>
> The comments on XML being able to handle information "Richness" that a
> predicate based model (such as the RM) could not annoyed me more than
> anything else in the quotations. I can only think that the term is used
> by XML proponents due to its ambiguity.
Heh. "Rich" is high on my list of words that set off the bullshit
meter.
Not to say that the word doesn't have legitimate uses; even "flat"
can actually mean something if used correctly. But "rich" is pretty
much second only to "nice" in being a sign that the writer doesn't
actually have anything to say.
Marshall
Cimode
Couple links from dbdebunk.com for XML nonsense...
On the algorhytmic consequences...
http://www.joelonsoftware.com/articles/fog0000000319.html
On the myth of self describing XML
http://www.oceaninformatics.biz/publications/e2.pdf
An overall view on the *advantages* of XML
http://www.sqlservercentral.com/columnists/dpeterson/isxmltheanswer.asp
paul c
Still not interested. Can't help but notice that no way to record God's
unnamed father was forthcoming. That might encourage a more charitable
reception.
p
Neo
>>
>> Assuming god's father is a person named bob, it would be:
>
OK, below assumes God's father is a thing without a name.
(new)
(createWRR god parent (it))
> If 'symbolizedBy' signifies some kind of operation, I'd say verbs and relationships are being mixed up. If it is instead some kind of assertion, I'd say facts and syntax are being mixed up.
Below script creates a word that is symbolized by two different
strings:
(new)
(create word instance (it))
(create (it) symbolizedBy 'employe)
(create (it) symbolizedBy 'employee)
I wanted to show that (it) can also be symbolizedBy chinese characters,
but I don't have them installed on my PC.
Neo
(new)
(createWRR god parent (it))
OR
(new)
(create god parent (it))
(create (it) child god)
OR
(new)
(create god parent (it))
Neo
In case, you absolutely wanted to use the word father, it would be:
(create (new) name (word+ 'father))
(create god father (new))
OR
(new)
(create (it) name (block
(new)
(create word instance (it))
(create (it)
symbolizedBy
(select 'f 'a 't 'h 'e 'r))
(return (it))
)
)
(new)
(create god
(and (select word instance *)
(select * symbolizedBy 'father))
(it)
)
Neo
(create god
(select * name (and (select word instance *)
(select * symbolizedBy 'father)))
(it)
)
Here the verb/relator is a thing whose name is a word symbolized by the
string 'father.
paul c
> JOG wrote:
>> ...> ...
I liked that one. Reminded me of when I was helping a medium-sized
airline go bankrupt. They had paid a German supplier to design an
interface from their flight system to a robotic warehouse at their hub.
There were something like fourteen different messages, eg. "flight xyz
has departed JFK", "flight xyz has arrived" and so forth. The robotic
system would shuffle packages and containers around based on cargo
destination, soonest next flights out and so forth. But lots of
contingencies had been ignored, eg., there was no provision for a flight
that might be re-directed after taking off, say due to bad weather at
the scheduled destination.
The warehouse machines were said to contain the same database as the
cargo system, which was in-between the flight system and the warehouse
computers, so I proposed that only three types of messages were needed,
namely 'insert', 'update' and 'delete'. This went nowhere and the
original scheme was implemented. I also noted that the airline's fact
book listed about 100,000 more annual passenger departures than arrivals!
p
Neo
> version of Godwin's Law ?
>
> [ horror snipped ]
Once you actually post SQL equivalent to the initial data/query and try
to update it to meet future unknown data requirements, you will see
that dbd's is simpler. If you want to verify this, please post script.
Also dbd's scripts can be made simpler. For example:
(new 'eve 'person)
is equivalent to:
(; Create a person named eve)
(new)
(create person instance (it))
(create (it) name (block
(new)
(create word instance (it))
(create (it) symbolizedBy (create 'e 'v 'e))
(return (it))))
Or you can see the difference in script length/complexity in recent
thread titled "Gray Hair is still relevant"
paul c
Okay, I'll bite. From the link, apparently 'new', 'createWRR' and
'create' are functions, although it seems to talk only of syntax. What
other functions are defined and is the word function used in the usual
sense?
Are you merely talking about alternative notation for LISP and a way to
serialize it? If so, I'd say 'dbd' is an implementation language, just
as assembler or C are, and no more a data language than those two are.
For example, what analogue does it have to make a logical inference,
such as 'these are the grand-nephews/first cousins twice removed of
god's father's sisters'?
p
Neo
> > observe the impact on existing schema/data/query when meeting future
> > unknown data requirements (to be proposed by someone else). Would
> > someone be willing to engage in this example?
>
> The question is patently impossible/ridiculous. Only a mystic can predict the 'future unknown'.
I do not assert to predict the future unknown. I only assert that dbd
is impacted less by future unknown data requirements than any other
data representation methodology because dbd's is more general. Would
someone be willing to demonstrate otherwise?
paul c
If you're making the claim, it is up to you to show how it so, not for
others to refute it. I suspect the former isn't possible as it would
necessarily require some unknown to become known for any demonstration
to work. This would seem a fallacy if one agrees that the known can't
also be unknown.
p
Marshall
>
> If you're making the claim, it is up to you to show how it so, not for
> others to refute it.
Agreed.
> I suspect the former isn't possible as it would
> necessarily require some unknown to become known for any demonstration
> to work. This would seem a fallacy if one agrees that the known can't
> also be unknown.
Yes, but it's not quite as hopeless as this makes it sound. We
can identify what the possible space of schema changes are,
and we can use empirical analysis to get an idea of how
common each of various different kinds of changes are.
In my experience (unmeasured) , the most common kind of
change is the adding of an attribute to an existing entity.
Marshall
Neo
Yes, these are "functions" similar to CREATE, INSERT, SELECT, DELETE
and UPDATE in SQL/RM.
> ... although it seems to talk only of syntax.
Yes, kind of like a car manual: Turn steering wheel to turn car. It
doesn't explain how it is accomplished.
> What other functions are defined
The basic ones are create, select, update and delete.
Others listed at www.dbfordummies.com/NLI/Function.asp
> and is the word function used in the usual sense?
Yes, see www.dbfordummies.com/NLI/Expression.asp
> Are you merely talking about alternative notation for LISP and a way to serialize it?
No, dbd is an implemenation of a data model that I developed. Dbd's
scripting interface has LISP-like syntax. See
www.dbfordummies.com/NLI/Default.asp
> For example, what analogue does it have to make a logical inference,
> such as 'these are the grand-nephews/first cousins twice removed of
> god's father's sisters'?
In the current universe/god/john/mary example, they are:
(; Find eve's children)
(; Finds john and mary)
(select eve child *)
(; Find john's parents)
(; Finds adam and eve)
(select john parent *)
(; Find adam's children that are part of mars)
(; Finds john)
(and (select adam child *)
(select mars part *))
(; Find eve's children that are part of a planet)
(; Finds john and mary)
(and (select eve child *)
(select (select planet instance *) part *))
(; Find god's grandchildren that are part of a planet)
(; Finds john and mary)
(and (select (select god child *) child *)
(select (select planet instance *) part *))
Examples of more complex queries are at
www.dbfordummies.com/Example/Ex039.asp
erk
Hear, hear. Manipulating XML in any language (I've primarily used XSLT
and DOM/SAX/JAXB/Castor in Java) runs you smack into the shambling,
bulky incoherence of the XML "InfoSet."
Apparently its "designers" never fully understood Antoine de
Saint-Exuper: "Perfection is achieved, not when there is nothing more
to add, but when there is nothing left to take away."
- erk
Neo
T1 (ie today)
Have someone specify a relatively simple problem (ie model john and
mary). You post SQL script to store/query data. I post dbd's script to
store/query data.
T2 (ie later today or tomorrow)
Have someone specify additional data requirements. You/I show/compare
the impact on data/script to accomodate new requirements.
The above simulates a customer specifying new/additional requirements
after project has been updated to meet customer's prior requirements.
Jay Dee
>>>I spoke in a recent thread of my distaste for XML from a theoretical standpoint ... I find this return of focus to hierarchical models since 1995 extremely frustrating.
>>
>>Addressing the idiocy above, the complexity and richness of the data are inherent to the data remaining with it no matter the representation. Increasing the complexity of the representing structures only increases complexity without adding any 'richness' at all. 'Richness' comes from the available operations for manipulating data represented in those structures, which are greatly reduced as the structural complexity increases.
>
>
> the simple example shown at www.dbfordummies.com/example/ex007.asp
> This example represents John and Mary in two hierarchies (without
> redundancy). In the first hierarchy, John and Mary are children of Adam
> and Eve who are children of God. In the second hierarchy, John and Mary
> are part of Mars and Venus respectively which are part of the Universe.
Again with the "Could someone.." requests?
Neo, as far as I can tell, no one understands what simple example
the web page depicts. There are some universe and god and child
dir and clsdir and part and john and mary and adam and eve words
mixed with some gui artifacts -- but nowhere a prose description
of wtf all that is supposed to represent.
If, as I gather from your post, there are simply two hierarchies
and a pair of nodes are nodes in each, I don't see any difficulty
at all in representing these in either a fully normal design or XML
-- with no more redundancy than I see in your example.
I think you need to do a better job of explaining the tacit
requirements in phrases like "multiple hierarchies" and "food
judging" that are, apparently, obvious to you but unknown to
the rest of us.
> To verify which method's underlying data model is more general, one can
> observe the impact on existing schema/data/query when meeting future
> unknown data requirements (to be proposed by someone else). Would
> someone be willing to engage in this trivial example?
>
Keith H Duggar
> paul c wrote :
> > From the link, apparently 'new', 'createWRR' and
> > 'create' are functions ...
>
> Yes, these are "functions" similar to CREATE, INSERT,
> SELECT, DELETE and UPDATE in SQL/RM.
>
> > ... although it seems to talk only of syntax.
>
> Yes, kind of like a car manual: Turn steering wheel to
> turn car. It doesn't explain how it is accomplished.
It seems you are confusing /syntax/, /semantics/, and
/implementation/. "Turn steering wheel to turn car" defines
(partly perhaps) the "meaning" ie /semantics/ of the
function (or perhaps function turn applied to argument
wheel) of "turn steering wheel". "how it is accomplished" is
part of /implementation/ neither /semantics/ nor /syntax/.
This is basic stuff and confusing them makes it more
difficult for others to understand you. So try not to
confuse them. You can easily find numerous resources to help
you understand the concepts of syntax and semantics more
clearly.
For example, if you take roughly that "what = semantics",
"how done = implementation", "how communicated = syntax",
then Paul is saying you spend inordinate amounts of time
showing "how to communicate" but very little time showing
/what/ is being communicated. You leave it up to us to infer
the /what/ or /semantics/ by essentially guessing. That is
inefficient and annoying. The fact that you cannot clearly
and succinctly state your data model and semantics of your
"dbs" functions, I think, tells a great deal.
-- Keith -- Fraud 6 --
Neo
the /what/ or /semantics/ by essentially guessing.
Are you saying one can't infer what is being communicated by the
comments prior to each section (which I have copied below)? Each
comment starts with "(;" and ends with respective ")".
(; Create a class directory item and name it age)
(; Create a main directory item and name it god)
(; Create a class directory item and name it person)
(; Create a person named adam)
(; Create a person named eve)
(; Create a person named john whose age is 35)
(; Create a person named mary whose age is 25)
(; Create god's children hierarchy)
(; Create a main directory item and name it universe)
(; Create a class directory item and name it planet)
(; Create planet mars)
(; Create planet venus)
(; Create universe's part hierarchy)
Are you saying one can't infer what is being communicated by the figure
at referred site (www.dbfordummies.com/example/ex007.asp)?
Could you post a roughly equivalent RM/SQL script that does it better?
And will it handle new data requirements as well as dbd's?
Neo
The following approach might be better. I will let you specify an
example. I will need you to post the SQL script and a few simple
queries. I will do the same with dbd.
Then I or someone else will specify some new data requirements (not
constraints). What I wanted to demonstrate is that dbd's method is
impacted less than RM's method of representing things.
Neo
> That is inefficient and annoying.
Does the below updated description explain it sufficiently?
This example models the following things:
A thing named God.
A person named Adam.
A person named Eve.
A person named John whose age is 35.
A person named Mary whose age is 25.
A thing named Universe.
A planet named Mars.
A planet named Venus.
This example also models two hierarchies. In the first hierarchy, John
and Mary are children of Adam and Eve who are children of God. In the
second hierarchy, John and Mary are part of Mars and Venus respectively
which are part of the Universe.
Even though John and Mary are in both hierarchies, they are not stored
redundantly. To verify this, enable the displaying of each thing's ID
via the View Menu.
Kenneth Downs
>> You leave it up to us to infer the /what/ or /semantics/ by essentially
>> guessing. That is inefficient and annoying.
>
> Does the below updated description explain it sufficiently?
>
>
> This example models the following things:
>
> A thing named God.
> A person named Adam.
> A person named Eve.
> A person named John whose age is 35.
> A person named Mary whose age is 25.
>
> A thing named Universe.
> A planet named Mars.
> A planet named Venus.
Sounds like Perelandra.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
Neo
Does the following updated description make sense?
This example models the following things:
A thing named God.
A person named Adam.
A person named Eve.
A person named John whose age is 35.
A person named Mary whose age is 25.
A thing named Universe.
A planet named Mars.
A planet named Venus.
This example also models two hierarchies. In the first hierarchy, John
and Mary are children of Adam and Eve who are children of God. In the
second hierarchy, John and Mary are part of Mars and Venus respectively
which are part of the Universe. Even though John and Mary are in both
hierarchies, they are not stored redundantly. One way to verify this is
to display the ID of each thing via the View Menu.
> There are some ... dir and clsDir ... gui artifacts --
In most dbs like Access or SQL Server, the main directory is the first
window which lists tabled, viewd, forms, reports, etc. In dbd, the main
directory is named 'dir' and is represented/manipulated like other
data.
In most dbs like Access or SQL Server, the command "CREATE TABLE
person" automatically relates table person to the main directory. Dbd
doesn't. User must specify via (create dir item person). This allows
the user to control what is displayed in the GUI. Additional info at
www.dbfordummies.com/Basic/SysData.asp.
paul c
>> I suspect the former isn't possible as it would necessarily require some unknown to become known for any demonstration to work. This would seem a fallacy if one agrees that the known can't also be unknown.
>
> T1 (ie today)
> Have someone specify a relatively simple problem (ie model john and
> mary). You post SQL script to store/query data. I post dbd's script to
> store/query data.
not simple to me without a lot more detail.
> T2 (ie later today or tomorrow)
> Have someone specify additional data requirements. You/I show/compare
> the impact on data/script to accomodate new requirements.
> ...
since the language in this thread is so loose (even looser than my
normal language!), i'd have to know what the 'additional' is, nor to
mention the original.
p
Marshall
> Bob Badour wrote:
> > Joe Kesselman wrote:
> >
> > > Reminder: XML is intended as an interchange syntax, and therefore was
> > > designed for maximum simplicity.
> >
> > If that was a design criterion, they failed miserably.
>
> Hear, hear. Manipulating XML in any language (I've primarily used XSLT
> and DOM/SAX/JAXB/Castor in Java) runs you smack into the shambling,
> bulky incoherence of the XML "InfoSet."
Most heartening idea I had today: check hotjobs.com for hits
for the phrases "sql" "xml" "xpath" "xquery" "xslt". After all,
everyone is under the impression that ruby is taking over the
world, when in fact it isn't.
sql: 13884
xml: 7340
xpath: 124
xquery: 35
xslt: 950
xml-schema: 115
So while it appears that *some* kind of use of XML is common,
use of things like xslt is fairly rare.
> Apparently its "designers" never fully understood Antoine de
> Saint-Exuper: "Perfection is achieved, not when there is nothing more
> to add, but when there is nothing left to take away."
I like it!
Marshall
J M Davitt
>>Neo, as far as I can tell, no one understands what simple example the web page depicts ... but nowhere a prose description of wtf all that is supposed to represent.
>
>
> Does the following updated description make sense?
>
> This example models the following things:
>
> A thing named God.
> A person named Adam.
> A person named Eve.
> A person named John whose age is 35.
> A person named Mary whose age is 25.
>
> A thing named Universe.
> A planet named Mars.
> A planet named Venus.
>
> This example also models two hierarchies. In the first hierarchy, John
> and Mary are children of Adam and Eve who are children of God. In the
> second hierarchy, John and Mary are part of Mars and Venus respectively
> which are part of the Universe. Even though John and Mary are in both
> hierarchies, they are not stored redundantly. One way to verify this is
> to display the ID of each thing via the View Menu.
Okay, there are several named things. Some of them are things, some are
persons, some are persons with ages, and some are planets. Right so
far? And their ID is the bit of magic which glues their characteristics
together? (Hmm.. Sounds like Microdata has done this.) CRUD on things
shouldn't be tough; you can handle those, right? And there are some
hierarchies. Let's treat those as trees.
How are the trees and forest identified? How does one plant a new tree?
How does one sprout a new leaf? How does a leaf become a branch?
How does one prune a limb and graft it onto a different part of the
tree? How does one cut a leaf from one tree and not the other?
Are these the kinds of operations you want someone to code up for you?
kvnkr...@gmail.com
Let's start simple. Let's see how the relation model (using either a
pure relational syntax or a proprietary SQL implementation) and "dbd"
model work against some simple requirements. We'll first evalute the
two based on how well they handle the initial specifications.
Basic Requirements: A business has many staff members (with full names
and a start date), some of whom are direct supervisors over other staff
members. The business has many clients (with full names), and each
client is registered on a specific date by a specific staff member.
Constraints: Assuming a few simple forms exists for directly entering
new data into the system, the following constraints should be enforced
w/out embedding the logic into the forms:
It should not be possible for a staff member to have multiple direct
supervisors.
A client cannot be registered twice.
A staff member cannot register a client before that staff member's
start date.
Queries: It should be possible to supply queries which resolve the
following questions:
'Alice' is retiring. List all of the clients she signed, and all
clients signed by employees whom she directly or indirectly supervised.
We need to make some staffing cuts. List all current employees who
have signed less than 10 clients in the past month, in order of
seniority.
Let's first evaluate how well the two models hold up relative to the
intial requirements. Obviously, if one model is markedly inferior with
respect to initial requirements, then who cares how well it responds to
changes in requirements?
Neo
In dbd, each thing can have 0 to many names.
> Some of them are things, some are persons, some are persons with ages, and some are planets. Right so far?
In dbd, they are all things, some of them are further classified as a
person, an age, a planet, etc.
> And their ID is the bit of magic which glues their characteristics together? (Hmm.. Sounds like Microdata has done this.)
Could someone post a Microdata script roughly equivalent to dbd's to
model/query the above data?
> CRUD on things shouldn't be tough; you can handle those, right?
In dbd, they are new, create, select, update and delete.
See www.dbfordummies.com/NLI/Function.asp for additional.
> And there are some hierarchies. Let's treat those as trees.
In the most general case, dbd manages a network where any thing can
have any type and number of relationships with other things. A subset
of the network can be a list, table, tree, etc. In the current example,
each thing can be in 0 to many trees. In some trees, it can be the
root. In some, a branch. In others a leaf. All without redundancy. See
www.dbfordummies.com/Basic/Hierarchy.asp
> How are the trees and forest identified?
> How does one plant a new tree?
> How does one sprout a new leaf?
> How does a leaf become a branch?
> How does one prune a limb and graft it onto a different part of the tree?
> How does one cut a leaf from one tree and not the other?
All the above are quite easy and implementing them doesn't affect it in
other hierarchies, lists, table, graphs, etc. Could you specify the
above in a more specific manner? Will the following specific changes be
sufficient? (If not, please specify)
How do I create a boss/employee hierarchy with Mary and John as boss of
Adam and Eve who are both part of Earth?
How do I add a new child of Mary named Suzie?
How do I change Suzie from being a child of Mary to being a child of
John?
How do I then make John a child of Mary instead of being a child of
Adam and Eve?
Could you or someone post a roughly equivalent SQL script to
model/query the original data and implement the above changes/additions
for comparison?
Neo
> and a start date), some of whom are direct supervisors over other staff
> members. The business has many clients (with full names), and each
> client is registered on a specific date by a specific staff member.
Ok, please specify a specific data for the above.
> Constraints: ...
Currently dbd doesn't implement user/app-defined constraints. To do so,
one would need to write an application in C/C++ which calls dbd via its
API. Some code examples at www.dbfordummies.com/Example/Default.asp
> Queries: 'Alice' is retiring. List all of the clients she signed, and all clients signed by employees whom she directly or indirectly supervised.
Ok
> Q: We need to make some staffing cuts. List all current employees who have signed less than 10 clients in the past month, in order of seniority.
Currently, dbd's select statements do not perform math operations,
sums, total, etc. For example, find all person who were hired after
1/1/06. It can do something similar, find all current employees who
have signed clients X, Y and Z on Date1, Date2, and have senority A, B
and C.
Neo
Ok, we can finish a prior example posted by you in "Poll: Expert user
vs. Internals Expert". Below you used Tutorial D(?) to model that Bob
and JayDee are sages, and Neo is a jerk, and that Bob's state is on,
and Neo's state is off.
> var sage real relation { name char } key { name } ;
> sage += relation {tuple { name 'Bob' }, tuple { name 'JayDee' } };
>
> var jerk real relation { name char } key { name } ;
> jerk += relation {tuple { name 'Neo' } } ;
>
> var state real relation { name char, state char } key { name } ;
> state += relation {tuple { name 'Bob', state 'on' }, tuple { name 'Neo', state 'off' } } ;
Below is dbd's script to represent the above:
(; Create sages and jerks)
(new 'bob 'sage)
(new 'jayDee 'sage)
(new 'neo 'jerk)
(; Create on and off states)
(new 'on 'state)
(new 'off 'state)
(; Create bob's and neo's states)
(create bob state on)
(create neo state off)
JayDee, now I would like you to extend your initial example to match
dbd's extension below:
(; Find the relator/verb between bob and sage)
(; Finds class)
(select bob * sage)
(; Find the relator/verb between sage and bob)
(; Finds instance)
(select sage * bob)
(; Represent that classifications sages and jerks are opposites)
(new 'opposite 'verb)
(create sage opposite jerk)
(create jerk opposite sage)
(; Find things whose classification is opposite of neo's)
(; Finds bob and jayDee)
(select (select (select neo class *) opposite *) instance *)
(; Represent that states on and off are opposites)
(create on opposite off)
(create off opposite on)
(; Find things whose state is opposite of neo's)
(; Finds bob)
(select * state (select (select neo state *) opposite *))
paul c
> Neo wrote:
>>> Neo, as far as I can tell, no one understands what simple example the
>>> web page depicts ... but nowhere a prose description of wtf all that
>>> is supposed to represent.
At the risk of repeating what others have already said, I have to agree.
Without some definition written in independent language, we can't have
any assurance that the various examples have any consistency, eg. the
same syntax could stand for two different meanings, for all we know,
sort of like Alice's friend the king who said a word means whatever he
wants it to mean.
p
Neo
> any assurance that the various examples have any consistency, eg. the
> same syntax could stand for two different meanings, for all we know,
> sort of like Alice's friend the king who said a word means whatever he
> wants it to mean.
Ok, so you are saying if a dbd user represents a person named Suzie
whose parents are John and Mary via ...
(new 'suzie 'person)
(createWRR suzie parent john)
(createWRR suzie parent mary)
... and when dbd returns Person for following query:
(select suzie class *)
... and when dbd returns John and Mary for following query:
(select suzie parent *)
....and when dbd returns Suzie for either of the following queries:
(select john child *)
(select mary child *)
that what the user meant by John, Mary, Suzie, person, parent, child,
etc when entered into the db and writing queries have a different
meaning when dbd uses the same words to return answers.
paul c
>> Without some definition written in independent language, we can't have
>> any assurance that the various examples have any consistency, eg. the
>> same syntax could stand for two different meanings, for all we know,
>> sort of like Alice's friend the king who said a word means whatever he
>> wants it to mean.
>
> Ok, so you are saying if a dbd user represents a person named Suzie
> whose parents are John and Mary via ...
No, I'm not. I think I need to see some English first and preferably
some formal notation outside of dbd script which defines what dbd does,
before I can understand the phrase 'dbd user represents a person', as
well as the rest of the dbd syntax. I'll have to give up on that until
I see something along those lines.
p
Neo
> some formal notation outside of dbd script which defines what dbd does,
> before I can understand the phrase 'dbd user represents a person', as
> well as the rest of the dbd syntax. I'll have to give up on that until
> I see something along those lines.
CREATE TABLE person (autoID, name);
INSERT INTO person (name) VALUES ("suzie");
Which of the below best describes the above?
RMDB user is creating Suzie (but user is not God).
RMDB user is modelling Suzie (but no lipstick or high heels are
involved).
RMDB user is representing Suzie (but not in Congress).
RMDB user is storing Suzie (but she won't fit in the PC).
RMDB user is storing data for Suzie (she can't do it herself).
RMDB user is storing data about Suzie (her pockets are full).
RMDB user is asserting a predicate about Suzie (sounds painful).
RMDB user is recording a fact that is Suzie which has implicit meaning
(user is doing something behind her back).
RMDB user is inserting a tuple in a relation corresponding to Suzie
(tuple and relation in their accepted mathematical sense).
paul c
?
p
Keith H Duggar
> Neo wrote:
> > Ok, so you are saying if a dbd user represents a person
> > named Suzie whose parents are John and Mary via ...
> > ...
>
> preferably some formal notation outside of dbd script
> which defines what dbd does, before I can understand the
> phrase 'dbd user represents a person', as well as the rest
> of the dbd syntax. I'll have to give up on that until I
> see something along those lines.
Paul, I don't think you are /ever/ going to get something
along these lines. Because Neo either doesn't know how to
provide it, is embarrassed to provide it, has a persecution
complex, or is paranoid and erroneously thinks he is going
to make millions off an RM "alternative" that took him "10
years" to develop.
I found these Neo comments illuminating:
Neo wrote:
> Currently dbd doesn't implement user/app-defined
> constraints. To do so, one would need to write an
> application in C/C++ which calls dbd via its API.
...
> Currently, dbd's select statements do not perform math
> operations, sums, total, etc. For example, find all person
> who were hired after 1/1/06. It can do something similar,
> find all current employees who have signed clients X, Y
> and Z on Date1, Date2, and have senority A, B and C.
I think if he ever does reveal the fruit of "10 years" we
are going to find out it's just yet another implementation
of a network model with a few C++ pointers (as in numerical
addresses) pointing in directions Neo considers novel.
Alas, it seems he is just going to continue playing secret
squirrel games hiding his nuts in the garden and squawking
for people to search for them.
Though, to be fair, his persistence is somewhat impressive,
no?
Neo
λ
> ... and semantics of your "dbs" functions
Would the following be clear and succinct for the create function?
Description:
The create function creates a relationship between specified things
which must already exist in the db. The create function requires two or
more parameters. In some cases, the first five parameters may be
thought of as being subject, verb, object, preposition and
objectOfPreposition. If a desired thing does not already exist in db,
first use the new function.
General Format:
(create arg1 arg2 [arg3] ...)
Examples:
(create john like mary)
(create john like mary from june to july)
(create 'john 'smith)
(create 'j 'o 'h 'n)
In the above expressions, john is shorthand for (. 'john)
which is approximately equivalent to
(select * name (select * symbolizedBy (select 'j 'o 'h 'n)))
which in english says:
a thing(t1) whose name is a thing(t2) that is symbolized by the
string(t3) formed from the sequence of symbols j(t4), o(t5), h(t6),
n(t7).
Dbd distinguishes between the person john, the sound john (same in
various languages), and the symbols that represent the sound (different
in various languages).
Same applies to create, select, like, mary, from, june, to, july, name,
symbolizedBy. These are all shorthand for (. 'create), (. 'select), (.
'like), etc ...
kvnkr...@gmail.com
Neo wrote:
> > Basic Requirements: A business has many staff members (with full names
> > and a start date), some of whom are direct supervisors over other staff
> > members. The business has many clients (with full names), and each
> > client is registered on a specific date by a specific staff member.
>
> Ok, please specify a specific data for the above.
>
The data values are not part of the initial specifications. I suppose
you could generate some test data, but ultimately, the client wants the
freedom to write their own application input forms for data entry. Is
dbd incapable of application and data storage independence? If so,
bummer.
> > Constraints: ...
>
> Currently dbd doesn't implement user/app-defined constraints. To do so,
> one would need to write an application in C/C++ which calls dbd via its
> API. Some code examples at www.dbfordummies.com/Example/Default.asp
>
Does dbd have no framework for enforcing constraints - so the client
must encode all business requirements explicitly into every application
form that interfaces with the dbd database? If so, bummer.
One of the "new surprise" requirements was going to be "add Salary to
each staff member" and "allow for pre-specified users to see salaries,
but others not to". How would dbd hold up to that requirement?
> > Queries: 'Alice' is retiring. List all of the clients she signed, and all clients signed by employees whom she directly or indirectly supervised.
>
> Ok
Um, idea being, you'd show us what the query would look like...
>
> > Q: We need to make some staffing cuts. List all current employees who have signed less than 10 clients in the past month, in order of seniority.
>
> Currently, dbd's select statements do not perform math operations,
> sums, total, etc. For example, find all person who were hired after
> 1/1/06. It can do something similar, find all current employees who
> have signed clients X, Y and Z on Date1, Date2, and have senority A, B
> and C.
No aggregation, mathematics, or ordering? Bummer.
Neo
> >
>
> The data values are not part of the initial specifications.
With dbd, user doesn't design a schema. When you have finished
designing the schema, please post it. We can then start adding some
initial data that might look like the below or not. Write a few
queries. Then someone can suggest unanticipated data, ie store the
asset(s) that each person/company owns some possibly shared. Adapting
each solution to the new data will allow us to evaluate or extrapolate
each data representation methodology's resiliency/generality.
Company IBM has 6 employees. There boss/employee hierarchy as follows:
John Smith (hired 7/4/45)
Mary Lee (hired 5/3/65)
Suzie Merk (hired 8/8/88)
Bob Lewis (hired 3/8/08)
Rick Branson (hired 8/9/48, 1/3/67 and 5/13/88)
Jack (hired 3/5/89) has two bosses: John and Suzie.
IBM has 5 clients (2 companies, 3 individuals) registered on date(s)
indicated by employee(s)
Dell reg by Mary on 1/1/01
Microsoft Inc reg by Suzie and Rick on 3/5/02 and 5/8/54
Warren Buffet reg by Bob on 5/8/02
George W. Bush III reg by Mary, Suze, Bob, Rick on 5/8/06
J Carter ref by John on 3/4/92
Neo
See related thread titled "IDJIT! Your Data Model Can't Posssibly Work!"
JOG
> > Alas, it seems he is just going to continue playing secret squirrel games hiding his nuts in the garden and squawking for people to search for them.
>
> See related thread titled "IDJIT! Your Data Model Can't Posssibly Work!"
Noone needs to read another thread to know graph models don't work.
Information isn't constrained to binary relationships and your model
is. You've essentially just created a big hypertext structure, and I'm
not sure at all why you've got confused and are posting it on a
database board.
The Semantic Web is doing this exact same thing but on an influential
scale with RDF and associated processing languages, so why not help
them out instead of flogging your own tiny efforts on an unapplicable
newsgroup?
Neo
Could you give a simple example of such information that dbd shouldn't
be able to handle? Could you show how to do it with a RMDB?
Neo
> > the simple example shown at ...
>
> No, I don't think anyone will. You've used up quite a good deal of
> good will. If you wish to proceed in your endevour, I would propose that it
> is your job to do these comparisons.
ftp://ftp.software.ibm.com/software/data/u2/pubs/whitepapers/nested_rdbms.pdf
compares RMDB's and IBM's Nested Relational Db's method of modelling
"nested" data. www.dbfordummies.com/Example/Ex305.asp shows how to
model a portion of that data. Would someone be willing to directly
compare RMBD vs dbd in modelling/querying the complete data shown in
figure 5 of the white paper?
JOG
> > ... graph models don't work. Information isn't constrained to binary relationships and your model is.
>
> Could you give a simple example of such information that dbd shouldn't
Well ok, but first, if your amenable to it, could you just remind me
how me how you would represent something like "A person called Bob is
friends with a person called Tom" in your system (obviously that's a
bidirectional relationship). Ta.
Marshall
is your job to do these comparisons. (See, other people can be
repetitive too.)
Why not learn enough SQL to be able to identify a query that's a
challenge in SQL, and *you* show how that query is easy in
your thing.
Marshall
Neo
> challenge in SQL, and *you* show how that query is easy in
> your thing.
Suppose we want to store persons, cars and who owns which cars. One way
to do this in RMDB is to use the following schema:
T_Person (personID, name);
T_Car (carID, name);
T_Own (personID, carID);
T_Person
1 John
2 Mary
T_Car
1 Chevette
2 Corvette
T_Own
1(John), 1(Chevette)
2(Mary), 1(Chevette)
2(Mary), 2(Corvette)
// Find all cars owned by Mary
SELECT T_Car.*
FROM T_Person INNER JOIN (T_Car INNER JOIN T_Own ON T_Car.CarID =
T_Own.CarID) ON T_Person.PersonID = T_Own.PersonID
WHERE (((T_Person.Name)="mary"));
Below is dbd's equivalent:
(new 'john 'person)
(new 'mary 'person)
(new 'chevette 'car)
(new 'corvette 'car)
(new 'own 'verb)
(create john own chevette)
(create mary own chevette)
(create mary own corvette)
(select mary own *)
Would someone be willing to update the RMDB solution and compare it to
dbd when meeting new data requirements. If you prefer you may start
with a different schema/query.
Andy Dingley
>Hear, hear. Manipulating XML in any language (I've primarily used XSLT
>and DOM/SAX/JAXB/Castor in Java) runs you smack into the shambling,
>bulky incoherence of the XML "InfoSet."
>
>Apparently its "designers" never fully understood Antoine de
>Saint-Exuper:
Infoset was never "designed", it was post facto documentation added
afterwards.
If you think XML is bad here, try working with SGML!
Neo
(new 'bob 'person)
(new 'tom 'person)
(new 'friend 'verb)
(create bob friend tom)
(create tom friend bob)
OR
(new 'bob 'person)
(new 'tom 'person)
(new 'friend 'verb)
(create friend vbType symmetric)
(createWRR bob friend tom)
OR ...
See old thread titled "Demo: Modelling Cost of Travel Paths Between
Towns" and related example www.dbfordummies.com/Example/Ex136.asp
JOG
> > how you would represent something like "A person called Bob is friends with a person called Tom" in your system (obviously that's a bidirectional relationship).
>
> (new 'bob 'person)
> (new 'tom 'person)
> (new 'friend 'verb)
> (create bob friend tom)
> (create tom friend bob)
>
ok gotcha, good start. Then you have:
bob --- is_friends_with ---> tom
tom --- is_friends_with ---> bob
What if I wanted to record a different sentence - "A person called
John is friends with Frank within the remit of Work"? (i.e. they aren't
friends outside of workhours)
Bob Badour
> Neo wrote:
>
>>>how you would represent something like "A person called Bob is friends with a person called Tom" in your system (obviously that's a bidirectional relationship).
>>
>>(new 'bob 'person)
>>(new 'tom 'person)
>>(new 'friend 'verb)
>>(create bob friend tom)
>>(create tom friend bob)
>
> ok gotcha, good start. Then you have:
>
> bob --- is_friends_with ---> tom
> tom --- is_friends_with ---> bob
>
> What if I wanted to record a different sentence - "A person called
> John is friends with Frank within the remit of Work"? (i.e. they aren't
> friends outside of workhours)
A better question would be to ask if the requirements change and one
needs to record when the friendship began, how does dbd record the bob
and tom have been friends since October 12, 1993 ?
One of course has to record that fact to answer questions like: What is
the average duration of current friendships? What percentage of
friendships last more than 15 years? Who began a friendship on October
12, 1993 ? etc.
Neo
> John is friends with Frank within the remit of Work"?
> (i.e. they aren't friends outside of workhours)
(new 'john 'person)
(new 'frank 'person)
(new 'at 'preposition)
(new 'work)
(create john (create friend at work) frank)
(create frank (select friend at work) john)
OR
(new 'from 'preposition)
(new '9AM 'time)
(new 'to 'preposition)
(new '5PM 'time)
(create john (create friend at work from 9AM to 5PM) frank)
(create frank (select friend at work from 9AM to 5PM) john)
Note: 9AM and 5PM modelled in simplified manner.
Neo
>>
>> (new 'bob 'person)
>> (new 'tom 'person)
>> (new 'friend 'verb)
>> (create bob friend tom)
>> (create tom friend bob)
>
> needs to record when the friendship began, how does dbd record the bob
> and tom have been friends since October 12, 1993 ?
(new 'since)
(new '10/12/1993 'date)
(create bob friend tom since 10/12/1993)
(create tom friend bob since 10/12/1993)
Note: date modelled in simplified manner. Also since could instead be
begin, start, etc.
JOG
Neo wrote:
> > What if I wanted to record a different sentence - "A person called
> > John is friends with Frank within the remit of Work"?
> > (i.e. they aren't friends outside of workhours)
>
> (new 'john 'person)
> (new 'frank 'person)
> (new 'at 'preposition)
> (new 'work)
> (create john (create friend at work) frank)
> (create frank (select friend at work) john)
>
I am unclear what you have done here not being familiar with your
syntax. Could you draw the resulting structure in ascii for me to
clarify the results of these instructions.
Aloha Kakuikanu
Let me guess. The date '10/13/1993 ' would be
(new 'as)
(new 'successor)
(create date '11/12/1993' as successor of 10/12/1993)
yahoo! This reminds me
Aloha Kakuikanu
Bob Badour wrote:
> JOG wrote:
> > Neo wrote:
> >
> >>>how you would represent something like "A person called Bob is friends with a person called Tom" in your system (obviously that's a bidirectional relationship).
> >>
> >>(new 'bob 'person)
> >>(new 'tom 'person)
> >>(new 'friend 'verb)
> >>(create bob friend tom)
> >>(create tom friend bob)
> >
> > ok gotcha, good start. Then you have:
> >
> > bob --- is_friends_with ---> tom
> > tom --- is_friends_with ---> bob
> >
> > What if I wanted to record a different sentence - "A person called
> > John is friends with Frank within the remit of Work"? (i.e. they aren't
> > friends outside of workhours)
>
> A better question would be to ask if the requirements change and one
> needs to record when the friendship began, how does dbd record the bob
> and tom have been friends since October 12, 1993 ?
>
> One of course has to record that fact to answer questions like: What is
> the average duration of current friendships? What percentage of
> friendships last more than 15 years? Who began a friendship on October
> 12, 1993 ? etc.
new 'ternaryRelation
(new 'john 'person)
(new 'frank 'person)
(new '10/12/1993 'date)
(create 'ternaryRelation john frank 10/12/1993)
Rather obvious, isn't it?
Aloha Kakuikanu
> Neo wrote:
> > > What if I wanted to record a different sentence - "A person called
> > > John is friends with Frank within the remit of Work"?
> > > (i.e. they aren't friends outside of workhours)
> >
> > (new 'john 'person)
> > (new 'frank 'person)
> > (new 'at 'preposition)
> > (new 'work)
> > (create john (create friend at work) frank)
> > (create frank (select friend at work) john)
> >
>
> I am unclear what you have done here not being familiar with your
> syntax. Could you draw the resulting structure in ascii for me to
> clarify the results of these instructions.
How about little imagination? Here is the famous "find all emps who
earn more than their managers":
create `emp
create `mgr
create 'earn
create 'more
create 'who
(select emp who earn more mgr)
Neo
> > (new 'frank 'person)
> > (new 'at 'preposition)
> > (new 'work)
> > (create john (create friend at work) frank)
> > (create frank (select friend at work) john)
>
> I am unclear what you have done here not being familiar with your
> syntax. Could you draw the resulting structure in ascii for me to
> clarify the results of these instructions.
The simplified, partial structure of the main, top-level things would
be:
[friend] --------- [At] -----------> [work]
[john] ----- [friendAtWork] ---> [frank]
<--- [friendAtWork] -----
In the 2nd and 3rd lines, the "verb" refers to the first sentence. The
2nd and 3rd lines could be "verbs" of some other sentences. This is
further demonstrated in www.dbfordummies.com/Example/Ex132.asp which
models complex sentences.
Are you familiar with "Godel, Escher, Bach: An Eternal Golden Braid" by
D. Hofstadter?
Neo
Parser would not accept this expression as it must start and end with
parenthesis. I'll assume you meant: (new 'ternaryRelation)
> (new 'john 'person)
> (new 'frank 'person)
> (new '10/12/1993 'date)
Ok
> (create 'ternaryRelation john frank 10/12/1993)
Note that 'ternaryRelation refers to the string ternaryRelation.
I think you meant ternaryRelation which refers to the thing who name is
a word symbolized by the string ternaryRelation. I'll assume you meant:
(create ternaryRelation john frank 10/12/1993)
> Rather obvious, isn't it?
It makes the same amount of sense as the sentence "ternaryRelation john
frank 10/12/1993", which would confuse most people since, for starters,
john is not a verb/relator.
Bob Badour
And how does one write the queries I mentioned?
JOG
> > > (new 'john 'person)
> > > (new 'frank 'person)
> > > (new 'at 'preposition)
> > > (new 'work)
> > > (create john (create friend at work) frank)
> > > (create frank (select friend at work) john)
> >
> > I am unclear what you have done here not being familiar with your
> > syntax. Could you draw the resulting structure in ascii for me to
> > clarify the results of these instructions.
>
> The simplified, partial structure of the main, top-level things would
> be:
>
> [friend] --------- [At] -----------> [work]
>
> [john] ----- [friendAtWork] ---> [frank]
> <--- [friendAtWork] -----
>
Ok, thanks. So If I had three propositions:
"John is friends with Frank at Work"
"Bob is friends with Sam at Home"
"Tommy is friends with Billy at School"
and (ignoring the bidirectionality for clarity), they would generate:
[ john ] -- [ [ friend ] --- [ at ] --> [ work ] ] --> [ frank ]
[ bob ] -- [ [ friend ] --- [ at ] --> [ home ] ] --> [ sam ]
[ tommy ] -- [ [ friend ] --- [ at ] --> [ school ] ] --> [ billy ]
Now in an RDB I might have a corresponding Friendships relation:
----------------------------------
Person Friend Location
----------------------------------
john frank work
bob sam home
tommy billy school
----------------------------------
For an RDB a simple question like "Which people have friends some place
other than at home" requires a statement something of the order of:
SELECT Person from Friendships WHERE Location != "home"
What would the corresponding query be in your system?
Neo
>
> Let me guess. The date '10/13/1993 ' would be
>
> (new 'as)
> (new 'successor)
> (create date '11/12/1993' as successor of 10/12/1993)
While user knows that 10/12/1993 implies month 11, day 12 and year
1993; to allow app to determine this systematically, it should be
modelled as below:
(new 'date)
(new 'month)
(new 'day)
(new 'year)
(new)
(create date instance (it))
(create (it) month (val+ '10))
(create (it) day (val+ '12))
(create (it) year (val+ '1993))
Prior expression "(create bob friend tom since 10/12/1993)" becomes:
(create bob friend tom since (and (select date instance *)
(select * month 10)
(select * day 12)
(select * year 1993)))
Aloha Kakuikanu
A little creativity would help:
(new 'average)
(new 'duration)
(select average duration from ternaryRelation)
Aloha Kakuikanu
> which would confuse most people since, for starters,
> john is not a verb/relator.
Do you expect the "relator" to be in the dummies vocabulary?
Neo
> > john is not a verb/relator.
>
> Do you expect the "relator" to be in the dummies vocabulary?
Good point, what word would you suggest a dummy could understand to
mean: a thing that relates or links two other things.
Aloha Kakuikanu
> While user knows that 10/12/1993 implies month 11, day 12 and year
> 1993; to allow app to determine this systematically, it should be
> modelled as below:
>
> (new 'date)
> (new 'month)
> (new 'day)
> (new 'year)
>
> (new)
> (create date instance (it))
> (create (it) month (val+ '10))
> (create (it) day (val+ '12))
> (create (it) year (val+ '1993))
>
> Prior expression "(create bob friend tom since 10/12/1993)" becomes:
> (create bob friend tom since (and (select date instance *)
> (select * month 10)
> (select * day 12)
> (select * year 1993)))
Why should I believe you this gibberish actually parses on your system?
Hint: make a web application where a user can enter these sentences. A
suggestion that somebody would actually download and install your
thingy is ridiculous.
Keith H Duggar
> And how does one write the queries I mentioned?
If you mean
Bob Badour wrote:
> One of course has to record that fact to answer questions
> like: What is the average duration of current friendships?
> What percentage of friendships last more than 15 years?
> Who began a friendship on October 12, 1993 ? etc.
then amusingly
Neo wrote:
> Currently, dbd's select statements do not perform math
> operations, sums, total, etc. For example, find all person
> who were hired after 1/1/06. It can do something similar,
> find all current employees who have signed clients X, Y
> and Z on Date1, Date2, and have senority A, B and C.
Thus it seems your queries are likewise beyond the support
of NeoDB.
-- Keith -- Fraud 6
J M Davitt
Well, model language and a few queries are given in the document.
Don't they suffice?
Bob Badour
If he had, could we send John to jail for having relations with a verb?
Should we?
J M Davitt
Don't we first have to know how old the verb is? Do I
correctly presume that "relations" refers to the variety
of intercourse which isn't social?
Neo
> "John is friends with Frank at Work"
> "Bob is friends with Sam at Home"
> "Tommy is friends with Billy at School"
> and (ignoring the bidirectionality for clarity), they would generate:
>
> [ john ] -- [ [ friend ] --- [ at ] --> [ work ] ] --> [ frank ]
> [ bob ] -- [ [ friend ] --- [ at ] --> [ home ] ] --> [ sam ]
> [ tommy ] -- [ [ friend ] --- [ at ] --> [ school ] ] --> [ billy ]
>
> Now in an RDB I might have a corresponding Friendships relation:
>
> ----------------------------------
> john frank work
> bob sam home
> tommy billy school
>
> other than at home" requires a statement something of the order of:
>
> SELECT Person from Friendships WHERE Location != "home"
Currently dbd's select expression doesn't implement NOT EQUAL TO and
would requires interfacing to the db via its API and looping thru
things.
Following expression finds a person that has a friend at home that is a
person:
(and (select person instance *)
(select * (select friend at home) (select person instance *)))
Following expression finds a person that has a friend at home. The
friend could be anything (ie dog, cat, etc).
(and (select person instance*)
(select * (select friend at home)))
I can use this example to show how dbd is less impacted by new data
requirements. Suppose the friend can be things other than people and
each type requires different attributes. Or suppose the locations are
of different types and require different tables. Or suppose we need to
relate data to Person (not a person), Friend (not a friend), or
Location (not a location). For example, that friend and enemy are
opposites. Or suppose the verb can be "friend before work", "friend
after work", "friend at gym", etc. Or suppose, John is friends with Bob
between 1PM to 5PM. Allowing for such flexibility in RMDB will impact
the schema severely, but has little to no impact in dbd.
JOG
Well okay we have got somehow neo. I appreciate your honesty and
responses to my questions. Hopefully we can now agree that in the case
of query formulation the RM has an advantage of your system, comparing:
SELECT Person from Friendships where Location != "Home"
with something that would of the nature of the following statement, but
with even greater complication due to the extra loops involved:
(and (select person instance *)
(select * (select friend at home) (select person instance *)))
The arguments I have put to you are analagous to the ones of the great
debate between Codds RM and CODASYL, that relational theory won
handsomely. Your queries will always be more complex because you have
created a navigational model. I'd like, if you had chance, for you to
read:
which explains this old kettle of fish a great deal better than I
could.
>
> Following expression finds a person that has a friend at home. The
> friend could be anything (ie dog, cat, etc).
> (and (select person instance*)
> (select * (select friend at home)))
>
> I can use this example to show how dbd is less impacted by new data
> requirements. Suppose the friend can be things other than people and
> each type requires different attributes. Or suppose the locations are
> of different types and require different tables. Or suppose we need to
> relate data to Person (not a person), Friend (not a friend), or
> Location (not a location). For example, that friend and enemy are
> opposites. Or suppose the verb can be "friend before work", "friend
> after work", "friend at gym", etc. Or suppose, John is friends with Bob
> between 1PM to 5PM. Allowing for such flexibility in RMDB will impact
> the schema severely, but has little to no impact in dbd.
Now flexibility in the form of having no schema is a different matter
altogether, and it is fine to have that whole different debate *so
long* as one has accepted that the navigational models have weaknesses
in query formulation compared to RM.
I hope this has been helpful to you - I have attempted to engage you
seriously, and hope that you can move forward with your work in light
of what I have learnt in the past too.
I also highly recommend you get a copy of "Data and Reality" by William
Kent off amazon as there is some really illuminative stuff in there.
Neo
> ----------------------------------
> john frank work
> bob sam home
> tommy billy school
> *Note: NOT removed from above query, since dbd's NLI doesn't implement NOT (yet).
> john (friend at work) frank
> bob (friend at work) sam
> tom (friend at work) billy
> DBD Query: (and (select person instance *) (select * (select friend at home) (select person instance *)))
> Hopefully we can now agree that in the case
> of query formulation the RM has an advantage of your system, comparing:
I agree (and have posted as such in the past) the SQL interface for
RMDBs is much better (provides more functions) than the NLI (Natural
Language Interface) for dbd. Currently dbd's NLI doesn't implement
functions such as NOT, sum, avg, min, max, etc; and requires one to
implement them in their application by loop thru a set of things
returned by high-level queries. For example, the psuedo code below
calculates the total age of all persons who are male. See
www.dbfordummies.com/example/ex004b.asp for actual sample code.
total = 0;
q1 = Expr_Process("(and (select age instance *) (select (and (select
person instance *)(select * gender male)) age *))");
while (age = Expr_Execute(q1)) {
total = total + convertToReal (age) ;
}
However as far as "basic" queries (those without sum, avg, etc), dbd's
are simpler than RMDB's once we get past non-normalized data stored in
one table as in this example so far. Making a conclusion at this point
might be premature. First note, RMDB solution only encodes half of the
bi-directional friend relationship, whereas dbd's is bi-directional.
Let's add a new data requirement and see how the existing
data/schema/query in RMDB and DBD are impacted. Suppose, there are now
two persons named Bob instead of just one. The first/original Bob owns
a Chevette (a car). The second/new Bob owns a Corvette (a car). Both
Bobs are friends (bi-directional relationship) of Sam at home. Below
shows how to update/add dbd's existing solution.
(create 'chevette 'car)
(create 'own 'verb)
(create bob own chevette)
(create 'corvette 'car)
(new 'bob 'person)
(create (it) own corvette)
(create (it) (select friend at home) sam)
OR
(create (and (select person instance *)
(select * name (word1st 'bob))
(select * own corvette))
(select friend at home)
sam)
Dbd's original data/structure is unaffected.
Dbd's orignal query to find persons who have friends at home is not
affected :
(and (select person instance *) (select * (select friend at home)
(select person instance *)))
This query now return both Bobs. If issuee via dbd's GUI, first the
node for Bob with Chevette is highlighted, click Ok, then the node for
Bob with Corvette is highlighted.
Please show how to adapt the RMDB solution to encode friend as a
bi-directional relationship and allow for two person with same name
distinguished by the car each owns.
> I also highly recommend you get a copy of "Data and Reality" by William Kent off amazon as there is some really illuminative stuff in there.
Thx, will check it out.
Neo
The above article compares CODASYL Network to RM. Dbd isn't based on
CODASYL Network, Hierarchal, MV, RM, XML, RDF, ProLog, lists, LISP or
some combination thereof. It is based on something more fundamental
that allows it to do all that the above can do but in a more general
manner, thus requiring more processing power and memory.
JOG
Sure, I was just pointing out that the same conclusions apply when it
comes to querying. I hope you can continue to have discussion in the
future as you have in the last few posts. I'd personally appreciate
less spamming (after all this was a thread about XML), and more
specific use of terms (e.g. 'can do it in a more general manner' is far
too nebulous) may get back a bit of that goodwill that has been lost -
you'll get much better response and that will help your database
journey (and its vital that you do RM/OO/etc comparisons yourself!).
One should never forget we are always learning, and that there is
always someone out there more experienced and learned than oneself.
This newsgroup is a valuable resource, and not to be neglected. Good
luck.
Keith H Duggar
> The above article compares CODASYL Network to RM. Dbd
> isn't based on CODASYL Network, Hierarchal, MV, RM, XML,
> RDF, ProLog, lists, LISP or some combination thereof. It
> is based on something more fundamental that allows it to
> do all that the above can do but in a more general manner,
> thus requiring more processing power and memory.
Still waiting for you to describe that "something more
fundamental" as clearly and concisely as lists, cons cells,
networks, hierarchies, and relations have been described by
numerous people numerous times.
It really shouldn't be so hard, why do you keep avoiding it?
And no, nobody wants to infer it from reems of lisp-like
examples. Instead state it clearly and concisely in plain
human language and/or mathematics.
It really shouldn't be so hard, why do you keep avoiding it?
Neo
>
> The above article compares CODASYL Network to RM.
In the above article, an employee/salary/dept example is used to show
that SQL for RMDB is easier than the queries for CODASYL Network Dbs.
If someone is willing, I can show that dbd's is simpler than SQL to
find specific things (vs things greater than, less than, avg of, etc)
as the example is extended to meet new data requirements. Anyone
willing to post the RM/SQL for comparision with dbd?
RMDB:
T_Emp (emp#, name, dept, salary);
Insert (123, john, finance, 100);
Insert (456, mary, safety, 200);
SELECT * FROM T_Emp WHERE (dept = safety) AND (salary = 200);
DBD:
(new 'emp#)
(new 'dept)
(new 'salary)
(new 'john 'employee)
(create (it) emp# (val+ '123))
(create (it) dept (val+ 'finance))
(create (it) salary (val+ '100))
(new 'mary 'empolyee)
(create (it) emp# (val+ '456))
(create (it) dept (val+ 'safety))
(create (it) salary (val+ '200))
(and (select employee instance *) (select * dept safety) (select *
salary 200))
Neo
λ
Jay Dee
>>Still waiting for you to describe that "something more fundamental" as clearly and concisely ...
>
>
> λ
>
Lambda? The calculus? Is that why the stuff you post is so lispy?
Clear? Nope. Concise? Yup. Correct? Don't know either what
you're trying to do or whether you've succeeded.
Marshall
> > Still waiting for you to describe that "something more fundamental" as clearly and concisely ...
>
> λ
This is a complete non-sequitur. You've never made the least
mention of lambda. Your model doesn't--
Argh! What am I doing? I'm like Charlie Brown and Neo is Lucy.
And dbd is the football.
Marshall
Keith H Duggar
> Neo wrote:
> > Keith H Duggar wrote :
> > > Still waiting for you to describe that "something more
> > > fundamental" as clearly and concisely ...
> >
>
> Lambda? The calculus? Is that why the stuff you post is so
> lispy?
Maybe he spent the last 10 years reinventing some form
(perhaps an inferior form) of a cons-cell? How sad.
> Clear? Nope.
You know, I don't think the word "clear" means what Neo
thinks it means. Other such words include "general",
"flexible", "fundamental", and "better".