New biograph maturity date columns Was: Re: [Babase] CADET
Karl O. Pinc
babase@www.eco.princeton.edu
Thu, 7 Oct 2004 11:01:23 -0500
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