At a full bib page (the ultimate destination of most successful catalog
searches here), we want to be able to display links to other versions of
the same work (audiobooks, large print, possibly translations).  OCLC's
xISBN service gives us something like the raw links we need, but we want
to refine the process for a number of reasons.

First, we don't want to incur an OCLC hit for every full-bib page view.
'Nuff said.

Second, we want to avoid doing unnecessary calculations for every page
hit -- almost all of the numbers returned by the xISBN service will not
match anything in our catalog.

So the ideal use case for our xISBN cache is that we would be querying
only a local database, and that database would only return ISBNs (or bib
numbers) of other editions which are actually in our catalog.

There is a possibility that we will add new versions of an existing
item, so we should be prepared to verify periodically that the xISBN
cache is accurate.  But for the most part, we should be able to do a
local query that will quickly return linking information (ISBN or
Horizon bib) that will identify every version in our catalog.  (And
ideally, these versions would be summarized as "large print", "abridged
audiobook", etc. as on Amazon.)

It doesn't much matter how much storage we use on the local database.
At 16 bytes or less per ISBN, a database of 700,000 items would only run
to about 12MB.  But if we cross-reference every ISBN to every other,
we'll have a factorial number of rows, which is probably less than
optimal.  On the other hand, if we do a histogram and find that 90% of
all items have no other versions in the catalog, perhaps this would be
an acceptable solution.

My guess is that we should have a row for each ISBN in the system, along
with a column that links that ISBN to some common identifier that will
symbolically mean e.g. "SQL for Dummies, any version".  We could then
ask "What is the identifier for the first ISBN of the item being
displayed?" and then do a second query that asks "What other ISBNs in
our catalog have that identifier?"

I'm most concerned with choosing a good identifier.  If there's a way to
uniquely identify a FRBR work, then surely that identifier would be the
best key to use.  If not, perhaps someone could suggest something?

The only remaining question, I think, is whether we should have one
table with ISBN as primary key and identifier as a second column (one
row per ISBN), and then another table with identifier as primary key and
ISBN as second column (again, one row per ISBN).  This could make our
queries faster at the cost of doubling storage space.  On the other
hand, perhaps we don't need to optimize that far.  It depends on how
mySQL reacts to searching the entire table for a non-primary-key column
value.  I'll have to fiddle with it and find out, unless one of you
knows already.

Then the next issue is how to inject that into the PAC, but DaveyP used
Ajax for that, so I think we're OK on that.

Any thoughts, folks?

Ben Ostrowsky