>
> 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 the work Andy
suggested yesterday.  One idea I had while yesterday was if you don't
care that much about the id internally you could use an auto-increment.

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.

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.


ps.  Andy's right, normalization is a good, good thing.  Only reason I
suggested looking at the costs was I was thinking it would be a lot easier
than trying to come up with a method to generate unique ids for a "group"
since my grasp of FRBR/xISBN is a little shaky I'll avoid any specific
terminology.
(Like I said in my original email, having a identifier or groups is a
definite advangtage).