[OPEN-ILS-DEV] TCN value question related to Keeping bib / auth / MFHD / record identifiers in sync post

[Jason Stephenson]

Quoting Alan Rykhus <alan.rykhus at mnsu.edu>:

> Hello,
>
> I've read the 4 posts related to the Dan Scott's post on keeping the 001
> field in sync with the EG record_entry id and it brings up a question
> for me.

I read those posts, also, and was thinking of replying, but saw your  
question and thought my reply would fit nicely in your thread.


>
> What exactly is the real purpose of the tcn_source and tcn_value columns
> in the biblio.record_entry table?

My understanding is that the tcn_value column is meant to hold the tcn  
value from the MARC 001 field and tcn_source is the id if the record  
source from the config.bib_source table. I could be mistaken but  
that's what I discerned from reading the code.




>
> I'm working on some conversion scripts and the one thing I am looking at
> changing in the current conversion scripts for loading records is to let
> the system generate the biblio.record_entry.id value and to store the
> previous system's record id in the biblio.record_entry.tcn_value field.

I actually did this in some test loads a year or two ago. The current  
import process, at least for 1.4 and later will let you do that, if  
you export your MARC records correctly. In our present, commercial ILS  
there is an option to move the 001 to 035 on export. Setting this  
option puts the current bib id into the 001. This is a fairly common  
practice when exporting records for import to other systems or  
vendors, as was mentioned in a previous email in the related thread.

>
> The current scripts populate the id and tcn_value with the old system's
> records id. My reasoning for changing this is that I can see bringing in
> records from different systems where these values would collide. An
> additional concern is that you convert some libraries into Evergreen,
> they run on it for a while, then you add additional libraries, bringing
> in new bibs, and again you might have biblio.record_entry.id collisions.
> If I let the system generate the ids, and store the old id in the
> tcn_value, I can use sql to find out the current bib id, which is needed
> to generate asset.copy(actually asset.call_number) entries and their
> related links.

(I should note that in what I describe below, we are not concerned  
about bringing in other library's or consortia's records since we are  
an already extant consortium and do not foresee any membership  
additions.)

I have written my own bib import program in Java because I didn't like  
the performance of the import process shipped with Evergreen, plus I  
wanted a bit more control over what was being done with our records.  
Furthermore, we have a slew of bibs with duplicate TCNs because our  
catalogers have been doing copy cataloging in the way that our current  
ILS vendor suggested, and our current ILS permits duplicate TCNs from  
the same source.--This latter practice is pretty much counter to the  
MARC standards.

In our case, we use the existing record's OO1 as the tcn_value.  
However, in those cases where a duplicate TCN exists, the program  
generates a new tcn using our consortium's 3-letter OCLC code followed  
by our current system's bib number padded with zeroes to a length of 8  
digits. This value is used as the both the new tcn and replaces the  
existing 001 field value. In these cases, the 003 is also added or  
modified to contain our 5-letter institution code from the list  
available at the Library of Congress.

The above keeps our cataloging practice for the 001 and 003 in line  
with the MARC standard and also gets around records that fail to load  
because of duplicate TCNs.

This import program also uses our old system's id number as the  
biblio.record_entry.id in Evergreen. This makes importing other data,  
such as patron bookbags from the OPAC, much easier.

The program also does not use the 901 fields in the way that Mike  
Rylander says they are used in the Evergreen import scripts. I have  
the old system export the bib id into a 959 subfield a, which my  
program strips out of the MARC after reading and storing the value,  
but before actually using the MARC data for import. The reason for  
using the 959a is that we currently have no records with that field  
filled in, while we do have some records that already contain 901  
fields with various information in them.

I will now have to look through the Evergreen code more thoroughly to  
see if there is any magic purpose for 901s after the import, thought  
the last time I looked, I was unable to find any.

So, long story made a bit longer, I also would like to see something  
in the database that keeps the 001 and tcn_value in sync. However, if  
its a trigger, perhaps it should be disabled during a first import or  
a large import, and the import process could be modified to keep the  
two fields in sync.

Also, thought it might be interesting for others if I shared some of  
what we've been doing on import. It is good to read what others are  
doing and to hear some of the reasoning behind the different  
approaches people take.

Cheers,
Jason

>
> thanks -- al
> --
> Alan Rykhus
> PALS, A Program of the Minnesota State Colleges and Universities
> (507)389-1975
> alan.rykhus at mnsu.edu
>
>