> 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
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
(Like I said in my original email, having a identifier or groups is a