[Babase] Fwd: baboons with no deathdate and Ositeti subgroups(formerly Mica's infant MESHAEK)

Jeanne Altmann altj at Princeton.EDU
Sat Oct 10 04:05:21 EDT 2009


I really like this, totally agree.
jeanne

-----Original Message-----
From: babase-bounces at eeblistserv.princeton.edu
[mailto:babase-bounces at eeblistserv.princeton.edu] On Behalf Of Susan
Alberts
Sent: Friday, October 09, 2009 4:09 PM
To: The Baboon Database Project
Subject: Re: [Babase] Fwd: baboons with no deathdate and Ositeti
subgroups(formerly Mica's infant MESHAEK)

Here's an alternative, which would solve the problem Karl raises, and  
Niki's, and would reflect the way we actually analyze the data:

The Status column has 3 values, Alive, Dead and Censored.

--Alive means that the animal is alive in the population as of the  
most recent database update (this is a different definition than we  
use now; now we use alive to mean "at the time of its statdate").

--Dead means that the animal is known dead as of the update (same as  
now)

--Censored means that the animal has disappeared from the study  
population as of the update and we don't know whether it's dead or  
alive, we just know it's not in the population.

Dead and Censored can be treated the same from the perspective of  
whether a sname is allowed to be used -- a censored sname can't be  
used unless the status is changed to alive.

Changes could occur in the status column in the following directions:
Alive can change to dead or to censored
Censored can change to alive or to dead
Dead can't change

Note that this is conceptually quite different from the suspected dead  
status that we used to have, that none of us liked. Censored (in  
statistical analyses) simply means that the information on the  
individual comes to an end with no indication of final status as dead  
or alive.

Susan




On Oct 9, 2009, at 3:37 PM, Karl O. Pinc wrote:

> On 10/09/2009 01:42:12 PM, Niki Learn wrote:
>
>>
>> Susan suggested the following (which makes sense as an alternative to
>> a "presumed dead" status):
>> It seems like it would require an additional column that might
>> indicate a "permanently retired" sname. The column would be "YES" (ie
>>
>> the sname is permanently retired) for all individuals with status =
>> dead, and for individuals with status = alive, there would be some
>> date or lapse of time after which we would permanently retire the
>> sname.
>
> I have a problem with this because it seems to put the same  
> information
> ("usable" or not) into two columns (the new one and
> Status).  Both users and the system would have to check in two
> places, and the system would have to have additional code
> to make sure the 2 columns are consistent.  (I.e. dead but not
> permanently retired does not sound valid.)   The data consistency is  
> no
> big deal but checking in 2 places could be, at least some work is
> involved.
>
> And I don't see another column buying anything at all beyond what
> you get with another legal value for the status column.
>
>
> Karl <kop at meme.com>
> Free Software:  "You don't pay back, you pay forward."
>                 -- Robert A. Heinlein
>
>
> _______________________________________________
> Babase mailing list
> Babase at www.eco.princeton.edu
> http://www.eco.princeton.edu/mailman/listinfo/babase

--------------------------------------------------------
Susan Alberts, Dept of Biology, Duke University, Box 90338, Durham NC  
27708, 919-660-7272 (Ph), 919-660-7293 (Fax)




_______________________________________________
Babase mailing list
Babase at www.eco.princeton.edu
http://www.eco.princeton.edu/mailman/listinfo/babase



More information about the Babase mailing list