About identifier-type value of property attribute.

7 posts / 0 new
Last post


The identifier-type value of property attribute is written following in 4.3.2 Metadata meta Properties of EPUB Publication 3.0.

> identifier-type
Extends: identifier

But, the identifier-type value is used following in the section of The DCMES source Element.

<dc:source id="src-id">urn:isbn:9780375704024</dc:source>
<meta refines="#src-id" property="identifier-type" scheme="onix:codelist5">15</meta>

So, I think that "Extends: identifier, source" in 4.3.2 section is correct.

Additionally, I suggest that extends of identifier-type is "All properties".
Because, if I want to write BISAC code in OPF file, I think that dc:subject element and meta element is written following.

<dc:subject id="subject1">COM087000</dc:subject>
<meta refines="#subject1" property="identifier-type" scheme="onix:codelist26">10</meta>

# Do you have better way than writing the above?

You could make the argument that it should be allowed to identify any code, but at this time I don't know that your usage would be recognized as it's not expected (although I'm not sure if reading systems are picking up refinements and using them at this time).

The property was defined to qualify what the dc:identifier elements contain, not to explain any code value used in any property, and since dc:source contains the identifier for the source the publication was derived from, it's actually not a deviation from the defined usage (but source should have also been listed to be more explicit about this, which is definitely a bug).

A more precise means of identifying the BISAC code would be to reference the specific controlled list, but the BISG site isn't particularly conducive to easy referencing. You'd need to declare a prefix and reference the list like this:

<package prefix=”bisg: http://www.bisg.org/” ...>
   <meta property="dc:subject" scheme="bisg:what-we-do-0-93-bisac-subject-headings-list-computers.php">COM087000</meta>

But this is where bringing back EPUB 2's DCMES elements made metadata verbose at times, as there's no equivalent way to express this that would be backwards compatible (i.e., an EPUB 2 reading system isn't going to recognize meta tags like these). To target both, you'd still have to add a dc:subject element with just the code, which is where a refinement like you're doing makes more sense (although less precise about the specific heading type).

If you want the usage extended, thouh, it would be best to open a bug in the issue tracker so that this can be discussed during the next revision.

Thanks for the polite reply.

I was a lack of understanding about identifier-type.

Also, until it is explained to you, I had been thinking only writing both dc:subject and meta element.
I'm interested in making the EPUB file for EPUB 3 reading systems only (at the moment).
So, I want to follow the code that you wrote.

Ah, okay, in that case you should be able to use just the <meta> version with @scheme. It's simpler and more direct.

The new <meta> metadata tag was designed to allow the codes used to be easily identified using the scheme attribute; it's just the old DCMES elements that cause some problems, because they don't have the same functionality and aren't easily extended in all cases.

Best of luck with your project!

Although this is not quite on-topic, it is closely related. As shown above, the typical format for an ISBN identifier is:

<dc:identifier id="isbn">urn:isbn:9780375704024</dc:identifier>
<meta refines="#isbn" property="identifier-type" scheme="onix:codelist5">15</meta>


From the Onix for Books Codelists Issue 25:

15 ISBN-13 International Standard Book Number, from 2007, unhyphenated (13 digits starting 978 or 9791–9799).

22 URN Uniform Resource Name: note that in trade applications an ISBN must be sent as a GTIN-13 and, where required, as an ISBN-13 – it should not be sent as a URN.

Therefore, as I read it, the typical example format is completely incorrect. If one uses the:


notation, then the onix:codelist5 value should be 22, not 15, as follows:

<meta refines="#isbn" property="identifier-type" scheme="onix:codelist5">22</meta>


The onix:codelist5 specifically says do NOT use the URN notation for ISBN. Further, the format defined for code 15 is a 13 digit non-hyphenated number. Therefore, as I read it, the correct syntax for an ISBN identifier should be:

<dc:identifier id="isbn">9780375704024</dc:identifier>

In this same vein, the International DOI Foundation maintains DOIs are NOT a URN and using that type of notation is incorrect. Instead, a URL type of notation is preferred. Therefore a DOI identifier should be of the form:

<dc:identifier id="doi">http://dx.doi.org/10.1000/182</dc:identifier>
<meta refines="#doi" property="identifier-type" scheme="onix:codelist5">06</meta>

The use of UUIDs or OIDs should still be correct as the typical examples show:

<dc:identifier id="uuid">urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479</dc:identifier>
<meta refines="#uuid" property="identifier-type" scheme="onix:codelist5">22</meta>

<dc:identifier id="oid">urn:oid:</dc:identifier>
<meta refines="#oid" property="identifier-type" scheme="onix:codelist5">22</meta>

If I have misinterpreted anything, please correct my misapprehension. Thank you in advance.

Yes, you're absolutely correct that the use of '15' for the scheme code is incorrect. During the 3.0 revision, we switched from bare number strings to URIs, but those values didn't get updated.

I checked in with the folks at EDItEUR to verify whether using '22' as a replacement is acceptable or not, and they've indicated that they don't see a problem. To paraphrase the response, because EPUB package metadata is not used in a trading context (i.e., it's primarily for reading system use), the use of the URN identifier code is not an issue. It may not be correct for use in an ONIX record, but that doesn't make it's use as an identifier of the scheme wrong for EPUB metadata (the identifier-type property is a hint to the reading system that doesn't have to be used).

One interesting sidenote that came up in those discussions is that the 13 digit URN scheme remains in limbo. It was a draft document with the IETF back when we did 3.0, but has since had a couple of additional extensions and then fell into limbo in the last year. Again, it doesn't make the usage wrong, but not fully conformant.

And, yes, adding urn: to the doi: is unnecessary and wrong. We'll get that changed.

I've opened a bug to address these issues in the EPUB issue tracker.[1] I'm not sure when the next revision will be, but in the meantime I'm going to look at adding these as errata.[2]

Thanks for the thorough review of the examples, and apologies for the late response.

[1] https://code.google.com/p/epub-revision/issues/detail?id=459

[2] http://www.idpf.org/epub/301/spec/epub-publications-errata/


Thank you for your reply, and excuse my late response as well. Here are a couple of links to posts on the EPUB Package Metadata; one of which is a fuller discussion of what I posted here. I hope you find them of interest.

And no matter how good the verbiage of a specification is, examples are what people use when they attempt to do things on their own; so correct examples are critical to prevent proliferation of poor documents. Thanks for making the corrections.

[1] http://blog.celtexworks.com/?p=1

[2] http://blog.celtexworks.com/?p=19

Secondary menu