Nearest Common Ancestor Report (XDb1's $1000 Challenge)

 > My guess is that XDb1 would accept the following without complaining:
 > person isa thing.
 > john isa person.
 > mary isa person.
 > neo isa john.
 >
 > XDb1 will probably gladly store it - but what does it mean?

At the db level, it would mean exactly the same as:
t1 isa t.
t2 isa t1.
t3 isa t1.
t4 isa t2.

At the db level, it doesn't care what the app is trying to encode. It
is upto the app to ensure the data has relavence to something. It
could mean the following:

vehicle isa thing.
car isa vehicle.
bus isa vehicle.
corvette isa car.

If Neo is a cloned from John, then even your example above could have
meaning.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

 > Who is older, John, Mary or Fido?
 > How can XDb1 (or any other type-less database) answer the last
 > question if the user has provided the following input:
 >
 > over-the-hill isa age.
 > very-young isa age.
 > 7 isa age.
 > john is over-the-hill.
 > mary is very-young.
 > fido is 7.

Again, the example provided earlier was simple. 7 can be further
classified as an integer (via 7 isa integer) thus allowing operations
appropriate to the integer class (aka "data type" in RM).

 > Most computers I have used will classify very-young as greater than
 > over-the-hill and will refuse to compare either of these to 7.
 > Like I said - there may be specific situations where a product such as
 > XDb1 has it's use. But it's not (to quote the web site) "the future of
 > databases" - not even remotely!

If I include human brains as computers (which they are), many of them
will come to the correct answer. XDb1 is partially a feeble attempt to
model and implement a db like that between our ears.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

  > > The ... statements creates the RM equivalent of the following:
  > > T_Name
  > > ID Symbo1 Sym2 Sym3 Sym4 .........
  > > -- ------ ---- ---- ----
  > > . ->J ->o ->h ->n
  > > . ->M ->a ->r ->y
  > > . ->8 ->0
 >
 > I would not call this "table" relational. It violates 1NF.

The above description of table T_Name was a simplification. Each thing
in XDb1 can have any number of names including none. Each name (ie
"John Smith", "Mary Smith") can be composed of any number of composite
symbols (ie "John", "Mary", "Smith"). Each composite symbol is
composed of any number of atomics symbols (ie 0-9, a-z, A-Z, etc). As
you correctly pointed, the composite symbols might be modelled more
appropriately as follows:

T_CompSymbol
ID Name
-- -----
.. ->Smith

T_CompSymbol_AtomicSymbol_Map
CSymID ASymID Order
------- ------ ----
->Smith ->S 1
->Smith ->m 2
->Smith ->i 3
->Smith ->t 4
->Smith ->h 5

T_AtomicSymobl
ID Sym
-- ---
.. a
.. b
.. c

 > If I did have the desire (which I don't have) to break down names
 > and values into individual letters and digits, I'd at least use a
 > design without repeating groups.

When a user enter "john smith isa person", XDb1 normalizes that data
down to atomic symbols, without "repeating groups".<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

On 18 May 2004 12:33:14 -0700, Neo wrote:

   >> > > you seem to desire the possibility to enter untyped data
   >> > All things in XDb1 are typed/classified.
  >> But I didn't use the word "classified", I used the word "untyped".
 >
 >In XDb1's data model type, class and domain are the same thing. Even
 >C.J. Date begins one of his chapters by saying "domain is essentially
 >a data type".

Hi Neo,

Well, I'm not much of a theorist. Even though I'm reading and writing this
from the .theory group (I don't subscribe to the other three this is
posted in), I am more a hands-on kind of guy.

That's probably the reason why I came up with a working solution, whereas
the theorists constrain themselved to hitting you on the head with a large
club for calling SQL Server and Access "reasonably close implementations
of the relational model". (Actually, for the Access part I' tempted to ask
them if I can borrow their club for a while :-> )

From my practical, hands-on real-world background, I treat types, classes
and domains as three different things. A class is a set of individual
items, events or notions from the real world that have enough attributes
in common to warrant treating them as individual items from one set. A
domain is the complete collection of allowable values for an attribute of
individual members of a class. I like to think of a datatype as a superset
of many domains. The domain for all integers is the same as the datatype
integer. The domain for attribute "age (in years)" of the class "employee"
is a subset of the integer domain.

(snip rest of your message - it's basically a repetition of an earlier
message and I can't find any point in it that I didn't already address in
a previous post)


Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

On 18 May 2004 13:01:31 -0700, Neo wrote:

  >> the schema should be strictly seperate from the data
 >
 >In XDb1's data model there is no separation between data and schema at
 >the db level, however the app logic can choose to make those
 >distinctions if needed.
 >
  >> and the datatype of the data should be known.
 >
 >In XDb1's data model, "data type" is simply an additional
 >classification of a thing. If it needs to be known, it should be
 >classified as such (ie. 35 isa integer).
 >
  >> And this is exactly the reason why I'd never use XDb1 for serious work,
  >> unless I encounter a problem area where the advantages of allowing untyped
  >> data outweigh the disadvantages.
 >
 >I think, I finally understand what you are saying. In the example,
 >since 35 was only classified as an age, it appears to be "untyped".
 >The example was simple. 35 can also be classified as an integer. Each
 >thing in XDb1 can have multiple classes, one of which can function
 >similar to its "data type".

Hi Neo,

Rereading what I wrote and what you replied, I may have chosen the wrong
word. (I'm Dutch - English is not my native language).

When I wrote "untyped", I meant that XDb1 performs no type checking. The
fact that you can classify 35 as an integer doesn't solve anything. I want
to be able to subtract John's age from Mary's age and be sure that the
result is their age difference, in years. That can only be achieved if the
database can be told that EACH age should be a whole number. That can be
done very easily in every RDBMS that I know. I have not yet seen how that
constraint can be built into XDb1.

Of course, you can allways do it in the application. But for something I
need very common, I prefer to have support built-in into my tools.

Note that I expect that at least 99.9% of my future work will require the
datatype of a value to be known to the programmer. This is based on 20
years of experience (where the percentage has always been 100%); the 0.1%
insecurity margin is included because I know that the unimaginable is
usually just about to happen.

Note also that MS SQL Server, the RDBMS I do most work on at the moment,
supports a datatype "sql_variant", that will store basically everything. I
have never used this datatype, not have I ever seen a question in any SQL
Server related newsgroup (and I participate in quite a few of them) where
this datatype would be the answer. And I expect I never will.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

On 18 May 2004 13:18:40 -0700, Neo wrote:

  >> My guess is that XDb1 would accept the following without complaining:
  >> person isa thing.
  >> john isa person.
  >> mary isa person.
  >> neo isa john.
  >>
  >> XDb1 will probably gladly store it - but what does it mean?
 >
 >At the db level, it would mean exactly the same as:
 > t1 isa t.
 > t2 isa t1.
 > t3 isa t1.
 > t4 isa t2.
 >
 >At the db level, it doesn't care what the app is trying to encode. It
 >is upto the app to ensure the data has relavence to something. It
 >could mean the following:
 >
 > vehicle isa thing.
 > car isa vehicle.
 > bus isa vehicle.
 > corvette isa car.

The English-like language you use in all XDb1 examples uses exactly the
same construction for modifying the meaning of the data ("vehicle isa
thing. / person isa thing." as opposed to "vehicle isa thing. / person isa
vehicle." and for modifying the data itself ("john isa person.")

The choice to use one syntax for modifying both intension and extension,
as opposed to the clear seperation of DML and DDL in SQL, gives me the
impression that end users of XDb1 databases will be allowed to use this
language to modify both the intension and the extension at will. While
that may be acceptable in some situations, it usually isn't,

OTOH, you sometimes write that the app should check things, like in the
above quote. That can only be done if the english-like language is not
made available to end users. But in that case, why would you bother to use
that language in the first place?


 >If Neo is a cloned from John, then even your example above could have
 >meaning.



Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

  > > Among other things, the difference in normalization between the
  > > implementations (still looking it over) is quite different.
 >
 > I don't demand that XDb1 should use a relational structure, you should not
 > demand that a RM solution uses XDb1's structure. If you want to compare,
 > do so at the level where it counts.

The report your solution generates is correct, I have no disagreement
with that. But the implemenation is generating it from unnormalized
data where as XDb1 generates it from data normalized down to atomic
symbols (ie a, b, c). Yes, I consider each symbol to be data. When
XDb1 prints the words 'john' and 'god' on the report it resolves down
to the one and only symbol 'o' in the db. The implementation provided
doesn't model the atomic symbols (ie a-z). As a starting point, the
word 'john' needs to be normalized as it appears multiple times in
multiple tables. Changing any one of them would corrupt the data. In
XDb1, there is only one instance of the word 'john'.

There is another issue that I will point out in another post.

  > > In an initial attempt to make them more comparable,
  > > I modified XDb1 algorithm so as to not
  > > resolve things' names and simply prints their IDs.
 >
 > Now you're changing the rules after the competition has started. Not a
 > sign of good sportsmanship, Neo!

I do not think so, data must be as normalized as in XDb1's db. In
general, there is no way XDb can compete with RM where a report is
being generated from simply one table.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

On 18 May 2004 13:52:07 -0700, Neo wrote:

  >> Who is older, John, Mary or Fido?
  >> How can XDb1 (or any other type-less database) answer the last
  >> question if the user has provided the following input:
  >>
  >> over-the-hill isa age.
  >> very-young isa age.
  >> 7 isa age.
  >> john is over-the-hill.
  >> mary is very-young.
  >> fido is 7.
 >
 >Again, the example provided earlier was simple. 7 can be further
 >classified as an integer (via 7 isa integer) thus allowing operations
 >appropriate to the integer class (aka "data type" in RM).
 >
  >> Most computers I have used will classify very-young as greater than
  >> over-the-hill and will refuse to compare either of these to 7.
  >> Like I said - there may be specific situations where a product such as
  >> XDb1 has it's use. But it's not (to quote the web site) "the future of
  >> databases" - not even remotely!
 >
 >If I include human brains as computers (which they are), many of them
 >will come to the correct answer. XDb1 is partially a feeble attempt to
 >model and implement a db like that between our ears.

Hi Neo,

Just caught this message. I think I addressed most points in my previous
posts. Except for the human brain part.

This places XDb1 in a completely different league from current RDBMS's, in
my eyes. If XDb1's main objective is emulating the human brain, I have to
consider it a very interesting research project, probably worthy of loads
of government and university funding.

Until now, based on your postings and the information about XDb1 on the
web site, I was under the impression that XDb1 was meant as a serious
alternative for current databases. Clearly, I was wrong.

But I still fail to see how the $1000 challenge that started this
discussion fits into this picture.....


Seriously now: if you one day really succeed in making a program that will
gladly accept data such as "very-young" and "over-the-top" and still come
to correct conclusion on only that data, *then* you can truly say that you
hold the future of databases in your hands. As well as the future of AI.
But until that day has come, you'd better learn a little modesty.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

On 18 May 2004 23:20:19 -0700, Neo wrote:

   >> > Among other things, the difference in normalization between the
   >> > implementations (still looking it over) is quite different.
  >>
  >> I don't demand that XDb1 should use a relational structure, you should not
  >> demand that a RM solution uses XDb1's structure. If you want to compare,
  >> do so at the level where it counts.
 >
 >The report your solution generates is correct, I have no disagreement
 >with that.

Thanks for the acknowledgement.


 > But the implemenation is generating it from unnormalized
 >data

Isn't Google just great? Here are Date's formal definitions for the five
(actually six, BCNF never got it's own number) normal forms, copied and
pasted from <a style='text-decoration: underline;' href="http://www.databasedesign-resource.com/normal-forms.html" target="_blank">http://www.databasedesign-resource.com/normal-forms.html</a>

(start quote)

First Normal Form

‘A relation R is in first normal form (1NF) if and only if all underlying
domains contain atomic values only.’

Second Normal Form

‘A relation R is in second normal form (2NF) if and only if it is in 1NF
and every nonkey attribute is fully dependent on the primary key.’

Third Normal Form

‘A relation R is in third normal form (3NF) if and only if it is in 2NF
and every nonkey attribute is nontransitively dependent on the primary
key.’

Boyce/Codd Normal Form

‘A relation R is in Boyce/Codd normal form (BCNF) if and only if every
determinant is a candidate key.’

Fourth Normal Form

‘A relation R is in fourth normal form (4NF) if and only if, wherever
there exists an MVD in R, say A -> -> B, then all attributes of R are also
functionally dependent on A. In other words, the only dependencies (FDs or
MVDs) in R are of the form K -> X (i.e. a functional dependency from a
candidate key K to some other attribute X). Equivalently: R is in 4NF if
it is in BCNF and all MVD’s in R are in fact FDs.’

Fifth Normal Form

‘A relation R is in fifth normal form (5NF) – also called projection-join
normal form (PJ/NF) if and only if every join dependency in R is a
consequence of the candidate keys of R.’

For every normal form it is assumed that every occurrence of R can be
uniquely identified by a primary key using one ore more attributes in R.


FD = Functional Dependency
MVD = Multi-Valued Dependency

(end quote)

And on another website (http://nunic.nu.edu/~ckettemb/DBNorm.html):

(start quote)

Domain Key Normal Form (DKNF)

We can also always define stricter forms that take into account additional
types of dependencies and constraints. The idea behind domain-key normal
form is to specify, (theoretically, at least) the "ultimate normal form"
that takes into account all possible dependencies and constraints. A
relation is said to be in DKNF if all constraints and dependencies that
should hold on the relation can be enforced simply by enforcing the domain
constraints and the key constraints specified on the relation.

For a relation in DKNF, it becomes very straightforward to enforce the
constraints by simply checking that each attribute value in a tuple is of
the appropriate domain and that every key constraint on the relation is
enforced. However, it seems unlikely that complex constraints can be
included in a DKNF relation; hence, its practical utility is limited.

(end quote)

If you really want to maintain that my implementation generated it's
report from unnormalized data, please tell me which Normal Form you think
I violated and why.


 > where as XDb1 generates it from data normalized down to atomic
 >symbols (ie a, b, c). Yes, I consider each symbol to be data. When
 >XDb1 prints the words 'john' and 'god' on the report it resolves down
 >to the one and only symbol 'o' in the db.

But a is not an atomis symbol at all! Most computers store an a as a
collection of 8 bits: 01100001 (97, the ASCII value of 'a').

I fail to see why you would you break down 'John' into J, o, h and n, but
since that's obviously what XBd1 does, I also fail to see why the breaking
down should stop at this (arbitrarily chosen) level. Why letters? Why not
bits? nibbles? syllables?


 > The implementation provided
 >doesn't model the atomic symbols (ie a-z).

And neither did XDb1's model. You're confusing implementation internals
with the model. The RDBMS model had phrases such as "insert things (thing)
values ('john')" / "insert types (thing, type) values ('john', 'person')".
The XDb1 model had phrases such as "john isa person".

Though XDb1's syntax is shorter and more English-like, it doesn't drill
down to the level of letters or symbols. I don't see any 'j' on it's own,
I only see the symbols 'john' and 'person' as a whole.

How XDb1 stores these symbols internally is interesting, but totally
irrelevant to the model. Same goes for the RDBMS. I don't know how SQL
Server stores 'john', and frankly I don't want to know. Maybe it
calculates a 400-byte bit battern from the individual letters, encrypts
that via 196-bit Rijndael encryption, swaps some bits and calculates a
checksum on top of that. Maybe it uses exactly the same way to store it's
data as XDb1. Maybe it even changes the way it stores data on a daily
basis, automatically converting all data at midnight. I don't know and I
couldn't care less, as long as "select thing from things" returns "john"
and not "jhon".


 > As a starting point, the
 >word 'john' needs to be normalized as it appears multiple times in
 >multiple tables.

And how does that violate normalization rules? If I changed the things
table to include an ID and a name, then changed all other tables to use
the ID instead of the name to refer to a thing, I'd still have the symbol
representing john multiple times in multiple tables. The fact that this
symbol now is the number 3 instead of the character string 'john' doesn't
change anything.


 > Changing any one of them would corrupt the data.

No. Changing any of them would result in a foreign key violation and the
transaction would be rolled back by SQL Server. You didn't miss the
"references" clauses in my DDL, did you?


 > In
 >XDb1, there is only one instance of the word 'john'.

And how many pointers (or similar structures that serve the same goal) to
that word?

 >
 >There is another issue that I will point out in another post.

It's now 15 hours since you posted this and I still don't see it. Could
you repost that message?


 >
   >> > In an initial attempt to make them more comparable,
   >> > I modified XDb1 algorithm so as to not
   >> > resolve things' names and simply prints their IDs.
  >>
  >> Now you're changing the rules after the competition has started. Not a
  >> sign of good sportsmanship, Neo!
 >
 >I do not think so, data must be as normalized as in XDb1's db.

  "I challenge you to make a wooden stair with screws and a
screwdriver in at most twice the time it takes me to make a similar chair
with nails and a hammer".
  "Done!"
  "Hmm, nice chair indeed. And you even finished before me. But I
see that you inserted the screws by rotating the screwdriver. That was not
the intention. You should have hit the screws repeatedly on the head with
the blunt end of the screwdriver, like I hit the nails with my hammer".

The challenge was "to produce the equivalent Nearest Common Ancestor
Report from normalized and NULL-less data and the solution must be as
generic, meaning allow the user to create any hierarchy, consisting of
different types of things (each type to allow different attributes)
and each thing in the hierarchy to have any number of parents".

There was nothing in the original message or the webpage mentioned in it
about mimicing XDb1's internal data structure, not about storing the
character 'o' only once. If that had been the challenge, I'd never have
bothered - I'm not in the habit of using a screwdriver for hammering
screws in wood.

I fulfilled all requirements you set for the challenge. I just checked all
groups this is crossposted to but saw no other entries. I hereby claim the
$1000 prize. Please trasfer the money to my bank account: International
Bank Account Number (IBAN) NL59 RABO 0118 3365 68 (bank information:
BIC/SWIFT address RABONL2U).


 > In
 >general, there is no way XDb can compete with RM where a report is
 >being generated from simply one table.

I fully agree with that. Even without the where-part.


Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

  > > Among other things, the difference in normalization between the
  > > implementations (still looking it over) is quite different.
 >
 > I don't demand that XDb1 should use a relational structure,
 > you should not demand that a RM solution uses XDb1's structure.

And I don't demand that a RM solution use XDb1's structure, only that
it provide a solution that normalizes the data to a similar extent.
For example, if the user names the first person 'john' and the dog
also 'john', your current solution won't work.

In XDb1, the solution will still continue to work, although it should
also print each thing's class (ie "person/john" and "dog/john") so
that user can distinguish them on the report. In XDb1, if the user
names the first person 'john', the second person 'mary' and the dog
'mary john', there would still be only one occurance of the word
'john' and one of the word 'mary' in the db ('mary john' would be
composed from references to 'mary' and 'john').<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

  > > Among other things, the difference in normalization between the
  > > implementations is quite different.
 >
 > It should not matter HOW my implementation generates the report.

It does matter because a less generic and unnormalized implementation
will cause more problems or even fail under a broader scope. For
instance when the names of two things are the same.

Another isssue with the provided implementation is that the class
hierarchy is not modelled faithfully. A part of the original hierarchy
is shown below:

thing
god
person
john
mary
dog
fido ...

In the provided implementation, the class hierarchy is (flat):

thing
god
person
john
mary
dog
fido ...

Thus, if a person is named 'skippy' and a dog is also named 'skippy',
and we print a thing's class to distinguish them on the report, XDb1
would print:
person/skippy
dog/skippy

whereas the provided implementation would print:
thing/skippy
thing/skippy<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

   > > > This indicates an elapsed time of less than 3 ms ...
  > >
  > > Among other things, the difference in normalization between the
  > > implementations is quite different.
  > > In an initial attempt to make them more comparable...
 >
 > Now you're changing the rules after the competition has started.
 > Not a sign of good sportsmanship, Neo!

The provided implementation was not similarly generic or normalized.
To make a very rough comparision, I simplified my implementation to
that which was provided. In general, XDb1 can't compete with RM in the
scope of a single table's worth of data since XDb1 has the overhead of
variable storage structures for each table cell. An yes, IDs are
faster than text so the comparision is far from perfect. XDb1 should
gain advantage as more tables are joined. The provided solution
doesn't join any tables since it is less generic and unnormalized.

As I said earlier, in the simplfied case, it takes XDb1 2 or 3 ms on a
500 Mhz, 512MB Dell PowerEdge Server. I ran the provided SQL Server
script on the same machine and the report generation takes 65 ms
(based on the avg of the 3 runs below):

Starting time Ending time Time Elapsed
------------- ------------ ------------
14:44:57.670 14:44:57.733 67 ms
15:02:26.233 15:02:26.297 64 ms
15:07:57.780 15:07:57.843 63 ms

What might I be doing wrong to get results different than yours?<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge) 

On 20 May 2004 11:25:21 -0700, Neo wrote:

   >> > Among other things, the difference in normalization between the
   >> > implementations (still looking it over) is quite different.
  >>
  >> I don't demand that XDb1 should use a relational structure,
  >> you should not demand that a RM solution uses XDb1's structure.
 >
 >And I don't demand that a RM solution use XDb1's structure, only that
 >it provide a solution that normalizes the data to a similar extent.

Already adressed in another message.

Really, neo, is it really necessary to repeat the same argument over and
over again? And is it really necessary to use three seperate message to
respond to one message of mine? It's getting quite hard to keep track of
everything in here if you keep splitting the thread like this.


 >For example, if the user names the first person 'john' and the dog
 >also 'john', your current solution won't work.

Indeed, it won't. And neither will XDb1.


 >In XDb1, the solution will still continue to work,

Should? Maybe, I don't know - I didn't design the thing. But it DOESN'T
continue to work, and that's the only thing that counts at the end of the
day.


 > although it should
 >also print each thing's class (ie "person/john" and "dog/john") so
 >that user can distinguish them on the report.

You obviously did not test this before you wrote this. Or you are a flat
out liar (but for now, I'll give you the benefit of the doubt - by the
way, did you already instruct your bank to transfer the $1000 you owe me?)

I downloaded XDb1, created a new database and fed the data from Ex076 to
XDb1, changing only 'fido' to 'john' but nothing else (by the way, is
there no way to execute an entire script at once in XDb1? I ended up
copying and pasting the script line by line, but there's got to be a more
efficient way, right?) Here's what happened:

Up until "dog isa thing" all went fine (of course - I had not executed one
if the changed lines yet). XDb1 accepted "john isa dog" just fine (unlike
what my SQL Server implementation would have done), but in spite of what
you say that "should" happen, XDb1 did not recognise john from john. There
still was only one john, classified as both a person and a dog and aged
35. The next lines went fine, until I came to "fido leader john", which I
of course changed to "john leader john". This resulted in an error
message: "Circular relation not allow." I skipped this one, continued to
enter the rest of the expression, than generated the nearest common
ancestor report. This was the output:

Common Ancestor Report for 'god'
ThingX ThingY CmnAnc Dist
army john army 1
army laptop1 army 2
army mary army 1
army trinity god 2
army luke god 3
john laptop1 john 1
john mary mary 1
john trinity trinity 2
john luke luke 1
laptop1 mary mary 1
laptop1 trinity trinity 2
laptop1 luke luke 2
mary trinity trinity 1
mary luke trinity 2
trinity luke trinity 1

If "continue to work" means that you still get *some* output, yes, then
XDb1 still continues to work. But it's not even close to the output of the
original input (when the dog was called 'fido'). And the report certainly
doesn't print "person/john" or "dog/john".


 > In XDb1, if the user
 >names the first person 'john', the second person 'mary' and the dog
 >'mary john', there would still be only one occurance of the word
 >'john' and one of the word 'mary' in the db ('mary john' would be
 >composed from references to 'mary' and 'john').

As I pointed out before - how the data is stored internally is completely
irrelevant. The relational model is not about how data is represented
inside a computer, it is about how relations between things are modelled.
You set a challenge to generate a report in the relational model, so let's
stick to that model and not discuss XDb1's internals anymore.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Nearest Common Ancestor Report (XDb1's $1000 Challenge)