Right now there isn't a stable identifier for the clusters in xISBN.
OCLC-PICA is looking into how OCLC could supply that to help local
catalogs group there items, though.


-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
Ben Ostrowsky
Sent: Tuesday, May 23, 2006 8:54 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Musings on using xISBN in our Horizon catalog

I appreciate all the comments thus far and I hope my chiming in again
won't shut anybody up.

I'll see if there's a cheap way to query the live database, as Mike
Rylander suggests.

If not, I'm thinking about how to be sure I don't have duplicate work
IDs.  Here's the scenario:

1. We query xISBN for a particular book and get a set of related ISBNs.

2. We check the catalog and derive a set of related ISBNs in our

3. We cache this derived set by assigning an auto-incrementing sequence
number to that set and linking it to each member of the derived set.

4. A new edition of the same work becomes available.  We add it to our
catalog.  When we query the local xISBN server, it finds no matching
records.  So we query xISBN and get the set consisting of all the old
ISBNs plus the ISBN of the new edition.

5. We check this new result set against the catalog and cache the result
by assigning an auto-incrementing sequence number.

6. Someone looks up one of the old editions.

7. We query the local cache and find... What?  Duplicate ISBNs that we
have to de-dupe on the fly each time?  Inelegant, to be sure.

That's why I'd love to know whether the xISBN database uses a common
identifier for each set of ISBNs, and whether (and I know 'pretty
please' is a poor justification for changing an API) it might be exposed
for this reason.

Am I making an invalid assumption here?  Or might there be a way to
tweak the algorithm so that we don't run into this problem?