Richard A. O'Keefe wrote:
> Jimmie Houchin <jhouchin at texoma.net> wrote about converting
> a data base to Smalltalk.  I was _just_ able to keep my oar out
> until I spotted this:
> 	>>JHPersonName (first, middle, last, maiden, suffix)
> 	JHPersonName probably should be
> 	JHPersonID and have 'first middle last maiden suffix ssn' instance 
> 	variables. ssn is the US Social Security Number our government ID number 
> 	for citizens.
> 	
> First off, no, that's NOT what an SSN is.  It is perfectly possible
> for a US citizen not to have an SSN.   It is also possible for a US
> citizen to have more than one SSN, or so I am credibly informed.  And
> of course it is possible for non-US-citizens to have US SSNs.  The
> SSN is basically the same as our TFN (Tax File Number), and the only
> legitimate reason for holding someone's SSN (or TFN) in a database
> is if the person and the database owner are involved in reportable
> taxable transactions.  Read the comp.risks archives for more than you
> want to know about the problems of SSNs.

Yes a non-citizen may have an SSN, but to my knowledge one cannot have 
legally have multiple concurrent SSNs. In my 15 years of dealing with 
the Social Security Administration and their paperwork, I have not 
encountered such. Nor do their forms indicate such possibility. I was 
imprecise in my description. It was merely meant as a basic description 
for someone who may not be familiar with what it represents.

Actually I can name several reasons for having a SSN that have 
absolutely nothing to do with taxable transactions.

Almost every government and other form I complete requires the SSN.
Death certificates, SS721, Veterans Administration, Insurance forms (now 
that one does have some monetary implications, but not purpose of the 
SSN as the SSN given no longer pays taxes.)

I wasn't going to mention such but it seems beneficial to clarify 
things. I am a licensed Funeral Director. I fill out legal certified 
documents. They have certain data criteria.

For all my forms the SSN or an 'unknown' or 'not available' must be 
provided. Empty is not an option, it will be rejected.

> The thing I really want to take issue with is this
> "first, middle, last, maiden, suffix" stuff.

I will address these real life issues. The forms I complete have spaces 
on them for *all* the above data.

> These are REAL examples:
> 
> * What are you going to do about people who only have one name?

Never encountered one, but fine, they do exist (probably all in 
California and I live Texas :).
While thinking about this the other day for a moment I had the thought 
of how would I handle  "The Artist Formerly Known as Prince". :)
Blank middle names are fine. Last name I would have to put 'No Last Name'.

> * What are you going to do about people who have exactly two names?

Middle name can be empty without problem.

> * What are you going to do about people who have more than one
>   name, but they don't fall into the pattern of "first" and "last"?

The legal first name will be the first name, and the legal last name 
will be the last name. All middle name(s) will go in the middle.

> * What are you going to do about people who have two names (person,
>   family) in their own language but use a third name in an Anglophone
>   country (e.g. "Ling (Charlie) Wong")?

For obituaries I can put anything they want. For death certificates I 
must put the legal name.

> * Do "first" and "last" really mean "written first" and "written last"
>   or are they code-words for "personal" and "family" name?  Is there
>   an expectation that names should be sorted with "last" name as most
>   significant?  In that case, what about Chinese and Hungarian names?

Legal first, legal last.

> * What about people with more than three names?  (Like my father,
>   John AEneas Byron O'Keefe, commonly known as Byron.)

Addressed above.

> * In general, what about people who have three names, but don't go
>   by their first name.  (Like my sister-in-law Andrea Fiona Ferris,
>   known as Fiona.)

Obituaries whatever the family wants. Legal documents, legal name.

> * What about people with compound surnames, like
>   (Cornelius) () (van der Vecker)?  (This one has no middle initial.)
> 
> * What about people whose names have an honorific in the middle?
>   For example, an Irish speaker told me that my name would be written,
>   in Irish, as "richard ursul o caiv" where the "ursul" bit means,
>   IIRC, "young knight" and functions like "Mr".
> 
> * When it comes to suffix, which rules are to be used?
>   According to Miss Manners (Judith something-or-other; I have several
>   of her books but haven't unpacked them since the last move) the
>   correct rule is that when the oldest bearer of the name dies,
>   everyone remaining moves up one, so that if for example all your
>   family are dead, you have no suffix, no matter how many of your
>   ancestors had the same name.  How is the data base to be informed
>   of this?  Or will the data base use the rule Miss Manners says is
>   incorrect, and everyone will keep their suffix unchanged?
>   (I'm assuming that the suffix is "Jn", "Sen", "3rd" and so on.)

Suffix is used to designate the legal designation as would be on a birth 
certificate. Senior, Sr. does not exist generally in the legal sense. 
But myself being Jimmie Lee Houchin, Jr., Jr. would be mine.

> * What about honorifics that go at the end of a name?  (Like my uncle,
>   J. Edward O'Keeffe, Esq.  Yes, he used two "f"s, my father used one.
>   My grandmother could never make up her mind which to use...)  It's
>   in the "suffix" position, so is "Esq(uire)" a suffix?  (He's another
>   example of someone going by a middle name, not a first name.)
> 
> * What about people who have married more than once?  A Californian
>   friend of a friend of my dad's had no fewer than three legal names
>   at the same time.

I have recently done such, put multiple last names on the death 
certificate. It is very uncommon to do so. Makes me no difference as 
long as the state Bureau of Vital Statistics accepts it.

> * What people want you to call them is not necessarily how they want
>   to identify themselves to you.  Mrs John Wilkes, as she wants you
>   to call her (see Miss Manners for why it's "John", not "Mary")
>   may want to offer her passport, which still reads "Mary Robinson",
>   for identification.  (After my marriage, my wife wished to be known
>   as Mrs Jeanene O'Keefe, but her passport said Jeanene Ferris; so
>   this is a very real example to me.)

We put down whatever the family states is the legal name. The family is 
on record as being informant and responsible for such.

> * What about people who change their names?  (For example, William
>   Thompson gets a bit political about his Polynesian ancestry and
>   changes his name to Wiremu Tamehana.  Or, thinking back to
>   "Switched-on Bach", Walter Carlos becomes Wendy Carlos.)

Whatever is the legal name.

> * What happened to honorifics, anyway?  If someone tells you he is
>   Professor Dr Sir Karl Elias, he probably doesn't want you to ignore
>   most of it.
> 
> * From a relational point of view, it doesn't make sense to put
>   SSN with name.  Someone can change their name without changing
>   their SSN.  Someone can change their SSN without changing their
>   name.  The number of names someone has and the number of SSNs
>   someone has are not related.

This is true. But I do need somewhere to tie the persons UUID (SSN) to 
their name. I might have multiple 'John Smith's but their SSN should be 
unique.

> I've sweated over this one for years.  I have been extremely annoyed
> at data bases that insisted on getting it wrong (like the people who
> send me mail addressed to RA Okeefe--I am not now and never have been
> a sun god).  There are complex solutions.  But there's also a simple
> solution.
> 
> (1) A name is a pair of strings.  One of them is a sort key, and
>     the other is for display.  It may suffice to use a bracket
>     convention:  "[Wong] Sie Lin" vs "J Strother [Moore]" -vs-
>     "{Professor Dr Sir} Karl [Elias]" -vs- "K. Edward [O'Keefe] {Esq}".
>     For sorting, take the bracketed part as primary key, everything
>     without the braced part as secondary key, and the whole thing as
>     tertiary key.  For display, delete the brackets and braces.
> 
> (2) People don't have names.  Instead there is a *relation* between
>     people and names.  (See William Kent's "Data and Reality".)
> 
> (3) Any of a person's names should be acceptable in input, but one
>     of the names should be designated as the preferred name for output.
> 
> This suggests a design fragment like
> 
>     JHPersonName (sortKey, displayText, whenValid)
> 
>     JHPerson (perferredName, otherName*, ssn?, ...)
> 
> But as someone else has already pointed out, you should approach
> a design problem like this NOT by saying "what structure can I
> perceive in the small range of name types I am familiar with" but
> "what do I actually need to DO with names?"

Tis true and I did withhold that (domain) information from the list.

> (Similar observations apply to addresses.  I am fed up with
> Web forms that won't let me submit them until I have filled in
> a state.  My country only has 4 million people.  We _haven't_
> any states.  Don't divide an address into standardised USA
> parts unless you really have to.)

For my app it probably needs to and will be appropriately so. Any legal 
paperwork I do will be for someone in my immediate area and as such will 
have such type data.

Fortunately this will be an in-house application. It will be written by 
me and for me. When I encounter areas where I am short-sighted (and I 
will) I have the freedom and liberty to correct them. And with Squeak 
the power. :)

You mention many real issues, and I withheld the domain of the app.
My bad.

The name attributes I mentioned were purely for the legal name.
Names are legal labels. Most of the mucky muddy exists outside of the 
legal description. It is understood by the government and companies 
(insurance, etc.) that women's names change and that the legal 
identifier I use on my paperwork may not match what they used on theirs 
whenever.

I actually do have other variables for names for things like obituaries 
where we have complete freedom to do what the family wishes.

Personally I think this is an area where Squeak could excel.
Business apps, vertical industry apps, data-centric apps.
Not that it doesn't excel elsewhere. :)

Hope this helps clarify where my thoughts were coming from and the 
constraints I am dealing with. The questions above are all very valid. 
It just happened I have most of those answers regarding my domain.

I was naive regarding the implications of my questions and the apparent 
impact my domain was going to have on prospective answers.

But, I understand Richard. I quite concur with the frustration of 
arbitrary decisions and constraints. I greatly encourage educational and 
informative responses to any of my emails. I want to understand and 
learn. I have many, many software ideas I want to implement. The other 
domains I might not understand so well.

My wife went to a sight the other day to register for a conference. She 
was denied online registration because she wasn't using IE6 or NS6. 
Their secure server used 128bit SSL. I viewed the source, saw the JS 
gatekeeper which rejected anything but id strings of IE6 or NS6. Yuck.

Capability wasn't an issue, but an arbitrary political decision. I 
looked at the correct URL and successfully established a secure 
connection with both IE5.x (latest on Mac) and NS4.7. Ugh!!!
No technical reasons. I launched an email to the webmaster. :)

Thanks for the education. It is easy to view the world with a vary 
narrow lense and make incorrect and arbitrary decisions. Fortunately 
this list is a big window to let the light in.

Jimmie Houchin