Re: "Show me the metadata!" :), was Re: Rough sketch for WP

On September 23, 2016 at 3:12:33 AM, Baldur Bjarnason (baldur@rebus.foundation) wrote:
> I figured I could do a quick overview of how the existing ePub ecosystem handles metadata,  
> with screenshots. This focuses on trade publishing so YMMV.

This is awesome! Thank you.  

> The first thing to note is that the information below applies only to side-loaded ebooks.  
> For ebooks bought through the retail channel, retail-level metadata often overrides  
> embedded metadata.
>  
> And it does so for a good reason:
>  
> A large portion of the trade publishing industry generally doesn’t embed any metadata  
> to speak of, beyond just the title and author. At least one of the big trade publishers  
> as a policy doesn’t even embed the cover in the ebook.
>  
> This, in turn, is also for a good reason:
>  
> Embedded metadata is a huge pain to manage once you have more than a few titles. This is  
> caused by the very portable and packaged nature of ePubs (packaged files are a logistical  
> nightmare at scale). Packaged files combined with a clunky retail distribution system  
> means that an ebook, once made, is hardly ever altered or updated, no matter what happens.  
> This makes managing their embedded metadata very tricky once you’ve got more than a few  
> titles.

This should be reflected in the use cases document.  

> Retail metadata is generally much easier. If your catalogue is big, you basically give  
> the retailer an XML file with all of the metadata for your catalogue (usually ONIX, though  
> other formats might be in use somewhere). If your catalogue is small, the web UIs for managing  
> retail metadata are generally better designed and more easily understandable than  
> using existing ePub editors or (shudder) hacking the ePub’s XML and then re-uploading  
> the packaged file to all of the various retail websites you are selling through. Having  
> minimal embedded metadata and focusing on retail metadata makes a lot of logistical  
> sense for publishers.
>  
> Finally, most reading systems don’t offer the level of metadata detail in their displays  
> as Readium does, even the systems that are based on Readium (such as ADE for iOS). That’s  
> because the reading systems tend to care more about reader-oriented metadata (e.g.  
> organising their books into collections) or contextual data (e.g. selling you some  
> other book to read) than about publisher supplied metadata. Partly this is a side effect  
> of how retail-oriented publisher-supplied metadata is: they are of little use to a reader  
> organising their collection.

So, depending on how we focus this effort, we should focus on metadata that is primarily useful to users to manage their collections. 

Would others agree?

> Anyway, the first two examples are from Marvin, which caters to power users. The example  
> book is The Bleeding Edge by Bob Hughes. You’ll note that despite their focus on expert  
> users, the app doesn’t expose ISBNs or URNs. It does let the user edit the metadata, though.  

That's pretty neat. Something that could be done in app... but if we do find critical metadata for users, they should be able to manage it (possibly allow the app to manage it)... that's a good requirement right there. 

> The next one is from Kobo, which failed at side-loading Bob’s book, despite multiple  
> attempts, so I’m using an example from a purchased book, Cat’s Eye, by Margaret Atwood.  
>  
>  
>  
> Next is the only example that exposes the URN/ISBN: ADE for iOS.
>  
>  
>  
> Then there’s the most metadata rich display I found in iBooks (doesn’t show much at all).  
>  
>  
>  
> The best designed metadata UI I found was in Aldiko for iOS.
>  
>  
>  
> Gerty, by the creator of Marvin, has a very user-oriented metadata view.
>  
>  
>  
> Finally, Bluefire, which has the same level of detail as Aldiko in a slighly klunkier  
> UI.

Thanks again! These should definitely end up in the use cases doc!

Received on Friday, 23 September 2016 10:06:10 UTC