[Babase] Psion jpsamps and fpsamps in wrong tables

Jeanne Altmann altj at Princeton.EDU
Fri Mar 2 15:51:49 EST 2007


Laurence was at first confused and worried about these, but for her use,
she can solve the immediately problem without trouble.  She will use
matdate, and the data she is looking at are the same in both types of
samples (activity).

As Karl points out, having them in the same file in the new system will
help a lot.

We do need this well documented for any new use or user, however, as it
is odd and at variance with collection protocol.  Is it well documented
in an immediate place to find?

We explicitly decided not to use matdate as I recall [SUSAN?] in order
not to lose a significant number of samples that would be useful for
just what Laurence is doing--basic time budgets--in situations when the
loss could be important.  Also, some of the type of error around the
time of maturation is inevitable because some matdates are a month or
two at odds with what the field team thinks--for example, when I look at
the records, an initial very small swelling does not ultimately meet our
criterion for a 'cycle'.  

-----Original Message-----
From: babase-bounces at eeblistserv.princeton.edu
[mailto:babase-bounces at eeblistserv.princeton.edu] On Behalf Of Karl O.
Pinc
Sent: Friday, March 02, 2007 1:41 PM
To: The Baboon Database Project
Cc: The Baboon Database Project
Subject: Re: [Babase] Psion jpsamps and fpsamps in wrong tables


On 03/02/2007 11:44:37 AM, kfenn wrote:
> Hi Everyone,
> 
> I'm going to open a can of worms that has been opened before, but we 
> need some input from Duke about current psion protocol and possible a 
> programmed "rule" to help clean up the psamps tables for users.

> However, the allowances in the jpsamps table have created problems  
> for users like Laurence.   If there is no rule enforcing membership  
> in only the adult table after a maturedate is listed, then the 
> individual can 'jump' back and forth between adult and juvenile tables

> for potentially up to a year if the field team and/or data managers 
> are not vigilant.  Anyone trying to use these data risk not capturing 
> all the available data if they only search one table or the
> other.   VEX is one example of this problem.
> 
> Even if we caution people that this is an existing condition of the 
> database, its hard to give users a simple work around ......you cannot

> reliable say that once an individual has moved from the juvenile table

> to the adult table (even if this doesn't prefectly coincide with 
> maturedate), henceforth it will always been found in the adult table.

> 'Maturity' is a slow process so I can see allowing recently matured 
> individuals to remain in juvenile samples for a while, but once an 
> animal is moved to the adult table, it seems important that they 
> should remain there.

We could make it a rule that once you get on the adult table you remain
there, assuming that that solves Laurance's problem.
It's not entirely clear to me that it does.  It seems more sane to just
go back to using the maturity date as a cutoff.

The new system addresses this problem by storing both the adult and
juvenile data in POINTS_DATA.  You can easily see both adult and
juvenile data at the same time by ignoring SAMPLES.Stype.
You may be able to emulate this sort of behavior in foxpro using the SQL
UNION operator.

Does this help?

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



More information about the Babase mailing list