[Babase] Fwd: Re: Request for Susan's input on SCI5 [babsat@stratosnet.com]

Karl O. Pinc babase@www.eco.princeton.edu
Wed, 20 Jul 2005 16:00:46 +0000


--=-wR19uQk9mcduyQ6A9QVK
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Forwarding to list for the archive.


Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                  -- Robert A. Heinlein
--=-wR19uQk9mcduyQ6A9QVK
Content-Type: message/rfc822

Return-Path: <babsat@stratosnet.com>
X-Original-To: kop@localhost
Delivered-To: kop@localhost.meme.com
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mofo.meme.com (Postfix) with ESMTP id 552266E422	for <kop@localhost>;
	Wed, 20 Jul 2005 10:17:25 -0500 (CDT)
X-Original-To: kop@meme.com
Delivered-To: kop@smtp.meme.com
Received: from 192.168.2.3 [192.168.2.3]	by localhost
	with POP3 (fetchmail-6.2.5)
	for kop@localhost (single-drop); Wed, 20 Jul 2005 10:17:25 -0500 (CDT)
Received: by smtp.meme.com (Postfix, from userid 1001)	id 9F53C200A5;
	Wed, 20 Jul 2005 09:35:32 -0500 (CDT)
Received: from hsmms2.stratos.ca (hsmms2.stratos.ca [63.79.211.24])
	by smtp.meme.com (Postfix) with ESMTP id 7D107200A5	for <kop@meme.com>;
	Wed, 20 Jul 2005 09:35:28 -0500 (CDT)
Received: from NYANI1 ([63.79.211.34]) by hsmms2.stratos.ca
	with InterScan 	Messaging Security Suite; Wed, 20 Jul 2005 14:21:22 -0000
Message-ID: <018201c58d36$10b00a50$37d34f3f@NYANI1>
From: "Amboseli Baboon Research Project" <babsat@stratosnet.com>
To: "Catherine Markham" <amarkham@Princeton.EDU>
Cc: "Jeanne Altmann" <altj@Princeton.EDU>,
	"Karl Pink" <kop@meme.com>, "Leah Gerber" <lgerber@duke.edu>,
	"Susan Alberts" <alberts@duke.edu>
References: <42DD1B04.2060003@princeton.edu>
Subject: Re: Request for Susan's input on SCI5
Date: Wed, 20 Jul 2005 13:22:06 +0300
Status: R
X-Status: 
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
X-imss-version: 2.029
X-imss-result: Passed
X-imss-scores: Clean:66.26654 C:2 M:3 S:5 R:5
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on janus.meme.com
X-Spam-Level: 
X-UIDL: nm5!!ljD!!oc`"!keW!!
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=0.94.4
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=iso-8859-1;
	reply-type=original
Content-Transfer-Encoding: 7bit

Hi Catherine, thanks for the clear description of the problem. Comments
below:

> Scion, a Proton's group female, had a conception date on 17 February 1993.
> Monitoring of Proton's group in the months that followed was spotty and
> the outcome of this pregnancy is not certain.  We know Scion was cycling
> again by April 1994 and that there was no mention of her with a young
> infant at that time.  We do not have enough information to determine
> whether or not the pregnancy was aborted and, if so, when or if the the
> birth successful but the infant died young.

Or whether the infant survived - this is possible too based on the info
provided.


>
> The way the data is currently entered in BaBase is as follows:
>
> (a) There is a row in PREGS with the PID for this pregnancy (SCI5) and the
> cid of the conceptive cycle.  The conceptive cycle is the last cycle
> information entered in CYCLES for Scion, so the resume cycle cid is blank.
>
> (b) There is a row in BIOGRAPH for the PID, SCI5.  Birth was estimated
> from the conception date (the birth date of 14 August 1993 is 178 days
> after the conception date of 17 February 1993).  Bstatus, name, statdate,
> status, and dcause are all blank.
>
> Now, onto the 3 possible scenarios for entering the information we do have
> into BaBase:
>
> 1.  Keep the rows in PREGS and BIOGRAPH but add more information to the
> BIOGRAPH record for SCI5.  Enter a statdate equal to the birth date, enter
> a status of 1 (for "dead"), provide a code for the dcause, and enter a
> bstatus of 1 (birth known within 1 year).

This is the option I would go for, except that I am not convinced we know
that SCI5 is dead. She could have had the baby in Aug93 and be cycling again
8 months later with the infant not with her when she was seen. I would argue
that we don't know and shouldn't assume dead.

 If we decide on this
> option, we will have to be certain to consider bstatus when querying for
> known abortions (typically queried for on the basis of birth = statdate
> and status = 1).

This issue has come up before and is an issue with all the statuses.  I
think our best alternative is to design a database that captures what we
know as accurately as possible and then assume an intelligent and
well-trained user -- and then, of course, choose and train our users well.
However -- see my next paragraph for a solution particularly relevant to
this case and others like it (where we stop observation when a female is
pregnant so we don't know the outcome of the pregnancy).

 [NOTE FROM KARL: Karl likes the idea of altering the
> STATUS values.  Right now there is "alive", "dead", and "missing". Missing
> is not kept up to date and should be got rid of.

Yes we discussed this in the spring at our meeting, and I agree. STATUS
should be either alive or dead -- it is the status at the last sighting of
the animal. This is how it is now defined in the babase documentation after
recent edits. Under this definition, "missing" doesn't make any sense.
However, we might want to add "unknown" or "fetus" as a status. This might
seem weird when you first think about it, but in fact it is the case with
all pregnancies that end after we stop observing a group. In other words,
although SCI5 is the test case here, in fact this will in general apply to
all animals that are still fetuses when we stop watching a group -- and, I
think, ONLY to animals that are still fetuses when we stop watching a group
(is that right?). My sense is that SCI5 is not the only one for which this
is true -- just that we were able to more confidently guess with the others.

 Then STATUS
> can be made to look like BSTATSUS, where there's codes for "alive", "dead,
> date known exactly", "dead, within 1 week", "dead, within 1 month", etc.
> Whatever time intervals make sense, not necessarily the same intervals
> that are used in BSTATUS. KOP]

In principle this is OK, but I am not sure we need it because it is the
statdate that we care about not the death date. The statdate has no error in
it. In other words, I don't think in practice we would use this. Also it
would not solve our problem with SCI5 because SCI5 might still be alive
today, we really don't know. I like better the idea of recognizing that
animals that are fetuses when we last "see" them will always have an unknown
status.

> 2.  Delete the row for SCI5 from BIOGRAPH but keep the record in PREGS.
I'm more comfortable keeping the rules consistent and so I do not favor this
option.

>
> 3.  Delete both the row in PREGS and the row in BIOGRAPH.  The time
> surrounding this pregnancy is a period of great caution for Proton's group
> anyway, so it might be best not to add the information to the database.
>

Yes this would bes my second choice after 1. Given that we are pretty
confident that Scion did get pregnant in Feb 93 it would result in lost
info. Perhaps not that big a deal compared to making the database too
complicated to use. But I would still favor 1, with the addition of
"unknown" or "fetus" as a status.

Susan



--=-wR19uQk9mcduyQ6A9QVK--