<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The ISBN as SKU</title>
	<atom:link href="http://pubfrontier.com/2008/06/16/the-isbn-as-sku/feed/" rel="self" type="application/rss+xml" />
	<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/</link>
	<description>A raucous public discussion of the publishing revolution.</description>
	<lastBuildDate>Sat, 25 Apr 2009 21:20:36 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Imma Wildcard</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-160</link>
		<dc:creator>Imma Wildcard</dc:creator>
		<pubDate>Fri, 25 Jul 2008 21:42:33 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-160</guid>
		<description>There&#039;s one real easy and quick fix to the multiple copy problem, and one that would require only a slight modification to computer programming that both creates and checks a barcode. AND one that would save publishers money and headaches.

The checksum number offers the possibility of 9 variations if it is discarded as a checking device (a rather quaint use, in some ways) and used instead as an ID number. Thus, one ISBN can now ID nine variations of the same book. 

Checking the ISBN for error during entry? Well, if the title on the book doesn&#039;t match the catalog, we know something&#039;s wrong, right? And if it is being read by a machine, just how common are errors today -- I would bet very low. I&#039;d prefer to double-check my numbers as I enter them and have an occasional glitch in inventory and have an instant nine possible variations on one ISBN. 

And for books sold only through Amazon.com or the like, the need to be scanned without error is almost non-existent. For a small publisher, these &quot;bootleg ISBNs&quot; make perfect sense (for the reason I&#039;m about to show below).

There are other advantages:  I can instantly call up ALL the variations of a title if I know just one ISBN whethr for the print, PDF, Kindle, talking book, or whatever version I might have in hand. I can just enter the ISBN for one version and a wild card in the checksum (now ID) space, I can see all the versions in one nice column. 

Try finding the PDF, MP3, Kindle, Hardcover, softcover, etc., etc., with one ISBN number search today and you&#039;re going to have problems. Chances are you won&#039;t discover them all, especially if this or that company has created a version of their own and tacked a new SKU to it (which as someone else noted, causes loss of control for the publisher, yet is done because of the expense of buying yet one more ISBN for the same title).

Of course this change in how the checksum is used would make it so those institutions issuing ISBNs can&#039;t gouge little publishers for 9 numbers when one would do the trick, and do it better for most of us. So those working for big publishing companies should be sure to avoid even considering such a change less small presses have a level playing field. Just saying ;o)</description>
		<content:encoded><![CDATA[<p>There&#8217;s one real easy and quick fix to the multiple copy problem, and one that would require only a slight modification to computer programming that both creates and checks a barcode. AND one that would save publishers money and headaches.</p>
<p>The checksum number offers the possibility of 9 variations if it is discarded as a checking device (a rather quaint use, in some ways) and used instead as an ID number. Thus, one ISBN can now ID nine variations of the same book. </p>
<p>Checking the ISBN for error during entry? Well, if the title on the book doesn&#8217;t match the catalog, we know something&#8217;s wrong, right? And if it is being read by a machine, just how common are errors today &#8212; I would bet very low. I&#8217;d prefer to double-check my numbers as I enter them and have an occasional glitch in inventory and have an instant nine possible variations on one ISBN. </p>
<p>And for books sold only through Amazon.com or the like, the need to be scanned without error is almost non-existent. For a small publisher, these &#8220;bootleg ISBNs&#8221; make perfect sense (for the reason I&#8217;m about to show below).</p>
<p>There are other advantages:  I can instantly call up ALL the variations of a title if I know just one ISBN whethr for the print, PDF, Kindle, talking book, or whatever version I might have in hand. I can just enter the ISBN for one version and a wild card in the checksum (now ID) space, I can see all the versions in one nice column. </p>
<p>Try finding the PDF, MP3, Kindle, Hardcover, softcover, etc., etc., with one ISBN number search today and you&#8217;re going to have problems. Chances are you won&#8217;t discover them all, especially if this or that company has created a version of their own and tacked a new SKU to it (which as someone else noted, causes loss of control for the publisher, yet is done because of the expense of buying yet one more ISBN for the same title).</p>
<p>Of course this change in how the checksum is used would make it so those institutions issuing ISBNs can&#8217;t gouge little publishers for 9 numbers when one would do the trick, and do it better for most of us. So those working for big publishing companies should be sure to avoid even considering such a change less small presses have a level playing field. Just saying ;o)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Mark Ockerbloom</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-129</link>
		<dc:creator>John Mark Ockerbloom</dc:creator>
		<pubDate>Thu, 19 Jun 2008 18:45:13 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-129</guid>
		<description>&quot;When we developed EPUB, we imagined its use in one of two ways. The first was software which natively rendered (read) EPUB files like Adobe Digital Editions does. The second was software which automatically converted from EPUB to a proprietary file format.&quot;

How is this different from OEBPF, which was first released back in 2000, and which was also imagined to be used both of these ways?   The reason I ask is because that format, in my recollection, didn&#039;t actually get used much as a native-reader format in many commercial ebook releases, but seemed to mainly be talked about as a  &quot;publisher intermediate format&quot; after it was released.

&quot;Proprietary formats simply exist now because EPUB wasn’t around for the past 8 years and software companies needed inventory from publishers to do business so they made their own.&quot;

This appears to skate over the whole DRM issue.  Are you expecting that this time most publishers will be content to release straight Epub (which I didn&#039;t think had DRM, but correct me if I&#039;m wrong), instead of putting it in their favorite DRM wrapper?  If so, what makes you think that?  (I&#039;d like that, but I&#039;m not sure I see definite signs of it happening.)  If not, why would Epub do anything about the existing proliferation of proprietary formats for commercial ebooks?</description>
		<content:encoded><![CDATA[<p>&#8220;When we developed EPUB, we imagined its use in one of two ways. The first was software which natively rendered (read) EPUB files like Adobe Digital Editions does. The second was software which automatically converted from EPUB to a proprietary file format.&#8221;</p>
<p>How is this different from OEBPF, which was first released back in 2000, and which was also imagined to be used both of these ways?   The reason I ask is because that format, in my recollection, didn&#8217;t actually get used much as a native-reader format in many commercial ebook releases, but seemed to mainly be talked about as a  &#8220;publisher intermediate format&#8221; after it was released.</p>
<p>&#8220;Proprietary formats simply exist now because EPUB wasn’t around for the past 8 years and software companies needed inventory from publishers to do business so they made their own.&#8221;</p>
<p>This appears to skate over the whole DRM issue.  Are you expecting that this time most publishers will be content to release straight Epub (which I didn&#8217;t think had DRM, but correct me if I&#8217;m wrong), instead of putting it in their favorite DRM wrapper?  If so, what makes you think that?  (I&#8217;d like that, but I&#8217;m not sure I see definite signs of it happening.)  If not, why would Epub do anything about the existing proliferation of proprietary formats for commercial ebooks?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kassia Krozser</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-125</link>
		<dc:creator>Kassia Krozser</dc:creator>
		<pubDate>Tue, 17 Jun 2008 02:17:04 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-125</guid>
		<description>For many years, I worked at a motion picture company that managed a large number of smaller products associated with a single &quot;meta&quot; product (think fifty years of a daily soap opera to understand the scope). I often wonder why the ISBN process doesn&#039;t  mirror this more closely: the &quot;product&quot; (title/author/publisher[s]), the format, and distribution channel. This keeps a single number associated with the actual title/author, but uses identifiers to isolate specific changeable aspects related to the book.

I&#039;m not saying that the system used by my former employer was perfect -- in fact, the entire notion of SKU destroyed the lovely symmetry as unaffiliated third parties had their own numbering systems -- but it sure beats separate and unique numbers for units that are part of a whole.</description>
		<content:encoded><![CDATA[<p>For many years, I worked at a motion picture company that managed a large number of smaller products associated with a single &#8220;meta&#8221; product (think fifty years of a daily soap opera to understand the scope). I often wonder why the ISBN process doesn&#8217;t  mirror this more closely: the &#8220;product&#8221; (title/author/publisher[s]), the format, and distribution channel. This keeps a single number associated with the actual title/author, but uses identifiers to isolate specific changeable aspects related to the book.</p>
<p>I&#8217;m not saying that the system used by my former employer was perfect &#8212; in fact, the entire notion of SKU destroyed the lovely symmetry as unaffiliated third parties had their own numbering systems &#8212; but it sure beats separate and unique numbers for units that are part of a whole.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Grace Agnew</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-123</link>
		<dc:creator>Grace Agnew</dc:creator>
		<pubDate>Mon, 16 Jun 2008 21:05:40 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-123</guid>
		<description>I think the issue of relationship among different entities becomes more and more critical.  The identifier can be &quot;dumb&quot; and used to validate authenticity of an object and ensure appropriate access, e.g., if I purchase the license to the Kindle version, I need an identifier that ensures I download Kindle and not a different e-book format, regardless of the distributor or download source.  The dumb identifier works if relationships among the various formats and versions exist, perhaps using OAI-ORE, to enable me to select the most appropriate version for me (e.g., the Kindle) so that the identifier associated with the Kindle can then ensure that I retrieve and use the appropriate resource--the resource I most likely have purchased the rights to.</description>
		<content:encoded><![CDATA[<p>I think the issue of relationship among different entities becomes more and more critical.  The identifier can be &#8220;dumb&#8221; and used to validate authenticity of an object and ensure appropriate access, e.g., if I purchase the license to the Kindle version, I need an identifier that ensures I download Kindle and not a different e-book format, regardless of the distributor or download source.  The dumb identifier works if relationships among the various formats and versions exist, perhaps using OAI-ORE, to enable me to select the most appropriate version for me (e.g., the Kindle) so that the identifier associated with the Kindle can then ensure that I retrieve and use the appropriate resource&#8211;the resource I most likely have purchased the rights to.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nick Bogaty</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-122</link>
		<dc:creator>Nick Bogaty</dc:creator>
		<pubDate>Mon, 16 Jun 2008 18:42:55 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-122</guid>
		<description>Leaving aside the subject of ISBN assignment as it relates to EPUB, I&#039;d like to address some issues which Mike brings up below.  I think the situation is a bit less dramatic than described:
 
As I&#039;ve previously detailed on this list, when we developed EPUB, we imagined its use in one of two ways.  The first was software which natively rendered (read) EPUB files like Adobe Digital Editions does.  The second was software which automatically converted from EPUB to a proprietary file format.  The criteria of success we always casually referred to in the second scenario was that the software would convert EPUB in an &quot;un-stupid&quot; way.  What this really meant was that the layout and composition of the original EPUB file would be maintained in the automatic conversion process, leaving a publisher&#039;s book still looking good after conversion.  Just like if you converted from MP3 to AAC in iTunes, the file would still sound good after conversion.
 
So, a publisher does and will continue to vet their EPUB files, only now on a software basis and not on a file by file basis.  For example, if a software company comes to a publisher and says, &quot;I can take your EPUB files and automatically convert them to XYZ format and your books will still look good,&quot; the publisher just needs to be sure that this statement is true.  A publisher can make sure this is true by taking 10 or 20 or a 100 files and open them in the software and see what their books look like.  At the end of the test, if everything converts well, no additional vetting would be required because the software company passed the test of converting &quot;un-stupidly&quot;.  This isn&#039;t a publisher giving up vetting, QC and responsibility for a well produced product, it is just a more efficient production workflow following an understanding by a publisher that a company&#039;s software works as expected.
 
I&#039;ll add though that an advantage of software that renders EPUB natively is that this vetting and QC step to insure that a file is converted correctly does not have to happen.  The software renders the EPUB file as the publisher created it.
 
Finally, I do not believe that EPUB necessarily allows the proliferation of file formats; that certainly wasn&#039;t our intention when we developed the format.  In only very unusual circumstances that I know of does software or hardware require conversion to a proprietary format because EPUB does not, for some reason, provide the necessary technology.  Proprietary formats simply exist now because EPUB wasn&#039;t around for the past 8 years and software companies needed inventory from publishers to do business so they made their own.  With all of the recent announcements by publishers on releasing EPUB inventory and a critical mass of EPUB selection coming to the market (I&#039;d guess by this Fall) the marks in the &quot;pro&quot; column for software supporting a proprietary format, seem to me, to dwindle.</description>
		<content:encoded><![CDATA[<p>Leaving aside the subject of ISBN assignment as it relates to EPUB, I&#8217;d like to address some issues which Mike brings up below.  I think the situation is a bit less dramatic than described:</p>
<p>As I&#8217;ve previously detailed on this list, when we developed EPUB, we imagined its use in one of two ways.  The first was software which natively rendered (read) EPUB files like Adobe Digital Editions does.  The second was software which automatically converted from EPUB to a proprietary file format.  The criteria of success we always casually referred to in the second scenario was that the software would convert EPUB in an &#8220;un-stupid&#8221; way.  What this really meant was that the layout and composition of the original EPUB file would be maintained in the automatic conversion process, leaving a publisher&#8217;s book still looking good after conversion.  Just like if you converted from MP3 to AAC in iTunes, the file would still sound good after conversion.</p>
<p>So, a publisher does and will continue to vet their EPUB files, only now on a software basis and not on a file by file basis.  For example, if a software company comes to a publisher and says, &#8220;I can take your EPUB files and automatically convert them to XYZ format and your books will still look good,&#8221; the publisher just needs to be sure that this statement is true.  A publisher can make sure this is true by taking 10 or 20 or a 100 files and open them in the software and see what their books look like.  At the end of the test, if everything converts well, no additional vetting would be required because the software company passed the test of converting &#8220;un-stupidly&#8221;.  This isn&#8217;t a publisher giving up vetting, QC and responsibility for a well produced product, it is just a more efficient production workflow following an understanding by a publisher that a company&#8217;s software works as expected.</p>
<p>I&#8217;ll add though that an advantage of software that renders EPUB natively is that this vetting and QC step to insure that a file is converted correctly does not have to happen.  The software renders the EPUB file as the publisher created it.</p>
<p>Finally, I do not believe that EPUB necessarily allows the proliferation of file formats; that certainly wasn&#8217;t our intention when we developed the format.  In only very unusual circumstances that I know of does software or hardware require conversion to a proprietary format because EPUB does not, for some reason, provide the necessary technology.  Proprietary formats simply exist now because EPUB wasn&#8217;t around for the past 8 years and software companies needed inventory from publishers to do business so they made their own.  With all of the recent announcements by publishers on releasing EPUB inventory and a critical mass of EPUB selection coming to the market (I&#8217;d guess by this Fall) the marks in the &#8220;pro&#8221; column for software supporting a proprietary format, seem to me, to dwindle.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Shatzkin</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-121</link>
		<dc:creator>Mike Shatzkin</dc:creator>
		<pubDate>Mon, 16 Jun 2008 18:41:33 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-121</guid>
		<description>As several commenters have made clear, how to manage the ISBNs IS a business question and publishers should not be making decisions based on how much admin is involved with one thing or another, but on the real business issues buried in this epub and ISBN discussion.

What epub allows is a proliferation of formats because the conversion from epub to somewhat different ebook formats can be pretty easily automated by the format creator. One could imagine with the iPhone, for example, where Apple seems (at the moment) disinterested in ebooks but is encouraging independent development, that more than one format could well be developed, perhaps already has been. Somewhat paradoxically and counterintuitvely, then, the &quot;standardization&quot; to epub could lead to a proliferation of formats which might not themselves be interoperable.

And, aside from not being interoperable, some of these versions might work a lot better than others. So among the business questions for the publishers are:

1. Are you happy with your epub file being turned into any format a downstream vendor can successfully peddle, without feeling the need for any sort of vetting or quality control?

2. Will you actually resist tracking sales and revenue reporting by the various formats and, in your own records and reporting to the author, just leave them rolled up by master (epub) ISBN?

3. How far does your laissez-faire attitude go, if a downstream epub vendor were to &quot;enhance&quot; your publication with additional material, criticism, notes, etc. assuming that your price-per-copy-sold were paid to you in full?

4. Time was, if the book you got was missing a signature or had a page printed upside down, you knew that the publisher was the responsible party and would address your complaint to the publisher. What does the consumer do if the ebook doesn&#039;t work and the publisher&#039;s involvement ended with the file handoff? Should a publisher accept that situation?

The question of whether an epub-only ISBN unconsciously crosses a line from selling an instance or an object to licensing content for use may become critical if Amazon decides that licensing the content and delivering their own versions -- like a big book club -- would be their preferred way to do business. And how far away could that day be?

Mike</description>
		<content:encoded><![CDATA[<p>As several commenters have made clear, how to manage the ISBNs IS a business question and publishers should not be making decisions based on how much admin is involved with one thing or another, but on the real business issues buried in this epub and ISBN discussion.</p>
<p>What epub allows is a proliferation of formats because the conversion from epub to somewhat different ebook formats can be pretty easily automated by the format creator. One could imagine with the iPhone, for example, where Apple seems (at the moment) disinterested in ebooks but is encouraging independent development, that more than one format could well be developed, perhaps already has been. Somewhat paradoxically and counterintuitvely, then, the &#8220;standardization&#8221; to epub could lead to a proliferation of formats which might not themselves be interoperable.</p>
<p>And, aside from not being interoperable, some of these versions might work a lot better than others. So among the business questions for the publishers are:</p>
<p>1. Are you happy with your epub file being turned into any format a downstream vendor can successfully peddle, without feeling the need for any sort of vetting or quality control?</p>
<p>2. Will you actually resist tracking sales and revenue reporting by the various formats and, in your own records and reporting to the author, just leave them rolled up by master (epub) ISBN?</p>
<p>3. How far does your laissez-faire attitude go, if a downstream epub vendor were to &#8220;enhance&#8221; your publication with additional material, criticism, notes, etc. assuming that your price-per-copy-sold were paid to you in full?</p>
<p>4. Time was, if the book you got was missing a signature or had a page printed upside down, you knew that the publisher was the responsible party and would address your complaint to the publisher. What does the consumer do if the ebook doesn&#8217;t work and the publisher&#8217;s involvement ended with the file handoff? Should a publisher accept that situation?</p>
<p>The question of whether an epub-only ISBN unconsciously crosses a line from selling an instance or an object to licensing content for use may become critical if Amazon decides that licensing the content and delivering their own versions &#8212; like a big book club &#8212; would be their preferred way to do business. And how far away could that day be?</p>
<p>Mike</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Lichtenberg</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-120</link>
		<dc:creator>Jim Lichtenberg</dc:creator>
		<pubDate>Mon, 16 Jun 2008 18:37:40 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-120</guid>
		<description>It&#039;s easier, and probably a reasonable first reaction, to think of digital identifiers in terms of the  (complex) technology that is involved.   But Michael&#039;s point underscores the importance of publishers moving toward a BUSINESS approach to these questions, based on the assumption that your content is YOUR content.

Granted paperbacks are are now so familiar, but publishers have dealt nicely with their evolving iterations after some grousing at the beginning.... so why not digital versions.   In the ancient days of 1995-1996, one of the things that made the Internet scary was the generally held view that publishers were at serious risk of having some giant technology company swoop down and take away all the content in digital form...

Best way to avoid falling into that deep river :-) is to manage the identifiers as Laura suggests as a cost of business, and respond to digital content as a business challenge,  not a technological one as per M. Holdsworth.</description>
		<content:encoded><![CDATA[<p>It&#8217;s easier, and probably a reasonable first reaction, to think of digital identifiers in terms of the  (complex) technology that is involved.   But Michael&#8217;s point underscores the importance of publishers moving toward a BUSINESS approach to these questions, based on the assumption that your content is YOUR content.</p>
<p>Granted paperbacks are are now so familiar, but publishers have dealt nicely with their evolving iterations after some grousing at the beginning&#8230;. so why not digital versions.   In the ancient days of 1995-1996, one of the things that made the Internet scary was the generally held view that publishers were at serious risk of having some giant technology company swoop down and take away all the content in digital form&#8230;</p>
<p>Best way to avoid falling into that deep river :-) is to manage the identifiers as Laura suggests as a cost of business, and respond to digital content as a business challenge,  not a technological one as per M. Holdsworth.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Holdsworth</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-119</link>
		<dc:creator>Michael Holdsworth</dc:creator>
		<pubDate>Mon, 16 Jun 2008 18:36:11 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-119</guid>
		<description>Some of these issues are addressed in &lt;a href=&quot;http://www.bisg.org/docs/DigitalIdentifiers_07Jan08.pdf&quot; rel=&quot;nofollow&quot;&gt;&lt;em&gt;the paper I wrote&lt;/em&gt;&lt;/a&gt; [pdf] for BISG and BIC earlier this year.

In one particular respect, that discussion paper has been overtaken by events - along the lines alluded to by Peter B.

In January, ISBNs were simply not available (within the International ISBN Agency&#039;s rules) for intermediaries and re-sellers to allocate. They couldn&#039;t get a prefix. This forced some to take quite extreme measures: for example, creating &quot;ISBN-like&quot; 13-digit identifiers, or even appropriating pirated prefixes from other (often East European) ISBN jurisdictions.

After the London Book Fair, however, the Agency agreed that national ISBN agencies (respectively Bowker and Nielsen in the USA and UK) may now legitimately assign registrant prefixes to eBook resellers to enable them to allocate ISBNs to individual eBook formats if, and only if, the publisher has not provided an eBook ISBN for each format, or if (illegally within the scheme) the publisher has used a composite identifier to cover more than one format.  If the publisher has provided separate ISBNs for each separate format, then the Agency insists that these should always be used in preference to any reseller ISBNs.

Publishers need to decide the nature of their eBook supply-chain relationship. Are they selling a product to a retailer to sell on, just like a print book, which is their (= the publisher’s) product all the way through to the user/consumer, and identifiable as such, with their brand, ISBN and their prefix?

Or are they allowing the retailer to create any number of products from a source file (ePub in its &#039;distribution&#039; model), which the publisher is simply licensing –the audible.com model - leaving it to the retailer/eBookseller to own and brand the product with their own ISBN and prefix?

The latter relationship starts to look very much like a traditional ‘secondary right’, with the retailer taking on the role as secondary publisher (like a newspaper, an anthologist, or a foreign-language publisher). This has the potential to impact the current debate between publishers, agents and authors’ societies about appropriate eBook royalty structures. And impacting it in the direction of higher royalties.

I&#039;m not a publisher any more, but if I were, I&#039;d be really nervous of third-parties deploying their own registrant prefixes and ISBNs for my content, but I&#039;d be leaving my business partners with no alternative if I haven&#039;t done the work of pre-allocating differentiated identifiers myself.

To Laura&#039;s point about systems-bloat, there are real concerns here. But I guess we fall back on the premise that computers are designed to manage complexity. They just need some clear rules...

Michael Holdsworth</description>
		<content:encoded><![CDATA[<p>Some of these issues are addressed in <a href="http://www.bisg.org/docs/DigitalIdentifiers_07Jan08.pdf" rel="nofollow"><em>the paper I wrote</em></a> [pdf] for BISG and BIC earlier this year.</p>
<p>In one particular respect, that discussion paper has been overtaken by events &#8211; along the lines alluded to by Peter B.</p>
<p>In January, ISBNs were simply not available (within the International ISBN Agency&#8217;s rules) for intermediaries and re-sellers to allocate. They couldn&#8217;t get a prefix. This forced some to take quite extreme measures: for example, creating &#8220;ISBN-like&#8221; 13-digit identifiers, or even appropriating pirated prefixes from other (often East European) ISBN jurisdictions.</p>
<p>After the London Book Fair, however, the Agency agreed that national ISBN agencies (respectively Bowker and Nielsen in the USA and UK) may now legitimately assign registrant prefixes to eBook resellers to enable them to allocate ISBNs to individual eBook formats if, and only if, the publisher has not provided an eBook ISBN for each format, or if (illegally within the scheme) the publisher has used a composite identifier to cover more than one format.  If the publisher has provided separate ISBNs for each separate format, then the Agency insists that these should always be used in preference to any reseller ISBNs.</p>
<p>Publishers need to decide the nature of their eBook supply-chain relationship. Are they selling a product to a retailer to sell on, just like a print book, which is their (= the publisher’s) product all the way through to the user/consumer, and identifiable as such, with their brand, ISBN and their prefix?</p>
<p>Or are they allowing the retailer to create any number of products from a source file (ePub in its &#8216;distribution&#8217; model), which the publisher is simply licensing –the audible.com model &#8211; leaving it to the retailer/eBookseller to own and brand the product with their own ISBN and prefix?</p>
<p>The latter relationship starts to look very much like a traditional ‘secondary right’, with the retailer taking on the role as secondary publisher (like a newspaper, an anthologist, or a foreign-language publisher). This has the potential to impact the current debate between publishers, agents and authors’ societies about appropriate eBook royalty structures. And impacting it in the direction of higher royalties.</p>
<p>I&#8217;m not a publisher any more, but if I were, I&#8217;d be really nervous of third-parties deploying their own registrant prefixes and ISBNs for my content, but I&#8217;d be leaving my business partners with no alternative if I haven&#8217;t done the work of pre-allocating differentiated identifiers myself.</p>
<p>To Laura&#8217;s point about systems-bloat, there are real concerns here. But I guess we fall back on the premise that computers are designed to manage complexity. They just need some clear rules&#8230;</p>
<p>Michael Holdsworth</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Bide</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-118</link>
		<dc:creator>Mark Bide</dc:creator>
		<pubDate>Mon, 16 Jun 2008 18:22:01 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-118</guid>
		<description>The challenge of maintaining metadata for media content is becoming increasingly obvious wherever you look.

 In my experience, looking at both publishing and the music industry, the problem is seriously exacerbated by looking at &quot;digital&quot; as an adjunct to &quot;physical&quot;. For example, when considering how to manage the relationships between content and products, and between products and related products, there is a natural tendency to start from legacy systems, particularly those systems we have used for years or even decades to manage metadata for physical content and products, and then try to adapt these to manage digital content and products. Unfortunately, so far as I have seen, such attempts are bound to fail (or at least bound to end in the sort of manual untangling that Linda describes which over time becomes increasingly unscalable). On the other hand, if you start from processes and systems designed for the management of metadata for digital, the addition of the management of metadata for physical is entirely straightforward. However, this kind of radical approach to systems development requires the sort of rethinking that is not easy to achieve (since it involves every part of the organisation).

But, as Linda says, managing metadata and identity properly has already become a cost of doing business.

Mark</description>
		<content:encoded><![CDATA[<p>The challenge of maintaining metadata for media content is becoming increasingly obvious wherever you look.</p>
<p> In my experience, looking at both publishing and the music industry, the problem is seriously exacerbated by looking at &#8220;digital&#8221; as an adjunct to &#8220;physical&#8221;. For example, when considering how to manage the relationships between content and products, and between products and related products, there is a natural tendency to start from legacy systems, particularly those systems we have used for years or even decades to manage metadata for physical content and products, and then try to adapt these to manage digital content and products. Unfortunately, so far as I have seen, such attempts are bound to fail (or at least bound to end in the sort of manual untangling that Linda describes which over time becomes increasingly unscalable). On the other hand, if you start from processes and systems designed for the management of metadata for digital, the addition of the management of metadata for physical is entirely straightforward. However, this kind of radical approach to systems development requires the sort of rethinking that is not easy to achieve (since it involves every part of the organisation).</p>
<p>But, as Linda says, managing metadata and identity properly has already become a cost of doing business.</p>
<p>Mark</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Laura Dawson</title>
		<link>http://pubfrontier.com/2008/06/16/the-isbn-as-sku/comment-page-1/#comment-117</link>
		<dc:creator>Laura Dawson</dc:creator>
		<pubDate>Mon, 16 Jun 2008 18:13:31 +0000</pubDate>
		<guid isPermaLink="false">http://pubfrontier.com/?p=41#comment-117</guid>
		<description>Maintaining the metadata associated with each one of these ISBNs is incredible. Say you&#039;ve got a Spanish textbook. Then you&#039;ve got the e-version of it in three different formats (VitalSource, Quia, and CourseSmart). Then you&#039;ve got the print lab manual and the print workbook. Then you&#039;ve got the e-versions of these. Plus you&#039;ve got downloadable language labs that you can port into your iPod. You&#039;ve got instructional animations that are available as a separate product that you can put on your iPod as well. That&#039;s 14 related ISBNs with associated metadata attached to each one. Then if you need to customize any of these for a particular state university adoption...

It&#039;s rather like having a very large extended family and having to keep track of birthdays, anniversaries, graduations, who&#039;s in trouble at school, who needs new clothes, what the babysitting schedule is, who is getting a divorce, and that your niece is learning-disabled and your brother has to sue the school district every year just to get her the services she needs....

In other words the more ISBNs you have, the more crucial accurate metadata becomes, because otherwise how the hell are you going to keep your products straight? And I think this is in large part what publishers object to. They have a lot of frustration in keeping up with the metadata explosion that goes on with these splintered, fragmented, related products.

The mistake is in thinking that fewer ISBNs means less data administration. Your products still need to be sold, even if we could come up with a different way of identifying them - just as your husband&#039;s second cousin will still need a new baby gift even if you can&#039;t for the life of you remember her name.

No, really. The more products you get involved with, the more metadata you have to keep track of. And that&#039;s just a cost of doing business.</description>
		<content:encoded><![CDATA[<p>Maintaining the metadata associated with each one of these ISBNs is incredible. Say you&#8217;ve got a Spanish textbook. Then you&#8217;ve got the e-version of it in three different formats (VitalSource, Quia, and CourseSmart). Then you&#8217;ve got the print lab manual and the print workbook. Then you&#8217;ve got the e-versions of these. Plus you&#8217;ve got downloadable language labs that you can port into your iPod. You&#8217;ve got instructional animations that are available as a separate product that you can put on your iPod as well. That&#8217;s 14 related ISBNs with associated metadata attached to each one. Then if you need to customize any of these for a particular state university adoption&#8230;</p>
<p>It&#8217;s rather like having a very large extended family and having to keep track of birthdays, anniversaries, graduations, who&#8217;s in trouble at school, who needs new clothes, what the babysitting schedule is, who is getting a divorce, and that your niece is learning-disabled and your brother has to sue the school district every year just to get her the services she needs&#8230;.</p>
<p>In other words the more ISBNs you have, the more crucial accurate metadata becomes, because otherwise how the hell are you going to keep your products straight? And I think this is in large part what publishers object to. They have a lot of frustration in keeping up with the metadata explosion that goes on with these splintered, fragmented, related products.</p>
<p>The mistake is in thinking that fewer ISBNs means less data administration. Your products still need to be sold, even if we could come up with a different way of identifying them &#8211; just as your husband&#8217;s second cousin will still need a new baby gift even if you can&#8217;t for the life of you remember her name.</p>
<p>No, really. The more products you get involved with, the more metadata you have to keep track of. And that&#8217;s just a cost of doing business.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
