Resiliency To New Data Requirements
Neo
schema/data/queries in RMDB and dbd solutions as a result of adapting
to new data requirements in one particular example. The example is
based on following article:
http://www.intelligententerprise.com/db_area/archives/1999/991105/online2.jhtml;jsessionid=4J3MNANICW05WQSNDLRCKHSCJUNN2JVN
The example models/creates/represents/stores (which is preferred?) John
and Mary who are employees. They belong to the finance and safety dept
respectively. Their salaries are 10,000 and 20,000 respectively. Note
that currently, dbd doesn't implement functions such as NOT, min, max,
avg, sum, total, etc in it's select statements so this example will be
limited to queries without them.
RMDB's initial implementation:
CREATE TABLE employee (emp#, name, dept, salary);
INSERT INTO employee VALUES (123, john, finance, 10000);
INSERT INTO employee VALUES (456, mary, safety, 20000);
// Following query returns Mary
SELECT * FROM employee WHERE (dept = "safety") AND (salary = 20000);
DBD's initial implementation:
(new '123 'emp#)
(new '456 'emp#)
(new 'finance 'dept)
(new 'safety 'dept)
(new '10000 'salary)
(new '20000 'salary)
(new 'john 'employee)
(new 'mary 'empolyee)
(create john emp# 123)
(create john dept finance)
(create john salary 10000)
(create mary emp# 456))
(create mary dept safety)
(create mary salary 20000)
(; Following query returns Mary)
(and (select employee instance *) (select * dept safety) (select *
salary 20000))
In the next post, a new data requirement (unknown initially) will be
added to see its impact on existing schema/data/query on above RMDB and
dbd solutions.
Neo
requirement is added: Each employee can be in 0 to many departments.
And add Bob, emp# 789, works in finance and personnel departments, has
a salary of 15,000.
RMDB: (schema change, transfer data, update query)
Add table named employee_dept (emp#, dept).
Move John and Mary's dept to new table employee_dept.
INSERT employee_dept (123, finance);
INSERT employee_dept (456, safety);
Remove dept field from employee table.
Add data for Bob.
INSERT employee (789, bob, 15000);
INSERT employee_dept (789, finance);
INSERT employee_dept (789, personnel);
Update original query to find Mary via table join.
SELECT employee.*
FROM employee INNER JOIN employee_dept ON employee.[emp#] =
employee_dept.[emp#]
WHERE ((employee_dept.dept)="safety") AND ((employee.salary)=20000);
DBD: (no changes, just add new data)
(new '789 'emp#)
(new '15000 'salary)
(new 'bob 'person)
(create bob emp# 789)
(create bob dept finance)
(create bob dept personnel)
(create bob salary 15000)
(; Original query still appropriate, returns Mary)
Neo
unique because Sam's emp# is also 123, works in marketing dept, has
salary 10,000.
RMDB: (schema change, update existing data)
In table employee, add field empID (autoID).
In table employee_dept, change emp# field to empID and update data.
Add data for Sam.
INSERT employee (123, sam, 10000);
INSERT employee_dept (4, marketing);
Update query to find Mary via table join on IDs.
SELECT employee.*
FROM employee INNER JOIN employee_dept ON employee.empID =
employee_dept.empID
WHERE ((employee_dept.dept)="safety") AND ((employee.salary)=20000);
DBD: (no changes, add new data)
(new 'sam 'employee)
(create sam emp# 123)
(create sam dept (val+ 'marketing))
(create sam salary 10000)
(; Original query still ok, returns Mary)
Neo
department's attributes thus requiring a separate table.
RMDB:
CREATE TABLE dept (deptID, name, ...);
INSERT INTO dept (1, finance);
INSERT INTO dept (2, safety);
INSERT INTO dept (3, personnel);
INSERT INTO dept (4, marketing);
Update employee_dept table, replace field dept with deptID, update
data.
Update Query:
SELECT employee.*
FROM (employee INNER JOIN employee_dept ON employee.empID =
employee_dept.empID) INNER JOIN dept ON employee_dept.deptID =
dept.deptID
WHERE (((dept.name)="safety") AND ((employee.salary)=20000));
DBD:
No change. Original query still ok, returns Mary.
Jay Dee
(You ain't still smokin' that ditch-weed, are you, Neo?)
So, which parts of all these are the lambda analogs?
Maybe, instead of pounding in some not-quite SQL, you
could write some cons ( cdr ( ... stuff that might illustrate
what all the chicken scratching and ju-ju are doing...
A number of us are still hanging -- trying to see whether the
lights will go on -- but it's still pretty dark where I'm sitting.
Neo
The fundamental part that is an analog of lambda calculus is that dbd's
expressions consist of a function and a input which are themselves
expressions. Because adhering to this at the user level would make
useful expressions extremely long, dbd's NLI (natural language
interface) provides various shortcuts.
In dbd, users manage data via expressions. Below are some typical
expressions:
(create john like mary)
(select john like *)
(update (select john like mary) to sue)
(delete mary)
In dbd, an expression starts with a "(" and ends with a corresponding
")". Within the parentheses there can be 0 to many elements. Elements
are separated by at least one white space. A white space is a space,
tab, carriage return or line feed. The first and last elements can be
adjacent to the parentheses. Elements are themselves expressions. An
expression's first element is a function. The remaining elements are
function inputs. An input is optional, if documentation shows it
surrounded by square brackets. Once an optional input is omitted,
remaining inputs cannot be specified. Functions that accept a variable
number of inputs are indicated via three dots. The general format of an
expression is:
(function input1 input2 input3 ...)
Expression Shorthands:
Expressions are frequently specified by their shorthand. Shorthands for
a string, a word and a named thing are described below:
The expression for the string john is (select 'j 'o 'h 'n). Its
shorthands are (str 'john) or simply 'john.
The expression for the word john is (and (select word instance *)
(select * symbolizedBy (select 'j 'o 'h 'n)). Its shorthand is either
(word1st 'john) or (word+ 'john). In dbd, word refers to that which is
spoken, not that which is written. Words are symbolized by a symbol or
more typically a string of symbols. This allows a word to be symbolized
in multiple languages and have multiple spellings.
The expression for a unique thing named john is approximately:
(select * name (and (select word instance *)
(select * symbolizedBy (select 'j 'o 'h 'n))))
The shorthand for this long expression is (. 'john) or simply john.
The expression for a unique thing named john b smith is (. 'john 'b
'smith). In dbd, things are named by words, not strings.
If a thing's name is not unique, refer to it via an expression such as:
(and (select person instance *)
(select * name (word1st 'john))
(select * age 28))
Thus in above section, the expression (create john like mary) is
actually a shorthand for the following:
((. 'create) (. 'john) (. 'like) (. 'mary))
or expanded even further:
(
(and (select function instance *)
(select * name (and (select word instance *)
(select * symbolizedBy (select 's 'e 'l 'e 'c 't))))
(select * name (and (select word instance *)
(select * symbolizedBy (select 'j 'o 'h 'n))))
(select * name (and (select word instance *)
(select * symbolizedBy (select 'l 'i 'k 'e))))
(select * name (and (select word instance *)
(select * symbolizedBy (select 'm 'a 'r 'y))))
)
Neo
Ok, we can do this by extending 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 roughly equivalent script:
(new 'bob 'sage)
(new 'jayDee 'sage)
(new 'neo 'jerk)
(new 'on 'state)
(new 'off 'state)
(create bob state on)
(create neo state off)
Now JayDee, could you to extend your initial example to match dbd's
extension below:
(; Find bob's relationship to sage)
(; Finds class)
(select bob * sage)
(; Find sage's relationship to 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)
(; Note: the verb/relator opposite already exists in db)
(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 *))
Note: currently, dbd doesn't implement functions such as NOT, min, max,
avg, sum, total, etc in it's select statements thus examples are
Marshall
>
> In dbd, an expression starts with a "(" and ends with a corresponding
> ")". Within the parentheses there can be 0 to many elements. Elements
> are separated by at least one white space. A white space is a space,
> tab, carriage return or line feed. The first and last elements can be
> adjacent to the parentheses. Elements are themselves expressions. An
> expression's first element is a function. The remaining elements are
> function inputs. An input is optional, if documentation shows it
> surrounded by square brackets. Once an optional input is omitted,
> remaining inputs cannot be specified. Functions that accept a variable
> number of inputs are indicated via three dots. The general format of an
> expression is:
>
> (function input1 input2 input3 ...)
This is actually a pretty good paragraph, in that it explains a lot and
is quite clear. This is the sort of thing that I generally find missing
from
your posts, and the lack generally makes it impossible for me to
follow what you're trying to say. Often your posts are almost nothing
but example dbd scripts with only the most vague description of what
they're supposed to do, and there's no way for me to connect the dots.
But there's still a lot missing, specifically semantics. What exactly
do new, select, create, update, delete do? (I think I've got 'and'
figured
out, though.) What kind of scope do symbols have?
> The expression for the word john is (and (select word instance *)
> (select * symbolizedBy (select 'j 'o 'h 'n)). Its shorthand is either
> (word1st 'john) or (word+ 'john). In dbd, word refers to that which is
> spoken, not that which is written. Words are symbolized by a symbol or
> more typically a string of symbols. This allows a word to be symbolized
> in multiple languages and have multiple spellings.
I couldn't really follow this.
Marshall
Jay Dee
>>... illustrate what all the chicken scratching and ju-ju are doing...
I read the previous post...
>
> Ok, we can do this by extending 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 roughly equivalent script:
> (new 'bob 'sage)
> (new 'jayDee 'sage)
> (new 'neo 'jerk)
>
> (new 'on 'state)
> (new 'off 'state)
>
> (create bob state on)
> (create neo state off)
...and recognize that that these are expressions comprised
elements; new and create are functions and everything else
is an input. But I really don't know what the results of
those functions are. Are the, perhaps, operations that
have no results? I don't know. (I might have convinced
myself that I knew enough about what create and new did
in order to follow along, but when they're both necessary:
I'm confused.)
> Now JayDee, could you to extend your initial example to match dbd's
> extension below:
>
> (; Find bob's relationship to sage)
> (; Finds class)
> (select bob * sage)
>
> (; Find sage's relationship to bob)
> (; Finds instance)
> (select sage * bob)
See, the train really leaves the tracks here: what
are those stars? (let along, what is that function?)
> (; Represent that classifications sages and jerks are opposites)
> (new 'opposite 'verb)
> (create sage opposite jerk)
> (create jerk opposite sage)
Say, what? Again with the new and create. And, from
previous posts, I remember that verbs are relators; is
verb a magic word? Why were there no (new 'sage 'adj)
and (new 'jerk 'adj) and (new 'state 'noun) above?
Do expect me to code
var opposite real relation {this char, that char} key {this, that} ;
opposite += relation {
tuple {this 'sage', that 'jerk},
tuple {this 'jerk', that 'sage'} } ;
Well, I won't. The values in such a relation correspond
to the names of relation variables. [When does a design
become self-aware? What critical threshold must be
surpassed? Yes, you in the back; Seamode, is it?]
And I don't expect the database to know that
something is "opposite" of something. Tuples
represent things that are different simply because
they're different and relations represent sets of
things that are different simply because they're
different. The database can keep up with that
and can find various values that are the same
or different. But whether they're antonyms,
homonyms, synonyms, or Christmas hymns doesn't have
anything to do with what the database can deduce.
> (; Find things whose classification is opposite of neo's)
> (; Finds bob and jayDee)
> (select (select (select neo class *) opposite *) instance *)
Class? Instance?
>
> (; Represent that states on and off are opposites)
> (; Note: the verb/relator opposite already exists in db)
[See, I got that part right!]
> (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 *))
And here the train plunges into the abyss. I parse this as
an expression comprised of the elements:
^ the function select and three inputs
^ a magic star
^ a noun
^ an expression comprised of
^ the function select and three inputs
^ an expression...
^ a verb
^
but I have no way to interpret this.
Lets back up:
nouns are _____.
verbs are _____.
adjectives are _____.
function new takes two inputs and does _____.
function create takes three inputs and does _____ yielding _____.
function select takes three inputs and does _____ yielding _____.
stars mean _____.
Keith H Duggar
> But there's still a lot missing, specifically
> semantics. What exactly do new, select, create, update,
> delete do? (I think I've got 'and' figured out, though.)
> What kind of scope do symbols have?
Jay Dee wrote :
> But I really don't know what the results of those
> functions are. Are the, perhaps, operations that have no
> results? ...
Neo has repeatedly been asked precisely these same questions
in a variety of ways and every time has refused or remains
unable to provide /actual/ answers. He often responds with
troll-like behavior: referencing irrelevant material as in
his direction to the "IDJIT" thread, responding with skew
lines and tangents, responding with wanna-be-erudite false-
pith like "lambda", etc. If it weren't for his website,
examples, etc he could easily be dismissed as a simple
troll. The presence of that material either makes him an
Elite Troll or a demi-crank of some kind.
His reluctance to answer "what" probably points to it being
a disguised rehash of network or entity-relationship models
or similar. But Neo is afraid if he comes out and honestly,
plainly states this fact nobody will pay attention to him
any longer. Below I'm quoting two of my posts in a previous
thread Neo hijacked that are directly on point.
Neo wrote:
> 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.
paul c wrote:
> Neo wrote:
> > 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.
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.
-- Keith -- Fraud 6 --
Marshall
> Marshall wrote :
> > But there's still a lot missing, specifically
> > semantics. What exactly do new, select, create, update,
> > delete do? (I think I've got 'and' figured out, though.)
> > What kind of scope do symbols have?
>
> Jay Dee wrote :
> > But I really don't know what the results of those
> > functions are. Are the, perhaps, operations that have no
> > results? ...
>
> Neo has repeatedly been asked precisely these same questions
> in a variety of ways and every time has refused or remains
> unable to provide /actual/ answers.
Yes, in fact Neo has been with us for a number of years now.
> He often responds with
> troll-like behavior: referencing irrelevant material as in
> his direction to the "IDJIT" thread, responding with skew
> lines and tangents, responding with wanna-be-erudite false-
> pith like "lambda", etc.
Yah, and in fact I think he's gotta be getting something of
a persecution complex by now.
> If it weren't for his website,
> examples, etc he could easily be dismissed as a simple
> troll. The presence of that material either makes him an
> Elite Troll or a demi-crank of some kind.
Nice terms! I'm going to vote for demi-crank.
Troll to me denotes that someone who is not actually arguing
in good faith; that is, they don't even themselves believe
what they are saying, being motivated instead entirely
from the effect of what they say. I don't believe Neo falls
in to that category; I think he really does believe what he's
saying. Unfortunately he has seized upon a number of ideas
that are not particularly justified, such as the insufficiency
of first order logic for some particular, unspecified task.
And the fact that he has lots of requirements but he can't
say what they specifically are, and that he has lots of
solutions but he can't say specifically what they are either,
moves him in to crank territory. But Neo does actually
come up with ideas, and he does actually make progress
over time, so maybe "demi-crank" is actually pretty good.
> His reluctance to answer "what" probably points to it being
> a disguised rehash of network or entity-relationship models
> or similar. But Neo is afraid if he comes out and honestly,
> plainly states this fact nobody will pay attention to him
> any longer.
I suppose that's possible, but I'm more inclined to think that
he's actually unable to state those things clearly. I think he's
kind of bit off more than he can chew, in that he seems to
be going for a solution that's AI-complete.
Marshall
Neo
I don't believe I have made assertions about first order logic.
Currently, I have no assertions to make about first order logic.
Neo
Something similar to what create, select, insert, update and delete do
in RMDBs. Documentation for various functions is available via
www.dbfordummies.com/NLI/function.asp
For example the following dbd and SQL psuedo scripts are roughly
equivalent:
(new)
(create person instance (it))
(create (it) name (word+ 'john))
(create (it) age (val+ '28))
INSERT INTO T_Person (
(SELECT wordID FROM T_Word WHERE string = "john"),
(SELECT ageID FROM T_Age WHERE value = 28));
Assuming CREATE TABLE T_Person (auto personID, nameID, ageID);
> What kind of scope do symbols have?
I don't understand your question. I am familiar with the concept of a
variable having a scope within a block, a function, a module and an
application. In dbd, symbols are modelled the same as John and Mary.
What scope do John and Mary have in RMDBs?
> > The expression for the word john is ...
>
> I couldn't really follow this.
In dbd, the following are different things: string john, word john and
person john. Various expressions specify each and the relationship
between them.
Neo
> > (new 'on 'state)
> > (create bob state on)
>
> ... I really don't know what the results of those functions are.
In breif, new creates a new thing (node if you prefer) in the db to
represent desired thing (ie bob, jayDee, neo, on, off, etc). In breif,
create function creates a sentence using things that already exist in
the db. A sentence indicates a relationship between things. In dbd, a
sentence itself is a thing, thus it can be used in subsequent
sentences.
Below is a more complete description of the new function from website:
Description:
The new function creates a new thing in the db.
User calls the new function to represent desired thing (ie john, mary).
General Format:
(new ['name] ['class1] ['class2] ...)
where:
The first input names the new thing.
The second and remaining inputs specify the new thing's classes.
If the specified classes do not exist, they is added and related as
items of the class directory.
Examples:
(new)
(new 'john)
(new 'mary 'person)
(new 'bob 'person 'doctor)
The expression (new 'mary 'person) is shorthand for following, assuming
the class person did not already exist:
(create (new) name (word+ 'mary))
(create (new) name (word+ 'person))
(create mary class person)
(create person instance mary)
(create clsDir item person)
> > (; Find sage's relationship to bob)
> > (; Finds instance)
> > (select sage * bob)
>
> See, the train really leaves the tracks here:
> what are those stars? (let along, what is that function?)
To understand, one needs to realize that the shorthand expression (new
'bob 'sage) earlier in the script included the expression (create sage
instance bob). Thus query expression (select sage * bob) returns
instance. Would any of the following alternate syntaxes be preferrable?
(select* sage * bob)
(select sage ? bob)
(select? sage ? bob)
(find sage ? bob)
(find? sage ? bob)
(get sage ? bob)
(get? sage ? bob)
> > (; Represent that classifications sages and jerks are opposites)
> > (new 'opposite 'verb)
> > (create sage opposite jerk)
> > (create jerk opposite sage)
>
> Say, what? Again with the new and create.
Same explanation of new and create functions above.
> And, from previous posts, I remember that verbs are relators;
In dbd, verb and relator are roughly equivalent.
> is verb a magic word?
No, but it is part of system data, meaning dbd added it in the db when
the db was first initialized. www.dbfordummies.com/basic/SysData.asp
> Why were there no (new 'sage 'adj) and (new 'jerk 'adj) ...
Because, I interpretted sage and jerk as classifictions of jayDee, bob
and neo rather than as adjectives based on Tutorial D example.
> ... and (new 'state 'noun) above?
Because I didn't see state classified as a noun in Tutorial D example.
> Do [you?] expect me to code:
> var opposite real relation {this char, that char} key {this, that} ;
> opposite += relation {
> tuple {this 'sage', that 'jerk},
> tuple {this 'jerk', that 'sage'} } ;
>
> Well, I won't. The values in such a relation correspond to the names of relation variables.
Ok, but I would still like to see Tutorial D's script to match dbd's
extension of original example.
> [When does a design become self-aware? What critical threshold must be surpassed? Yes, you in the back; Seamode, is it?]
Hofstadter ponders the same point in his book "Gödel, Escher, Bach: an
Eternal Golden Braid".
> ... But whether [sage and jerk are] antonyms ... doesn't have anything to do with what the database can deduce.
Ok, but I would still like to see Tutorial D's script to match dbd's
extension of original example.
> > (; Find things whose classification is opposite of neo's)
> > (; Finds bob and jayDee)
> > (select (select (select neo class *) opposite *) instance *)
>
> Class? Instance?
See expanded expressions for the new function above. The shorthand
expression (new 'neo 'jerk) expands to include the expressions (create
jerk instance neo), (create neo class jerk), etc.
> > (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 *))
>
> And here the train plunges into the abyss. I parse this as
> an expression comprised of the elements:
> ^ the function select and three inputs
> ^ a magic star
> ^ a noun
> ^ an expression comprised of
> ^ the function select and three inputs
> ^ an expression...
> ^ a verb
> ^
>
> but I have no way to interpret this.
One way to interpret the above dbd query is:
(select * state X1) where X1 is (select X2 opposite *) where X2 is
(select neo state *)
above simplifies to:
(select * state X1) where X1 is (select X2 opposite *) where X2 is off
above simplifies to:
(select * state X1) where X1 is (select off opposite *)
above simplifies to:
(select * state X1) where X1 is on
above simplifies to:
(select * state on)
above simplifies to:
bob
> Lets back up:
> nouns are _____.
Things.
> verbs are _____.
Things.
> adjectives are _____.
Things.
> function new takes two inputs and does _____.
The new function can take 0 to many inputs, see above. It create a
thing in the db to represent desired thing (ie jayDee, bob, neo, etc).
> function create takes three inputs and does _____ yielding _____.
The create function can take 2 to many inputs and yields a sentence
that represents the relationship between them.
> function select takes three inputs and does _____ yielding _____.
The select function can take 1 to many inputs. It normally returns the
specified sentence. If one of the inputs is an asterisk, it return the
thing in that position of the sentence.
> stars mean _____.
The asterisk lets the select function know which element of sentence to
find/select/get.
Some of the above questions are answered in the following two areas of
website:
www.dbfordummies.com/basic/thing.asp
www.dbfordummies.com/NLI/default.asp
Jay Dee
[and did some heavy-handed snipping...]
>>Why were there no (new 'sage 'adj) and (new 'jerk 'adj) ...
>
> Because, I interpretted sage and jerk as classifictions of jayDee, bob
> and neo rather than as adjectives based on Tutorial D example.
>> ... and (new 'state 'noun) above?
>
> Because I didn't see state classified as a noun in Tutorial D example.
>>Do [you?] expect me to code:
>>var opposite real relation {this char, that char} key {this, that} ;
>>opposite += relation {
>> tuple {this 'sage', that 'jerk},
>> tuple {this 'jerk', that 'sage'} } ;
>>
>>Well, I won't. The values in such a relation correspond to the names of relation variables.
> Ok, but I would still like to see Tutorial D's script to match dbd's
> extension of original example.
>>[When does a design become self-aware? What critical threshold must be surpassed? Yes, you in the back; Seamode, is it?]
> Hofstadter ponders the same point in his book "Gödel, Escher, Bach: an
> Eternal Golden Braid".
>>... But whether [sage and jerk are] antonyms ... doesn't have anything to do with what the database can deduce.
> Ok, but I would still like to see Tutorial D's script to match dbd's
> extension of original example.
And we've arrived at an impasse: you're interpreted a design,
decided that some attributes are "classifications" rather than
"adjectives" and that others are not "nouns" and cobbled
together a dbd design that represents your reinterpretation
of whatever it was being represented.
In fact, you're seem to have created an admixture of attributes
and values that I can't follow.
Consequently, there's no way that (i) you can call the dbd
design an extension of the Tut D design or (ii) I can present a
Tut D equivalent for what you've put together, irregardless of
the fact that I can't seem to understand your explanations of
what it is you've created. It all seems to be horribly confused
and lacking coherence.
Sorry; I don't think I can help you.
[snip]
Neo
That task has been to find the most general method of representing
things.
> ... seems to be going for a solution that's AI-complete.
It turns out that the most general method of representing things is
resilient to new data requirements and applicable to AI-type
applications.
Marshall
> > [Neo] has seized upon a number of ideas ... for some particular, unspecified task.
>
> That task has been to find the most general method of representing
> things.
Answering that question is easy. The most general method of
representing things is to use bits.
All that remains is the matter of filling in the details. Some of
the first details that should be filled in would be a specification
of what exactly "generality" means with regards to "representing"
"things." Until there *is* such a specification, I assert that the
particular task you are trying to solve is unspecified.
Marshall
Neo
Ok, so you are saying that I mis-interpretted sage and jerk in the
Tutorial D script (shown below) as being classifications and that they
are in fact adjectives of Bob/JayDee and Neo, respectively.
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' } } ;
> ... and that others are not "nouns" ...
Dbd's implemention didn't represent state as being or not being nouns
as neither was explicit in the Tutorial D script shown below:
var state real relation { name char, state char } key { name } ;
state += relation {tuple { name 'Bob', state 'on' },
tuple { name 'Neo', state 'off' } } ;
> ... and cobbled together a dbd design that represents your reinterpretation of whatever it was being represented.
If you would like, I can redo the dbd's implementation with the correct
interpretation although I am still unclear if you wanted state to be
classified as a noun or not as a noun or neither.
Bob Badour
> Neo wrote:
>
>>>[Neo] has seized upon a number of ideas ... for some particular, unspecified task.
>>
>>That task has been to find the most general method of representing
>>things.
>
> Answering that question is easy. The most general method of
> representing things is to use bits.
There is a more general method, which is to use sets. See formalism as a
foundation of mathematics.
{} is the canonical set with zero elements and represents zero or false
{{}} is the canonical set with one element and represents one or true
{{},{{}}} is the canonical set with two elements etc.
> All that remains is the matter of filling in the details.
Indeed. One can keep filling in the details forever thinking one is
making wonderful progress. That is until Goedel comes along and spoils
the party by telling one that one will never reach a destination.
Some of
> the first details that should be filled in would be a specification
> of what exactly "generality" means with regards to "representing"
> "things." Until there *is* such a specification, I assert that the
> particular task you are trying to solve is unspecified.
A far more important question to ask is: What does it do? A
representation is not worth much if it doesn't do much.
Neo
If this is true, why don't data models (ie hierarchal, relational, etc)
mention bits?
> All that remains is the matter of filling in the details. Some of the first details that should be filled in would be a specification of what exactly "generality" means with regards to "representing" "things." Until there *is* such a specification, I assert that the particular task you are trying to solve is unspecified.
Would you consider the relational method of representing things to be
more general than the hierarchal method? If so, why?
Marshall
> Marshall wrote:
>
> > All that remains is the matter of filling in the details.
>
> Indeed. One can keep filling in the details forever thinking one is
> making wonderful progress. That is until Goedel comes along and spoils
> the party by telling one that one will never reach a destination.
That Goedel guy is a bastard. Other party poopers include
Russel and Girard with their paradoxes. <mutter>Think they're
so smart.</mutter>
> Some of
> > the first details that should be filled in would be a specification
> > of what exactly "generality" means with regards to "representing"
> > "things." Until there *is* such a specification, I assert that the
> > particular task you are trying to solve is unspecified.
>
> A far more important question to ask is: What does it do? A
> representation is not worth much if it doesn't do much.
Indeed. I might be somewhat bold and propose there is a
canonical order in which the issues seem to get addressed.
Structure first, then querying, then manipulation, then integrity.
Most do not get past the first step.
Marshall
Marshall
> > The most general method of representing things is to use bits.
>
> If this is true, why don't data models (ie hierarchal, relational, etc)
> mention bits?
Because they've filled in the details.
> > Some of the first details that should be filled in would be a
> > specification of what exactly "generality" means with regards
> > to "representing" "things." Until there *is* such a specification,
> > I assert that the particular task you are trying to solve is unspecified.
>
> Would you consider the relational method of representing things to be
> more general than the hierarchal method? If so, why?
Yes, I would. Hierarchies only allow one to use a single organizational
scheme; relations allow as many as are necessary. In fact, if you
follow the normal forms, the organization scheme is complete abstracted
from the structure of the data itself and becomes an attribute of
particular queries instead.
Another difference: hierarchies have only the single way of indicating
a relationship between two kinds of things, which is placing them in
adjacent levels in the hierarchy ("containment".) This is sufficient
for modelling many-to-one relationships, but fails at many-to-many
relationships. Relations have no trouble with many-to-many
relationships.
In fact, it was exactly this surprising quality of relations that
pierecd
my OOP-smug-shield and made me pay attention to them.
Marshall
Neo
> > more general than the hierarchal method? If so, why?
>
> Yes, I would. Hierarchies only allow one to use a single organizational
>
> Another difference: hierarchies have only the single way of indicating
> Relations have no trouble with many-to-many relationships.
Would you say, it is impossible to represent, query, manage, etc some
data with one particular data model (ie hierarchal) vs another (ie
relational)?
Keith H Duggar
> Marshall wrote:
>
> > Neo wrote:
> >
> >>>[Neo] has seized upon a number of ideas ... for some particular, unspecified task.
> >>
> >>That task has been to find the most general method of representing
> >>things.
> >
> > Answering that question is easy. The most general method of
> > representing things is to use bits.
>
> There is a more general method, which is to use sets. See formalism as a
> foundation of mathematics.
>
> {} is the canonical set with zero elements and represents zero or false
> {{}} is the canonical set with one element and represents one or true
> {{},{{}}} is the canonical set with two elements etc.
I would have said the "most general way of representing
things" is a sequence of symbols from an alphabet. Of which
{}, {{}}, {{}{{}}}, along with the characters I'm using now
to represent English, predicate logic, etc are all examples.
If you limit the alphabet to only two symbols 0 and 1 then
you have binary sequences.
Bob Badour
Ah, now we are getting into the representations of our representations.
My suggestion for most general uses only a single concept: set. Yours
uses three concepts: 0, 1 and sequence.
JOG
I miss my OOP-smug-shield. I felt like batfink, with my wings of steel.
After examining set theory and how to apply it to information, it turns
out they were made of tissue paper after all.
>
>
> Marshall
Neo
The general form of the following Tutorial D script ...
sage += relation {tuple { name 'Bob' };
jerk += relation {tuple { name 'Neo' } } ;
state += relation {tuple { name 'Bob', state 'on' }, ... } ;
... seems to be:
X1 += relation { tuple{...}, ... };
In general, how would an application (ie an andriod) know to interpret
X1 as an adjective (vs a class) in some cases and a noun in others
cases?
Marshall
> Marshall wrote:
>
> > In fact, it was exactly this surprising quality of relations that
> > pierecd my OOP-smug-shield and made me pay attention to them.
>
> I miss my OOP-smug-shield. I felt like batfink, with my wings of steel.
> After examining set theory and how to apply it to information, it turns
> out they were made of tissue paper after all.
Yes, it kept me warm at night. Turns out though it was the same
warmth you get from cheap malt liquor.
Marshall
Neo
Are RMDBs and dbd subject to Godel's Incompletenes Theorem which says
something like:
"For any consistent formal theory that proves basic arithmetical
truths, it is possible to construct an arithmetical statement that is
true but not provable in the theory. That is, any consistent theory of
a certain expressive strength is incomplete."
If so, what is a simple way to demonstate this in RMDBs and dbd.
Neo
In my search for the most general method of representing things, it
appears I may have re-invented via trial and error what is essentially
the basic part of lambda calculus and set theory. What lambda calculus
calls expression, and what set theory calls set, is what I have been
calling thing. Thing is the general form of all things.
You say tomahto (set), I say tomato (thing). I choose thing because in
layman's language we say "a chair is a thing", "a car is a thing";
while in set-theory language we could say "a chair is a set", "a car is
a set".
Some may find this old post amusing:
http://groups.google.com/group/comp.databases/browse_frm/thread/e460c14f722d89a9/0e3faf55b19f9077?lnk=gst&q=%22everything+is+a+thing%22&rnum=3#0e3faf55b19f9077
So it may turn out that we are all partially blind and groping the very
same elephant (thing/set/expression).
The Blind Men and the Elephant by John Godfrey Saxe (1816-1887)
It was six men of Indostan
To learning much inclined,
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind
The First approached the Elephant,
And happening to fall
Against his broad and sturdy side,
At once began to bawl:
God bless me! but the Elephant
Is very like a wall!
The Second, feeling of the tusk,
Cried, Ho! what have we here
So very round and smooth and sharp?
To me tis mighty clear
This wonder of an Elephant
Is very like a spear!
The Third approached the animal,
And happening to take
The squirming trunk within his hands,
Thus boldly up and spake:
I see, quoth he, the Elephant
Is very like a snake!
The Fourth reached out an eager hand,
And felt about the knee.
What most this wondrous beast is like
Is mighty plain, quoth he;
'Tis clear enough the Elephant
Is very like a tree!
The Fifth, who chanced to touch the ear,
Said: Even the blindest man
Can tell what this resembles most;
Deny the fact who can
This marvel of an Elephant
Is very like a fan!?
The Sixth no sooner had begun
About the beast to grope,
Than, seizing on the swinging tail
That fell within his scope,
I see, quoth he, the Elephant
Is very like a rope!
And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!
Moral:
So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!
David Cressey
"Neo" <neo5...@hotmail.com> wrote in message
news:1154968099.2...@i42g2000cwa.googlegroups.com...
> > My suggestion for most general uses only a single concept: set.
>
> In my search for the most general method of representing things, it
> appears I may have re-invented via trial and error what is essentially
> the basic part of lambda calculus and set theory. What lambda calculus
> calls expression, and what set theory calls set, is what I have been
> calling thing. Thing is the general form of all things.
My sweet lord!
Neo has discovered that everything is a thing! This seems to be the
ultimate "theory of everything" (T.O.E.)
BTW, for those of you who have found Neo's writings fairly opaque, let me
suggest that it's because he only shows you his interface, and not his
underlying implementation.
I expect that, when he finally gets around to showing us his
implementation, he'll tell us that the whole thing is implemented in a
single line of source code! I forget his syntax, but the one line
implementation will look like this:
{new 'dbd 'database_server}
And system does the rest!
(just kidding, Neo).
Keith H Duggar
> Keith H Duggar wrote:
> > Bob Badour wrote:
> > > Marshall wrote :
> > > > Neo wrote :
> > > > > of representing things.
> > > >
> > > > Answering that question is easy. The most general
> > > > method of representing things is to use bits.
> > >
> > > There is a more general method, which is to use
> > > sets. See formalism as a foundation of mathematics.
> > >
> > > {} is the canonical set with zero elements and represents zero or false
> > > {{}} is the canonical set with one element and represents one or true
> > > {{},{{}}} is the canonical set with two elements etc.
> >
> > I would have said the "most general way of representing
> > things" is a sequence of symbols from an alphabet. Of
> > which {}, {{}}, {{}{{}}}, along with the characters I'm
> > using now to represent English, predicate logic, etc are
> > all examples. If you limit the alphabet to only two
> > symbols 0 and 1 then you have binary sequences.
>
> Ah, now we are getting into the representations of our
> representations. My suggestion for most general uses only
> a single concept: set. Yours uses three concepts: 0, 1 and
> sequence.
(since similar discussions frequently crop up in sci.logic a
cross-post might get some interesting input.)
My suggestions for the most general uses only a single
concept: language. Yours uses three concepts: set, element,
and zero. :-)
Seriously, giving a concept a name (set for example) doesn't
make it more or less singular. Determining the singularity
of concepts is notoriously difficult. Surely you are aware
that the set concept is often argued and many attempts are
regularly made to provide a correct and complete definition.
The "element" language you used seems to indicate a concept
of "set" as a collection of elements with the collection
regarded as a whole or in Cantor's words "Any collection
into a whole M of definite and separate objects m of our
intuition or our thought."
Thus, there are in fact two concepts in this concept of set:
element and aggregate. The concept of aggregate or wholeness
being necessary to distinguish {{}}, {{},{}}, etc from {}
for example. Furthermore, you can't get very far without at
the additional concept of the empty set (or the concept of
zero, nothing, etc) or ur-elements or some other atoms.
So you chose element, collection, and zero, while I chose 0,
1, and sequence. Which seem equally simple, no? No, I admit
to also seeing sets as somehow "more simple". Partly because
the concept of collection seems more simple than sequence
obviously because collection lacks order. Though as natural
as order is to humans perhaps the sequence concept does
not add much if any "conceptual" complexity.
Alas, the question was of "generality" not simplicity. And
I've never seen set theory represented without the use of
sequences of symbols ;-) (Loaded statement of course.)
Bob Badour
> "Neo" <neo5...@hotmail.com> wrote in message
> news:1154968099.2...@i42g2000cwa.googlegroups.com...
>
>>>My suggestion for most general uses only a single concept: set.
>>
>>In my search for the most general method of representing things, it
>>appears I may have re-invented via trial and error what is essentially
>>the basic part of lambda calculus and set theory. What lambda calculus
>>calls expression, and what set theory calls set, is what I have been
>>calling thing. Thing is the general form of all things.
>
> My sweet lord!
>
> Neo has discovered that everything is a thing! This seems to be the
> ultimate "theory of everything" (T.O.E.)
Don't you mean the BIG theory of everything? (BIG T.O.E. ?)
Bob Badour
Of course. ;-)
J M Davitt
[snip]
> (since similar discussions frequently crop up in sci.logic a
> cross-post might get some interesting input.)
Now you've done it! Next thing you know, Douglas
Eagleson will be pissing in our pond!
Nice shot, No. 6.
Keith H Duggar
> Some may find this old post amusing:
> http://groups.google.com/group/comp.databases/browse_frm/thread/e460c14f722d89a9/0e3faf55b19f9077?lnk=gst&q=%22everything+is+a+thing%22&rnum=3#0e3faf55b19f9077
Yes, I found the post very amusing. I had discovered it a
few days ago in a search to learn more about you to decide
for myself whether you are a troll or a demi-crank. In fact,
I wrote a post that began with:
------
Whoa! You can learn all you need to know about Neo and his
DBD by reading some of his 2002 and 2003 posts.
>From his first announcement
"ANN: XDb"
and his meteoric rise from fundamental ignorance of relations
"General Form of Relationships?"
to a vociferously ignorant "expertise" in only 2 months
"ANN: XDb for AI (Asymmetric Irrationality) Applications"
generating a 300+ post alternating Neo/BB exchange ...
------
Alas, I decided the rest of the post was unkind and in a
moment of weakness or perhaps mercy decided not to post any
of it. However, the point of your "meteoric rise to VI
expertise" given above is, I believe, a valid one.
You see, Neo, for at least the last 10,000 years, human
beings have been intelligent. And those alive today are no
more intelligent than their ancestors. In my experience it
is very common, however, for many humans, out of their shear
ignorance and unmitigated arrogance, to dismiss their
predecessors as less intelligent; and, to dismiss what they
"think" or "feel" them to have thought or done as inferior
in every way.
This is why archaeologists are continually surprised by
discoveries such as the Antikythera mechanism, Han Dynasty
Jade burial suits, terra preta, Roman mining pumps, Machu
Picchu, etc, etc, etc. Because they underestimated ancient
cultures, even to point of arrogantly dismissing firsthand
accounts as "myths".
This is why if you read some medieval fight books, you would
probably be shocked at how deeply and carefully they thought
about mortal combat. This is why there is no such thing as a
"secret punch" that only a select few ju ju monks know but
that you, Neo, can learn for $39.95.
This is why Dawn writes articles with arrogant titles like
"Is Codd Dead?" and makes derisive comments about work that
long preceded her intellectual capacity to comprehend it.
This is why many are almost entirely ignorant of material
that isn't in Wikipedia or Google.
This is why you, Neo, entering a study explored by thousands
before you yet knowing almost nothing of the corpus they
produced, will eventually realize they were not all idiots
who missed something as easy as binary relations or Lambda.
And why if you want to contribute something original and
useful, you should drop the arrogant ignorance and at least
master prior art before going ape-shit.
J M Davitt
> Neo wrote:
>
>>Some may find this old post amusing:
>>http://groups.google.com/group/comp.databases/browse_frm/thread/e460c14f722d89a9/0e3faf55b19f9077?lnk=gst&q=%22everything+is+a+thing%22&rnum=3#0e3faf55b19f9077
>
>
> Yes, I found the post very amusing. I had discovered it a
> few days ago in a search to learn more about you to decide
> for myself whether you are a troll or a demi-crank. In fact,
> I wrote a post that began with:
I followed the link. Wowzers! "From a tiny seed..." &c.
You know, I've often thought that running into Neo -
towards the end of a night of drinking, in a bar where
the amateurs don't flock and you have a chance to hear
what others are saying - might be a memorable experience.
He is, no doubt, energized and focused; he has a deep
passion for whatever it is he's pursuing. He reminds
me of someone I knew, years ago, who could see the wind
and spent most of each day watching the wind as it
crossed the road, traveled through fields, turned left
(or right) at the tree line, then meandered about, almost
lost, before deciding upon a new direction and gathering
itself up in a rush to a new destination. Unfortunately,
his father was court-appointed guardian and took charge
of the check that the government sent every month --
paying his rent, buying his clothes, and mailing him
five dollars every day. Any more than that at one time
would simply result in another overdose of a psychoactive
substance. I always wondered, "How could you tell?"
(The "perfect vacuum is an ocean of ones" and the "black
hole is an ocean of all zeroes where data [are]
propagated...to zeroes" reminded me of the wind watcher,
in case you're wondering.)
dawn
<snip>
>
> "Is Codd Dead?" and makes derisive comments about work that
> long preceded her intellectual capacity to comprehend it.
Is there really a need to bring me into this and trash me, Keith? The
title of the blog was all about marketing, brother. Time did Ok with
the original "Is God Dead?" and how else was a girl sittin' in the
middle of the corn fields not connected to any large corporations gonna
get thousands of readers for the launch of her blog?
To your point, don't forget, I'm definitely working with information
that pre-dates me. MultiValued databases pre-date 1NF. I'm definitely
not diss'ing the relational model like the RM-advocates have trashed
the models that came before it (even though they seemed to have ZERO
emperical data to prove their point). So your history lesson (which I
see I snipped) is not all that relevant. Additionally, I work from this
angle -- the quote I keep around from George Bernard Shaw
"The reasonable man adapts himself to the world: the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man."
(I do the translation on the pronouns.)
In spite of being a reader in a variety of subjects, I have no problem
stating clearly that I am ignorant of many things (unlike some on this
list who seem to think they are all-knowing). What really irks some
people is that they know that I really do understand enough about set
theory and predicate logic to know why Codd came up with normalization
(as originally defined) in the first place. I really do have a modicum
of intelligence and capability, even if there are greater minds than
mine in this forum.
I'm an end-user of DBMS tools (often an end-end-user) and they simply
need to work better, so I want them to adapt to me, Al Franken, because
I want progress. They need to be more flexible. They need to permit
developers to specify data structures such as lists and, generally, to
model data in a way that is more flexible for software development and
maintenance over time. Lists can be defined in set theory too, by the
way. There is nothing evil about them (I taught Godel's theorem,
including the proof of it, once upon a time, so don't snow me with
that) and they are useful.
In theory lists can now be defined with user-defined domains in the RM,
but they are not integral to the RM "data model" and I want them in any
"data model" I use for typical DB101 applications. Why not? Whatever
the hang-up is, get over it. It was proven useful before Codd to
employ them and it is still useful to model "property lists" as
multivalued attributes. Many developers do it all the time in software
applications today. For a couple of decades many felt guilty about not
"normalizing" their data, but that isn't what I hear today. NF2
(Non-first-normal-form) and 2VL (two-valued logic) data modeling is on
an upward trend. It is time to ditch The Information Principle."
However ignorant (sure) or arrogant (you don't know me then) you think
I am, I don't waste my time writing about how others are less
intelligent, more arrogant, or more ignorant than I (I do waste time on
some reality shows, however, and I'm watching Jon Stewart right now,
but that is surely not a waste of time, right?). Instead, I have a
"hobby" of trying to make a small difference in an area that I think
needs some changes in order to help software developers provide better
bang for the buck solutions.
Onward. --dawn
P.S. I figured I respond so that you didn't look like a coward
attacking someone who wasn't around to defend herself. smiles.
Jay Dee
Adjective? Class? Noun? Neo, they're variables.
What makes any variable an adjective or a noun or
an index or an accumulator or a cache or a list
or a queue or a tree or a pointer or a hash or a
_____? How would any application know what its
variables are? (Androids, I don't know about.)
Keith H Duggar
> Keith H Duggar wrote:
> > like "Is Codd Dead?" and makes derisive comments about
> > work that long preceded her intellectual capacity to
> > comprehend it.
>
> Is there really a need to bring me into this and trash me,
> Keith?
Hello Dawn,
I'm not sure what you are asking precisely. Yes, you filled
the need for an appropriate example quite nicely. You were
not the only possible example just one of several I chose.
In that sense you were not necessary but sufficient. No, I
don't think I "trashed" you but rather explained or modeled
some of your previous behavior. Hopefully that answers the
questions that underly the one asked.
> P.S. I figured I respond so that you didn't look like a
> coward attacking someone who wasn't around to defend
> herself. smiles.
Though I might appreciate the sentiment you should know
generally I'm not concerned with the personal judgments
others make. Furthermore, you had already announced your
continued presence a few weeks ago. Finally, I have some
doubts the sentiment is genuine since you used it as an
opportunity to defensively justify previous behavior and
to rant about topics having nothing to do with my post.
about two months ago dawn wrote:
> The terrorists have won. I'm outta here. You guys know
> where to find me in the future if the group is ever to a
> point where it can tolerate my questions and perspective
> again.
So I take it that either some guys wrote to you and informed
you that cdt has grow more tolerant or that was an emotional
outburst you didn't really /mean/? Do you have any intention
of apologizing for accusing some here of "raping" you?
David Cressey
"dawn" <dawnwo...@gmail.com> wrote in message
news:1155093201.6...@h48g2000cwc.googlegroups.com...
> that pre-dates me. MultiValued databases pre-date 1NF. I'm definitely
I think you ARE dissing the relational model, Dawn.
> ... like the RM-advocates have trashed
> the models that came before it (even though they seemed to have ZERO
> emperical data to prove their point).
Not true, at least in terms of the material I read when I first read about
relational databases. The material I read certainly compared the relational
model with two earleir models, the hierarchical and the network model.
They certainly pointed out some weaknesses in those two models, ones that
the writers claimed the relational model overcame. However, it's a gross
overstatement to say that they "trashed" those two models. Again, I'm
commenting on the material I read about 20 years ago. The material you read
may have been different.
I also disagree about the lack of empirical data to prove their point. The
experience of tens of thousands of database builders and users may not come
up to the standard of "scientific data", but it is certainly "empirical
data". It is you who intentionally ignore that enormous body of data,
calling attention only to the failures that have cropped up in that
experiences and overlooking a massive amount of success.
I certainly have NEVER maintained that the relational model is the end of
history as far as data modelling goes. But a return to a pre-relational
model seems to me to be a waste of time. I remain unconvinced by your
arguments, as far as I got in reading them.
dawn
David Cressey wrote:
> "dawn" <dawnwo...@gmail.com> wrote in message
> news:1155093201.6...@h48g2000cwc.googlegroups.com...
> > that pre-dates me. MultiValued databases pre-date 1NF. I'm definitely
> > not diss'ing the relational model...
>
> I think you ARE dissing the relational model, Dawn.
Yes, I definitely am -- that is the first phrase in the simile
>
> > ... like the RM-advocates have trashed
> > the models that came before it (even though they seemed to have ZERO
> > emperical data to prove their point).
>
> Not true, at least in terms of the material I read when I first read about
> relational databases. The material I read certainly compared the relational
> model with two earleir models, the hierarchical and the network model.
> They certainly pointed out some weaknesses in those two models, ones that
> the writers claimed the relational model overcame. However, it's a gross
> overstatement to say that they "trashed" those two models.
Perhaps it would be more precise to say that they "threw the baby out
with the bathwater." I found arguments, but no emperical data, that
showed the relational model to be beneficial to those using it. If you
are aware of any emperical data, particularly any that shows that the
RM is more flexible over time than either MUMPS or PICK that predate
it, I would really like to see that.
> Again, I'm
> commenting on the material I read about 20 years ago. The material you read
> may have been different.
Yes, so please pass along any pointers to emperical data comparing data
models.
> I also disagree about the lack of empirical data to prove their point. The
> experience of tens of thousands of database builders and users may not come
> up to the standard of "scientific data", but it is certainly "empirical
> data". It is you who intentionally ignore that enormous body of data,
> calling attention only to the failures that have cropped up in that
> experiences and overlooking a massive amount of success.
I'll admit there is marketing data to suggest that on the whole the
products based on SQL have been hugely successful. One thing done very
well was to have a standard language that the industry tapped into.
And I definitely agree that SQL-based products work. My sense is that
the marketing of the relational model has been excellent for decades.
So, yes, there is data to prove that Windows NT was a better OS than
OS/2, from that perspective. So, I will accept your point on that if
that is what you mean.
> I certainly have NEVER maintained that the relational model is the end of
> history as far as data modelling goes.
Great, but there are some who still do. I am only saying that it is
time to move on. Some are moving on by redefining the model
significantly (redefining normalization, for example, suggesting we
return to 2-valued logic, etc.).
> But a return to a pre-relational
> model seems to me to be a waste of time.
I agree. If we are going to start somewhere and move forward, we might
be well-served to look to what works today outside of the RM (even
though it, of course, typically markets itself as relational). Is it
less expensive to work with Cache' than Oracle given such and such an
environment? If so, why?
> I remain unconvinced by your
> arguments, as far as I got in reading them.
That's fine and I appreciate you reading. I took on too much "real
work" and have slowed my writing down. Happily I'm seeing enough
movement in the industry since I started delving into this topic that I
am optimistic that many of my target areas (NF2, 2VL for starters) will
become much more popular in the future. Cheers! --dawn
Marshall
>
> I agree. If we are going to start somewhere and move forward, we might
> be well-served to look to what works today outside of the RM (even
> though it, of course, typically markets itself as relational). Is it
> less expensive to work with Cache' than Oracle given such and such an
> environment? If so, why?
Is there theory behind any of this? Any mathematical models or other
formalisms? It seems to me that comparing Cache with Oracle for
TCO is not on-topic on c.d.t.
Does any of "what works today outside of the RM" have any theory
behind it? This is a theory newsgroup after all.
Marshall
Bob Badour
Ugh. Is she back to grind that idiotic pick-axe again?
Marshall
> Marshall wrote:
> >
> > behind it? This is a theory newsgroup after all.
>
> Ugh. Is she back to grind that idiotic pick-axe again?
"PICK" axe. It works on so many levels. Makes me think
of John Henry.
Marshall
frosty
>>> Does any of "what works today outside of the RM"
>>> have any theory
>>> behind it? This is a theory newsgroup after all.
> Bob Badour wrote:
>> Ugh. Is she back to grind that idiotic pick-axe again?
Marshall wrote:
> "PICK" axe. It works on so many levels.
> Makes me think of John Henry.
Subsequent to the death of Dick Pick, Pick Systems
was acquired by PickAX, Inc... I kid you not.
--
frosty
Jonathan Leffler
> Perhaps it would be more precise to say that they "threw the baby out
> with the bathwater." I found arguments, but no emperical data, that
> showed the relational model to be beneficial to those using it. If you
> are aware of any emperical data, particularly any that shows that the
> RM is more flexible over time than either MUMPS or PICK that predate
> it, I would really like to see that.
The original debate over the relative merits of hierarchical vs
relational DBMS included an example of a program written for the
hierarchical system that had something like 60 lines of code and at
least a couple of bugs in the code, whereas the equivalent relational
code to answer the same problem had about 4 lines of code (and no bugs).
You'd find that material in C J Date's original 'Relational Database:
Selected Writings' book, IIRC (my copy is boxed in the garage - I can't
easily validate that assertion; it was in a C J Date book).
Additionally, the relational code would have continued to work under
many reasonable physical reorganizations of the tables; the
non-relational code would not.
OK - that comparison is not with MUMPS or PICK, but there was certainly
empirical data about the benefits of relational over (some)
non-relational DBMS.
--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
dawn
Hi Marshall. The reason I originally came to this list was to learn
what it was about the theory that lead the industry down a path of
throwing out some good features such as lists, which I have used as my
primary example. I learned from this forum and elsewhere that the
theory has come back around to now permit nested structures, while a
huge amount of software implementations are stuck, for practical
purposes, with the flawed theory of what was once known as 1NF.
So I want to talk about theory and its relationship to practice. We
don't need another two decades of flawed tools that blindly try to
follow another flawed theory. The industry had lists, then pooh-poohed
them, and now is bringing them back, where "the theory" seems to now
permit nested sets (although there are still many who are not ready to
accept that extension of the theory), and lists are accepted if defined
as user-defined types. But there are still no list operations in the
theory as best I can tell. If theory people want to discuss theory
sans "end users" of the theory (like me), they can do their work in a
vacuum, but then perhaps the industry would be well-served if more of
it (than in the past) would stay there so we don't repeat the mistakes
of the past (e.g. normalization as originally defined being implemented
before it was ripe).
So, while I want to talk about theory and its relationship to practice,
I'm not developing theory, and I don't know the totality of the theory
behind any di-graph models, for example. I suspect that there are many
here who would not accept anything other than set theory (functions are
sets, so I'm sure anything software developers do can be modeled as
sets if someone has a reason to do so.)
Did that clarify? If so, is that, or is that not a valid discussion in
this forum? (Don't worry, even if you suggest it is valid to discuss,
I will still keep a low profile here as I know there are some who
really, really dislike having me around and I prefer the company of
those who are at least civil in their discourse when they disagree with
someone, as you, David, mAsterdam, JOG, x, and many others have always
been).
Cheers! --dawn
JOG
> Marshall wrote:
> > dawn wrote:
> > >
> > > I agree. If we are going to start somewhere and move forward, we might
> > > be well-served to look to what works today outside of the RM (even
> > > though it, of course, typically markets itself as relational). Is it
> > > less expensive to work with Cache' than Oracle given such and such an
> > > environment? If so, why?
> >
> > Is there theory behind any of this? Any mathematical models or other
> > formalisms? It seems to me that comparing Cache with Oracle for
> > TCO is not on-topic on c.d.t.
> >
> > Does any of "what works today outside of the RM" have any theory
> > behind it? This is a theory newsgroup after all.
>
> Hi Marshall. The reason I originally came to this list was to learn
> what it was about the theory that lead the industry down a path of
> throwing out some good features such as lists, which I have used as my
> primary example. I learned from this forum and elsewhere that the
> theory has come back around to now permit nested structures, while a
> huge amount of software implementations are stuck, for practical
> purposes, with the flawed theory of what was once known as 1NF.
I think the initial interpretation of 1NF was confused rather than
'flawed' - at the end of the day all theories are developed
iteratively. Of course in math, a relation can contain an element from
any domain, and once RM became established this was picked up on
relatively quickly. I think it's pretty much accepted now that how one
operates on that complex element is not within the remit of the RM
itself, and as such the DBMS must handle its decomposition. And of
course that's the way it should be given that dates, strings and other
decomposable types have no relevance to relational theory.
>
> So I want to talk about theory and its relationship to practice. We
> don't need another two decades of flawed tools that blindly try to
> follow another flawed theory. The industry had lists, then pooh-poohed
> them, and now is bringing them back, where "the theory" seems to now
> permit nested sets (although there are still many who are not ready to
> accept that extension of the theory), and lists are accepted if defined
> as user-defined types. But there are still no list operations in the
> theory as best I can tell. If theory people want to discuss theory
> sans "end users" of the theory (like me), they can do their work in a
> vacuum, but then perhaps the industry would be well-served if more of
> it (than in the past) would stay there so we don't repeat the mistakes
> of the past (e.g. normalization as originally defined being implemented
> before it was ripe).
I've seen you refer to this as "throwing the baby out with the bath
water". I'm not sure at all thats a good analogy, as it infers that
complex types were the most important factor involved - if they had
been RM would have seriously struggled, whereas the other important
advantages of the model over its competitors proved to be overwhelming,
and it dominated in good old darwinian fashion.
Unfortunately recent 'advances' in db work such as XML databases seem
to be attempting to retrieve the 'baby' by rebuilding a bathroom
without any planning schematics, installing an upside-down bath and,
worst of all, no plumbing system.
>
> So, while I want to talk about theory and its relationship to practice,
> I'm not developing theory, and I don't know the totality of the theory
> behind any di-graph models, for example. I suspect that there are many
> here who would not accept anything other than set theory (functions are
> sets, so I'm sure anything software developers do can be modeled as
> sets if someone has a reason to do so.)
Well, graph theory is constructed from set theory itself, a graph being
defined as a triple (set of inputs, set of outputs, set of edges). It
has a powerful theory layered on top of this definition and is hence
applicable to a whole range of practicalities. Unfortunately
information handling is not one of these , given some information
relationships will not fit into a binary approach such as graphs at the
logical level*. Believe me, I spent an an incredibly frustrating year
attempting to 'make them fit' before conceding defeat - looking back it
seems a very naive period, but it was an invaluable education.
Jim.
(* That is apart from 'hypergraphs', which uninvuitively allow edges to
connect > 2 nodes, so allowing the handling of n-ary relationships.
However, then the set of edges essentially become a set of tuples - an
n-ary relation, and we are left with somewhat of a reinvention of
relational theory.)
Keith H Duggar
> Marshall wrote:
> > dawn wrote:
> > > I agree. If we are going to start somewhere and move
> > > forward, we might be well-served to look to what works
> > > today outside of the RM (even though it, of course,
> > > typically markets itself as relational). Is it less
> > > expensive to work with Cache' than Oracle given such
> > > and such an environment? If so, why?
> >
> > Is there theory behind any of this? Any mathematical
> > models or other formalisms? It seems to me that
> > comparing Cache with Oracle for TCO is not on-topic on
> > c.d.t.
> >
> > Does any of "what works today outside of the RM" have
> > any theory behind it? This is a theory newsgroup after
> > all.
>
> Hi Marshall. The reason I originally came to this list
> was to learn
Stop lying, Dawn. From even your first postings in cdt it is
evident that you came with a history to grind a PICK-ax, not
to learn.
> what it was about the theory that lead the industry down a
> path of throwing out some good features such as lists,
> which I have used as my primary example.
And it has been explained to you so many times that lists
have not been "thrown out". Stop lying, Dawn.
> So I want to talk about theory and its relationship to
> practice. We don't need another two decades of flawed
> tools that blindly try to follow another flawed theory.
Here you show the exact mentality I warned Neo about when I
used you as an example. Arrogant and ignorant dismissal of
what came before you as "blind" and "flawed". Yes, that is
surely the attitude of /someone who wants to learn/.
[snip complete non-sense]
Dawn, even as a novice when it comes to relational theory,
and with limited historical knowledge, even I can tell that
paragraph was complete non-sense theoretically, socially,
and historically.
> So, while I want to talk about theory and its relationship
> to practice, I'm not developing theory, and I don't know
> the totality of the theory behind any di-graph models, for
> example.
In other words your answer to Marshall's question is in fact
"I don't know". Then why did you post? Simply to rant?
> I suspect that there are many here who would not accept
> anything other than set theory
There you go, assume some idiotic "suspicions" about the
people you are trying to "learn" from.
> Did that clarify?
It clarifies far more than you intended.
> If so, is that, or is that not a valid discussion in this
> forum? (Don't worry, even if you suggest it is valid to
> discuss, I will still keep a low profile here as I know
> there are some who really, really dislike having me around
> and I prefer the company of those who are at least civil
> in their discourse when they disagree with someone, as
> you, David, mAsterdam, JOG, x, and many others have always
> been).
Yes, yes you clearly prefer civil discourse such as calling
others "terrorists" and "rapists". And in case you haven't
noticed or don't understand, rants are not "low profile".
Neo
This is a broad statement that could apply to many. Could you be more
specific?
dawn
> dawn wrote:
> > Marshall wrote:
> > > dawn wrote:
> > > >
> > > > I agree. If we are going to start somewhere and move forward, we might
> > > > be well-served to look to what works today outside of the RM (even
> > > > though it, of course, typically markets itself as relational). Is it
> > > > less expensive to work with Cache' than Oracle given such and such an
> > > > environment? If so, why?
> > >
> > > Is there theory behind any of this? Any mathematical models or other
> > > formalisms? It seems to me that comparing Cache with Oracle for
> > > TCO is not on-topic on c.d.t.
> > >
> > > Does any of "what works today outside of the RM" have any theory
> > > behind it? This is a theory newsgroup after all.
> >
> > Hi Marshall. The reason I originally came to this list was to learn
> > what it was about the theory that lead the industry down a path of
> > throwing out some good features such as lists, which I have used as my
> > primary example. I learned from this forum and elsewhere that the
> > theory has come back around to now permit nested structures, while a
> > huge amount of software implementations are stuck, for practical
> > purposes, with the flawed theory of what was once known as 1NF.
>
> I think the initial interpretation of 1NF was confused rather than
> 'flawed' - at the end of the day all theories are developed
> iteratively.
OK, or perhaps "the use of 1NF" was flawed, while there is nothing
wrong with coining and defining it. I'm not sure that "nonsimple
domains" (in the definition) was ever nailed down as precise
mathematics. But if the mathematicians tell me the mathematics was not
flawed, then I'm good with that. It is the application of that
mathematics to data (the modeling of data) where my interests lie. The
mistake was requiring software development teams to model data in what
was termed 1NF.
> Of course in math, a relation can contain an element from
> any domain, and once RM became established this was picked up on
> relatively quickly.
I gather that you mean "in theory" it was picked up relatively quickly.
I'm not heavily tapped into what everyone out there is doing, but my
pals are not defining new domains right and left.
> I think it's pretty much accepted now that how one
> operates on that complex element is not within the remit of the RM
> itself, and as such the DBMS must handle its decomposition.
This is a fine distinction, but I'll buy that "relational theory" can
define itself as working with relations and as "orthogonal" to the
question of what domains are supported. This can simply be a matter of
defintiion. I'm not so sure I can buy that the relational model, that
being the model of data that SQL attempted to implement whether they
missed the mark by a lot or a little, can claim that any operators are
irrelevant, including those that are specific to one domain or another.
Here is Date on Codd re the meaning of "data model"
"Codd defines a data model in a 1980 paper Data models in database
management. By his definition a data model consists of a collection of
data structure types, operators that can be applied to instances of
these types and consistency rules that define valid states for the
data."
Are these consistency rules only related to relationships between
relations? Are they unrelated to the consistency of data values for an
attribute, the sets from which valid values may come? Are contraints
related to domains outside of the scope of the relational model? If
so, what is the name of the scope they are in? Given that SQL
implements a model that is bigger/broader that includes specific
domains, for example, I need a name for what seems to me to be "a data
model" that is implemented (with flaws) by SQL. In your terminology
would that then be some sort of "uber data model"?
The good news is that even if theorists are split or narrowly define
the RM so that it no longer contains any of the issues it helped cause
in the industry, I think practioners would generally understand the
relational data model to be the model that (at least in the 80's)
forbade nested values, repeating groups, multivalues, non-1NF, or
whatever you want to call it. So I think when I speak about "the
relational model" with practitioners, they pretty much understand that
it disallows lists as attribute values, for example.
I suspect we could both agree to the terminology that it is the advent
of the relational model that brought about what was termed 1NF and
disallowed non-simple domains (such as lists) even if we define the RM
differently today.
> And of
> course that's the way it should be given that dates, strings and other
> decomposable types have no relevance to relational theory.
Again, I guess I'll go along with a redefinition of relational theory
that says that it no longer cares if the value of an attribute is
itself a relation. But once upon a time, it was definitely a player in
the problems that arose from the relational model (not just from the
implementations thereof).
> > So I want to talk about theory and its relationship to practice. We
> > don't need another two decades of flawed tools that blindly try to
> > follow another flawed theory. The industry had lists, then pooh-poohed
> > them, and now is bringing them back, where "the theory" seems to now
> > permit nested sets (although there are still many who are not ready to
> > accept that extension of the theory), and lists are accepted if defined
> > as user-defined types. But there are still no list operations in the
> > theory as best I can tell. If theory people want to discuss theory
> > sans "end users" of the theory (like me), they can do their work in a
> > vacuum, but then perhaps the industry would be well-served if more of
> > it (than in the past) would stay there so we don't repeat the mistakes
> > of the past (e.g. normalization as originally defined being implemented
> > before it was ripe).
>
> I've seen you refer to this as "throwing the baby out with the bath
> water". I'm not sure at all thats a good analogy, as it infers that
> complex types were the most important factor involved - if they had
> been RM would have seriously struggled,
OK, I'll buy that.
> whereas the other important
> advantages of the model over its competitors proved to be overwhelming,
> and it dominated in good old darwinian fashion.
I never thought of darwinianism in terms of the marketing buzz
surrounding survival of one technology and not another, but ... ;-)
> Unfortunately recent 'advances' in db work such as XML databases seem
> to be attempting to retrieve the 'baby' by rebuilding a bathroom
> without any planning schematics, installing an upside-down bath and,
> worst of all, no plumbing system.
And I'd have to say that the baby isn't coming to life in that area for
me yet either, but we might still in the pregnancy and the morning
sickness is awful (I'll skip my great anecdote on that one).
> > So, while I want to talk about theory and its relationship to practice,
> > I'm not developing theory, and I don't know the totality of the theory
> > behind any di-graph models, for example. I suspect that there are many
> > here who would not accept anything other than set theory (functions are
> > sets, so I'm sure anything software developers do can be modeled as
> > sets if someone has a reason to do so.)
>
> Well, graph theory is constructed from set theory itself, a graph being
> defined as a triple (set of inputs, set of outputs, set of edges). It
> has a powerful theory layered on top of this definition and is hence
> applicable to a whole range of practicalities. Unfortunately
> information handling is not one of these
Hmmm. www?
> , given some information
> relationships will not fit into a binary approach such as graphs at the
> logical level*.
I'll admit I don't know what you are referring to, but are these
relationships absolutely essential to your average software
applications? Where is the show-stopper?
> Believe me, I spent an an incredibly frustrating year
> attempting to 'make them fit' before conceding defeat - looking back it
> seems a very naive period, but it was an invaluable education.
Just as with relational theory covering relations and something else
covering domain operators in a single "data model" (or what I would
term one), we can partition the space so that one theory meets some
requirements for solutions and another meets another. It could even be
partitioned so that some types of problems or domains use this data
model and others use another, right? (I fully accept that I'm not
"getting it" on this point and you may certainly point that out).
Cheers! --dawn
erk
> [...]how else was a girl sittin' in the
> middle of the corn fields not connected to any large corporations gonna
> get thousands of readers for the launch of her blog?
Dawn, be fair here. I've seen web sites that specialize in corn-fed
midwestern girls working creatively to get thousands of subscribers.
:-)
> I'm definitely
> not diss'ing the relational model like the RM-advocates have trashed
> the models that came before it (even though they seemed to have ZERO
> emperical data to prove their point).
Probably true, but computing history, and probably math and logic too,
is filled with models and ideas for which no empirical evidence of
superiority exists. Physical sciences have it, of course, primarily in
the coinage of prediction.
> I'm an end-user of DBMS tools [...] They need to permit
> developers to specify data structures such as lists
I don't necessarily agree here. There are many programming languages
which would cheerfully ignore many programmers' requirements that they
need to use pointers, or need to have a GOTO, or what have you.
> and, generally, to
> model data in a way that is more flexible for software development and
> maintenance over time. Lists [...] are useful.
But that's the main point of disagreement. If I believed that lists
were that useful, I'd be on your side (although that's somewhat beside
the point). Most uses of lists that I see are simply inferior to sets
or relations. I find them hopelessly specialized for most purposes, and
introducing them into a relational data model involves tacking on a
specialized syntax and semantics for a data structure already subsumed
by relations (and with little work).
> In theory lists can now be defined with user-defined domains in the RM,
> but they are not integral to the RM "data model" and I want them in any
> "data model" I use for typical DB101 applications. Why not?
"A designer knows he has achieved perfection not when there is nothing
left to add, but when there is nothing left to take away." - Antoine
de Saint-Exupery
> Whatever the hang-up is, get over it.
No. I don't wanna.
> It was proven useful before Codd to
> employ them and it is still useful to model "property lists" as
> multivalued attributes. Many developers do it all the time in software
> applications today.
In my experience, I've found far more cases than not where correcting a
bug or extending the system required re-designing such multivalued
attributes: introducing either something more general and unordered and
easily-accessed (e.g. a map), or something with a hard-typed interface
(e.g. different slots for different values and attributes, additional
classes for "special values", etc.). In cases I've seen, such lists
(and in fact most lists) occupy the "sour spot" between generality and
specificity, with most of the disadvantages of both extremes and few of
the advantages of either.
> For a couple of decades many felt guilty about not
> "normalizing" their data, but that isn't what I hear today. NF2
> (Non-first-normal-form) and 2VL (two-valued logic) data modeling is on
> an upward trend. It is time to ditch The Information Principle."
Why? Relations don't conflict with however you want to define your
domains. Even Pick is simply vaguely relation-flavored with
system-defined, syntactically significant 1 and 2 level lists as an
available attribute type. Even in MVDBs, you're not ditching the
Information Principle entirely, as the top-level container is still the
relation.
> However ignorant (sure) or arrogant (you don't know me then) you think
> I am, I don't waste my time writing about how others are less
> intelligent, more arrogant, or more ignorant than I [...]
True enough; I think Keith dragged you back into this NG in a fashion
needlessly rude.
- erk
> P.S. I figured I respond so that you didn't look like a coward
> attacking someone who wasn't around to defend herself. smiles.
Ouch. Nicely done.
erk
> Perhaps it would be more precise to say that they "threw the baby out
> with the bathwater." I found arguments, but no emperical data, that
> showed the relational model to be beneficial to those using it. If you
> are aware of any emperical data, particularly any that shows that the
> RM is more flexible over time than either MUMPS or PICK that predate
> it, I would really like to see that.
It doesn't exist.
> > Again, I'm
> > commenting on the material I read about 20 years ago. The material you read
> > may have been different.
>
> Yes, so please pass along any pointers to emperical data comparing data
> models.
It won't be found, and if the empirical datais to be based on market
popularity, I'm not sure what meaning I'd derive from that anyway.
Since the empirical data is lacking both directions (MV over relational
or relational over MV), aren't we all just arguing from a subjective
standpoint? At this point, then, examples and logical arguments are all
we have.
- erk
erk
> OK, or perhaps "the use of 1NF" was flawed, while there is nothing
> wrong with coining and defining it. I'm not sure that "nonsimple
> domains" (in the definition) was ever nailed down as precise
> mathematics. But if the mathematicians tell me the mathematics was not
> flawed, then I'm good with that. It is the application of that
> mathematics to data (the modeling of data) where my interests lie. The
> mistake was requiring software development teams to model data in what
> was termed 1NF.
Perhaps. Relational still doesn't accept more than 1 value for an
attribute of a tuple; in other words, if you query a single attribute
in a single tuple, the RDBMS will only give you 1 value back. That
value can be complex, but the RDBMS doesn't have anything beyond that
one value. Functions can be used to transform it, of course.
If that value is a relation (in an RVA), you gain the power of
relational algebra/calculus without having to introduce special syntax
or semantics. But of course, any user-defined domain can have functions
over it as well.
As far as I know, the only doubt about 1NF is the range of domains
[strange phrase] from which values can be drawn. Early relational
practictioners didn't consider or implement complex domains (at least
for the most part). We now understand that an attribute can be of ANY
domain. Presumably even a database.
> > Of course in math, a relation can contain an element from
> > any domain, and once RM became established this was picked up on
> > relatively quickly.
>
> I gather that you mean "in theory" it was picked up relatively quickly.
> I'm not heavily tapped into what everyone out there is doing, but my
> pals are not defining new domains right and left.
True, but off-the-shelf applications and suppliers of various
frameworks might. Left and right isn't necessary for the notion to have
value.
> Are these consistency rules only related to relationships between
> relations? Are they unrelated to the consistency of data values for an
> attribute, the sets from which valid values may come? Are contraints
> related to domains outside of the scope of the relational model? If
> so, what is the name of the scope they are in?
They're constraints, of a sort - but enforcement requires only that the
value placed into a tuple attribute be of the same type as that
attribute. This requires that values can be selected - that there be
expressions to designate values of that type.
> The good news is that even if theorists are split or narrowly define
> the RM so that it no longer contains any of the issues it helped cause
> in the industry,
What issues?
> I think practioners would generally understand the
> relational data model to be the model that (at least in the 80's)
> forbade nested values, repeating groups, multivalues, non-1NF, or
> whatever you want to call it. So I think when I speak about "the
> relational model" with practitioners, they pretty much understand that
> it disallows lists as attribute values, for example.
I think "disallows" is too strong, especially with our new
understanding. People have used Oracle to store arrays, and even (ugh)
lists encoded in strings. But certainly there's the indication that if
you've got a complex type (define that how you like), you should
instead be using another relation. You don't have to, and may have
reasons not to, but it's a "design smell."
> I suspect we could both agree to the terminology that it is the advent
> of the relational model that brought about what was termed 1NF and
> disallowed non-simple domains (such as lists) even if we define the RM
> differently today.
I'm not so sure - did earlier data models allow "container" types at
its nodes? I thought the main difference in those models was the mode
of navigation, and the lack of a predicate correspondence.
> > whereas the other important
> > advantages of the model over its competitors proved to be overwhelming,
> > and it dominated in good old darwinian fashion.
>
> I never thought of darwinianism in terms of the marketing buzz
> surrounding survival of one technology and not another, but ... ;-)
While survival in the market indicates something, I can't say it always
indicates advantages of the sort that are meaningful to rational
thought.
> Just as with relational theory covering relations and something else
> covering domain operators in a single "data model" (or what I would
> term one), we can partition the space so that one theory meets some
> requirements for solutions and another meets another. It could even be
> partitioned so that some types of problems or domains use this data
> model and others use another, right? (I fully accept that I'm not
> "getting it" on this point and you may certainly point that out).
The trouble is when the solutions are part of the same enterprise, and
later need to interact. I suspect that whatever their models, relations
offer a better model for interaction between "inferior" models.
- erk
Keith H Duggar
> dawn wrote:
> > However ignorant (sure) or arrogant (you don't know me
> > then) you think I am, I don't waste my time writing
> > about how others are less intelligent, more arrogant, or
> > more ignorant than I [...]
>
> True enough;
False enough. Dawn wastes a great deal of time ranting and
insulting implicitly and explicitly entire communities. One
need only read virtually any of her postings to see this
demonstrated. For example the one you are replying to:
dawn wrote:
> > ... the RM-advocates have trashed ... even though they
> > seemed to have ZERO emperical data to prove their point
> > ... some on this list who seem to think they are
> > all-knowing ... I want them to adapt to me because I
> > want progress ... They need to be more flexible ...
> > Lists can be defined in set theory too, by the
> > way. There is nothing evil about them ... so don't snow
> > me with that ... Whatever the hang-up is, get over
> > it. It is time to ditch The Information Principle."
Other choice insults hurled by Dawn include "rape[ists]",
"terrorists", "blind", etc. So please Erk, do not support
Dawn's lies.
> I think Keith dragged you back into this NG in a fashion
> needlessly rude.
I didn't drag her here! We all know she was lurking, losing
the battle to hold back her rants and PICK-ax grinding.
> > P.S. I figured I respond so that you didn't look like a
> > coward attacking someone who wasn't around to defend
> > herself. smiles.
>
> Ouch. Nicely done.
Her sentiment is not genuine and is merely a thinly veiled
insult meant to conceal the pathetic fact that she found an
excuse to rant. I've learned my lesson. Using Dawn's name
simply fed a cranky troll. But, it was inevitable she would
break her word and return to cdt merely two months after
loudly proclaiming her departure.
Bob Badour
> dawn wrote:
>
>>OK, or perhaps "the use of 1NF" was flawed
What an idiot! Even after three years she is too stupid to realize that
1NF is not flawed at all while NFNF has too many flaws to enumerate easily.
, while there is nothing
>>wrong with coining and defining it.
What a complete moronic ass.
Bob Badour
> dawn wrote:
>
>>I'm definitely
>>not diss'ing the relational model like the RM-advocates have trashed
>>the models that came before it (even though they seemed to have ZERO
>>emperical data to prove their point).
What a complete moron. She ignores all of the mountains of blatant
obvious empirical evidence that surrounds her and then claims none exists.
She not only lacks intellectual honesty but on the honesty scale hers is
far in the negative range. She's perverse.
Bob Badour
> dawn wrote:
>
>>Perhaps it would be more precise to say that they "threw the baby out
>>with the bathwater." I found arguments, but no emperical data, that
>>showed the relational model to be beneficial to those using it. If you
>>are aware of any emperical data, particularly any that shows that the
>>RM is more flexible over time than either MUMPS or PICK that predate
>>it, I would really like to see that.
>
> It doesn't exist.
Bullshit! Look, if you are going to engage the ignorant cranks, at least
call them on their bullshit. Don't swallow it!
JOG
Well, either way, at least we are agreed that the modern relational
model is not absolutely identical to its 36 year old counterpart, and
some of the rough edges have been smoothed out. Certainly accepts
complex types. A lot of people don't realise this, and its up to us to
let people know Dawn, especially those who create the software based on
RM.
>
> > Of course in math, a relation can contain an element from
> > any domain, and once RM became established this was picked up on
> > relatively quickly.
>
> I gather that you mean "in theory" it was picked up relatively quickly.
> I'm not heavily tapped into what everyone out there is doing, but my
> pals are not defining new domains right and left.
>
> > I think it's pretty much accepted now that how one
> > operates on that complex element is not within the remit of the RM
> > itself, and as such the DBMS must handle its decomposition.
>
> This is a fine distinction, but I'll buy that "relational theory" can
> define itself as working with relations and as "orthogonal" to the
> question of what domains are supported. This can simply be a matter of
> defintiion. I'm not so sure I can buy that the relational model, that
> being the model of data that SQL attempted to implement whether they
> missed the mark by a lot or a little, can claim that any operators are
> irrelevant, including those that are specific to one domain or another.
RM definitely allows complex types. If an implementation of it doesn't,
it is a bug.
> Here is Date on Codd re the meaning of "data model"
>
> "Codd defines a data model in a 1980 paper Data models in database
> management. By his definition a data model consists of a collection of
> data structure types, operators that can be applied to instances of
> these types and consistency rules that define valid states for the
> data."
>
> Are these consistency rules only related to relationships between
> relations? Are they unrelated to the consistency of data values for an
> attribute, the sets from which valid values may come? Are contraints
> related to domains outside of the scope of the relational model? If
> so, what is the name of the scope they are in? Given that SQL
> implements a model that is bigger/broader that includes specific
> domains, for example, I need a name for what seems to me to be "a data
> model" that is implemented (with flaws) by SQL. In your terminology
> would that then be some sort of "uber data model"?
It's the DBMS no?
A complex type is still just an atom to the data model. Consider an
image, a perfectly acceptable element - its just a list of pixels after
all, but I don't expect my data model to natively handle its
decomposition.
>
> The good news is that even if theorists are split or narrowly define
> the RM so that it no longer contains any of the issues it helped cause
> in the industry, I think practioners would generally understand the
> relational data model to be the model that (at least in the 80's)
> forbade nested values, repeating groups, multivalues, non-1NF, or
> whatever you want to call it. So I think when I speak about "the
> relational model" with practitioners, they pretty much understand that
> it disallows lists as attribute values, for example.
As I said, we've done the research practically in tandem it seems. Time
to tell those practitioners that they're mistaken.
I have personal friendships with some of the most influential people in
hypertext and the internet. To a man they all loathe the hideous mess
that is the web and none would say it has anything to do with data
modelling. It is a publishing medium (and a poor shadow of what it
could have been at that), but can hardly be processed as a data model.
I'm guessing that your reference to www was tongue in cheek.
Graphs, when used at the logical level, cannot handle anything more
than binary relationships, and hey we know from irreducible tuples,
that a lot of information _cannot_ be broken down into binary form.
Thats exactly why graph databases and the Semantic Web are such a load
of tosh.
>
> > , given some information
> > relationships will not fit into a binary approach such as graphs at the
> > logical level*.
>
> I'll admit I don't know what you are referring to, but are these
> relationships absolutely essential to your average software
> applications? Where is the show-stopper?
>
> > Believe me, I spent an an incredibly frustrating year
> > attempting to 'make them fit' before conceding defeat - looking back it
> > seems a very naive period, but it was an invaluable education.
>
> Just as with relational theory covering relations and something else
> covering domain operators in a single "data model" (or what I would
> term one), we can partition the space so that one theory meets some
> requirements for solutions and another meets another. It could even be
> partitioned so that some types of problems or domains use this data
> model and others use another, right? (I fully accept that I'm not
> "getting it" on this point and you may certainly point that out).
> Cheers! --dawn
I don't think data model is the correct term for what you mean. There
are an infinite number of possible domains (consider that image element
example), and it hence requires a higher level (I'm not sure we need to
leet it up by calling it uber) to handle decomposing them. People seem
to be starting to talk about a relational language on cdt though, so
this may be a good sign.
J.
dawn
Coincidentially, at lunch today I was told that in the quote from
Matthew "if the salt has lost its saltiness" the "has lost its
saltiness" is the translation of the Greek "moronic" (or variation
thereof).
I assure you that I have not lost my saltiness
(I was going to say that my ass has not, as that would have played with
both words, but it was just too nasty, perhaps coming a bit too close
to JOG's interests ;-)
dawn
Oops, looks like that was erk. My apologies. You guys all look alike.
dawn
erk wrote:
> dawn wrote:
> > [...]how else was a girl sittin' in the
> > middle of the corn fields not connected to any large corporations gonna
> > get thousands of readers for the launch of her blog?
>
> Dawn, be fair here. I've seen web sites that specialize in corn-fed
> midwestern girls working creatively to get thousands of subscribers.
>
> :-)
I'll check with them and see if they can give me some tips.
> > I'm definitely
> > not diss'ing the relational model like the RM-advocates have trashed
> > the models that came before it (even though they seemed to have ZERO
> > emperical data to prove their point).
>
> Probably true, but computing history, and probably math and logic too,
> is filled with models and ideas for which no empirical evidence of
> superiority exists.
Yup, like that "earth is flat" and "sun goes around the earth"
> Physical sciences have it, of course, primarily in
> the coinage of prediction.
>
> > I'm an end-user of DBMS tools [...] They need to permit
> > developers to specify data structures such as lists
>
> I don't necessarily agree here. There are many programming languages
> which would cheerfully ignore many programmers' requirements that they
> need to use pointers, or need to have a GOTO, or what have you.
Doesn't stop users from indicating what they think they need, however.
So, maybe I'm just an old goat asking for my pointers back. Maybe, but
I don't think so. I recall working with someone like that -- a person
who didn't want to move forward. I do want to move forward, and I want
forward to include some of what has been highly effective in the past.
I just heard an interesting statement on cdp and don't know if it is
true, but I'll repeat it anyway. Someone suggested that IBM has a
large catalog of off-the-shelf solutions using their DBMS tools and
there are more U2 apps than DB2. Can that be true? Those DBMS's order
attributes, uniquely identify attributes by their position in a tuple,
use descriptive not prescriptive schema with everything being a string
(or binary, but ignoring those) that could be described as an integer
and also a character string, for example, assumes all attributes can
have values of variable length, and generally would be seen as out of
line with relational theory. Maybe all they have going for them is the
flexibility and related low cost of development and maintenance of
software applications.
Yes, I'm very interested in emperical data, even if also liking-ish
theory
> > and, generally, to
> > model data in a way that is more flexible for software development and
> > maintenance over time. Lists [...] are useful.
>
> But that's the main point of disagreement. If I believed that lists
> were that useful, I'd be on your side (although that's somewhat beside
> the point).
Have you ever seen people model lists by assigning numbers with gaps so
that other items could fit "in between"? GL account structures are
famous for that, but it is a rather pathetic "design pattern", don't
you think? What about adding an ordinal as an attribute to create a
list without leaving gaps? Developers then reimplement the functions
for inserting and ripple deletes.
Worse than that, there are lists that would be good for the user, but
that 1NF designers leave as single-valued just because it is too much
work to jump from 1 to n. When something is a pain in the neck to do,
developers can more easily justify not doing it.
> Most uses of lists that I see are simply inferior to sets
> or relations. I find them hopelessly specialized for most purposes, and
> introducing them into a relational data model involves tacking on a
> specialized syntax and semantics for a data structure already subsumed
> by relations (and with little work).
Good party line there, erk
> > In theory lists can now be defined with user-defined domains in the RM,
> > but they are not integral to the RM "data model" and I want them in any
> > "data model" I use for typical DB101 applications. Why not?
>
> "A designer knows he has achieved perfection not when there is nothing
> left to add, but when there is nothing left to take away." - Antoine
> de Saint-Exupery
So I suppose my house would be better without the whirlpool tub?
> > Whatever the hang-up is, get over it.
>
> No. I don't wanna.
If you really need to keep your pointers, that's your issue ;-)
> > It was proven useful before Codd to
> > employ them and it is still useful to model "property lists" as
> > multivalued attributes. Many developers do it all the time in software
> > applications today.
>
> In my experience, I've found far more cases than not where correcting a
> bug or extending the system required re-designing such multivalued
> attributes: introducing either something more general and unordered and
> easily-accessed (e.g. a map), or something with a hard-typed interface
> (e.g. different slots for different values and attributes, additional
> classes for "special values", etc.). In cases I've seen, such lists
> (and in fact most lists) occupy the "sour spot" between generality and
> specificity, with most of the disadvantages of both extremes and few of
> the advantages of either.
We clearly have had different experiences.
> > For a couple of decades many felt guilty about not
> > "normalizing" their data, but that isn't what I hear today. NF2
> > (Non-first-normal-form) and 2VL (two-valued logic) data modeling is on
> > an upward trend. It is time to ditch The Information Principle."
>
> Why? Relations don't conflict with however you want to define your
> domains.
OK, then, at least the Information Principle as it was understood by
everyone before 1990 and by the masses even today.
> Even Pick is simply vaguely relation-flavored with
> system-defined, syntactically significant 1 and 2 level lists as an
> available attribute type. Even in MVDBs, you're not ditching the
> Information Principle entirely, as the top-level container is still the
> relation.
I'm not at all opposed to modeling with relations, it is just that the
IP requires exclusivity and I want the model to also "understand'
lists, for example.
> > However ignorant (sure) or arrogant (you don't know me then) you think
> > I am, I don't waste my time writing about how others are less
> > intelligent, more arrogant, or more ignorant than I [...]
>
> True enough; I think Keith dragged you back into this NG in a fashion
> needlessly rude.
>
> - erk
>
> > P.S. I figured I respond so that you didn't look like a coward
> > attacking someone who wasn't around to defend herself. smiles.
>
> Ouch. Nicely done.
thanks. smiles. --dawn
dawn
Yes.
> Certainly accepts
> complex types. A lot of people don't realise this, and its up to us to
> let people know Dawn, especially those who create the software based on
> RM.
I'm working on it, in my own little way. Thanks for spreadin' the news
too.
That's not the name of the abstraction, that is the implementation. A
whole raft of DBMS's look similar to each other and are often referred
to as RDBMS's or RELATIONAL while another group might be called MUMPS,
another PICK. The products are not the same -- Revelation (in the Pick
family tree), is different from jBASE or UniData. SQL Server is
different from Oracle. But jBASE and Revelation pretty much implement
the same "data model" (PICK) as do SQL Server and Oracle (RELATIONAL).
> A complex type is still just an atom to the data model. Consider an
> image, a perfectly acceptable element - its just a list of pixels after
> all, but I don't expect my data model to natively handle its
> decomposition.
I'm OK if relational theory doesn't cover working with lists as long as
relational theory is not all that is employed. We can use set
processing for some things and pull in the list processing for others.
It is only when relational operators demand exclusivity at some level
that I have a problem with it.
> >
> > The good news is that even if theorists are split or narrowly define
> > the RM so that it no longer contains any of the issues it helped cause
> > in the industry, I think practioners would generally understand the
> > relational data model to be the model that (at least in the 80's)
> > forbade nested values, repeating groups, multivalues, non-1NF, or
> > whatever you want to call it. So I think when I speak about "the
> > relational model" with practitioners, they pretty much understand that
> > it disallows lists as attribute values, for example.
>
> As I said, we've done the research practically in tandem it seems. Time
> to tell those practitioners that they're mistaken.
I'm tryin' to (but it can be brutal)
And all of the women in software development in my county (OK, there
might be another one somewhere) think it is beautiful in its
usefulness, simplicity (well, maybe not, I can't believe how hard it
was to make css and xhtml work in both IE and FF)
> and none would say it has anything to do with data
> modelling.
There are a lot of documents out there too, but use it as an app
run-time container or an RSS feed and you start getting into structured
data modeling, not just documents.
> It is a publishing medium (and a poor shadow of what it
> could have been at that),
Wouldn't it be better to say "could be"?
> but can hardly be processed as a data model.
> I'm guessing that your reference to www was tongue in cheek.
It was a counter-example. Your words were "information handling" so it
worked.
>
> Graphs, when used at the logical level, cannot handle anything more
> than binary relationships,
I don't think of the question as "what can this handle" but "are these
data structures and operators useful"? I like relations and relational
operators and I also like navigating from node to node when it is
helpful, such as from an order to its lineItems.
> and hey we know from irreducible tuples,
> that a lot of information _cannot_ be broken down into binary form.
> Thats exactly why graph databases and the Semantic Web are such a load
> of tosh.
I just deleted a clever response here, but the upshot is that I've read
quite a bit of the semantic web stuff and I'm not a believer yet
either.
> > > , given some information
> > > relationships will not fit into a binary approach such as graphs at the
> > > logical level*.
> >
> > I'll admit I don't know what you are referring to, but are these
> > relationships absolutely essential to your average software
> > applications? Where is the show-stopper?
> >
> > > Believe me, I spent an an incredibly frustrating year
> > > attempting to 'make them fit' before conceding defeat - looking back it
> > > seems a very naive period, but it was an invaluable education.
> >
> > Just as with relational theory covering relations and something else
> > covering domain operators in a single "data model" (or what I would
> > term one), we can partition the space so that one theory meets some
> > requirements for solutions and another meets another. It could even be
> > partitioned so that some types of problems or domains use this data
> > model and others use another, right? (I fully accept that I'm not
> > "getting it" on this point and you may certainly point that out).
> > Cheers! --dawn
>
> I don't think data model is the correct term for what you mean. There
> are an infinite number of possible domains (consider that image element
> example), and it hence requires a higher level (I'm not sure we need to
> leet it up by calling it uber) to handle decomposing them. People seem
> to be starting to talk about a relational language on cdt though, so
> this may be a good sign.
And I do like Tutorial-D's group and ungroup that at least gets at some
of what I want. Add in a few more features for list handling at the top
level, permit synonyms (of different types), and a bunch of other
features and we just might be able to combine a good theory with good
practice. Pick is practical in a big bang for the buck way.
Relational theory is elegant in a mathematical way. I don't want to
cheat on either theory or practice, but if they aren't going to align,
I'm stickin' with practical and flexible.
Cheers! --dawn
Bob Badour
Perhaps her pals are smarter than she is; although, that wouldn't be
saying much. Then again, perhaps not.
>>>I think it's pretty much accepted now that how one
>>>operates on that complex element is not within the remit of the RM
>>>itself, and as such the DBMS must handle its decomposition.
>>
>>This is a fine distinction, but I'll buy that "relational theory" can
Why would anyone give a flying fuck what this embecile "will buy" ?
She's a moron. Nobody cares.
erk
I'm not swallowing any arguments about flaws in the RM, but I don't
know of evidence for the benefits of RM that would fit the definition
of "empirical data" she seems to be using. Then again, that sort of
data is also lacking for the benefits of any programming language,
operating system, etc., making every decision on every technology
similarly "arbitrary," and reducing the entire thing to nonsense. That
line of argument is a rabbit's hole, so I ceded the argument - "it"
(meaning what she's looking for) doesn't exist, though it has no
bearing on the arguments.
None of this has any bearing on my knowledge that the RM is superior,
both objectively (via logic, thought experiments, reading, etc.) and in
my personal experience. But I can't call that "empirical data" in the
sense in which she means it.
- erk
erk
> False enough. Dawn wastes a great deal of time ranting and
> insulting implicitly and explicitly entire communities.
No, I haven't found that to be the case. You can call her ignorant if
you like, but insulting? You'd have to be terminally thin-skinned to
believe that.
> One
> need only read virtually any of her postings to see this
> demonstrated.
I've read many of her posts, not least because the conversation that
surrounds them is always compelling. And I don't see what you see. I've
read things similar to this before, concerning Dawn, and I find her
civil and restrained - especially in view of what's typically slung at
her.
> For example the one you are replying to:
>
> dawn wrote:
> > > ... the RM-advocates have trashed ... even though they
> > > seemed to have ZERO emperical data to prove their point
> > > ... some on this list who seem to think they are
> > > all-knowing ... I want them to adapt to me because I
> > > want progress ... They need to be more flexible ...
> > > Lists can be defined in set theory too, by the
> > > way. There is nothing evil about them ... so don't snow
> > > me with that ... Whatever the hang-up is, get over
> > > it. It is time to ditch The Information Principle."
I don't see a single insult in here - again, unless your flesh is
phyllo. You can say she's wrong (I don't agree with her much),
ignorant, blah blah blah, but not insulting. Sorry. That's just false,
however much I disagree with her.
> Other choice insults hurled by Dawn include "rape[ists]",
> "terrorists", "blind", etc. So please Erk, do not support
> Dawn's lies.
Were we talking about truth or insults? Different scopes. Dawn can be
and has been wrong about various things, and some arguments I find
compelling simply don't convince her at all. I don't think she lies,
although I think she misinterprets things about the RM, things I've
already spelled out elsewhere. All of the above is standard in debate,
right?
Sorry I lack the encyclopedic knowledge of Dawn's word choices that you
seem to have; I missed the "rapeist" line, although any rational person
would interpret her use of the words "terrorist" and "rape" as
metaphors for written attacks. Perhaps they're overblown, but she's
certainly not actually accusing anyone of rape or terrorist acts.
> I didn't drag her here! We all know she was lurking, losing
> the battle to hold back her rants and PICK-ax grinding.
hahahahahahahaha
I'm sorry, that's just funny. She said she was leaving, and you didn't
believe her; you invoked her name, she replied, and now you're accusing
her of having manipulated your mind to force you to do so?
> > > P.S. I figured I respond so that you didn't look like a
> > > coward attacking someone who wasn't around to defend
> > > herself. smiles.
> >
> > Ouch. Nicely done.
>
> Her sentiment is not genuine and is merely a thinly veiled
> insult meant to conceal the pathetic fact that she found an
> excuse to rant.
OK, yes, here she does insult you. I found it clever, and padded for
minimum discomfort, redness, swelling, and chafing.
> I've learned my lesson. Using Dawn's name
> simply fed a cranky troll. But, it was inevitable she would
> break her word and return to cdt merely two months after
> loudly proclaiming her departure.
A hideous lie; we're all reeling from the deception.
> -- Keith -- Fraud 6
heh
- erk
Fraud Without Number
erk
> erk wrote:
> > Probably true, but computing history, and probably math and logic too,
> > is filled with models and ideas for which no empirical evidence of
> > superiority exists.
>
> Yup, like that "earth is flat" and "sun goes around the earth"
I'm not sure I get your point, but mine was: computing has nothing
vaguely related to the empiricism and experimentation of physical
sciences. Experiments in various computing models would look like
psychological and sociological ones, as humans are always involved.
> Have you ever seen people model lists by assigning numbers with gaps so
> that other items could fit "in between"? GL account structures are
> famous for that, but it is a rather pathetic "design pattern", don't
> you think?
Yes, I do.
> Worse than that, there are lists that would be good for the user, but
> that 1NF designers leave as single-valued just because it is too much
> work to jump from 1 to n. When something is a pain in the neck to do,
> developers can more easily justify not doing it.
If you don't have control of the data structures, then you run into
this, although I've yet to ever see an attribute that was single-valued
and later needed to be multivalued. Maybe it happens, but I've yet to
encounter it. Converting something from 1 to N involves creating a new
relation/table, a foreign key constraint, an insert statement, and a
final alteration on the original table.
> > Most uses of lists that I see are simply inferior to sets
> > or relations. I find them hopelessly specialized for most purposes, and
> > introducing them into a relational data model involves tacking on a
> > specialized syntax and semantics for a data structure already subsumed
> > by relations (and with little work).
>
> Good party line there, erk
Da, komrade. Ignore the hordes of peasants starving for lists.
> > > In theory lists can now be defined with user-defined domains in the RM,
> > > but they are not integral to the RM "data model" and I want them in any
> > > "data model" I use for typical DB101 applications. Why not?
> >
> > "A designer knows he has achieved perfection not when there is nothing
> > left to add, but when there is nothing left to take away." - Antoine
> > de Saint-Exupery
>
> So I suppose my house would be better without the whirlpool tub?
Heh - I'd consider lists more like a rope ladder up to the second
floor, hanging right next to the staircase and the elevator.
> We clearly have had different experiences.
Fair enough.
> > Even Pick is simply vaguely relation-flavored with
> > system-defined, syntactically significant 1 and 2 level lists as an
> > available attribute type. Even in MVDBs, you're not ditching the
> > Information Principle entirely, as the top-level container is still the
> > relation.
>
> I'm not at all opposed to modeling with relations, it is just that the
> IP requires exclusivity and I want the model to also "understand'
> lists, for example.
If that's the case, what other types does the model have to
"understand"? Just lists? Sets too? The advantage to me is that
relational treats all those the same way, thus hobbling no one, and
keeping concerns separated.
- erk
Apparatchik Number 1
Bob Badour
Do you suppose she means it in some sense other than "relying on or
derived from observation or experiment" or "guided by practical
experience" ?
Empirical evidence abounds.
One could argue that lines of code and number of bugs are not valid
measures for comparing two solutions, but the argument would be very
weak. One could argue that man-years of effort is a loose measure and
one would be correct. If one were comparing two things where the
measures were close, one could not conclude much. However, when one
compares two things where the effort for the equivalent product is
orders of magnitude different, the measure suffices for coarse conclusions.
Network model and NFNF models require orders of magnitude more effort
for the same outcome. Proponents of these logical data models invariably
deliver buggy code with an order of magnitude or more complexity while
ignoring concurrency, integrity and a whole host of other concerns dealt
with by relational solutions. The red and blue car cross-post thread
offers empirical evidence that Pick proponents lack the cognition to
recognize the faults in their beliefs.
Others have recently mentioned the examples from the Great Debate
comparing a CODASYL solution with a much simpler relational solution.
Anyone who claims that no empirical evidence exists to shred network
model and NFNF models is either ignorant or in denial.
Bob Badour
> Keith H Duggar wrote:
>
>>False enough. Dawn wastes a great deal of time ranting and
>>insulting implicitly and explicitly entire communities.
>
> No, I haven't found that to be the case. You can call her ignorant if
> you like, but insulting? You'd have to be terminally thin-skinned to
> believe that.
>
>>One
>>need only read virtually any of her postings to see this
>>demonstrated.
>
> I've read many of her posts, not least because the conversation that
> surrounds them is always compelling. And I don't see what you see. I've
> read things similar to this before, concerning Dawn, and I find her
> civil and restrained - especially in view of what's typically slung at
> her.
Snake-oil salesmen and confidence men invariable do seem that way.
That's how they separate lonely old widows from their life's savings.
>>For example the one you are replying to:
>>
>>dawn wrote:
>>
>>>>... the RM-advocates have trashed ... even though they
>>>>seemed to have ZERO emperical data to prove their point
Empirically false. Others have provided mountains of empirical evidence.
It is an insult to them for her to turn around and simply deny their
efforts. I don't let the insult bother me--I simply note that engaging
trolls like her is a waste of effort.
>>>>... some on this list who seem to think they are
>>>>all-knowing ...
I agree with the statement. Dawn apparently thinks that way. However, I
suggest she intended it as an insult to the all-knowing Erk, who knows
no empirical evidence could possibly exist.
I want them to adapt to me because I
>>>>want progress ...
Erk, bow down before me and obey my will! Only in this way can we progress.
While you are down there, fetch me my slippers.
They need to be more flexible ...
Erk, you are inflexible.
>>>>Lists can be defined in set theory too, by the
>>>>way. There is nothing evil about them ...
Erk, stop calling lists evil.
so don't snow
>>>>me with that ...
And stop snowing her by calling lists evil. While you are at it, stop
fucking sheep.
Whatever the hang-up is, get over
>>>>it.
Yeah, get over the hang-up--there's nothing wrong with thinly-haired
bipedal apes.
It is time to ditch The Information Principle."
While you are ditching that, don't forget to ditch intellectual honesty,
empiricism, and pi. Why pi? I don't know, but let's ditch it.
> I don't see a single insult in here - again, unless your flesh is
> phyllo.
To feel much of anything as a result of the insult would imply thin
skin. However, that doesn't make them any less insults.
You can say she's wrong (I don't agree with her much),
> ignorant, blah blah blah, but not insulting. Sorry. That's just false,
> however much I disagree with her.
Whether one cares about the insult or feels anything in particular as a
result of the insult is different from whether it is an insult in the
first place.
>>Other choice insults hurled by Dawn include "rape[ists]",
>>"terrorists", "blind", etc. So please Erk, do not support
>>Dawn's lies.
>
> Were we talking about truth or insults?
Erk, stop raping terrorists. How could you be so blind?
Different scopes. Dawn can be
> and has been wrong about various things, and some arguments I find
> compelling simply don't convince her at all.
At this moment, you are exhibiting a surprising lack of intellectual
honesty. Denial of an objective reality doesn't serve any useful purpose.
I don't think she lies,
Either she lies or she is remarkably stupid or both. Does it matter which?
> although I think she misinterprets things about the RM, things I've
> already spelled out elsewhere. All of the above is standard in debate,
> right?
All kinds of sophistry is rampant in the formal method of debate as a
means of emotional persuasion. However, sophistry and emotion have no
real use in the face of logical argument and theory.
> Sorry I lack the encyclopedic knowledge of Dawn's word choices that you
> seem to have; I missed the "rapeist" line, although any rational person
> would interpret her use of the words "terrorist" and "rape" as
> metaphors for written attacks.
Insulting metaphors used as a rhetorical technique. Perhaps, she should
spend more of her time at comp.databases.rhetoric instead of here.
Perhaps they're overblown, but she's
> certainly not actually accusing anyone of rape or terrorist acts.
Are you suggesting that morally equating someone to a rapist or
terrorist is somehow not an insult unless it is an actual accusation of
rape or terrorism?
>>I didn't drag her here! We all know she was lurking, losing
>>the battle to hold back her rants and PICK-ax grinding.
>
> hahahahahahahaha
>
> I'm sorry, that's just funny. She said she was leaving, and you didn't
> believe her; you invoked her name, she replied, and now you're accusing
> her of having manipulated your mind to force you to do so?
I don't see how you jumped to that last conclusion.
>>>>P.S. I figured I respond so that you didn't look like a
>>>>coward attacking someone who wasn't around to defend
>>>>herself. smiles.
>>>
>>>Ouch. Nicely done.
>>
>>Her sentiment is not genuine and is merely a thinly veiled
>>insult meant to conceal the pathetic fact that she found an
>>excuse to rant.
>
> OK, yes, here she does insult you. I found it clever, and padded for
> minimum discomfort, redness, swelling, and chafing.
So, insinuating cowardice is an insult, but morally equating someone to
a rapist is not? Am I correct in your interpretation of what constitutes
an insult? Doesn't the moral equation insinuate cowardice?
>>I've learned my lesson. Using Dawn's name
>>simply fed a cranky troll. But, it was inevitable she would
>>break her word and return to cdt merely two months after
>>loudly proclaiming her departure.
>
> A hideous lie; we're all reeling from the deception.
>
>>-- Keith -- Fraud 6
>
> heh
>
> - erk
> Fraud Without Number
Do you like large numbers or small numbers? If you like large numbers, I
nominate you for Avogadro's Number, and if you like small numbers, I
nominate you for e, the natural base. Or do you prefer to remain without
number? Like a "Minister without Portfolio" ?
erk
> erk wrote:
> > I've read many of her posts, not least because the conversation that
> > surrounds them is always compelling. And I don't see what you see. I've
> > read things similar to this before, concerning Dawn, and I find her
> > civil and restrained - especially in view of what's typically slung at
> > her.
>
> Snake-oil salesmen and confidence men invariable do seem that way.
> That's how they separate lonely old widows from their life's savings.
Probably, but that's not what we were talking about.
> >>dawn wrote:
> >>
> >>>>... the RM-advocates have trashed ... even though they
> >>>>seemed to have ZERO emperical data to prove their point
>
> Empirically false. Others have provided mountains of empirical evidence.
> It is an insult to them for her to turn around and simply deny their
> efforts. I don't let the insult bother me--I simply note that engaging
> trolls like her is a waste of effort.
Yes, engaging trolls is a waste of effort.
However disappointing or disingenuous, I still don't take her reaction
to presented evidence as an insult to the presenter (nor would I if I
had presented it).
> >>>>... some on this list who seem to think they are
> >>>>all-knowing ...
>
> I agree with the statement. Dawn apparently thinks that way. However, I
> suggest she intended it as an insult to the all-knowing Erk, who knows
> no empirical evidence could possibly exist.
Not of the sort she seems to want, though I agree the definition of
"empirical" has been molested in this discussion (by me too,
mistakenly). I think there is ample empirical evidence; just not the
type that she seems to want. I said "it doesn't exist" simply trying
(once again) to dissuade her apparent desire for a database of
reproducible statistical evidence, all factors accounted for.
> >>>>Lists can be defined in set theory too, by the
> >>>>way. There is nothing evil about them ...
>
> Erk, stop calling lists evil.
They're raping my sheep.
> so don't snow
> >>>>me with that ...
>
> And stop snowing her by calling lists evil. While you are at it, stop
> fucking sheep.
Do I have to leave the communist party and stop beating my wife too?
> Whatever the hang-up is, get over
> >>>>it.
>
> Yeah, get over the hang-up--there's nothing wrong with thinly-haired
> bipedal apes.
How did you know I was thinly-haired?
> It is time to ditch The Information Principle."
>
> While you are ditching that, don't forget to ditch intellectual honesty,
> empiricism, and pi. Why pi? I don't know, but let's ditch it.
And that avocado number. I hate 'em.
> > I don't see a single insult in here - again, unless your flesh is
> > phyllo.
>
> To feel much of anything as a result of the insult would imply thin
> skin. However, that doesn't make them any less insults.
I was judging feelings from the intensity and duration of others'
reactions to her; I may have misjudged.
> You can say she's wrong (I don't agree with her much),
> > ignorant, blah blah blah, but not insulting. Sorry. That's just false,
> > however much I disagree with her.
>
> Whether one cares about the insult or feels anything in particular as a
> result of the insult is different from whether it is an insult in the
> first place.
True, although my implicit definition of "insult" is apparently more
lax than yours and others'.
> >>Other choice insults hurled by Dawn include "rape[ists]",
> >>"terrorists", "blind", etc. So please Erk, do not support
> >>Dawn's lies.
> >
> > Were we talking about truth or insults?
>
> Erk, stop raping terrorists. How could you be so blind?
I only rape blind terrorists. And sheep. But not blind sheep.
> Different scopes. Dawn can be
> > and has been wrong about various things, and some arguments I find
> > compelling simply don't convince her at all.
>
> At this moment, you are exhibiting a surprising lack of intellectual
> honesty. Denial of an objective reality doesn't serve any useful purpose.
Thanks for saying it's surprising. But, RM student and advocate though
I am, I can't classify her not being convinced as denial of objective
reality.
> I don't think she lies,
>
> Either she lies or she is remarkably stupid or both. Does it matter which?
Sure, in most forums. For purposes of this discussion... not really.
> > although I think she misinterprets things about the RM, things I've
> > already spelled out elsewhere. All of the above is standard in debate,
> > right?
>
> All kinds of sophistry is rampant in the formal method of debate as a
> means of emotional persuasion. However, sophistry and emotion have no
> real use in the face of logical argument and theory.
I think proponents of logical argument need to recognize when sophistry
is needed. I don't think virtues survive on their own merits simply
because they're virtues. So if someone doesn't swallow an argument I
find logical, I assume I need to approach it differently, or (most
likely) that my written communications have sucked.
> Perhaps they're overblown, but she's
> > certainly not actually accusing anyone of rape or terrorist acts.
>
> Are you suggesting that morally equating someone to a rapist or
> terrorist is somehow not an insult unless it is an actual accusation of
> rape or terrorism?
I wasn't aware she'd made that moral equation as anything other than a
defensive joke.
> >>I didn't drag her here! We all know she was lurking, losing
> >>the battle to hold back her rants and PICK-ax grinding.
> >
> > hahahahahahahaha
> >
> > I'm sorry, that's just funny. She said she was leaving, and you didn't
> > believe her; you invoked her name, she replied, and now you're accusing
> > her of having manipulated your mind to force you to do so?
>
> I don't see how you jumped to that last conclusion.
I don't either; must have been a long day.
> > OK, yes, here she does insult you. I found it clever, and padded for
> > minimum discomfort, redness, swelling, and chafing.
>
> So, insinuating cowardice is an insult, but morally equating someone to
> a rapist is not? Am I correct in your interpretation of what constitutes
> an insult? Doesn't the moral equation insinuate cowardice?
I don't remember the details of the rape comment, and didn't feel like
looking; I just don't think she meant it. If she did, it's certainly an
insult. Even the insinuation of cowardice above is far more teasing
than actual insult. And no, I don't have a hard-and-fast definition of
the boundary between the two.
> > - erk
> > Fraud Without Number
>
> Do you like large numbers or small numbers? If you like large numbers, I
> nominate you for Avogadro's Number, and if you like small numbers, I
> nominate you for e, the natural base. Or do you prefer to remain without
> number? Like a "Minister without Portfolio" ?
Fraud e will do nicely, I think.
- Fraud e
Keith H Duggar
> Keith H Duggar wrote:
> > False enough. Dawn wastes a great deal of time ranting
> > and insulting implicitly and explicitly entire
> > communities.
>
> No, I haven't found that to be the case. You can call her
> ignorant if you like, but insulting? You'd have to be
> terminally thin-skinned to believe that.
[snip more redefinition of "insult"]
As Bob already explained to you, an insult is an insult
regardless of the targets skin. Also, I think you missed
the word "implicitly" above.
> > I didn't drag her here! We all know she was lurking,
> > losing the battle to hold back her rants and PICK-ax
> > grinding.
>
> hahahahahahahaha
>
> I'm sorry, that's just funny. She said she was leaving,
> and you didn't believe her; you invoked her name, she
> replied, and now you're accusing her of having manipulated
> your mind to force you to do so?
Get your facts straight. Dawn had /already/ returned to
posting to cdt /before/ this thread. In other words, when I
mentioned her here, I already knew she was back and lurking.
> Fraud e will do nicely, I think.
>
> - Fraud e
A natural choice, though not as perfect as 6. ;-)
Bob Badour
Why can't we all be Fraud 4? That's what I want to know.
Keith H Duggar
Bob Badour wrote:
> Keith H Duggar wrote:
>
> > erk wrote:
> >
> >>Keith H Duggar wrote:
> >>
> >>Fraud e will do nicely, I think.
> >>
> >>- Fraud e
> >
> > A natural choice, though not as perfect as 6. ;-)
> >
> > -- Keith -- Fraud 6
>
> Why can't we all be Fraud 4? That's what I want to know.
You mean convert to C'mode numerals?.
Bob Badour
> Bob Badour wrote:
>
>>erk wrote:
>>[...]
>>
>>>I've read many of her posts, not least because the conversation that
>>>surrounds them is always compelling. And I don't see what you see. I've
>>>read things similar to this before, concerning Dawn, and I find her
>>>civil and restrained - especially in view of what's typically slung at
>>>her.
>>
>>Snake-oil salesmen and confidence men invariable do seem that way.
>>That's how they separate lonely old widows from their life's savings.
>
> Probably, but that's not what we were talking about.
I disagree. Dawn has snake-oil to sell.
David Cressey
"erk" <eric...@gmail.com> wrote in message
news:1155565396.7...@m79g2000cwm.googlegroups.com...
> > > Most uses of lists that I see are simply inferior to sets
> > > or relations. I find them hopelessly specialized for most purposes,
and
> > > introducing them into a relational data model involves tacking on a
> > > specialized syntax and semantics for a data structure already subsumed
> > > by relations (and with little work).
> >
> > Good party line there, erk
>
> Da, komrade. Ignore the hordes of peasants starving for lists.
How do I disdain lists?
Let me list the ways....
dawn
I love it! --dawn
erk
> How do I disdain lists?
> Let me list the ways....
Would you take it as a compliment if I called you listless?
- erk
JOG
> [snippage]
> I'm OK if relational theory doesn't cover working with lists as long as
> relational theory is not all that is employed. We can use set
> processing for some things and pull in the list processing for others.
> It is only when relational operators demand exclusivity at some level
> that I have a problem with it.
Relational operators only demand exclusivity at the bottom level.
Anything you want you can layer on top. From your posts I figure that's
good enough for you ;)
> [snippage]
> > I have personal friendships with some of the most influential people in
> > hypertext and the internet. To a man they all loathe the hideous mess
> > that is the web
>
> And all of the women in software development in my county (OK, there
> might be another one somewhere) think it is beautiful in its
> usefulness, simplicity (well, maybe not, I can't believe how hard it
> was to make css and xhtml work in both IE and FF)
Quite. The www is only a dog compared to what it could be like. Its
still pretty damn useful as it is.
> > It is a publishing medium (and a poor shadow of what it
> > could have been at that),
>
> Wouldn't it be better to say "could be"?
No, I think the web is too entrenched now. It'd take a revolution not
an evolution.
>
> > but can hardly be processed as a data model.
> > I'm guessing that your reference to www was tongue in cheek.
>
> It was a counter-example. Your words were "information handling" so it
> worked.
But you knew what I meant dawn, and were just being polemic. Paper
holds information, but its not gonna be too hot for data modelling.
> [snippage]
> > and hey we know from irreducible tuples,
> > that a lot of information _cannot_ be broken down into binary form.
> > Thats exactly why graph databases and the Semantic Web are such a load
> > of tosh.
>
> I just deleted a clever response here, but the upshot is that I've read
> quite a bit of the semantic web stuff and I'm not a believer yet
> either.
There is no clever response that can't be refuted when it comes to the
semantic web ;) It's a dead man walking because of RDF's ternary nature
(although it may be a long walk).
> [snippage]
> And I do like Tutorial-D's group and ungroup that at least gets at some
> of what I want. Add in a few more features for list handling at the top
> level, permit synonyms (of different types), and a bunch of other
> features and we just might be able to combine a good theory with good
> practice.
Well that's certainly a change in standpoint. (I have a great deal of
respect for those who can change their opinions after doing the
research, especially after being on the wrong end of a lot of stick)
Nothing wrong with layers on top of RM and I agree group/ungroup normal
form is very interesting.
> Pick is practical in a big bang for the buck way.
> Relational theory is elegant in a mathematical way. I don't want to
> cheat on either theory or practice, but if they aren't going to align,
> I'm stickin' with practical and flexible.
> Cheers! --dawn
I'm a firm believer that we can, in the end, get everything we want
from building up theory without resorting to diving in headfirst with
ad-hoc models. Its always just a case of clarifying and iterating
theory to get there. (i.e. Codd's legacy is certainly not dead).
Jim.
dawn
JOG wrote:
> dawn wrote:
> > [snippage]
> > I'm OK if relational theory doesn't cover working with lists as long as
> > relational theory is not all that is employed. We can use set
> > processing for some things and pull in the list processing for others.
> > It is only when relational operators demand exclusivity at some level
> > that I have a problem with it.
>
> Relational operators only demand exclusivity at the bottom level.
Yes (or the "top level" depending on your perspective). There really
is only one additional construct I'm looking to be supported at that
level -- the list.
> Anything you want you can layer on top. From your posts I figure that's
> good enough for you ;)
I have such great retorts for that, but I think I better hold my
tongue.
> > [snippage]
> > > I have personal friendships with some of the most influential people in
> > > hypertext and the internet. To a man they all loathe the hideous mess
> > > that is the web
> >
> > And all of the women in software development in my county (OK, there
> > might be another one somewhere) think it is beautiful in its
> > usefulness, simplicity (well, maybe not, I can't believe how hard it
> > was to make css and xhtml work in both IE and FF)
>
> Quite. The www is only a dog compared to what it could be like. Its
> still pretty damn useful as it is.
Agreed.
> > > It is a publishing medium (and a poor shadow of what it
> > > could have been at that),
> >
> > Wouldn't it be better to say "could be"?
>
> No, I think the web is too entrenched now. It'd take a revolution not
> an evolution.
Like some ignorant, moronic girl trying to move the industry away from
SQL, right?
I remember someone telling me that we would still be running gopher ten
years from now because there was so much there ('92 or '93). But, yes,
a migration over time - we are not going to swap out either current www
nor current sql-based solutions in an instant.
> > > but can hardly be processed as a data model.
> > > I'm guessing that your reference to www was tongue in cheek.
> >
> > It was a counter-example. Your words were "information handling" so it
> > worked.
>
> But you knew what I meant dawn, and were just being polemic.
Maybe a little, but the www is still a very large distributed database
of sorts. It has structured data (in spite of what others might call
it), persisted on secondary storage devices, accessed by people. There
isn't a great query langauge, I'll grant. The requirements are not
identical to those of a DBMS, but the model for the data ought to be
taken seriously and moved forward accordingly.
> Paper
> holds information, but its not gonna be too hot for data modelling.
I do understand your point, but again, there doesn't need to be such a
huge difference between those who would draft what we once called a
"data entry form" on paper (which we still end up filling out often in
life) for filing in a paper database and those modeling data for a
computerized database. There is quite a bit of commonality, even if
some differences.
> > [snippage]
> > > and hey we know from irreducible tuples,
> > > that a lot of information _cannot_ be broken down into binary form.
> > > Thats exactly why graph databases and the Semantic Web are such a load
> > > of tosh.
> >
> > I just deleted a clever response here, but the upshot is that I've read
> > quite a bit of the semantic web stuff and I'm not a believer yet
> > either.
>
> There is no clever response that can't be refuted when it comes to the
> semantic web ;) It's a dead man walking because of RDF's ternary nature
> (although it may be a long walk).
Agreed, oddly enough.
> > [snippage]
> > And I do like Tutorial-D's group and ungroup that at least gets at some
> > of what I want. Add in a few more features for list handling at the top
> > level, permit synonyms (of different types), and a bunch of other
> > features and we just might be able to combine a good theory with good
> > practice.
>
> Well that's certainly a change in standpoint.
I've learned a lot from you guys. I came here to learn and I have. I
have learned more about human nature than I really wanted to learn, but
ah well.
> (I have a great deal of
> respect for those who can change their opinions after doing the
> research, especially after being on the wrong end of a lot of stick)
I'm still pretty much on the unpopular side of most related
discussions, but I can see a little better how my requirements should
not be too far fetched for relational theorists (many already accept my
2VL approach, so they just need to dump the information principle and
adopt lists ;-), even if still a ways from RM implementations.
> Nothing wrong with layers on top of RM
If lists are in the data model employed by designers, developers,
maintainers of software, then it is not "on top of the RM" it is a new
model. So, we still differ on terminology.
> and I agree group/ungroup normal
> form is very interesting.
>
> > Pick is practical in a big bang for the buck way.
> > Relational theory is elegant in a mathematical way. I don't want to
> > cheat on either theory or practice, but if they aren't going to align,
> > I'm stickin' with practical and flexible.
> > Cheers! --dawn
>
> I'm a firm believer that we can, in the end, get everything we want
> from building up theory without resorting to diving in headfirst with
> ad-hoc models.
That would please me. If I thought ad-hoc was the best way to go for
the long haul, I wouldn't be reading cdt. But neither do I think the
"look, there's a mathematical theory, let's go there" approach served
the industry well.
> Its always just a case of clarifying and iterating
> theory to get there. (i.e. Codd's legacy is certainly not dead).
I agree with the last statement. But I would add to the first statement
something about how we need to refine our practices as well and not
accept theory without testing it out to understand in terms of
resources and quality just what we gain with any given theory before we
ditch known best practices and jump on theory bandwagons. A theory,
like relational theory, might be tight mathematically, but that is no
proof that it is the best way to model propositions, for example. I
might not have said that well, but I'm clicking to send anyway.
Cheers! --dawn
Thanks for the dialog, jog. --dawn
Marshall
>
> Maybe a little, but the www is still a very large distributed database
> of sorts.
It totally isn't. What makes up a database? Structure, integrity,
manipulation to start with. HTTP+HTML has *none* of those,
let alone more advanced things we might consider part of
a dbms.
> It has structured data (in spite of what others might call
> it),
No it doesn't. It has markup. Markup is not structure; there is
no schema. If HTML is structured data, then troff is structured
data. No schema: no structure. The level of things you can
do with HTML are: put this word in bold.
There's no DML. There isn't even a query language. GET is
not a query language. There are no integrity rules.
HTTP+HTML doesn't even remotely qualify as a data
management system. It's a distributed document retrieval
system. They are not the same thing. I'm not even sure
on what basis one could claim they were related.
> persisted on secondary storage devices, accessed by people.
If this is your definition, then 3x5 cards is data management.
> There isn't a great query langauge, I'll grant.
There isn't *any* query language. Retrieving a document by
a key isn't a query language. It's a cheapo function call.
> The requirements are not
> identical to those of a DBMS, but the model for the data ought to be
> taken seriously and moved forward accordingly.
No, it shouldn't. There is no data model to take seriously.
Efforts to retrofit one have been embarrassing. If we want
to do data management, and we are studying HTML+HTTP,
then we should consider it a negative example.
Marshall
Keith H Duggar
> JOG wrote:
> > No, I think the web is too entrenched now. It'd take a
> > revolution not an evolution.
>
> Like some ignorant, moronic girl trying to move the
> industry away from SQL, right?
Many people (perhaps everyone) would love a "better" SQL.
That is not why you come across as ignorant, moronic, etc.
Rather it is because you stubbornly and repeatedly refuse
to differentiate between SQL and relational theory. Well
that is a part, and only a part, of the reason.
> I remember someone telling me that we would still be
> running gopher ten years from now because there was so
> much there ('92 or '93). But, yes, a migration over time
> - we are not going to swap out either current www nor
> current sql-based solutions in an instant.
And, in case you stll have hope, they are not going to
migrate to PICK either.
> Maybe a little, but the www is still a very large
> distributed database of sorts. It has structured data (in
> spite of what others might call it), persisted on
> secondary storage devices, accessed by people. There
> isn't a great query langauge, I'll grant. The requirements
> are not identical to those of a DBMS, but the model for
> the data ought to be taken seriously and moved forward
> accordingly.
Hehehe. "in spite of what others" might think, Dawn knows
what's what and is here to tell YOU what to take seriously.
That pretty much tells one all they need to know about the
poor little midwest girl trying to get noticed by the world.
> I came here to learn and I have.
No you didn't. Stop repeating that lie over and over. In
contradistinction, I actually did come here to learn and
learned a lot. For example, I know that SQL != RM. A fact
you continue not to grasp even after all these years.
> I have learned more about human nature than I really
> wanted to learn, but ah well.
I truly hope, Dawn, that you have learned more about
yourself than you have about humans.
> I'm still pretty much on the unpopular side of most
> related discussions, but I can see a little better how my
> requirements should not be too far fetched for relational
> theorists
Do you see that they do /not care/ about /your/ requirements?
> (many already accept my 2VL approach, so they just need to
> dump the information principle and adopt lists ;-), even
> if still a ways from RM implementations.
Back to telling everyone what to do?
> > Nothing wrong with layers on top of RM
>
> If lists are in the data model employed by designers,
> developers, maintainers of software, then it is not "on
> top of the RM" it is a new model. So, we still differ on
> terminology.
No, Dawn, you are falling to grasp his simple point. That
being there is no /need/ to make "a new model" since lists
can be modeled already. You are simply refusing to accept
that fact or such a solution and are trying to hide your
/demands/ as innocent "terminology".
> > I'm a firm believer that we can, in the end, get
> > everything we want from building up theory without
> > resorting to diving in headfirst with ad-hoc models.
>
> That would please me. If I thought ad-hoc was the best
> way to go for the long haul, I wouldn't be reading cdt.
> But neither do I think the "look, there's a mathematical
> theory, let's go there" approach served the industry well.
Perhaps because you were not around and are ignorant of the
industry /before/ the theory? Perhaps because all the stuff
you rant about are results of failing to go with the theory?
Perhaps because you fail to grasp those and related points
regardless of reason, evidence, etc?
> > Its always just a case of clarifying and iterating
> > theory to get there. (i.e. Codd's legacy is certainly
> > not dead).
>
> I agree with the last statement. But I would add to the
> first statement something about how we need to refine our
> practices as well and not accept theory without testing it
> out to understand in terms of resources and quality just
> what we gain with any given theory before we ditch known
> best practices and jump on theory bandwagons. A theory,
> like relational theory, might be tight mathematically,
> but that is no proof that it is the best way to model
> propositions, for example. I might not have said that
> well, but I'm clicking to send anyway.
LOL. That paragraph was fantastically, beautifully ironic in
so many ways. Were you are troll that would have be without
question an elite coup de grace.
Oh by the way, are you ever going to apologize for calling
some /people/ here rapists and terrorists?
JOG
I totally agree. The www is no more a database than a newspaper is imo
- its a publishing medium.
JOG
> [snippage]
> > No, I think the web is too entrenched now. It'd take a revolution not
> > an evolution.
>
> Like some ignorant, moronic girl trying to move the industry away from
> SQL, right?
...?
> [snippage]
> I've learned a lot from you guys. I came here to learn and I have. I
> have learned more about human nature than I really wanted to learn, but
> ah well.
Bad dawn - you know It takes two to tango. :(
> [snippage]
> So, we still differ on terminology.
that's good hey. terminology generates a lot of miscommunication but
ultimately it is a minor thing.
> [snippage]
> A theory, like relational theory, might be tight mathematically, but that
> is no proof that it is the best way to model propositions, for example.
Well the thing is we all agree with this. I doubt anyone has the
naivite to say the RM is the final word and that an improved theory may
not arise in the millennia ahead of us.
> I might not have said that well, but I'm clicking to send anyway.
> Cheers! --dawn
>
> Thanks for the dialog, jog. --dawn
no problem. (dialogue by the way. US variations are so colourful...)
Bob Badour
> dawn wrote:
>
>>JOG wrote:
>>
>>(many already accept my 2VL approach, so they just need to
>>dump the information principle and adopt lists ;-)
Only an ignorant moron such as Dawn would want to do anything so stupid.
, even
>>if still a ways from RM implementations.
>
> Back to telling everyone what to do?
Where do you get the 'back' part? It's not like she ever stopped.
>>>I'm a firm believer that we can, in the end, get
>>>everything we want from building up theory without
>>>resorting to diving in headfirst with ad-hoc models.
>>
>>That would please me. If I thought ad-hoc was the best
>>way to go for the long haul, I wouldn't be reading cdt.
Sadly, she doesn't do much listening or comprehending of cdt. She would
do herself and everyone a big favour if she spend more time thinking and
less time posting.
>>But neither do I think the "look, there's a mathematical
>>theory, let's go there" approach served the industry well.
What is the point of her posting such idiotic fluff? Nobody here thinks
all mathematical theory is created equal. Ironically, if we did, we
would all stupidly jump to graph theory just as Dawn does.
> Perhaps because you were not around and are ignorant of the
> industry /before/ the theory? Perhaps because all the stuff
> you rant about are results of failing to go with the theory?
> Perhaps because you fail to grasp those and related points
> regardless of reason, evidence, etc?
She lacks intellectual capability and intellectual honesty. What else is
there to say?
>>>Its always just a case of clarifying and iterating
>>>theory to get there. (i.e. Codd's legacy is certainly
>>>not dead).
>>
>>I agree with the last statement. But I would add to the
>>first statement something about how we need to refine our
>>practices as well and not accept theory without testing it
>>out to understand in terms of resources and quality just
>>what we gain with any given theory before we ditch known
>>best practices and jump on theory bandwagons.
What idiotic nonsense. The Pick bandwagon was accepted without
refinement or reference to any theory. The relational model has proved
itself with mountains of empirical evidence.
Dawn simply denies the elephant in the room.
A theory,
>>like relational theory, might be tight mathematically,
>>but that is no proof that it is the best way to model
>>propositions, for example. I might not have said that
>>well, but I'm clicking to send anyway.
>
> LOL. That paragraph was fantastically, beautifully ironic in
> so many ways. Were you are troll that would have be without
> question an elite coup de grace.
>
> Oh by the way, are you ever going to apologize for calling
> some /people/ here rapists and terrorists?
>
> -- Keith -- Fraud 6
She is about as likely to do that as she is to apologize for wasting
everybody's time and for hijacking a theory newsgroup to satisfy her own
perverse fetishes.
Bob Badour
> dawn wrote:
>
>>[snippage]
>>
>>>No, I think the web is too entrenched now. It'd take a revolution not
>>>an evolution.
>>
>>Like some ignorant, moronic girl trying to move the industry away from
>>SQL, right?
Maybe. Ignorant morons tend to start these fads. Whether it will be
anyone from the midwest or a girl is much less certain.
>>[snippage]
>>So, we still differ on terminology.
>
> that's good hey. terminology generates a lot of miscommunication but
> ultimately it is a minor thing.
Jim, if you are going to engage the ignorant cranks and trolls, please,
do a better job of calling them on their bullshit.
Bob Badour
> dawn wrote:
>
>>[snippage]
>>I'm OK if relational theory doesn't cover working with lists as long as
>>relational theory is not all that is employed. We can use set
>>processing for some things and pull in the list processing for others.
>>It is only when relational operators demand exclusivity at some level
>>that I have a problem with it.
>
> Relational operators only demand exclusivity at the bottom level.
> Anything you want you can layer on top. From your posts I figure that's
> good enough for you ;)
Jim, if you are going to engage the ignorant cranks and trolls, please,
do a better job of calling them on their bullshit.
The relational model includes types and the operations on values of
those types, while only specifying one required type. Which types are
included in any given design is nearly orthogonal to the RM with the
exception that a boolean type is required. However, nobody has to layer
anything on top of the RM to use lists in the RM. One only has to
include a list type in the design.
I have yet to see any proposal for a useful list type or operations on
values of a list type that were not already better handled using relations.
Your recent replies to the cranks and trolls have been incoherent. If
you are not going to put in the effort to respond coherently to the
cranks and trolls, you would do us all a favour by simply citing Date's
_Principle of Incoherence_ and moving on.
>>>but can hardly be processed as a data model.
>>>I'm guessing that your reference to www was tongue in cheek.
>>
>>It was a counter-example. Your words were "information handling" so it
>>worked.
>
> But you knew what I meant dawn, and were just being polemic. Paper
> holds information, but its not gonna be too hot for data modelling.
Paper works in many applications and worked just fine for a couple
millenia prior to the advent of computers. I am having trouble
discerning a point to your stroking the egos of the self-aggrandizing
ignorants. It seems you are just wasting everyone's time.
>>[snippage]
> Nothing wrong with layers on top of RM and I agree group/ungroup normal
> form is very interesting.
That depends on exactly what you mean by a layer. There is everything
wrong with violating the information principle or layering physical
pointers 'on top of' the RM.
>>Pick is practical in a big bang for the buck way.
Bullshit. We have plenty of empirical evidence that Pickies universally
lack sufficient cognition to evaluate their own solutions. We have
plenty of empirical evidence that Pick forces causual users to have
expert level file processing skills in order to effectively use the
product. We have plenty of empirical evidence...
>>Relational theory is elegant in a mathematical way.
It is elegant in every way, and it is hugely practical at the same time.
I don't want to
>>cheat on either theory or practice, but if they aren't going to align,
>>I'm stickin' with practical and flexible.
Which Dawn has proved beyond any doubt that she could not recognize if
it bit her on the ass. If you are going to pretend to engage her,
please, do a better job of calling her on her bullshit.
JOG
> JOG wrote:
> > dawn wrote:
> >
> >>[snippage]
> >>I'm OK if relational theory doesn't cover working with lists as long as
> >>relational theory is not all that is employed. We can use set
> >>processing for some things and pull in the list processing for others.
> >>It is only when relational operators demand exclusivity at some level
> >>that I have a problem with it.
> >
> > Relational operators only demand exclusivity at the bottom level.
> > Anything you want you can layer on top. From your posts I figure that's
> > good enough for you ;)
>
> Jim, if you are going to engage the ignorant cranks and trolls, please,
> do a better job of calling them on their bullshit.
>
> The relational model includes types and the operations on values of
> those types, while only specifying one required type. Which types are
> included in any given design is nearly orthogonal to the RM with the
> exception that a boolean type is required. However, nobody has to layer
> anything on top of the RM to use lists in the RM. One only has to
> include a list type in the design.
Thanks, you are obviously correct.
> I have yet to see any proposal for a useful list type or operations on
> values of a list type that were not already better handled using relations.
Agreed.
> Your recent replies to the cranks and trolls have been incoherent. If
> you are not going to put in the effort to respond coherently to the
> cranks and trolls, you would do us all a favour by simply citing Date's
> _Principle of Incoherence_ and moving on.
I was encouraging movement in position that I saw. I obviously gather
you think its a complete waste of time here.
I still want to convince people of what I've learned - while your 'cut
the crap' posting style has grown on me a lot, it doesn't seem to do
that. Worse still, you don't have to be a genius to see that it often
entrenches them, they carry on disseminating mistakes and it
perpetuates ignorance as a whole. While you can be very succinct and
perceptive at your best, you can be counterproductive at your worst,
just perpetuating their positions. You'd be a crap politician (you can
take that as a compliment if you so desire).
Now I know your thinking some people can't be convinced, and you'd be
spot on. But I'm young and naive so I'm gonna try anyway. No doubt one
day soon I'll lose my patience too, but until then you do your shit,
and I'll do mine. In the end the goal's the same.
>
>
> >>>but can hardly be processed as a data model.
> >>>I'm guessing that your reference to www was tongue in cheek.
> >>
> >>It was a counter-example. Your words were "information handling" so it
> >>worked.
> >
> > But you knew what I meant dawn, and were just being polemic. Paper
> > holds information, but its not gonna be too hot for data modelling.
>
> Paper works in many applications and worked just fine for a couple
> millenia prior to the advent of computers. I am having trouble
> discerning a point to your stroking the egos of the self-aggrandizing
> ignorants. It seems you are just wasting everyone's time.
>
>
> >>[snippage]
> > Nothing wrong with layers on top of RM and I agree group/ungroup normal
> > form is very interesting.
>
> That depends on exactly what you mean by a layer. There is everything
> wrong with violating the information principle or layering physical
> pointers 'on top of' the RM.
>
>
> >>Pick is practical in a big bang for the buck way.
>
> Bullshit. We have plenty of empirical evidence that Pickies universally
> lack sufficient cognition to evaluate their own solutions. We have
> plenty of empirical evidence that Pick forces causual users to have
> expert level file processing skills in order to effectively use the
> product. We have plenty of empirical evidence...
I'd appreciate if you stopped mixing posts from different authors. Its
confusing and they start to look like neo's.
dawn
Marshall wrote:
> dawn wrote:
> >
> > Maybe a little, but the www is still a very large distributed database
> > of sorts.
>
> It totally isn't. What makes up a database? Structure, integrity,
> manipulation to start with.
I didn't say that it was a DBMS. Your definition of "database" is not
the norm, it seems, but I went to the cdt glossary and found this
"[Database]
"A logically coherent collection of related real-world data
assembled for a specific purpose." -- rephrased from
"Fundamentals of Database Systems", Elmasri & Navathe.
1. Deluxe filesystem
2. Shared databank (E. Codd) "
I think the web fits within these definitions.
> HTTP+HTML has *none* of those,
> let alone more advanced things we might consider part of
> a dbms.
>
>
> > It has structured data (in spite of what others might call
> > it),
>
> No it doesn't. It has markup.
You see no structure in the marked-up data?
> Markup is not structure; there is
> no schema.
If we limit it to the xhtml pages, would you then say it is structured
data?
> If HTML is structured data, then troff is structured
> data. No schema: no structure. The level of things you can
> do with HTML are: put this word in bold.
>
> There's no DML. There isn't even a query language. GET is
> not a query language. There are no integrity rules.
Perhaps there is a theory definition of the word structure that you are
using to draw the conclusion that the web does not have structured
data. My take is that a single page can be a node/attribute with a
value that is the html, for example, with directional paths to other
nodes for which there are links in the page. Structure, no?
> HTTP+HTML doesn't even remotely qualify as a data
> management system.
Agreed. It doesn't fit my def of a DBMS.
> It's a distributed document retrieval
> system. They are not the same thing. I'm not even sure
> on what basis one could claim they were related.
Every attribute value is a document, of sorts, however small.
> > persisted on secondary storage devices, accessed by people.
>
> If this is your definition, then 3x5 cards is data management.
Not DBMS, but, yes, it would be a database by my definition (and the
def of many others as I understand it).
>
> > There isn't a great query langauge, I'll grant.
>
> There isn't *any* query language. Retrieving a document by
> a key isn't a query language. It's a cheapo function call.
Fine. Again, perhaps the industry has done something with the English
word "query" so that when I put a word into google and retrieve a list
of "keys" from which to choose that would not be a query. It seems
like a query to me, but surely not like an SQL query.
> > The requirements are not
> > identical to those of a DBMS, but the model for the data ought to be
> > taken seriously and moved forward accordingly.
>
> No, it shouldn't. There is no data model to take seriously.
Perhaps not until "it" (a di-graph of tree nodes, perhaps?) replaces
that which currently is considered the only possible data model, eh?
Since the model of data that I typically work with (in what most would
call a DBMS) could be seen as a di-graph of trees, we know it is
possible to do data management with such collections, even if we don't
want to call the abstraction of this approach a data model. I'll grant
it is not the same. But I will stand my ground that it should be taken
seriously by those researching data models.
> Efforts to retrofit one have been embarrassing. If we want
> to do data management, and we are studying HTML+HTTP,
> then we should consider it a negative example.
For some things, yes, e.g. 404s. Cheers! --dawn
dawn
JOG wrote:
> dawn wrote:
> > [snippage]
> > > No, I think the web is too entrenched now. It'd take a revolution not
> > > an evolution.
> >
> > Like some ignorant, moronic girl trying to move the industry away from
> > SQL, right?
>
> ...?
>
> > [snippage]
> > I've learned a lot from you guys. I came here to learn and I have. I
> > have learned more about human nature than I really wanted to learn, but
> > ah well.
>
> Bad dawn - you know It takes two to tango. :(
Even when sitting in one of the reddest counties in the US and not
supporting GWB, I was able to dialog with people without the
intimidation techniques and bullying I have experienced here (not by
you). There have been no attempts to drive me out of town. So, this
is a new experience and not a fun one. So, I'm disappointed you
thought that was a bad statement on my part.
> > [snippage]
> > So, we still differ on terminology.
>
> that's good hey. terminology generates a lot of miscommunication but
> ultimately it is a minor thing.
>
> > [snippage]
> > A theory, like relational theory, might be tight mathematically, but that
> > is no proof that it is the best way to model propositions, for example.
>
> Well the thing is we all agree with this. I doubt anyone has the
> naivite to say the RM is the final word and that an improved theory may
> not arise in the millennia ahead of us.
I'm really glad to hear that.
> > I might not have said that well, but I'm clicking to send anyway.
> > Cheers! --dawn
> >
> > Thanks for the dialog, jog. --dawn
>
> no problem. (dialogue by the way. US variations are so colourful...)
you mean "colorful," right? (some might suggest the comma is in the
wrong place too)
Bob Badour
It was worse than a waste of time. Please, take a moment to think about
the meaning of Date's _Principle of Incoherence_: It's very difficult to
reply coherently to that which is incoherent.
Effectiveness requires coherence. When replying to the incoherent,
coherence requires great effort. What you posted was incoherent because
you failed to put in the necessary effort. The incoherence makes what
little effort you did put into it counter-productive.
In the end, you elevate and legitimize the self-aggrandizing ignorant
while impeaching yourself.
When you engage the self-aggrandizing ignorants indiscriminately and
without putting in the necessary effort for coherence, you put the rest
of us in a difficult situation. Either we have to put in extra effort to
respond coherently to your incoherence, or we have to dismiss you right
along with the self-aggrandizing ignorants.
I ask that if you are going to engage the self-aggrandizing ignorants
that you please do so sparingly and put in the necessary effort. Don't
gloss over the most incoherent bits of what they say to try to find some
common ground. That only legitimizes their nonsense while depriving
others the benefits of the most valuable pedagogic opportunities.
> I still want to convince people of what I've learned - while your 'cut
> the crap' posting style has grown on me a lot, it doesn't seem to do
> that.
One will never reach those who have no motivation to learn and every
motivation not to. That said, I have had my share of successes among
those who remain.
Dawn is not here to learn. She is here to promote herself and to advance
her own economic agenda.
Worse still, you don't have to be a genius to see that it often
> entrenches them, they carry on disseminating mistakes and it
> perpetuates ignorance as a whole.
What you fail to understand is they are already entrenched in their
minds. We can either surrender and allow them complete freedom to
disseminate ignorance, or we can expose them for the charlatans they are.
In the two or three years when I stayed away and when Marshall and
others pretended to engage Dawn at an intellectual level as a peer, the
newsgroup gave her a semi-official glossary to pollute with her own
ignorant misconceptions. That does far more to perpetuate ignorance than
putting the self-aggrandizing ignorants on the defensive where they belong.
While you can be very succinct and
> perceptive at your best, you can be counterproductive at your worst,
> just perpetuating their positions.
You and I obviously disagree as to what is counterproductive. Those who
are closed-minded enough to ignore me over style deserve their ignorance.
You'd be a crap politician (you can
> take that as a compliment if you so desire).
Politics, as much as religion, opposes knowledge and science. In the
end, it invariably prefers an ignorant and self-destructive consensus to
frank honesty. I suggest we leave it to the many blood-sucking parasites.
> Now I know your thinking some people can't be convinced, and you'd be
> spot on. But I'm young and naive so I'm gonna try anyway.
I only ask that you try harder to be effective instead of leaving the
hard work to others.
No doubt one
> day soon I'll lose my patience too, but until then you do your shit,
> and I'll do mine. In the end the goal's the same.
The question is: How much damage are you going to do to yourself and to
your goal in the meantime?
>>>>>but can hardly be processed as a data model.
>>>>>I'm guessing that your reference to www was tongue in cheek.
>>>>
>>>>It was a counter-example. Your words were "information handling" so it
>>>>worked.
>>>
>>>But you knew what I meant dawn, and were just being polemic. Paper
>>>holds information, but its not gonna be too hot for data modelling.
>>
>>Paper works in many applications and worked just fine for a couple
>>millenia prior to the advent of computers. I am having trouble
>>discerning a point to your stroking the egos of the self-aggrandizing
>>ignorants. It seems you are just wasting everyone's time.
>>
>>
>>>>[snippage]
>>>
>>>Nothing wrong with layers on top of RM and I agree group/ungroup normal
>>>form is very interesting.
>>
>>That depends on exactly what you mean by a layer. There is everything
>>wrong with violating the information principle or layering physical
>>pointers 'on top of' the RM.
>>
>>
>>>>Pick is practical in a big bang for the buck way.
>>
>>Bullshit. We have plenty of empirical evidence that Pickies universally
>>lack sufficient cognition to evaluate their own solutions. We have
>>plenty of empirical evidence that Pick forces causual users to have
>>expert level file processing skills in order to effectively use the
>>product. We have plenty of empirical evidence...
>
> I'd appreciate if you stopped mixing posts from different authors. Its
> confusing and they start to look like neo's.
There is a very easy way for you to achieve what you desire. If you are
going to excerpt blatant nonsense, respond to it coherently. If you are
unwilling to put in the effort for coherence, at least identify it for
what it is.
Keith H Duggar
> JOG wrote:
> > I still want to convince people of what I've learned -
> > while your 'cut the crap' posting style has grown on me
> > a lot, it doesn't seem to do that.
>
> One will never reach those who have no motivation to learn
> and every motivation not to. That said, I have had my
> share of successes among those who remain.
Sorry for this topic shift but that reminded me of something
specific I still would like to learn from you. I think maybe
my question may have slipped through the cracks. Here is the
excerpt from "What Databases Have Taught Me"
Keith H Duggar wrote:
> Bob Badour wrote:
> > Because computing science, in a sense, is the process of
> > building abstract machines and formalisms, the fact that
> > one can axiomatize is very useful. The fact that one can
> > arbitrarily choose different axiomatizations is useful
> > too.
>
> Ok. So it seems we agree that axiomatization is useful. I
> think I should have just simply said from the start that the
> definition of "type" that I currently find most useful in
> programming is "type = algebraic structure". Now, I can't
> remember if algebraic structures are permitted to have an
> unlimited number of sets, operations, and axioms. If they
> are then let me append "with a limited number of sets,
> operations, and axioms" to the definition.
>
> Which definition(s) [or notions] do you find more useful?
> Or what is it about the algebraic structure definition
> that you find not useful or insufficient?
>
> I recall once you mentioned type theory had failed in some
> manner. Can you elaborate? Do you know of any alternatives
> or recent work in type (or category) theory that is doing
> better and is more useful to computer science?
When you have a chance I'd appreciate your thoughts. Oh, and
of course same goes for any other type theory enthusiasts
out there.
Thanks!
erk
those slow on the uptake (and I'm not excluding myself).
Bob Badour wrote:
> Effectiveness requires coherence. When replying to the incoherent,
> coherence requires great effort. What you posted was incoherent because
> you failed to put in the necessary effort. The incoherence makes what
> little effort you did put into it counter-productive.
I can agree, having fallen into this many times myself. I don't claim
to be the most coherent on this board, but replying coherently to
incoherence requires a great deal of time, editing, and commitment.
> There is a very easy way for you to achieve what you desire. If you are
> going to excerpt blatant nonsense, respond to it coherently. If you are
> unwilling to put in the effort for coherence, at least identify it for
> what it is.
O'Reilly's next book, Trolls In A Nutshell?
- erk
Keith H Duggar
> O'Reilly's next book, Trolls In A Nutshell?
"Trolls, Frauds, and Cranks: The Fate of Human Thought"
"Troll! I know you are but what am I? : 21 Days In Hell"
dawn
<snip>
>
> Dawn is not here to learn. She is here to promote herself and to advance
> her own economic agenda.
Just to set the record straight for others (Bob filters me and attacks,
trying to intimidate, those who respond to me, in case you haven't
figured that out) -- I have no motivation here other than to learn in
order to help the industry provide better bang for the buck software
solutions.
I make no money studying data modeling or from any of my work here. I
wonder what he thinks I'm promoting. I do have a blog and I promote
that. It does have ads on it (as an experiment). To date, google
analytics tells me that just over 5.000 "absolute unique visitors" have
read my blog and adsense says that I have made $69 (in 7.5 months), but
they do not distribute dollars until you get $100. So, that's my goal
for the year related to my database related research and writing.
Maybe someday I will make money in this particular field (I do make
money in s/w dev), but money has never been a motivation for me (I have
found that the lack of money can be motivating, however ;-)
> What you fail to understand is they are already entrenched in their
> minds. We can either surrender and allow them complete freedom to
> disseminate ignorance, or we can expose them for the charlatans they are.
When someone asks questions you think are stupid or states opinions
that you think are wrong, it seems it would be best to either ignore or
engage them, as you choose. Bullying the person is not on my list of
appropriate responses, and I'm sorry that Bob and company think it is
appropriate.
> In the two or three years when I stayed away and when Marshall and
> others pretended to engage Dawn at an intellectual level as a peer, the
> newsgroup gave her a semi-official glossary to pollute
I was given no such glossary. When the group was asked at various
times to provide definitions, I sometimes contributed. When my
contribution was acceptable, it was added IIRC.
> with her own
> ignorant misconceptions.
Some people only speak about topics on which they are certain (Bob
seems to fall into that category). I speak on topics about which I
have opinions, but often where I am not certain. I learn a lot that
way.
Contributing to a shared glossary, as with all writing for me, is a way
for me to learn if my definitions align with others or not (as well as
helping to minimize mis-communication due to having different
definitions). I think mAsterdam did a good job facilitating the
glossary.
I have never seen or felt such bullying before and prefer to spend time
where I am welcome, so I'll go back to lurking again soon. I recognize
that there is a risk in replying to me because you might be the next
target, and being bullied, even just in a news group, is not fun -- it
can be emotionally draining. So, to those who have defended my right
to express opinions and ask questions in this forum, many thanks and
cheers! --dawn
Keith H Duggar
> Bob Badour wrote:
> > Dawn is not here to learn. She is here to promote
> > herself and to advance her own economic agenda.
>
> Just to set the record straight for others (Bob filters me
> and attacks, trying to intimidate, those who respond to
> me, in case you haven't figured that out) -- I have no
> motivation here other than to learn in order to help the
> industry provide better bang for the buck software
> solutions.
Repeating a lie does not make it true. You know, simple
logic, A & A = A. One need only read your posts to see the
lie. Indeed you have even ADMITTED you came to advocate. Do
you deny this? Do you want me to dredge up your admission?
And how about all the "it's time to ditch ...", "we need to
abandon ...", etc crap? Isn't that advocacy?
> Bullying the person is not on my list of appropriate
> responses, and I'm sorry that Bob and company think it is
> appropriate.
How about calling people rapists and terrorists? Is that
appropriate?
> Some people only speak about topics on which they are
> certain (Bob seems to fall into that category). I speak
> on topics about which I have opinions, but often where I
> am not certain. I learn a lot that way.
It's not that you speak or ask questions. It's that you act
vociferously and /refuse to learn/. Along with other things.
> I have never seen or felt such bullying before and prefer
> to spend time where I am welcome, so I'll go back to
> lurking again soon.
Any idea when?
> I recognize that there is a risk in replying to me because
> you might be the next target, and being bullied, even just
> in a news group, is not fun -- it can be emotionally
> draining.
Not as draining as trying to defend knowledge from the VI.
(VI : vociferous ignoramus).
> So, to those who have defended my right to express
> opinions and ask questions in this forum, many thanks and
Stop playing in the straw. It's never been about your
freedom of expression, Dawn.
JOG
> [snip]
> Worse still, you don't have to be a genius to see that it often
> > entrenches them, they carry on disseminating mistakes and it
> > perpetuates ignorance as a whole.
>
> What you fail to understand is they are already entrenched in their
> minds. We can either surrender and allow them complete freedom to
> disseminate ignorance, or we can expose them for the charlatans they are.
I hear your advice, but I will not yet concede that /all/ are immovably
entrenched or motivated by personal agendas.
JOG
> Perhaps there is a theory definition of the word structure that you are
> using to draw the conclusion that the web does not have structured
> data. My take is that a single page can be a node/attribute with a
> value that is the html, for example, with directional paths to other
> nodes for which there are links in the page. Structure, no?
No, Marshall is correct. Information such as that on the web is known
in the scientific literature as Unstructured data. That which comes
between that and relationally represented data is known as
Semi-structured data. Definitions are woefully slapdash, but Google
scholar will supply a whole host of papers on the subject.
Bob Badour
I don't recall saying that type theory failed in any manner. Perhaps you
could point to where you reached that conclusion? Perhaps I misspoke, or
perhaps the comment applies within a limited context.
My only objection to "type = algebraic structure" is the requirement for
closure within a single type. For any type, we can define the algebra as
the type and the subset of the type's operations that exhibit closure.
In my view, the type includes the entire set of operations defined on
the values of the type including those not exhibiting closure.
For instance, an operation might have a single character string operand
with non-negative integers as result as is the case with the length
operation. That operation is certainly part of the character string type
and arguably part of the non-negative integer type. It is not part of
any algebraic structure. Or do I misunderstand something?
Square root is part of the algebra for non-negative reals and for
perfect squares but not for integers. It is, however, a valid operation
on integers resulting in values of a different type.
Division is not part of the algebra for any type that includes zero as
one of its values. Or is it?
Other than possibly the _Principle of Cautious Design_, I can think of
no immediate objection to a type where the set of operations in the
algebra is empty. On the other hand, it might be difficult to devise
such a type that has any use.
Gene Wirchenko
>Bob Badour wrote:
><snip>
>>
>> Dawn is not here to learn. She is here to promote herself and to advance
>> her own economic agenda.
>
>Just to set the record straight for others (Bob filters me and attacks,
>trying to intimidate, those who respond to me, in case you haven't
>figured that out) -- I have no motivation here other than to learn in
>order to help the industry provide better bang for the buck software
>solutions.
So your sly and not-so-sly attacks on Codd, 1NF, etc. never
happen?
>I make no money studying data modeling or from any of my work here. I
So?
[snip]
>> What you fail to understand is they are already entrenched in their
>> minds. We can either surrender and allow them complete freedom to
>> disseminate ignorance, or we can expose them for the charlatans they are.
>
>When someone asks questions you think are stupid or states opinions
>that you think are wrong, it seems it would be best to either ignore or
>engage them, as you choose. Bullying the person is not on my list of
>appropriate responses, and I'm sorry that Bob and company think it is
>appropriate.
They do not, but you have used the same sorry lines over and
over.
>> In the two or three years when I stayed away and when Marshall and
>> others pretended to engage Dawn at an intellectual level as a peer, the
>> newsgroup gave her a semi-official glossary to pollute
>
>I was given no such glossary. When the group was asked at various
>times to provide definitions, I sometimes contributed. When my
>contribution was acceptable, it was added IIRC.
>
>> with her own
>> ignorant misconceptions.
>
>Some people only speak about topics on which they are certain (Bob
>seems to fall into that category). I speak on topics about which I
>have opinions, but often where I am not certain. I learn a lot that
>way.
You speak with definite statements in areas where you do not
know.
>Contributing to a shared glossary, as with all writing for me, is a way
>for me to learn if my definitions align with others or not (as well as
>helping to minimize mis-communication due to having different
>definitions). I think mAsterdam did a good job facilitating the
>glossary.
>
>I have never seen or felt such bullying before and prefer to spend time
>where I am welcome, so I'll go back to lurking again soon. I recognize
>that there is a risk in replying to me because you might be the next
>target, and being bullied, even just in a news group, is not fun -- it
>can be emotionally draining. So, to those who have defended my right
>to express opinions and ask questions in this forum, many thanks and
>cheers! --dawn
I will be glad when you are gone again. Disagreement does not
bother me, but willful stupidity does.
Sincerely,
Gene Wirchenko