New biograph maturity date columns Was: Re: [Babase] CADET
Stephanie Combes
babase@www.eco.princeton.edu
Thu, 07 Oct 2004 12:04:58 -0400
Hi all -
I think we need to think about males and females differently. Female
maturities are nice and discreet. Males are not. But, for those born into
the study groups, we have a pretty good sense of maturational events. I
think the actual rank dates and mature dates for these should stay as
"real" dates, i.e. ones for which we are pretty confident. I still like
the idea of having separate "ranked by" and "matured by" columns for
immigrant males. Some of these guys are so grown up that mixing their
dates with the "real" dates seems potentially dangerous - in terms of
mixing things up. The ranked by and matured by columns would be used, for
example, when we want to figure out who potential fathers could be. Then
we just want to know who's absolutely an adult in certain years - accuracy
to the month isn't necessary. But, if we are really trying to look at male
maturational events, we would want to use the "real" dates. I worry that
if we mix them and then code or flag them, we could potentially end up with
an analysis combining good dates and "just for your information" dates. We
don't need "ranked by" or "matured by" for females. So, I still vote for
the original separation.
-steph
--On Thursday, October 07, 2004 11:01 AM -0500 "Karl O. Pinc"
<kop@meme.com> wrote:
>
> On 2004.10.07 10:01 Susan Alberts wrote:
>> My response is below in the stream...
>>
>>>> My understanding was that the rankdate and maturedate in the new
>>>> tables would exist only for animals for whom we actually know the
>>>> date they matured or became ranked.
>>>>
>>>> There is a large set of males for whom these dates are missing
>>>> because, when we first met them (when they first immigrated into
>>>> study groups) they were already adult. Hence, they have no
>>>> maturedate or rankdate (the markers of subadulthood and adulthood,
>>>> respectively, for males) even if they have already achieved one or
>>>> both of these markers.
>>>>
>>>> One things that we often need to ask babase is "find all the adult
>>>> males in group x on this date". As it is currently constructed,
>>>> this is very difficult to do because there is no marker of
>>>> adulthood encoded in babase except matdate and rankdate, which are
>>>> missing for many males. "Mature by" and "Ranked by" dates would
>>>> provide this.
>>>>
>>>> For males for whom we already have matured dates and ranked dates,
>>>> these columns would be redundant. However, this is a relatively
>>>> small fraction of all the males in the database. I envisionsed
>>>> using the rankdate and maturedate when analyzing/asking questions
>>>> about the age at which these events happened, and using "ranked by
>>>> and matured by" to differentiate adult and subadult from juvenile
>>>> males for any particular time period.
>>>
>>> Rather than having two columns with the same information, at least
>>> some of the time, my inclination would be to have a status flag that
>>> indicates whether the date should be used in analysis, or rather
>>> what sort of analysis the date is suitable for. The traditional
>>> problem is keeping duplicate data in sync. We can use triggers
>>> to enforce this (probably) but I'm still dis-inclined as the
>>> practice goes against the way relational databases are supposed
>>> to be used. It could be something of a forced fit, both from
>>> the tech side and when it comes to using the data.
>>>
>>> On the other hand, we can do it. What advantages do you see
>>> to having another date field vs a status flag for each date?
>>
>>
>> As I see it the problem is that even though the values have similar
>> names, they really have totally different functions in the database.
>> In other words, there are no dates to put status flags on for most
>> males. It would seem highly artifical to assign a rankdate to a male
>> that immigrates into a study group at the advanced age of 14, for
>> instance. It makes me uncomfortable to equate the two values. Also,
>> it's not that we DO want to use some values and DONT want to use
>> others, it is that they serve different functions.
>
> When would 'ranked by' be a different date from 'rankdate'
> or 'mature date' be a different date from 'matdate'?
>
> Maybe my problem here is that I don't see the males and females
> as being different populations? Is it that I don't see enough of a
> difference between males and females that different sexes
> need different columns to record maturation events?
>
> Let's write definitions of each current and proposed data element.
> The clarity of what we would write for each scheme is a good
> clue. (I also think that, in general, how easy it is to
> impliment is a good guide too. It seems that a status field
> would be an order of magnitude less work, or thereabouts.
> Not that we're talking much work in toto regardless so don't
> let that be a overwelming consideration.)
>
> (From the current docs)
>
> RANKDATES.Ranked
> The date the individual first attained a rank among adults.
>
> MATUREDATES.Matured
> The date the individual reached sexual maturity. This is the
> date of "menarche" for females and the date of testicular enlargement
> for males. All sexually mature individuals should have a value.
> (The current doc says all sexually mature individuals should have
> a non-blank value, but since we moved it from BIOGRAPH if it
> does not have a value it does not exist.)
>
> MATUREDATES.Mstatus
> Sexual maturity status. This field records the quality of the
> sexual maturity date. (Current docs says "When this field is empty the
> sexual maturity date is from recorded observation." but that is no longer
> right, there must be a value.) Summary: Meaning of "E" value, MSTATS
> support table.
>
> (New)
>
> RANKDATES.Ranked
> (new stuff) For immigrent males the rankdate is the date we guess they
> reached some rank wherevere they came from. Or ... the date they
> were first ranked in a study group.
>
> RANKDATES.Rstatus
> Whether the rankdate was obtained by direct observation or guess.
> Or....
> Whether we know the rankdate is the earliest date the individual
> actually obtained rank (because we observed it) or whether the
> individual (probably) obtained rank elsewhere andthe rankdate
> is merely the first observed rankdate.
>
> (The alternate scheme)
>
> RANKEDBY.Ranked
> RANKDATES.Ranked when the individual was born into our study group,
> or the earliest observed rank date for immigrents.
>
>
>>
>>>
>>>>
>>>>>> The other thing that I think we need to add for males is "ranked
>>>>>> by" and "matured by" (and perhaps dispersed by, although the
>>>>>> first two are by far the most important) columns or a new table.
>>>>>> This is because when a male enters the study population already
>>>>>> as an adult he never gets a matured or ranked date, creating the
>>>>>> contradictory situation that a male who appears to have never
>>>>>> matured is functioning as an adult male. This has been a constant
>>>>>> source of confusion that we've had to work around.
>>>>>
>>>>> How would the new "ranked by" and "matured by" be different from
>>>>> the current rankdate and maturedate?
>> http://www.eco.princeton.edu/mailman/listinfo/babase
>
> Karl <kop@meme.com>
> Free Software: "You don't pay back, you pay forward."
> -- Robert A. Heinlein
> _______________________________________________
> Babase mailing list
> Babase@www.eco.princeton.edu
> http://www.eco.princeton.edu/mailman/listinfo/babase