> > 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).