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."
>>>
>>>
>>>
>>
>>
>> I cannot speak for OCLC, but xOCLCNUM service includes a "getVariants"
>> service which normalizes OCLCNUM somehow, such as:
>>
>>
>> http://xisbn.worldcat.org/webservices/xid/oclcnum/07913025?method=getVariants
>>
>> The API document has a link to how OCLCNUM variants are used:
>>
>> http://xisbn.worldcat.org/xisbnadmin/xoclcnum/api.htm#getvariants
>>
>> http://www.oclc.org/support/documentation/worldcat/tb/253/253.pdf
>>
>> It may be clear from the service that when you use naked OCLCNUM, you
>> should
>> remove the leaving zeros, but if you use it with a prefix "ocm", it was
>> recommended to pad the number to 8 digits, such as "ocm07913025".
>>
>> The getVariants service was suggested by Tod Matola in OCLC.
>>
>> xiaoming
>>
>>
>>
>>
>>> So I actually think Google is doing an acceptable thing, and you should
>>> remove leading zeroes before making a query to it. Although it would be
>>> kind
>>> of Google to normalize on making a query too. But I wouldn't hold your
>>> breath; my impression on this stuff, after trying to talk to Google about
>>> it
>>> before, is that it's pretty much a Finished Thing that nobody at Google
>>> is
>>> currently working on and nobody at Google currently cares about.
>>>
>>> But it would be nice if OCLC published a statement saying "remove leading
>>> zeroes from OCLC numbers before comparing two OCLCnumbers to see if they
>>> match, or submitting an OCLC number to a foreign system for comparison."
>>> Jonathan
>>>
>>>
>>> Jimmy Ghaphery wrote:
>>>
>>>
>>>
>>>> NGC4LIB,
>>>>
>>>> We have noticed an issue with using the Google API for older items where
>>>> we have leading zeros in the OCLC number.
>>>>
>>>> For example with the leading zero, no result found:
>>>> http://books.google.com/books/feeds/volumes?q=OCLC07913025
>>>>
>>>> Take out the zero:
>>>> http://books.google.com/books/feeds/volumes?q=OCLC7913025
>>>>
>>>> What is the collective take on this? Does this seem like a reasonable
>>>> accommodation that Google should make (ideally at someone's request with
>>>> more juice than me, hint OCLC)? Or should I scurry about and make
>>>> changes locally?
>>>>
>>>> -Jimmy
>>>>
>>>> --
>>>> Jimmy Ghaphery
>>>> Head, Library Information Systems
>>>> VCU Libraries
>>>> http://www.library.vcu.edu
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
Received on Wed Jul 22 2009 - 22:53:59 EDT