[Babase] Psion jpsamps and fpsamps in wrong tables
kfenn
kfenn at princeton.edu
Fri Mar 2 15:48:42 EST 2007
Karl,
I see those juv and adult data in the SAMPLES table, not POINTS_DATA.
Am I misreading your email?
We still have the same problem in the new system since those juv vs
adult stype values that show up in the SAMPLES table are just getting
imported from the old FoxPro tables. When I query the Samples table for
Vex, you can still see her jumping between juvenile and adult status
between 2003-07-07 and 2004-01-08. The new table certainly makes it
easier to pick out the jumps so Laurence could fix them in her own
analysis, but it leaves the data mixed up and requires someone to query
every individual to check for the 'right' stype through time if their
analysis can be biased by this inconsistency..... not very practical.
I'll let Duke and Jeanne weigh in on the rule you proposed. I don't
know the ins and outs of maturity dates, but for Laurence's purposed, I
believe she was in favor of a rule that would say
1) an individual can't be uploaded into the adult table until after
their maturity date (you probably already have this rule, I didn't look)
2) once an indv is listed in the adult table, subsequent psion sample
dates for that individual cannot be input to the juvenile table.
Tabby
Tabby
Karl O. Pinc wrote:
>
> 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
--
Tabby Fenn
Research Assistant
Dept of Ecology and Evolutionary Biology
401 Guyot Hall
Princeton University
Princeton, NJ 08544
609 258-6898 (Ph)
609 258-2712 (Fx)
More information about the Babase
mailing list