Rachel's message evidently prompted this:

http://www.oclc.org/developer/news/2015/change-to-xid-services.en.html

"OCLC offers an array of APIs that provide additional access points to WorldCat 
and the WorldShare platform, allowing libraries and partners to use the data 
inside applications in new and creative ways.  While we add APIs at times, we 
also must retire some.  The xID product, including xISBN, xISSN and xOCLCNum, 
has experience low usage and will be retired from the OCLC API offering. No new 
keys are being issued, and the service will be unavailable beginning March 15, 
2016."

OCLC people:  how about releasing the data behind the xID services?  A big 
static dump of all of the numbers (ISBN, LCCN, OCLCnum) and how they're related. 
It'll be out of date the next day, but it'll still be very, very useful.

When you needed them, the xID services were EXTREMELY helpful.  Perhaps part of 
the cause of low usage was the access restrictions, both of number of requests 
and commercial use.  If the data had been open, many more uses would have 
arisen.  I say make it open now, under something like an Open Data Commons 
Attribution License.

Bill


On 10 December 2015, Maderik, Rachel A wrote:

> Just a warning about OCLC's xID API: a few weeks ago I requested an access token to bypass the rate limit, and was told that they are no longer giving these out. I was also told that the data in xID has not been updated for some time (I don't know when they stopped, but I think the rep told me it was at least a year out of date). It was very disappointing to learn this; if the project is essentially dead, this fact should be advertised (at the very least, they should take down the pricing list!).
>
>
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of William Denton
> Sent: Wednesday, December 09, 2015 5:40 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Matching print and electronic editions of the same book
>
> Thanks!  That opens things up.  We do have a lot of OCLC numbers.  For my example book, there's an 035 with three of them, including 841051199. If I look at
>
> http://worldcat.org/oclc/841051199
>
> it takes me to the human-readable page, but
>
> http://worldcat.org/oclc/841051199.rdf
>
> shows it all in RDF, and I can see a lot of things like
>
> <rdf:Description
> rdf:about="http://experiment.worldcat.org/entity/work/data/1613596711#Place/japan">
>
> so I can pick out the work ID and look it up.  (Perhaps the work ID be specified directly there?)
>
> So that would work, but aha, I just noticed I could make it a little simpler by using xOCLCNUM to get the work ID, which is the owi field here:
>
> http://xisbn.worldcat.org/webservices/xid/oclcnum/841051199?method=getMetadata&format=json&fl=*
>
> And then I can go to
>
> http://experiment.worldcat.org/entity/work/data/1613596711.rdf
>
> and get all the workExample links, and use those OCLC numbers.
>
> (Which I'm sure you knew, Roy, but perhaps didn't mention because of the rate-limiting, but as far as I know our subscription means I can get an access token so I can do some larger queries.)
>
> A first run of something like this would take a while to process everything, but I'd store locally what I need to know, and then incremental updates for a month's worth of news ebooks wouldn't take long.  Thanks!
>
> Bill
>
> On 9 December 2015, Roy Tennant wrote:
>
>> Do you have an OCLC number in your records? If so, you could call it
>> at WorldCat like this:
>>
>> http://worldcat.org/oclc/XXXXXXX
>>
>> scrape the structured linked data on the page, looking for the
>> "Example of Work" link, then follow it to the Work Record:
>>
>> http://experiment.worldcat.org/entity/work/data/1613596711
>>
>> That then will give you all of the OCLC numbers that we consider are
>> part of that work (under the "WorkExample" tab).
>>
>> I know, not an optimal solution even if you have the OCLC number. But
>> it could work if you do.
>> Roy
>>
>> On Wed, Dec 9, 2015 at 1:37 PM, William Denton <[log in to unmask]> wrote:
>>
>>> I'm looking at how to match print (p) and electronic (e) editions of
>>> the same book in our collection.  There is no connection between them
>>> in our system (VuFind in front of Symphony).
>>>
>>> For example, two catalogue entries for two versions of COMPOSING
>>> JAPANESE MUSICAL MODERNITY, entirely separate:
>>>
>>> + https://www.library.yorku.ca/find/Record/3238132
>>> + https://www.library.yorku.ca/find/Record/3311584
>>>
>>> I want know they're the same book so I can do more usage and
>>> collection analysis.  I've been looking at two ways of doing it with
>>> data available right now:
>>>
>>> 1 a) MARC 020 (ISBN) can list multiple ISBNs. We have e books where
>>> the p editions are listed.
>>>
>>> 1 b) MARC 776 (additional physical form entry) for e books can list a
>>> p ISBN or other control number. If we have that edition, great. If
>>> not, need to go from e -> p-we-don't-have -> p-we-do-have, which I
>>> could do with xISBN.
>>>
>>> 2) OCLC's xISBN. When it reports other editions of the same work, it
>>> can include e versions.
>>>
>>> There is also:
>>>
>>> 3) Vendors supplying data.  For example, YBP seems to have all the p
>>> and e editions of books tied together.  We could ask.
>>>
>>> I've been looking around but can't find any discussion about making
>>> these connections.  Have any of you done it?  Know of it being done
>>> in code I can see? Written it up?
>>>
>>> Thanks for any pointers,
>>>
>>> Bill
>>> --
>>> William Denton ↔  Toronto, Canada ↔  https://www.miskatonic.org/
>>
>
> --
> William Denton ↔  Toronto, Canada ↔  https://www.miskatonic.org/
>

-- 
William Denton ↔  Toronto, Canada ↔  https://www.miskatonic.org/