> From: Code for Libraries [mailto:[log in to unmask]] On
> Behalf Of Jonathan Gorman
> Sent: 23 May, 2006 09:54
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Musings on using xISBN in our Horizon catalog
>
> >
> > 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.
> >
>
> Hopefully the OCLC people can answer that.  It might be in

I'm following up that issue with a colleague down the hall who
is responsible for xISBN.  BTW, xISBN is an Office of Research
prototype [1] that we encourage feedback on.  On the left side
of the Web page [1] is a feed back link to a form for comments,
like "we really like this service" or enhancements, like Ben's
suggestion about if we are using an identifier under the covers
it would be nice to expose that in the response XML.

Also, we encourage experimentation with the service, but please
keep in mind that it's a Research prototype and not a 24 by 7
production service.  There are the typical issues associated
with a prototype like, but not limited to, the software breaks,
the data returned is not complete or up-to-date (we do make an
effort to keep it up-to-date, but we do have other priorities),
the server it is running on my go down and we will not know
unless we discover it or someone brings it to our attention
(one of the downsides of not running on a production server
where operations staff monitor the server.)

[1] <http://www.oclc.org/research/researchworks/xisbn/default.htm>

> To clarify, we'll assume that any isbn in a set will return
> the same set in xISBN.
> IE asking for isbns related to a returns a,b and c.  Asking
> for b or c should return a,b,c.

I believe that this assumption is correct.  My vague recollection
of our internal discussions on xISBN is that to create the group
of ISBN's we used our FRBR algorithm key [2].  So by definition
an ISBN cannot be in two FRBR groups at the same time.

[2] <http://www.oclc.org/research/software/frbr/default.htm>

> So we can do as Andy suggested and start building our table
> by taking the set of all current isbns, normalized a bit I'd imagine.
>
> In a computationally-expensive method:
>
> Start with the first isbn (x) and get the set of isbns from
> xISBN that is related (A).  Iterate over every member of A
> testing for the following:
> is the member assigned to a group already.  If it has, stop
> the loop and assign x to the same group.  If none in A have
> been assigned a group, start a new group and add x.
>
> You'll have to do this every once in a while to make sure
> you're getting all the new books.
>
> Hopefully this makes up for the advice I gave yesterday ;).
> I'm sure you can probably come up with a better algorithm
> though, something about the backward-lookup everytime makes
> me think that there's a better way.

Another algorithm approach might be:

1. generate the FRBR key for catalog record
2. lookup the FRBR key in the FRBR to ISBN relationship table
3. when the FRBR key is found in the table, e.g., a previous
   lookup to xISBN, then add the ISBN when it's not already
   associated with the FRBR key
4. when the FRBR key is not found in the table, use xISBN to
   return the ISBN relationships and add them to FRBR to ISBN
   relationship table

As Ben suggested, if xISBN does keep an identifier internally,
then exposing that identifier in the response XML would eliminate
step (1) at the expense of calling xISBN every time.


Andy.