EPUB3-compatible Amazon ASIN metadata

jcsalomon · 07-25-2017, 10:07 AM

In EPUB2 books, a metadata entry of the form

Code:

<dc:identifier opf:scheme="AMAZON">BXXXXXXXXX</dc:identifier>

(where “BXXXXXXXXX” is the ASIN) seems to be the correct way to add such information. But in EPUB3, “opf:scheme” is not allowed, so I’m wondering what the “correct” method should be. Seems something along the lines of

Code:

<dc:identifier id="amazon-id">urn:AMAZON:BXXXXXXXXX</dc:identifier>
<meta refines="#amazon-id" property="identifier-type" scheme="xsd:string">AMAZON</meta>

should work, but is this right? Is the “<meta refines>” even needed, or perhaps is the “urn:AMAZON:” not correct?

(Perhaps, following http://idpf.org/epub/30/spec/epub30-...f-dcidentifier and substituting “01” [Proprietary] for “06” [DOI], the second line should be something like

Code:

<meta refines="#amazon-id" property="identifier-type" scheme="onix:codelist5">01</meta>

but http://stison.com/onix/codelists/onix-codelist-5.htm says, “Note that <IDTypeName> is required with proprietary identifiers” and there is no obvious place to put such “IDTypeName” information.)

Note that I’m asking what the EPUB3 spec suggests. I know full well that the Kindle generating process ignores such metadata, and I know that the first line is a format Calibre will interpret and EpubCheck will pass.

KevinH · 07-25-2017, 11:14 AM

My 2 cents here:

All of these seem correct.

But since refines go away under epub 3.1 metadata rules, and because the official rules of Universe Resource Name (urn:) are quite vague and do not require use of an "identifier-type", I would stick with the simplest approach for epub 3.0, using

<dc:identifier id="amazon-id">urn:AMAZON:BXXXXXXXXX</dc:identifier>

with no extra refines as parsing that urn provides all of the information needed to fully understand the identifier.

DiapDealer · 07-25-2017, 11:15 AM

I honestly don't think the extra meta refines entry would be necessary. But if you do add it, I don't think your initial example would violate epub spec. I'm not the go-to spec expert, though.

EDIT: seems KevinH beat me with similar info.

jcsalomon · 07-25-2017, 01:09 PM

Thanks, both of you.

(Is it always like this when diving into the spec? It seems in some ways vastly over-specified and in other ways astoundingly under-defined.)

j.p.s · 07-29-2017, 07:12 PM

Quote:

Originally Posted by jcsalomon

Is it always like this when diving into the spec?

It seems in some ways vastly over-specified and in other ways astoundingly under-defined.

What he asked.

Toxaris · 07-30-2017, 03:15 AM

Quote:

Originally Posted by jcsalomon

Thanks, both of you.

(Is it always like this when diving into the spec? It seems in some ways vastly over-specified and in other ways astoundingly under-defined.)

Yup. And don't forget my favorite: giving room to wiggle by using words like 'should', 'might', 'could'. A standard/specifications should not use those words if it can be avoided for at least the core. This is a short way of ensuring different interpretations and executions of the standard.

pdurrant · 07-30-2017, 06:27 AM

The ePub spec has been a great disappointment to me, concentrating on extraneous stuff like video and sounds, and ignoring things like specifying minimal rendering standards so that it was possible to do things like drop caps, or even simple superscripts, without having to be concerned about how it will render.

HarryT · 07-30-2017, 06:51 AM

Agreed. ePub 3 is in many ways a step backwards from ePub 2, to my mind.

JSWolf · 07-30-2017, 04:37 PM

Quote:

Originally Posted by HarryT

Agreed. ePub 3 is in many ways a step backwards from ePub 2, to my mind.

Also, ePub 3 is more difficult to make than ePub 2. Plus, all the focusing on multi-media is just so very wrong. What should have been done is take a look at ePub 2 and make changes to make it better without multi-media.

Support for multiple authors, series, covers without needing an html file to display it, support for non-ToC lines in the NCX ToC for display so there would be 100% no need for the HTML ToC and even support for multiple NCX as in an omnibus, and I bet there are other things I've not thought of.

Toxaris · 07-31-2017, 05:32 PM

Quote:

Originally Posted by JSWolf

Support for multiple authors, series, covers without needing an html file to display it, support for non-ToC lines in the NCX ToC for display so there would be 100% no need for the HTML ToC and even support for multiple NCX as in an omnibus, and I bet there are other things I've not thought of.

Proper footnote support and capabilities...

pdurrant · 08-01-2017, 03:39 AM

Proper drop cap support (i.e. specify a drop cap for three lines, require the renderer to make the drop cap fit three lines, even if the line spacing gets changed, and taking into account the cap height of the selected font. Not really hard for a renderer to do, but impossible currently.)

Proper subscript/superscript support. Require that adding subscript/superscript doesn't change line spacing for the line the superscript is on.

Poetry formatting. So that wrapped lines are right aligned. As was available in the Mobipocket format!

HarryT · 08-01-2017, 04:28 AM

Quote:

Originally Posted by pdurrant

Poetry formatting. So that wrapped lines are right aligned. As was available in the Mobipocket format!

Yes, this is such a simple thing, and so vital for poetry!

JSWolf · 08-01-2017, 06:16 AM

Quote:

Originally Posted by Toxaris

Proper footnote support and capabilities...

And also real smallcaps for the fonts installed with the Reader/app as well as working text-transform.

JSWolf · 08-01-2017, 06:21 AM

Quote:

Originally Posted by pdurrant

Proper subscript/superscript support. Require that adding subscript/superscript doesn't change line spacing for the line the superscript is on.

That's not always possible. I like a tight line height and a subscript/superscript would change the line height. Nothing can be done about it.

It's like a larger first letter on a Kindle with KF8. That first line is going to have the line-height different from the rest of the lines and nothing can be done about it.

Turtle91 · 08-01-2017, 12:54 PM

Quote:

Originally Posted by JSWolf

That's not always possible. I like a tight line height and a subscript/superscript would change the line height. Nothing can be done about it.

It's like a larger first letter on a Kindle with KF8. That first line is going to have the line-height different from the rest of the lines and nothing can be done about it.

Does kindle not support "float" for those large initial letters??

07-25-2017, 10:07 AM	#1
jcsalomon Zealot Posts: 100 Karma: 1204 Join Date: Jun 2012 Device: Bookari (née Mantano Reader) on Android; Kindle Fire HD	EPUB3-compatible Amazon ASIN metadata In EPUB2 books, a metadata entry of the form Code: <dc:identifier opf:scheme="AMAZON">BXXXXXXXXX</dc:identifier> (where “BXXXXXXXXX” is the ASIN) seems to be the correct way to add such information. But in EPUB3, “opf:scheme” is not allowed, so I’m wondering what the “correct” method should be. Seems something along the lines of Code: <dc:identifier id="amazon-id">urn:AMAZON:BXXXXXXXXX</dc:identifier> <meta refines="#amazon-id" property="identifier-type" scheme="xsd:string">AMAZON</meta> should work, but is this right? Is the “<meta refines>” even needed, or perhaps is the “urn:AMAZON:” not correct? (Perhaps, following http://idpf.org/epub/30/spec/epub30-...f-dcidentifier and substituting “01” [Proprietary] for “06” [DOI], the second line should be something like Code: <meta refines="#amazon-id" property="identifier-type" scheme="onix:codelist5">01</meta> but http://stison.com/onix/codelists/onix-codelist-5.htm says, “Note that <IDTypeName> is required with proprietary identifiers” and there is no obvious place to put such “IDTypeName” information.) Note that I’m asking what the EPUB3 spec suggests. I know full well that the Kindle generating process ignores such metadata, and I know that the first line is a format Calibre will interpret and EpubCheck will pass.

07-25-2017, 11:14 AM	#2
KevinH Sigil Developer Posts: 7,635 Karma: 5433388 Join Date: Nov 2009 Device: many	My 2 cents here: All of these seem correct. But since refines go away under epub 3.1 metadata rules, and because the official rules of Universe Resource Name (urn:) are quite vague and do not require use of an "identifier-type", I would stick with the simplest approach for epub 3.0, using <dc:identifier id="amazon-id">urn:AMAZON:BXXXXXXXXX</dc:identifier> with no extra refines as parsing that urn provides all of the information needed to fully understand the identifier. Last edited by KevinH; 07-25-2017 at 01:21 PM.

07-25-2017, 11:15 AM	#3
DiapDealer Grand Sorcerer Posts: 27,546 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	I honestly don't think the extra meta refines entry would be necessary. But if you do add it, I don't think your initial example would violate epub spec. I'm not the go-to spec expert, though. EDIT: seems KevinH beat me with similar info. Last edited by DiapDealer; 07-25-2017 at 02:12 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Metadata for PDF magazines - ASIN? other id?	dhdurgee	Library Management	5	02-12-2016 04:21 PM
Download options for Identifier (isbn, asin, etc.) metadata	digital_carver	Library Management	14	09-06-2015 08:35 PM
Download metadata from ASIN	CaitlinShaw	Library Management	3	06-17-2015 12:56 AM
Mobi-asin and metadata	desertblues	Calibre	6	01-20-2013 09:43 AM
Downloading ASIN from Amazon	nynaevelan	Library Management	6	02-02-2012 09:53 PM

07-25-2017, 01:09 PM	#4
jcsalomon Zealot Posts: 100 Karma: 1204 Join Date: Jun 2012 Device: Bookari (née Mantano Reader) on Android; Kindle Fire HD	Thanks, both of you. (Is it always like this when diving into the spec? It seems in some ways vastly over-specified and in other ways astoundingly under-defined.)

07-30-2017, 06:27 AM	#7
pdurrant The Grand Mouse 高貴的老鼠 Posts: 71,496 Karma: 306214458 Join Date: Jul 2007 Location: Norfolk, England Device: Kindle Voyage	The ePub spec has been a great disappointment to me, concentrating on extraneous stuff like video and sounds, and ignoring things like specifying minimal rendering standards so that it was possible to do things like drop caps, or even simple superscripts, without having to be concerned about how it will render.

07-30-2017, 06:51 AM	#8
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Agreed. ePub 3 is in many ways a step backwards from ePub 2, to my mind.

08-01-2017, 03:39 AM	#11
pdurrant The Grand Mouse 高貴的老鼠 Posts: 71,496 Karma: 306214458 Join Date: Jul 2007 Location: Norfolk, England Device: Kindle Voyage	Proper drop cap support (i.e. specify a drop cap for three lines, require the renderer to make the drop cap fit three lines, even if the line spacing gets changed, and taking into account the cap height of the selected font. Not really hard for a renderer to do, but impossible currently.) Proper subscript/superscript support. Require that adding subscript/superscript doesn't change line spacing for the line the superscript is on. Poetry formatting. So that wrapped lines are right aligned. As was available in the Mobipocket format!

Advert

Advert