Well factored Objects

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu May 1 02:33:17 UTC 2003


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*.

(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.)

	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.

	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.)

	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.

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.

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?

	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,

  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).
  
  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.

  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, ...)

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...

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.

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.



More information about the Squeak-dev mailing list