Richard A. O'Keefe wrote:
> Jimmie Houchin <jhouchin at texoma.net> has now explained his
> problem a bit more.
> 	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.
> 	
> AH *HAH*.  Now all becomes clear.  You aren't modelling a person at all.
> The thing you are REALLY modelling is a *FORM*.

No I'm modelling more than a form, but I am modelling an odd collection 
of information for diverse purposes. The name does have design criteria 
based on government forms. The name here is a mere 5-6 attributes of 
100+ for the aggregate person object. It is much more than a name or form.

Just because something is form data doesn't make it invalid in other 
context. Probably 70-80% (just an estimate, I could check my current db) 
of the *legal names* are also the names the people went by and are used 
in all of the other non-formal information we produce.

> (I'm a little unclear on the concept of "legal name".  My father (R.I.P.)
>  was a lawyer, taught law in two countries, wrote many law textbooks, and
>  told me on more than one occasion that someone can call themselves
>  anything they want as long as it isn't with intent to defraud.  Your
>  birth certificate may say "Phillip Arthur George McDonald Fraser McKie"
>  but you can call yourself "Bill McGonagle", even in contracts, without
>  having to inform the government.  I have no idea what USA law might be.)

I can't say what USA law states either. However, I can only put one name 
on the DC. I am willing to put whatever the Dr./Justice of the 
Peace/Coroner/Medical Examiner/Judge/etc. is willing to sign and 
Registrar is willing to file and the family is willing to be accountable 
for. I have yet to encounter a family who had difficulty putting down a 
proper name.

Whatever may be technically the legal boundaries is rarely the reality. 
Regardless the family will have to provide me with something I can put 
into the spaces.

> 	For all my forms the SSN or an 'unknown' or 'not available' must be 
> 	provided. Empty is not an option, it will be rejected.
> 	
> 	I will address these real life issues. The forms I complete have spaces 
> 	on them for *all* the above data.
> 	
> Right.  You are not modelling social reality, you are modelling
> official forms.

Only some of the time. The obituary, family record and such are not forms.

I write obituaries, death certificates, social security form 721, 
Veterans Administration forms, genealogical information. It's not just 
forms but the story (abbreviated) of the person.

> 	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.
> 	
> I'm rather unhappy about the idea of a legal system defining what is a
> legal first name and/or a legal last name.  (Yes, I'm aware of the practice
> in some Scandinavian countries of the government telling you what you can
> call a child/yourself, and I'm aware that some other countries do it too.
> It does prevent a certain about of silliness, but it can go too far.)

Well there does need to some definition and some consistency. I won't 
argue whether or not the standards are sensable. :)

> 	For obituaries I can put anything they want. For death certificates I 
> 	must put the legal name.
> 	
> So you have forms, defined by the government, and there are constraints
> and semantics for those things defined by the government.
> 
> 	> * 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.
> 	
> That tells me nothing, because I don't know what "legal first" and
> "legal last" are.  The point about Chinese and Hungarian names is that
> they write family name first, personal name last.  I'm _guessing_ that
> "legal first" means "personal" and "legal last" means "family".  But
> again, the point is that the thing you are modelling is not a JHPerson
> but a UsGovtDeathCertificate.

No, its a Person. The legal first and legal last are reasonable and 
sensable. Yes legal first and legal last are as you described. It is not 
unreasonable for an application to be modelled where it is actually 
used. I am not going to use Unicode for the character set on the 
possibility we might do business with a Klingon. I wouldn't not object 
to Unicode for other reasons. :)
I can't speak as to how I would handle Chinese or Hungarian names. I've 
never encountered such. Nor do I have a Chinese character set in my 
computer and wouldn't know how to use it if I did.

If I handled the service of a Chinese person or a Hungarian person I 
would put in the information what the family provided. Nevertheless it 
will still be a text string containing whatever information they say 
belongs there, whether I can say it or understand it.

JHPerson is not a government form. This discussion is regarding names, 
which not at all what JHPerson is limited to, not by a long shot.

> I think it will probably pay, long term, to regard the *person*'s name(s)
> and the *form*'s name fields as independent things and not try to derive
> one from the other, while making it easy in the user interface for people
> to copy one to the other for the common case where there is a simple
> relationship.
> 
> 	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.
> 	
> I don't think we _have_ a "legal designation" in this country, which is
> why I didn't understand.

This would be simply what is on the birth certificate or other legal 
document if the name was changed.

> Presumably someone's legal name is whatever it is the their birth certificate
> or their most recently accepted change of name form (if any).  What happens
> if a resident non-citizen dies?  How is the legal name defined then?

Whatever the non-resident's informant tells us it is, potentially 
verified by other forms of ID and documentation. Nevertheless they came 
into the country with some form of legal ID.

Seldom is there a question as to what the legal identity of the 
individual is. 99.999% of the cases there is no issue at all. Legal 
identity issues are generally well settle before we come into the picture.

> 	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.
> 	
> Yes, you need to tie the SSN to the person.
> No, not directly to "the" name.
> 
> William Kent's "Data and Reality" really is an indispensable guide.
> IIRC, he advises to use your *own* "surrogate" (approx= oid) for entities.
> Still talkikng in data base terms here,

I'll look into that. Sadly enough Amazon has no description. I see if I 
can locate the publisher for one.

It probably is an interesting read and will open my eyes to things I've 
never considered.

Does it discuss SQL? I would still read it but am not really interested 
in SQL.

>   There should be a Person relation with primary key PersonID
>   generated by YOU, *not* an SSN.
> 
>   You have already mentioned that SSN might be 'unknown' or
>   'not available', which makes it unusable as a primary key (for you).

True. Rare but true.

>   On your account, a person can have at most one SSN when they die.
>   The SSN is a property of the person, not of the person's name(s).
> 
>   So it makes sense to have Person(PersonID, SSN?, ...)
> 
>   There should be a DeathCertificate relation with primary key
>   PersonID which is also a foreign key for Person.  This describes
>   the form.
> 
>   Does the form require the address and legal name for the informant,
>   as well as for the deceased?  In that case, it makes sense for
>   legal name to be part of Person.

Yes.

>   It might then make sense to have a UsaLegalName domain.
> 
>   So you might have
>     Person(PersonID, SSN?, UsaLegalName, Address, UsualName, ...)
>     UsaDeathCertificate(PersonID, PersonID InformantID, Date, ...)

Reasonable enough.

> In this situation, it makes sense to have a UsaLegalName object
> split into fields because the fields exist on the form, but it's
> really the form that's being modelled, not the person.
> 
> 	But, I understand Richard. I quite concur with the frustration of 
> 	arbitrary decisions and constraints.
> 
> Just today I was unable to register on a web site to participate in
> a language standardisation effort I care about greatly, because it
> wouldn't let me spell my name correctly...

Yuck.

> One of the reasons why modelling business information is sometimes
> (sometimes!) easier than modelling "real life" is that what one is
> really modelling in the business situation is a set of forms.  In
> effect, one is modelling an already simplified model.
> 
> One of the reasons why this tends to make life hard for customers
> is that the computer is enforcing the simplified rules.  When it's
> your own system, and you're in complete charge, you can always work
> around it.

As stated I am the only customer of this product. If I err, I fix. :)

> On a vaguely related note, the NZ government wants people to save
> 10% on electricity use this winter.  The local newspaper pointed
> out a day or two ago that the town hall was still brightly lit at
> night.  A council spokesman apologise, and explained that they had
> been searching for days trying to find the switch...  Somewhere, a
> timer is still enforcing what seemed like a good idea at the time.

Yep.

Jimmie Houchin