[Babase] Mismatch in MEMBERS.origin and CENSUS.status

Karl O. Pinc babase@www.eco.princeton.edu
Tue, 27 Sep 2005 16:25:42 +0000


On 09/27/2005 11:04:27 AM, Catherine Markham wrote:
> Karl,
> 
> Here's another MEMBERS comparison question regarding a change I  
> recently made to MEMBERS for TIT.
> 
> TIT was missing rows in CENSUS and MEMBERS from November 1989 through  
> her death in June 1990.  We went back and forth a bit on what to  
> enter for MEMBERS.origin for those rows (listserv email cut/pasted  
> below).  I had written down that the final decision was to make them  
> all have origin = "N".
> 
> >>>>> On 08/03/2005 03:44:57 PM, Catherine Markham wrote:
> >>>>>
> >>>>>> Karl,
> >>>>>> I showed Jeanne the records for TIT today - we definitely do  
> want  to
> >>>>>> add her census info from November 1989 through her death in  
> June
> >>>>>> 1990.
> >>>>>> I should just do this manually?  Make the origin equal to "L"  
> and
> >>>>>> interp equal to "0" for each calendar day in the missing  
> interval?
> >>>>>
> >>>>>
> >>>>>
> >>>>> I'm thinking that you should make the origin "N" for
> >>>>> manual-already-analyzed and be sure to make a note somewhere
> >>>>> as to why the rows are in there.  The "somewhere" could be
> >>>>> in DEMOG for one of the endpoint days.  This is an item for
> >>>>> the procedure manual I'd think.  (We can always take both
> >>>>> the rows and the note in the manual out if/when we go
> >>>>> back and enter the real census data.)
> 
> For adding the rows to CENSUS, you came up with that new program.   
> The other rows for TIT's group during this time period all had  
> CENSUS.status = "L" and there were no "N" statuses in the table.  So  
> I entered the rows with a status of "L".

The computer does not care, "N" and "L" do the same thing as
regards interpolation.  However, distinguishing between the "L"s
that were computed ever so long ago and the "N"s that we've just
figured out we want to use to jigger the data seems like a good
distinction to record in the db.

> In skipping ahead a bit in the MEMBERS Comparison, I see a mismatch  
> in the origin values for those records.  The old system has  
> CENSUS.status = "L" and MEMBERS.origin = "N" and the new system wants  
> both MEMBERS.origin and CENSUS.status to both be "L", presumably  
> because the system wants them to match(?).

Yes, MEMBERS.Origin and CENSUS.Status always match (except for
absences, which are in CENSUS but not MEMBERS, and "I"s,
which are vice versa.)

> Either the status or the origin wouldn't be difficult to correct, but  
> I'm not sure which value(s) to change.  Am I correct in thinking that  
> "N" - and "M" for that matter - are both reserved just for  
> MEMBERS.origin and not CENSUS.status?  If so, should the  
> MEMBERS.origin rows be equal to "L" after all?

No.  "N" and "M" can be used on CENSUS.  In fact, you are not
allowed to change MEMBERS, so if you could only use them
there then they could never be used.

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