So it gets confusing understanding how these thigns relate. But I think I’ve figured it out, and it’s actually quite simple. By EAN, I mean EAN-13 specifically, which is usually what people mean when they say EAN.
A UPC is just an EAN beginning with 0 (zero), with the initial 0 left off. All EAN’s beginning with 0 are US/Canadian. At some point someone in the US thought, hey, we don’t need to actually interoperate with the rest of the world, we only care about us, so let’s just leave that 0 off, since all of ours are 0 anyway. Since n+0=0 (you can call that the ‘arithmetic identity property of zero’ if you want to be fancy), you don’t need to recompute the check digit or anything, just take a UPC, prepend a 0 to it, you’ve got a valid EAN. Likewise, if you have an EAN beginning with 0, just drop it and you’ve got a UPC.
An ISBN-13 is an EAN. That’s right, any EAN beginning with 978 or 979 is an ISBN-13, and any ISBN-13 already is an EAN. Those first few digits in an EAN are a region/country code, but since there are so many books published, books got their own ‘country’ in the EAN Universe, the so-called “Bookland.” (I want to live there!).
So an ISBN-10, to be converted to an EAN, just needs to be converted to an ISBN-13 (including recalculating check-digit). The move from ISBN-10 to ISBN-13, in addition to adding extra space for ISBNs, also makes them fully legal EANs with no conversion necessary. (That’s why they used 978 and 979 instead of say “1”, and “2” — to make it finally a fully harmonized and valid EAN while they were expanding the address space. Since 978 and 979 are the EAN ‘bookland’ prefixes.).
Phew. Took me a few days of puzzling to figure that out, so maybe it’ll help someone else. Someone correct me if I’m wrong, but I believe I ain’t.
Oh, and on top of all that, it looks like an EAN-13 is now officially called a GTIN-13. Phew. So many names for essentially the same thing.
While we’re on the topic
OCLC/LC standards actually TELL you to put binding information (eg “paperback”) and other “qualification” (eg “vol 1”) right jammed into 020$a with the ISBN. Making it uneccesarily difficult for machine actors to actually pull out the actual ISBN, which they might need, from a bib record. You might think it would be a lot better to put that info in a different sub-field, and in fact there is a subfield $b for binding information, but it’s “obsolete. do not use.”
What the heck is wrong with us?
Question for the crowd
Is there a canonical way (or any good way) to express an EAN as a URI?
update 5:36pm. Oh boy. I think. Maybe. There’s also something called EPC, which it turns out is a superset of EAN-13. I think you can losslessly convert an EAN-13 to an EPC, and I think that an EPC may have a canonical URI form. EPC is intended for use with RFID, and can express more than an EAN-13 (aka a GTIN-13), but I think you can have a valid EPC which is no more or less than a representation of an EAN-13. But I can’t quite figure out the details.
Confused enough yet?
update again two minutes later. aha! http://tools.ietf.org/html/draft-mealling-epc-urn-02
Still confused. It looks like you can have a URN for a GTIN (aka EAN-13?) like for example this:
But you do need those periods. And only the first two groups of numbers corresopnd to the EAN-13. In that case, the EAN0-13, would, I think, be 9001000003456. That next number is some extra info (I think identifying the particular item in FRBR-speak, the actual individual physical thing). What if you don’t have the extra info, can you still make a GTIN URN? I could be wrong about a GTIN being the same thing as an EAN-13. Very confused.
Using the good folks at O’Reilly as an example, it looks like urn:epc:id:gtin (instead of sgtin) can be used to represent a standard GTIN-13.
Except what I don’t understand is why they supply an ISBN-13 which appears to be different. Based on my understanding that GTIN-13 == EAN-13 == ISBN-13, the ISBN-13 should be the same… and yet it is not…
So I still remain confused. But looks like the folks at O’Reilly might be good to talk to.