Summon reloaded records don't have persistent IDs

[ruthtillman]

A subset of Summon subscriptions get reloaded through a delete/load process to ensure only current coverage in the catalog. This leads to primary keys getting retired and 404 pages. For these records, could we use the serialssolutions ID as the ID in the URL instead?

Example would be: https://catalog.libraries.psu.edu/catalog/27763009/

035 contains: ss360mi0047732

Note -- Ruth needs to consult with Jeff/Ken to determine the subset of records to which this problem applies (not all records are reloaded like this) and shared characteristics. I believe that the records concerned should all contain the ss360mi.

[ruthtillman]

Contacted Rachael at IU and they're the ones who do it. She'll be passing information on to us.

[ruthtillman]

So this is gonna be a Dan Peters/Jaime, maybe Maryam thing and I'll need to open a ticket in Symphony. Recording this answer here and closing the ticket:

Let me move backward from Blacklight through extract through Symphony through record load to SS. Stop me if any of this is confusing. :)

In Blacklight, we use the Catalog Key of the record in the 001 field, which provides the record-specific identifier in the URL. I can see you do the same (the MARC view of one of your records in your OPAC shows a number in the 001 which matches the initial part of the barcode in the 949 $i, so that must be the catkey). https://catalog.libraries.psu.edu/catalog/42537743/marc_view

In our extract for Blacklight, we write the catkey into the 001 (apispeak: catalogdump -kc [or -kc001 if you're being overly explicit]), which overwrites any existing 001, which is unfortunate, imho. FWIW, we also write the catalog key out to an 035 field, as well (see, e.g., https://iucat.iu.edu/catalog/20321572/librarian_view).

In Symphony, we have the SS-provided record number (with either ssj or ssib as prefix) in the 001 field and as the title control number. I can see you also have the SS record number in the 001 field in Symphony (LC's Z39.50 gateway lets me look up the same record in your db!). But I'm guessing that since this is an issue for you, maybe you don't use that number as your title control number/flexkey?

We get the SS record number as the title control number when we load the records (apispeak: catalogload -fg).

We process the files we get from SS separately by type. The update files are loaded in match-and-overlay mode (apispeak: catalogload -hu949 -mb). The new files are loaded in create mode (apispeak: catalogload -hs949 -mc). The delete files have their keys extracted and removed separately (apispeak: cat keyfile | selcatalog -iF -oC | selitem -iC -oI | delitem).

We get the records from SS with their record number in the 001. Setting up specs with them was before my time, so I don't know if that's something special, but I am guessing you do the same.

Does this help? I know that before Blacklight, our OPAC was pre-Enterprise SirsiDynix (webcat??) and it didn't have persistent URLs. In that era, we didn't have persistent catkeys for our SS load, because we didn't do updates—we used the update file twice: once to delete all the records and then a second time to add them back in. This was hugely wasteful (of catalog keys, staff time, etc. but mostly adutext processing time). I think perhaps they couldn't figure out how to overlay the records without duplication of the fields we had marked "local" (i.e. the fields we force the system to keep from the old record when overlaying with the new). Once I fixed that, it really wasn't much of a stretch to do the updates correctly by overlaying them in place, resulting in persistent catkey and, in Blacklight, a persistent URL.