Sure! Here's how we check the 856 fields:
We put the resulting records from the load into a review file in Create Lists (call this Review File A).
We examine some of the records to identify some bit of text unique to the URLs for this vendor.
We prepare a Global Update of Review File A, changing the 856 fields that match that unique text into 956 fields. But before we execute the update, we carefully examine the Preview of the update. This will show us those records that don't have a URL for this vendor, or have multiple URLs for this vendor.
For those missing a URL for this vendor, we go to the vendor's site to find the correct URL to add to the record. For those with multiple URLs, we determine whether to delete any.
Once the records are fixed, we redo the Preview and finish the Global Update, changing the matching URLs to 956 fields, making sure every record gets at least one 956 field.
We can use Global Update on Review File A to change the |3 and |z of the 956 fields to the text we want, and add our proxy (if we haven't already done it in pre-load preparation).
Then we deal with the 856 fields for other vendors. Prepare a Global Update on Review File A to change all remaining 856 fields to 956 fields. Before executing the update, examine the Preview. If you see any 856 fields you want to delete rather than keep, uncheck the box for that record. Execute the Global Update. Do another Global Update to delete all remaining 856 fields.
(Alternatively, you could do a Global Update to delete the 856 fields, and uncheck the boxes for the ones you want to keep. In either case, if you aren't sure whether to keep or delete the URL, check the bib record itself, looking for 910 fields.)
Do one final Global Update to change the 956 fields to 856 fields.
This is unfortunately a lot of Global Updates, and I'm currently examining how to reduce the number of Millennium transactions for post-load editing. This will probably mean moving more of the editing to the preparation stage (using MarcEdit), but at least some of the 856 checking has to happen in Millennium, after overlaying.
Steve McDonald
[log in to unmask]
> -----Original Message-----
> From: Program for Cooperative Cataloging
> [mailto:[log in to unmask]] On Behalf Of D. Brooking
> Sent: Thursday, December 15, 2011 12:03 PM
> To: [log in to unmask]
> Subject: Re: [PCCLIST] Provider-Neutral records and batch processes
>
> Thanks, Steve!
>
> Yes, I would like more details, since we also use the III system. In
> particular, for the following paragraphs, are you examining records
> manually one by one? Do you use Create lists and Global update
> to help automate this part?
>
> "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)."
>
>
>
>
>
> ************
> 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
>
> On Thu, 15 Dec 2011, McDonald, Stephen wrote:
>
> > 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.
> >
> > Steve McDonald
> > [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
> >> of
> >> urls?
> >>
> >> 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
> >> to
> >> 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
> >
|