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

Karl O. Pinc kop at meme.com
Mon Sep 21 22:43:46 EDT 2009


On 09/21/2009 08:23:01 PM, Susan Alberts wrote:
> HI Niki et al,
> 
> I am forwarding this to the babase mailing list because I think it  
> sort of became a babase question.
> 
> For Karl and others new to the discussion, the question revolves  
> around individuals with a statdate  prior to the last census (ie  
> individuals that are really gone from the population) but that have a 
> 
> status of alive. In our demographic analyses, these are "censored"  
> individuals, in that we don't know how long they lived, and of course 
> 
> its important to indicate that they were alive at last census and we  
> don't konw if they're dead. That is, we don't want to artificially  
> assign them to the "dead" category even if they've been gone 30 
> years.

The real question is what are you trying to accomplish?  There's
no reason you could not make another status of "missing in action"
or "mostly dead" or some such.  It'd be the same as dead to the
system, which tests for a status of 0 (zero) to mean alive.
This would keep individuals from accidentally being reincarnated.

> 
> However, Niki raises the point that this creates individuals in the  
> database that could theoretically 'come back' after 30 years or more. 

We could even make a warning that checks for alive individuals with
no census information for, say, 10 years.

> 
> She asks whether there is some utility in indicating that it is no  
> longer possible for them to come back.  If we could indicate this,  
> then for one thing we would minimize errors where a new individual is 
> 
> accidentally designated with an old sname (either as a typo or  
> whatever) and babase allows this, because the original bearer of that 
> 
> sname is still "alive". This has happened with GRI accidentally being 
> 
> called GRE by the team, and it might not have been picked up before 
> it
>  
> entered the database because GRE was indeed an animal from long ago  
> (alas, still so alive in my memory).
> 
> See below for comments.
> 
> 
> Begin forwarded message:
> 
> > From: Niki Learn <nlearn at Princeton.EDU>
> > Date: September 21, 2009 4:23:33 PM EDT
> > To: 'Susan Alberts' <alberts at duke.edu>
> > Cc: lroerish4 at gmail.com, 'Jeanne Altmann' <altj at Princeton.EDU>,  
> > 'Lacey Maryott' <lacey.maryott at duke.edu>
> > Subject: baboons with no deathdate and Ositeti subgroups (formerly  
> > Mica's infant MESHAEK)
> >
> > Yes, I know that's why those animals were left dangling and clearly 
> 
> > the males that are still of an age to be alive should still have an 
> 
> > open status since they may show up again.  I guess I have wondered  
> > if there's a way to declare the older ones (that are surely dead 
> and
>  
> > whose names we don't come across too often and so don't often  
> > recognize) dead without any actual data on their deaths.  I guess  
> > that would require an extra code of some kind
> 
> 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. Is that what you are thinking?
> 
> > and careful explanation of the statdate (once we decide upon when  
> > they should be declared dead, which could be a tricky question).  
> As
>  
> > I recall from reading up on the status thing, Karl was clear that 
> he
>  
> > only wanted one code for dead so I guess this would have to be a  
> > dcause code?  But declaring them dead could help prevent some of  
> > these sorts of errors from being accepted by babase, and I was  
> > initially confused by the seemingly long lives of members of some 
> of
>  
> > these groups when I first encountered them during a query a few  
> > months ago.
> >
> > I only noticed the GRI/GRE error because I then made a table for 
> the
>  
> > Ositeti subgroups and, since GRI showed up a couple other times  
> > spelled correctly, I realized that his name might have been  
> > misspelled in one or more of the notes and looked up the snames.   
> > Otherwise Grendel would probably still be listed as having appeared 
> 
> > in Ositeti group at age 33.
> >
> > -----Original Message-----
> > From: Susan Alberts [mailto:alberts at duke.edu]
> > Sent: Monday, September 21, 2009 3:27 PM
> > To: Niki Learn
> > Cc: lroerish4 at gmail.com; 'Jeanne Altmann'; 'Lacey Maryott'
> > Subject: Re: Mica's infant MESHAEK
> >
> > Thanks for pointing out this issue Niki.
> >
> > In fact it is not just older animals or animals from old groups 
> that
> > won't throw up a error if you enter their sname -- it's ANY animal
> > that disappears from the study population without known fate. This
> > include many many males (actually most adult males) that emigrate
> (or
> > die and we never know it).
> >
> > The thing is that an animal is allowed to reappear in the 
> population
> > after he's been gone for a while. This has to be true, because we 
> do
> > sometimes have males reappear after a long time.
> >
> > In fact, there is a dead animal with sname MIS in babase, but that
> > animal has a status of 1, so in this particular case you'll get an
> > error. But it's not guaranteed.
> >
> > Susan
> >
> > On Sep 21, 2009, at 3:16 PM, Niki Learn wrote:
> >
> >> It was Grivet from Ositeti.  His name was misspelled as Grevet in
> >> the other groups notes for Linda's group in May.  Not being
> familiar
> >> with Grivet I didn't realize that it was misspelled and entered 
> GRE
> >> as the sname but then realized after I uploaded to babase that 
> this
> >> was Grendel - oh, actually, he was not in Lodge's - there was a
> >> group called Grendel's group!  Anyway, I fixed it after I realized
> >> the error (which I think was the week after I did the upload).
> >>
> >> The statdate is simply the last date a baboon appears in the 
> census
> >> table (though I must say I don't really understand his later 
> census
> >> entries...M and E?) unless he has been declared dead, which the
> >> baboons from these old groups that we stopped monitoring have not 
> -
> >> he and many others are still listed with a status of alive (even 
> if
> >> they would clearly be dead by now), which means that babase does
> not
> >> throw an error when you enter new data for them by accident...
> >>
> >> bioid ¦ sname ¦ name    ¦ pid  ¦ birth      ¦ bstatus ¦ sex ¦
> >> matgrp ¦ statdate   ¦ status ¦ dcause
> >> −−−−−−+−−−−−−−+−−−−−−−−−+
> >> −−−−−−+−−−−−−−−−−−−+−−−−
> >> −−−−−+−−−−−+−−−−−−−−+−−−−
> >> −−−−−−−−+−−−−−−−−+−−−−−−
> >> −
> >> 141 ¦ GRE   ¦ GRENDEL ¦ GIN1 ¦ 1976-01-27 ¦       0 ¦ M   ¦
> >> 1.00 ¦ 1993-09-30 ¦      0 ¦      0
> >>
> >>
> >> -----Original Message-----
> >> From: Lacey Maryott Roerish [mailto:lroerish4 at gmail.com]
> >> Sent: Monday, September 21, 2009 3:00 PM
> >> To: nikihile at rci.rutgers.edu
> >> Cc: Susan Alberts; nlearn at Princeton.EDU; Jeanne Altmann; Lacey  
> >> Maryott
> >> Subject: Re: Mica's infant MESHAEK
> >>
> >> nikihile at rci.rutgers.edu wrote:
> >>> Sorry, just getting this over here on my Rutgers account.  As
> Lacey
> >>> said,
> >>> MES is correct on all the census sheets.  He also did not appear
> in
> >>> any
> >>> demography notes from birth through now so that is all good.
> >>>
> >>> I did find a similar instance with a demography note where the
> team
> >>> mispelled a baboon's name so I used the wrong sname and babase 
> did
> >>> NOT
> >>> throw an error because, although the individual that matched that
> >>> sname
> >>> was from many years past, he was from Lodge's group and so never
> >>> received
> >>> a deathdate.
> >> There are animals that don't have statdates??  Hmm I am confused/
> >> concerned.
> >> Or does this mean that the data checks distinguish status (ie, 
> dead
>  
> >> or
> >> missing or alive)..  I am going to do some reading of the
> >> documentation.
> >>> Fortunately I realized it soon after and fixed the error.
> >>> Just something for everyone to be aware of.
> >>>
> >>> I will alert Laurence about the possibility of an error on fecal
> >>> samples
> >>> for Meshaek.
> >>>
> >>> Niki
> >>>
> >>>
> >>>> Thanks.
> >>>>
> >>>> Susan
> >>>>
> >>>> On Sep 18, 2009, at 12:47 PM, Lacey Maryott Roerish wrote:
> >>>>
> >>>>
> >>>>> Yes, thats right.
> >>>>>
> >>>>> Susan Alberts wrote:
> >>>>>
> >>>>>> OK, thanks, this is helpful. I think you are saying that, 
> apart
> >>>>>> from any fecals currently in the field, we don't need RSM to 
> do
> >>>>>> anything in particular, as you think you will catch all cases  
> >>>>>> here
> >>>>>> on this end, yes?
> >>>>>>
> >>>>>> Susan
> >>>>>>
> >>>>>> On Sep 18, 2009, at 12:45 PM, Lacey Maryott Roerish wrote:
> >>>>>>
> >>>>>>
> >>>>>>> MES was born 10-2008.  I have been fixing the sname problem 
> in
> >>>>>>> all
> >>>>>>> adlibs, and it was fixed in all psion data where it occured 
> in
> >>>>>>> 08 /
> >>>>>>> ( i didn't realize it was such a focused problem then and
> >>>>>>> overlooked the few fixes I had to make   MES wasn't doing 
> much
>  
> >>>>>>> in
> >>>>>>> nov and dec 08)/.  Where the problem became clear was indeed
> in
> >>>>>>> the 09A adlib data, and that was when I noticed it was just
> Raph
> >>>>>>> writing it as MIS.  Niki put MES in as MES in the db, and I 
> am
> >>>>>>> guessing that all census sheets were correct as they are
> written
> >>>>>>> out and looked at by the whole team.
> >>>>>>>
> >>>>>>> Juline found no mistakes of this type in fecal and FTA.
> >>>>>>>
> >>>>>>> It would be good to know when Raph started using MES, so that
> I
> >>>>>>> can make sure we catch it everywhere, but again, the DB won't 
> 
> >>>>>>> let
> >>>>>>> MIS in anywhere anyway as it checks against members and
> biograph
> >>>>>>> for adlib and psion. For Example for adlibs I get a message
> >>>>>>> "Interact.date cannot be greater than biograph.statdate" and
> MIS
> >>>>>>> statdate was 1975-10-25.  Even if it is in Psion I will get 
> an
> >>>>>>> error that says "Neighbor past statdate: Dead Neighbor" and 
> it
> >>>>>>> will not allow any upload until I fix it.
> >>>>>>>
> >>>>>>> So I think that as long as he is using MES consistently now,
> >>>>>>> anything we get back from the field that had MIS on it, will
> be
> >>>>>>> fixed by me or caught by the system.
> >>>>>>>
> >>>>>>> Lacey
> >>>>>>>
> >>>>>>>
> >>>>>>> Susan Alberts wrote:
> >>>>>>>
> >>>>>>>> To clarify, we are talking about the 09a update, right? Or
> did
> >>>>>>>> you simply notice this in going through ad libs from very  
> >>>>>>>> recent
> >>>>>>>> months? And since Niki has already completed 09a, can/should
> we
> >>>>>>>> assume that it did not affect any aspects of her part of the
> >>>>>>>> update?
> >>>>>>>>
> >>>>>>>> Yes, this might affect fecal samples and FTA cads, it would
> be
> >>>>>>>> good for Juline to check those that are here.
> >>>>>>>>
> >>>>>>>> We should also figure out what we need to ask Raphael to do
> in
> >>>>>>>> the field -- when did he fix the problem, and has he tracked 
> 
> >>>>>>>> it,
> >>>>>>>> etc.
> >>>>>>>>
> >>>>>>>> Susan
> >>>>>>>>
> >>>>>>>> On Sep 18, 2009, at 12:24 PM, Lacey Maryott Roerish wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I have come across it in Adlibs thus far. As far as Psion,  
> >>>>>>>>> this
> >>>>>>>>> is something that will show up when I am uploading the 
> Psion
> >>>>>>>>> (as
> >>>>>>>>> MIS's statdate was quite some time ago and will throw 
> errors
>  
> >>>>>>>>> at
> >>>>>>>>> me).  I can look for it sooner if we want to get a feel for
> >>>>>>>>> what
> >>>>>>>>> data is affected, but I am positive it will not go into the
> db
> >>>>>>>>> if I don't look until update time, because the upload
> program
> >>>>>>>>> has a very reliable check for that. Let me know which 
> course
>  
> >>>>>>>>> of
> >>>>>>>>> action I should take.    I am not sure of any other places
> >>>>>>>>> where
> >>>>>>>>> this may crop up. Possibly on fecal samples or FTA cards? I
> >>>>>>>>> have
> >>>>>>>>> Juline checking this for samples that are already here.
> >>>>>>>>>
> >>>>>>>>> Lacey
> >>>>>>>>>
> >>>>>>>>> Susan Alberts wrote:
> >>>>>>>>>
> >>>>>>>>>> Lacey and Niki,
> >>>>>>>>>> can you address this question of where we need to look for
> >>>>>>>>>> this
> >>>>>>>>>> error?
> >>>>>>>>>> Susan
> >>>>>>>>>>
> >>>>>>>>>> On Sep 18, 2009, at 11:03 AM, Jeanne Altmann wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Does this mean it is wrong in adlibs and Psion until now?
> >>>>>>>>>>> What
> >>>>>>>>>>> else?
> >>>>>>>>>>> jeanne
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Susan Alberts [mailto:alberts at duke.edu]
> >>>>>>>>>>> Sent: Friday, September 18, 2009 7:32 AM
> >>>>>>>>>>> To: Lacey Maryott; Jeanne Altmann; Niki Learn
> >>>>>>>>>>> Subject: Fwd: Mica's infant MESHAEK
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Begin forwarded message:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> From: Amboseli Baboon Research <ambnyani at princeton.edu>
> >>>>>>>>>>>> Date: September 18, 2009 2:53:50 AM EDT
> >>>>>>>>>>>> To: Susan Alberts <alberts at duke.edu>
> >>>>>>>>>>>> Subject: Re: Mica's infant MESHAEK
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi susan,
> >>>>>>>>>>>> I realized this mistake and changed  already that is was
> >>>>>>>>>>>> back
> >>>>>>>>>>>> last
> >>>>>>>>>>>> month i remember telling Sns bout it.
> >>>>>>>>>>>> So i'm back to the right spelling.
> >>>>>>>>>>>> Thanks
> >>>>>>>>>>>> Rsm
> >>>>>>>>>>>> Susan Alberts wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Raphael,
> >>>>>>>>>>>>> The sname for Mica's infant MESHAEK is MES, but it
> appears
> >>>>>>>>>>>>> that you
> >>>>>>>>>>>>> have been using MIS. SNS and JKW are using MES and
> that's
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>> official sname. Can you change this in the future? 
> Also,
> >>>>>>>>>>>>> please
> >>>>>>>>>>>>> check to see where you might have been using MIS and
> >>>>>>>>>>>>> correct
> >>>>>>>>>>>>> it to
> >>>>>>>>>>>>> MES. Please reply to confirm.
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>> SUsan
> >>>>>>>>>>>>> 
> --------------------------------------------------------
> >>>>>>>>>>>>> Susan Alberts, Dept of Biology, Duke University, Box  
> >>>>>>>>>>>>> 90338,
> >>>>>>>>>>>>> Durham
> >>>>>>>>>>>>> NC 27708, 919-660-7272 (Ph), 919-660-7293 (Fax)
> >>>>>>>>>>>>>
> >>>>>>>>>>> --------------------------------------------------------
> >>>>>>>>>>> Susan Alberts, Dept of Biology, Duke University, Box
> 90338,
> >>>>>>>>>>> Durham NC
> >>>>>>>>>>> 27708, 919-660-7272 (Ph), 919-660-7293 (Fax)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> --------------------------------------------------------
> >>>>>>>>>> Susan Alberts, Dept of Biology, Duke University, Box 
> 90338,
> >>>>>>>>>> Durham NC 27708, 919-660-7272 (Ph), 919-660-7293 (Fax)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> --------------------------------------------------------
> >>>>>>>> Susan Alberts, Dept of Biology, Duke University, Box 90338,
> >>>>>>>> Durham NC 27708, 919-660-7272 (Ph), 919-660-7293 (Fax)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>> --------------------------------------------------------
> >>>>>> Susan Alberts, Dept of Biology, Duke University, Box 90338,  
> >>>>>> Durham
> >>>>>> NC 27708, 919-660-7272 (Ph), 919-660-7293 (Fax)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> --------------------------------------------------------
> >>>> Susan Alberts, Dept of Biology, Duke University, Box 90338,
> Durham
> >>>> NC
> >>>> 27708, 919-660-7272 (Ph), 919-660-7293 (Fax)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> > --------------------------------------------------------
> > Susan Alberts, Dept of Biology, Duke University, Box 90338, Durham
> NC
> > 27708, 919-660-7272 (Ph), 919-660-7293 (Fax)
> >
> >
> >
> >
> >
> 
> --------------------------------------------------------
> 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
> 
> 




Karl <kop at meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein




More information about the Babase mailing list