Thank you, Exlibris!

I tested out the new OCLC Control Number data fields in Analytics and they work perfectly.

Hello everyone.
While beginning to plan the development on this we noticed a very similar (almost the same) request from NERs (https://ners.igelu.org/): "ReqId 5684 - Create a Separate Search Index for Specific OCLC Number".

This is for a new search index which would also take the 035 with certain prefixes and not from all fields that currently go to searcher index "other system number".

In the desire to keep things organized and easily explainable and maintainable: We would like to do the same in analytics that is being done in the new search index.
Comments from anyone?

Hi Katie,

To retain the prefixes, etc. is to allow exact matching, and let other libraries see the original forms to troubleshoot, or manipulate them to meet different needs. I like the idea of creating an additional field called OCLC number (Normalized), just like existing fields: ISSN, ISSN (Normalized); ISBN, ISBN (Normalized); Title, Title (Normalized). This OCLC number (Normalized) field will have the prefixes and leading zero(s) removed, so it will help with the common tasks most libraries do.

A bib record has two unique OCLC numbers?! It is beyond my wildest dream. I doubt if Alma would go to that length to differentiate if the two OCLC numbers in the same row are the same or not. To accommodate more libraries with their unique situations, e.g. your situation, now the best strategy seems to be to present what is originally found in the bib records, even when there are more than one valid 035 subfield a OCLC number. Then libraries can manipulate them in different ways to meet their needs.

Thank you for your message.

Pauline

Thanks, Pauline! Our data person had this comment:

----------

Better would be to have it like this:

OCLC number
1762661

and actually be a unique/deduped list of numbers. You only need the prefix when the 035 field needs namespacing to specify which kind of control number it is. If you have already clarified the semantics by the column, the "(OCoLC)" and ocm/ocn/on and leading zeros are just noise.

-------------

I want to emphasize that where multiple unique OCLC numbers exist in a single record, they should both be included in the Analytics field. We have a lot of these in our database that need cleaning up.

Hello all,

A lot of our records have the OCLC number in two 035 subfields a in a slightly different formats in the SAME bib record, e.g.

In the SAME bib record:
035 $a (OCoLC)01762661
035 $a (OCoLC)ocm01762661

This idea, if implemented, will likely have the result in an analytics report like this:

OCLC number
(OCoLC)01762661; (OCoLC)ocm01762661

Having two OCLC numbers in the same row will pose problems. We would like to see only ONE OCLC number for One bib record, regardless of how many times the OCLC number appears in 035 subfield a in the bib record, e.g.

OCLC number
(OCoLC)01762661

Sometimes vendor records have strange things in them. When the above situation happens, the only way to make the OCLC number field useful is to work with regular expression to extract the first numbers. That means, even after enhancement, we still have to do work to make this field work for us.

Please voice your comments/support. Thanks!

Pauline Smith
Eastern Washington University

Hello all.
This is being changed to "planned" and the development will tentatively be as follows:

Create a new field in Alma Analytics shared “bibliographic details” folder and call it “OCLC number”
It will include only 035 (regardless of indicators)
It will include only subfield a which have a prefix of (OCLC) or (OCoLC) or (ocm) or (ocn) or (on) and that prefix will be included as part of the field.

For example none of the following would be included in the new field “OCLC number”
035 __ |a (CKB)2550000001330164
035 __ |a (SSID)ssj0001293728
035 __ |a (PQKBManifestationID)11828995
035 __ |a (PQKBTitleCode)TC0001293728
035 __ |a (PQKBWorkID)11311334
035 __ |a (PQKB)10870284
095 __ |a (OCLC)6136499369
095 __ |a (OCoLC)2486499369

The following would be in the new field “OCLC number”
035 __ |a (OCLC)6136499369
035 __ |a (OCoLC)2486499369
035 __ |a (ocm)29111947

If a bibliographic record has the following

035 __ |a (YLK)4675851
035 __ |a 7851437
035 __ |a (OCoLC)814782 |z(OCoLC)7374506
095 __ |a (OCLC)6136499369
095 __ |a (OCoLC)2486499369

Then the only new field “OCLC number” would be as follows (exactly as follows):
(OCoLC)814782

I would like to point out:

1. The name of the column has to be the same as the column ID supported by the creating a set process. Currently, it accepts “OCLC number” as the header. If we use “OCLC identifier”, then we will have to change the column header manually in the input file each time. It also won’t work for creating a set directly from an analytic report column, unless we change the column header in the report before creating the set, which is unnecessary work.
2. A list of OCLC numbers from an analytic report may be used to search the repository. So it is essential that the one valid OCLC number for each record in the report column has to be exactly the same as it appears in 035$a to make a match.

Yoel,
This would be extremely helpful for us. In addition to '(OCoLC)' and '(OCLC)', you will want to include the following prefixes for OCLC numbers: 'ocm', 'ocn', and 'on'. These are left anchored and precede the OCLC master record number.

Examples:
035 __ |a ocm01311259
035 __ |a ocn470982983
035 __ |a on1017569492

For our purposes, most of the time a single OCLC number from 035 $a would work. It would be a fast improvement over the current mash of "Network Numbers" in Analytics. Occasionally we might want to search through 035 $z OCLC numbers or other numbers identified with OCLC, but could probably do that with additional searching or manipulating the fields.

Also, as suggested below, making the OCLC identifier field available in Alma exports of sets or title results would also be extremely helpful.

Question from Ex Libris
Please confirm that the following is a correct additional way of describing what you want:
Create a new field in Alma Analaytics shared "bibliographic details" folder and call it "OCLC identifier"
It will include only 035 (regardless of indicators)
It will include only subfield a which have a prefix of (OCLC) or (OCoLC) and that prefix will be included as part of the field.

For example none of the following would be included in the new field "OCLC identifier"
035 __ |a (CKB)2550000001330164
035 __ |a (SSID)ssj0001293728
035 __ |a (PQKBManifestationID)11828995
035 __ |a (PQKBTitleCode)TC0001293728
035 __ |a (PQKBWorkID)11311334
035 __ |a (PQKB)10870284
095 __ |a (OCLC)6136499369
095 __ |a (OCoLC)2486499369

The following would be in the new field "OCLC identifier"
035 __ |a (OCLC)6136499369
035 __ |a (OCoLC)2486499369

If a bibliographic record has the following

035 __ |a (YLK)4675851
035 __ |a 7851437
035 __ |a (OCoLC)814782 |z(OCoLC)7374506
095 __ |a (OCLC)6136499369
095 __ |a (OCoLC)2486499369

Then the only new field "OCLC identifier" would be as follows (exactly as follows):
(OCoLC)814782

Looking forward to hearing from you,
Yoel

We just implemented ALMA, and realized the incapability of retrieving OCLC number is a huge barrier to us.

In addition to this proposal for Analytics, the new OCLC column should be added to the canned Physical Title export in Managed Sets.

Seriously, there are so many things we could do so much better with this functionality. The power of Analytics is severely undermined when all you get is a field of garbage. Please make it my field of dreams instead! (And agreed it would be useful to be able to distinguish between $a and $z.)

I also like Pauline's suggestion of normalizing the OCLC#s

Yes, please! This would make my life SO much easier. I spend too much time either mining for OCLC numbers or working around the various issues described in this suggestion and the other comments.

I heartily agree with every point already made.

I would think that if Ex Libris has already managed to distinguish OCLC numbers from all other such numbers in order to provide a unique match point for imports, it seems to me they should be able to use that same data or technique to accomplish this.

I also agree that there should be one search for JUST 035$a with OCLC prefixes, and separate searches for the many related resources.

I would add to this suggestion the notion that, while the most frequently needed number is OCLC, it is not the only one. It would be ideal if there was functionality to report and search where an option to prompt for prefix. This would let us also isolate vendor records -- (CaSfKAN), (EBL), (MiAaPQ), etc. -- for matching at import or for batch editing.

Thanks for suggesting, Marcus! DG

OCLC are definitely needed. I noticed that our Alma will add holdings to WorldCat when we add new titles, but will not automatically delete our holdings when we withdraw titles. We are doing a massive weeding project, so we have to go through a lot just to create a list of OCLC numbers of titles we are withdrawing. We've been extracting the bibliographic records before they are removed by importing a file of scanned barcodes from the weeded books. Then running a job to extract the bib records, taking the exported file and running it through MarcEdit to create a list with the fields we actually need. Then copy and paste just the OCLC numbers into a text file and run that through OCLC client. It would be nice to have a quicker way of doing this.

From a data extraction/reporting standpoint, system numbers in general are always a headache to deal with. I like this idea, and hope it goes through. In my opinion, only 035$a fields should be included having OCoLC, ocn, ocm prefixes (and NOT the subfield $z). Also agree with Kevin that there should be a separate repository search for OCLC number.

Kevin, you are absolutely right! When we want to search for the resources themselves, we do not want to see their siblings or relatives (774, 775, etc.) in the result list. Ex Libris has to give us a separate index for this purpose. Your idea deserves a separate entry in Idea Exchange. If you could kindly submit it, I will definitely vote for it! Thanks!

There needs to be an ability to search OCLC numbers in the repository search as well, not just in Analytics. The entire Other System Number indexing needs to be re-thought. There needs to be a way, in a search, to distinguish between: (a) system numbers pertaining to the resource described--i.e,, 019/035, and: (b) system numbers pertaining to related resources--such as 773, 774, etc. Moreover, I do not understand at all why the Other System Number index would include subfield $w from fields 773-775, 777, and 786 but NOT from fields 760, 762, 765, 767, 770, 772, 776, 780, 785, and 787.