Here is a summary of what we do here at Tufts.
For each e-book batch load, we add a local 910 field with the name of the package and date (usually the date of the batch from the vendor), e.g. "E-BOOK Springer Complete Collection 2011-12-15". If later we discover a problem with a collection, or a specific load, or drop a particular vendor, we can do a search on this field.
We maintain a spreadsheet listing every batch load, including source, size, and the value of the 910 field, to make sure we mark things consistently and so we know how to search for a particular load.
The spreadsheet also has columns for the date of preparation, date of load, and date of post-load editing, so we can keep track of what has been done and what is pending.
When we load, we protect both the 856 field and the 910 field, so that if it overlays an existing record we still have that critical information. The resulting record will have both the new fields and the protected fields from the older record. Unprotected fields are deleted or replaced with the new fields.
We make some bulk changes in preparation, and some in post-load editing.
In the post-load editing, we check for instances of multiple 856 fields and determine whether we need to delete any. The 910 fields help determine whether we have access from multiple vendors and need to keep both links. Occasionally there are multiple 856 fields from the same vendor, especially if it is an updated record from that vendor. In those cases, we determine whether they both resolve to the same e-book (we pick one to delete), whether one is an old broken link (delete it), or whether they point to multiple volumes of a multi-volume item (keep them all).
If the vendor uses batch loads to identify records to be deleted, we use this process to determine whether to just delete the 856 for that vendor (if we still have access from another vendor), or whether to suppress or delete the record itself (no other vendor access).
The big benefit of using the 910 fields is that we have a complete tally within the record of when it was loaded, which vendors provide us access, and how many times the record was updated by a particular vendor. One problem is that if we have to get non-OCLC records from the vendor, we are unlikely to match it to another vendor's records for the same items, and we can end up with multiple records. Fortunately, only a few vendors giving us non-OCLC records are likely to have overlapping collections.
Our ILS is III's Millennium. We have found some methods with Create List and Global Update that make it easier to check the 856 fields. If you would like the specific process, I can send it to you.
[log in to unmask]
> -----Original Message-----
> From: Program for Cooperative Cataloging
> [mailto:[log in to unmask]] On Behalf Of D. Brooking
> Sent: Wednesday, December 14, 2011 2:25 PM
> To: [log in to unmask]
> Subject: [PCCLIST] Provider-Neutral records and batch processes
> Has anyone out there come up with any workflows for dealing with the
> maintenance of P-N records, especially with regard to batch loading,
> updating and deleting; bib records, any attached records, and handling
> There's not a problem if we have a P-N record with just one vendor url.
> But if we get a title from more than one vendor, maintenance is proving
> be quite the puzzle.
> I'd be extremely grateful for any insights. Thanks.
> Diana Brooking (206) 685-0389
> Cataloging Librarian (206) 685-8782 fax
> Suzzallo Library [log in to unmask]
> University of Washington
> Box 352900
> Seattle WA 98195-2900