Re: leading zeros on OCLC numbers and Google book search

But if you strip the zeros, will the numbers work for WorldCat Local or for
batchloading records to WorldCat? 

If anyone from OCLC is reading this, as Jonathan suggested earlier, could
you please provide the official OCLC word on the 'correct' format for OCLC
numbers, given how important those numbers are for machine matching all over
the place.

Here is my understanding of the formats that OCLC can (currently) accept
when it is matching on its number (# = digit):
in 001:
ocm######## (8 digits, with leading zeros)
ocn######### (9 digits)

in 035$a:
(OCoLC)######## (with or without leading zeros)
(OCoLC)######### (no leading zeros)
ocm######## (8 digits, with leading zeros)
ocn######### (9 digits)
(OCoLC)ocm######## (8 digits, with leading zeros)
(OCoLC)ocn######### (9 digits)

It is my understanding * that OCLC records are exported with OCLC numbers
formatted as:
001:
ocm######## (8 digits, with leading zeros)
ocn######### (9 digits)
035$a: 
(OCoLC)######## (without leading zeros)
(OCoLC)######### (9 digits)
————————————————————-
* From TB 253: http://www.oclc.org/support/documentation/WorldCat/tb/253/
Field 035
All bibliographic records output from OCLC systems will include the OCLC
number from field 001 in field 035:

The 035 field will appear immediately before the first field greater or
equal to 035, ignoring fields 040 and 066. 
Both indicators are blank. 
Subfield ‡a will include the OCLC number as a variable-length numeric string
with no leading zeros and preceded by "(OCoLC)". Subfield ‡a will be present
in all bibliographic records output from OCLC systems (except Connexion
client 1.60). 
—————————————————-

Bearing in mind that many libraries use OCLC numbers to detect duplicate
incoming records, if a library decides to re-format its OCLC numbers, *in
its stored database*, it will have to reformat *and re-index* all of the
OCLC numbers in the database in order for incoming OCLC numbers to match
existing OCLC numbers.

Deborah

 
------
Deborah Fritz
MARC Database Consultant
The MARC of Quality
www.marcofquality.com
Voice/Fax: (321) 676-1904
 

> -----Original Message-----
> From: Next generation catalogs for libraries 
> [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Maurice York
> Sent: Wednesday, July 22, 2009 10:51 PM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] leading zeros on OCLC numbers and 
> Google book search
> 
> For what it's worth, we had quite a go-around with padded 
> OCLC numbers in our local database when trying to implement 
> WorldCat Local. Even OCLC's internal documentation was a bit 
> vague on standard practice. After a good bit of back and 
> forth, they clarified best practice for us and updated their 
> documentation. Here's how they describe correctly normalized numbers:
> 
> OCLC numbers less than eight digits are zero padded to eight 
> digits and prefixed with ocm
> 
> OCLC numbers equal to eight digits are not zero padded, but 
> are prefixed with ocm
> 
> OCLC numbers equal to nine digits are neither prefixed nor 
> padded In terms of interoperability with WorldCat services 
> (and I'm sure they gave the same guideline to Google when 
> they were setting up GBS with WCL) is:
> 
> "In terms of best practice for ILS interoperability with 
> services such as WorldCat Local, we always recommend that (if 
> it's re-indexing) an institution locally index the OCLC 
> number in 035 $a with NO padding and NO prefixing.  (The only 
> exception to this recommendation is for Voyager
> sites.)  The second most common practice that we accommodate 
> is to index the OCLC number in the 001 field; again, with no 
> padding or prefixing."
> 
> So, I think the upshot is, if you're going to have 
> interaction between your local ILS and WCL or GBS services, 
> you're going to need to strip those zeros. I'm guessing 
> Google is going to go with OCLC's standard, and they're 
> highly unlikely to change it.
> 
> -M
> 
> 
> ************************************
> Maurice York
> Head, Information Technology
> NCSU Libraries
> North Carolina State University
> Raleigh, NC 27695
> 
> maurice_york_at_ncsu.edu
> Phone: 919-515-3518
> 
> 
> On Wed, Jul 22, 2009 at 3:50 PM, Jonathan Rochkind 
> <rochkind_at_jhu.edu> wrote:
> 
> > So we really do need feedback from Google on how they want us to 
> > normalize oclcnumbers before sending to them, and what, if 
> any OCLCnum 
> > normalization they do on their end, and if they could start.
> >
> > Good luck getting that feedback though, like I said, when 
> I've tried, 
> > there's nobody left at Google who cares about the GBS API 
> at all, and 
> > certainly nobody who cares about OCLC numbers. Or at least nobody I 
> > could find. Whoever worked on the original implementation 
> is now off 
> > to some other project.
> >
> > Jonathan
> >
> >
> > Xiaoming Liu wrote:
> >
> >> On Wed, Jul 22, 2009 at 2:37 PM, Jonathan Rochkind 
> <rochkind_at_jhu.edu>
> >> wrote:
> >>
> >>
> >>
> >>> What we actually need is for OCLC to publish a spec on 
> "normalizing" 
> >>> OCLC numbers.  Which I guess would actually be as simple 
> as "remove 
> >>> leading zeroes."
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4267 (20090722) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com