[Babase] Proofing CYCLES
Karl O. Pinc
kop at meme.com
Sat May 27 00:16:49 EDT 2006
(Leah, see the P.S. vis training of new users.)
On 05/26/2006 03:34:36 PM, Catherine Markham wrote:
> Hi Karl,
>
> Ok, finally got back into the proofing of the CYCLES/CYCPOINTS data
> and will be continuing with that as first priority into next week.
> As promised, though, I wanted to give you a sense of what kind of
> discrepancies I'm seeing:
>
> TYPE 1:
> 2 examples...
> + 4690 ABB 18 2005-12-24
> + 4691 BUN 6 1985-11-26
>
> The new system has added an automatic mdate based on a female's last
> entered ddate BUT, because it is based of the last ddate, we don't
> have complete cycle information entered. Out of these two examples,
> we will likely get more data for ABB but never for BUN. In the past,
> we only entered complete cycles (never left a dangling mdate unless
> it was an unusual case where the female died, monitoring stopped,
> etc.). Personally, I don't like the idea of adding this last mdate
> although I guess it isn't a big problem so long as users are aware of
> edge effects and there are good notes on how it was generated (I'll
> reread the Babase documentation shortly to check). Sorry if all this
> was discussed earlier - maybe I'm just forgetting the conclusions we
> reached on this a while back.
What exactly would the rule be? You can only have an automatic Mdate
if there are subsequent CYCPOINTS (or CYCGAPS far enough into the
future to allow room for the automatic Mdate)? Or does it depend
on whether or not your dead?
In this particular case the automatic Mdate is following the rules
(See the Automatic Mdate Generation section) but maybe there is a
problem in the general case. The rules arn't explicit about what
happens at the Statdate, at least in that section. The CYCPOINTS
section says you can't have any CYCPOINTS, automatic or not, after
the Statdate. I'm wondering if it isn't a little more sane to allow
automatic Mdates after the Statdate if the individual is alive.
(They would have to go away if the individual becomes dead.) This
sorta corresponds with what interpolation is doing.
>
>
> ERROR 2:
> Can you double check the conceptive ddates you entered? I've noticed
> several errors so far in the day portion of the date. For example
>
> In the file I emailed you,
> ALT has a conceptive ddate on 19 February 1970 (NOT 1 February 1970)
> BUN has a conceptive ddate on 10 November 1984 (NOT 1 November 1984)
> DAD has a conceptive ddate on 21 June 1984 (NOT 2 June 1984)
>
> The pattern SEEMS to be (I'm not 100% on this) that if the day
> portion of the date is the first through the ninth of the month, the
> dates in the new system are correct. However, if the day portion of
> the date was the tenth or after, only the first digit of the day was
> entered (for example, "1" entered instead of "14" and "2" entered
> instead of "22").
*sigh* I _thought_ I'd gotten rid of this one. Maybe my fix made
another problem.
>
> Other than those two error types (which seem to continue as far in
> the checking as I've gotten - in other words, not something specific
> to just the first few alphabetized females), the only other
> discrepancy I'm seeing occurs when the auto mdates have been added.
> As we said a while back, for now I'm simply checking that the records
> are mismatched because an mdate has been added - after I go through
> all the current discrepancy checking, I'll do some queries on the
> logic and accuracy of the specific mdate that was generated.
Sounds good.
> P.S. Nearly forgot - how difficult would it be to create a table in
> the new system from CYCPOINTS that looks like the old CYCLES? Would
> be quite helpful, but no problem if it is troublesome to do.
There is already a view for that:
select * from CYCPOINTS_CYCLES;
I hesitated before making that view because I think it's something of
a crutch and working with CYCLES and CYCPOINTS themselves allows
for more powerful queries. But I decided to because I wanted an
easy introduction, otherwise working with sexual cycle information
might be too hard for the novice. Check out the other views,
particularly MATERNITIES and ACTOR_ACTEES and see what you
think regards introducing people to the system.
Feel free to make a list if you think there should be
others. (You can actually make your own views in the sandbox
schema for everybody to use, but if everybody really is using
them then we ought to move them into Babase itself so they
can be part of the official documention.)
The one problem with the views is that they don't show up
in the ER diagrams that give an overview of how to link
things. I don't know exactly what to do about this,
there seem to be too many different diagrams they might
show up in. Apparently there's a way to draw in the wiki,
maybe the answer is to have you guys draw what you need?
The people who enter data need to understand the underlying
database. Everybody else can have their life made easy
with views etc.
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