I want to thank all who have given advise and wisdom in answer to my 
question. I am very glad I asked. :)

It seems that the advise was:

1. Don't get too wound up about it. :)
      Smalltalk is easy to refactor as true objects/classes
      become apparent in the code.

2. Its about behavior and not data structures.

3. Potential independence of the object outside of its owner/possessor.


Tom Phoenix wrote:
> On 9/29/07, Jimmie Houchin <j.squeak at cyberhaus.us> wrote:
> 
>> Is this a correct way to do this in Squeak or am I off base?
> 
> I don't see anything necessarily wrong with your approach. On the
> other hand, I don't see that it's an especially helpful way to
> approach your task. The best way to find out whether it's "correct" or
> not is to try to implement it. To find out whether one way is better
> than another, implement both.
> 
> In some languages, there's mostly one way to do a given task. But
> Squeak (Smalltalk) generally allows you to structure your code and
> data in a wide variety of ways, depending upon your needs and skills.
> Further, it allows you quickly and easily to refactor your design once
> you see enough of it to know what changes are needed.
> 
> In particular, factoring out a person's birth info might make
> especially good sense if that BirthInfo object might be passed around
> without the rest of the Person; I can imagine that for some
> applications. But if the Person and the BirthInfo always stick
> together, I foresee many methods delegating like this, for little or
> no benefit:
> 
>   Person>>daysUntilBirthday
>     "Answer the number of days (0-365) until this Person has a birthday."
>     ^self birthInfo daysUntilBirthday

When modeling this I hadn't thought about the BirthInfo being passed 
around per se, it was really more of a data structure providing a 
variety accessor methods to the data.

> On the other hand, if you might have place-and-date-and-more about
> Birth, and also similarly about Death, Marriage, Adoption, Childbirth,
> and so on, an EventInformation object might make sense to unify the
> way you handle that data. It's all about the nature of your task, and
> how it can best be broken into manageable pieces.

The website I am developing is a church website for the Worship Team. So 
that definitely affects how I model the person. I am trying to offer a 
whole lot of functionality that the current website (that I didn't 
design) that I am migrating from has. So when I look at the data I have 
to migrate, some of the birthdays in the database are in error. Some 
people don't reveal a year of birth, or intentionally give an incorrect 
year. So I have to deal with people who want year of birth to be private 
data.

As a Funeral Director of 20 years, I have somewhat modeled a person 
object in the database I wrote to generate the regular paperwork I have 
to do when serving my families. For this case, the person object is 
incredibly complex.

Fortunately for me this person object will be far simpler. :)

> In the end, there's no substitute for experience. Have a good one!

Yes, absolutely!  But I am happy to avail myself to the experience, 
wisdom and knowledge of those who have traveled down the road before me, 
as I acquire my own experience.

Thanks. And again, thanks to all who helped.

Jimmie