TMG-L Archives

Archiver > TMG > 2004-07 > 1088793524


From: "Lee Kaiwen" <>
Subject: RE: [TMG] RE: Assigning ID Numbers
Date: Sat, 3 Jul 2004 02:38:44 +0800
In-Reply-To: <20040702070453.20195.qmail@web80108.mail.yahoo.com>


Thanks, Tim, for your considered reply. I really appreciate the time and
effort you spent. It's given me some good opportunities for further
reflection. I'll keep my reply as brief as possible.

> should I put all birth certificates together, or ... keep all
> documents together that pertain to each individual?

Sorry, I wasn't clear in my first post, but I AM planning to file my
documents by document type. Within types I'll just assign numbers
arbitrarily as the documents come in, and maintain an index page. The
numbering system is mostly for the pedigree charts and family group folders,
within which I'll largely be keeping family group sheets, pointers back to
source documents, research notes, some indices, occasional pages from
compiled histories, and so forth.

> the difficult task of assigning IDs based upon a pedigree
> number .... idea is not a very good one in my opinion.

On further reflection, I'd already reached that conclusion; it wouldn't
solve the problem of excessively large ahnentafels. With ahnentafels in the
trillions, reduction even by a factor of 32 (assuming 32 individuals per
page) would still leave me with 12-digit numbers.

> What about ... a previously unknown child... you need to add?

Or deleting a child, or reordering children. It's occurred to me. Birth
order isn't critical to my system, so the solution may simply be to allow
arbitrary assignment of dot-numbers within a family group. Start with birth
order if you want, perhaps, but don't sweat it if the numbers get out of
order later; you can always check the family group sheet if you need to.

> listen to Mr. Tim Powys-Lybbe ... rich with ... challenges

I'm chagrined to admit admit I haven't see his advice. It's difficult to
keep up with the volume in this list; I usually just scan subject lines for
the interesting or relevant stuff.

I AM interested in challenges to my system. The organizationalist in me is
intrigued by the challenge of developing a useful system just as an exercise
(in futility? Perhaps), even apart from my ad hoc motivations.

> There has to be a reason where every
> system designer does it this way.

<Smile>. You know the story of the pot roast, right? Young girl asks mother
why she cuts the pot roast in half before cooking it. Mother replies,
"That's what my mother taught me." Girl asks Grandma, gets the same reply.
Finally, she asks Great-Grandma who replies, "Because all my pans were too
small." A reason? Certainly. A GOOD reason? Hmm.

As I former technology consultant, I've some familiarity with both the
advantages of electronic databases and the exigencies of their design, so I
understand what you're saying. But I'm not convinced all those exigencies
apply in the "real world" -- or rather, there may be additional real world
exigencies that electronic databases don't need to account for. For example,
you say reference numbers should be "dumb"; however, I note that libraries
have long employed intelligent numbering systems, nor do they seem keen on
abandoning them now they've switched to electronic card catalogs.

My feelings are probably three parts philosophical, and in part I agree with
much of what you say. But when you say, "Let the computer do its job", part
of me hears, "Cede all control." What if I actually WANT to make an inquiry
sans computer? Or what if my computerphobic Aunt Luella wants to browse
through my research? The idea of a collection that's inaccessible WITHOUT a
computer just doesn't give me the warm fuzzies.

And of course, we're all familiar with the downside of computerized
databases -- data can be rendered inaccessible for many reasons, not the
least of which is locking it away in proprietary database formats (and in
genealogy there IS no open format, GEDCOM notwithstanding). Not that
electronic databases don't have their uses; I'm just not convinced, given
their downside, we should be absolutely dependent on them.

Of course, any manual system will require extra work to maintain. But a
well-designed system in addition to flexibility, will be designed for ease
of use. I think my system shouldn't require an exhorbitant amount of
overhead -- generating an ID is straightforward, and then one simply needs
to add it to the individual's computer record.

Further, computers don't really make decisions at all; they just apply rules
designed by people -- in this case rules designed for computers, and not
necessarily the "real world". In any case, since the real advantages of
computers in genealogy go far beyond -- and do not depend on -- the
particulars of ID assignment, a well-designed program shouldn't care how or
by whom it is assigned.

> the computer has far better methods of keeping
> track of all of this intelligence

The computer can certainly do it faster and with less effort, but since
those "methods" -- or rules -- are designed by the programmers, what you're
really saying is that the designers have better methods than I do. Which
sounds like a challenge to me, and I love challenges!

> with a few simple keystrokes, the computer can
> ... alternate views ... including other ahnentafels

If Great-aunt Gertrude wants to locate her four-times-removed third cousin,
she only needs to look up his ID number in the name index list.

> You probably do not anticipate a need for such, but you never know.

Unanticipated needs are a problem faced by every system designer.
Flexibility is the key.

> the computer can always tell you exactly where to go

This, of course, is my great fear :-)

Lee Kaiwen,
Taiwan


This thread: