ISBN in dc:terms

7 posts / 0 new
Last post

I create ePubs3 for a smaller academic publishing house. We typically distribute ePubs and sellers usually generate mobi on their servers (because of their own social DRMs). Than they offer both formats.

For me the problem is always how to build the ePub for both cases. Formatting questions aside now.

Is there any way how to include ALL ISBNs into metadata opf section?

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

That is enough for ePub, I suppose. How can I specify/refine another siblings' ISBNs? Can I? In case I can't, it would be maybe better not to provide such information in metadata at all! Don't want mobi readers to have ePub's ISBN in book's info panel...

Just my understanding of the issue:

Do avoid misunderstandings: ISBN and identifier is exclusively to identify this specific book publication (here the EPUB book the OPF-file belongs to), similar content in others formats are other publications with other identifiers and ISBNs.

Dublin Core element or term source will be only correct, if the content of the EPUB book is derived from the referenced resource, not vice versa.
If books with similar content but other formats have the same source, the Dublin Core element or term relation seems to be ok for this purpose, source only for the common source, if this exists and is published as well.
Usually, because amazon formats somehow bork the semantical meaning and accessibility due to encryption, they can be considered to be derived from a non encrypted EPUB, therefore such an EPUB would be a source, not the book in an Amazon format. If the EPUB is encrypted itself, it can be considered not as a source, because it is borked as well and not the origin, that might be not published at all. In such a case there are only relations between borked descendants, but no referenceable source.

3.0.1 lifted some restrictions, therefore there can be more than one Dublin Core source element for the book and in 2 and 3 anyway the number of relations is not limited and the number of Dublin Core source terms never was limited.

Different from the XHTML rel(ation) 'alternative' the Dublin Core term with the same name seems to have another meaning, therefore unfortunately not helpful here.

Thanks, probably I haven't explained that correctly. I am not in doubt in the case of source ISBN, that is clear, for us it is the ISBN of printed book. The problem is I have an ePub file which is later (without my control) used for automatically generated mobi file. I thought it could be helpful to include all ISBN codes bounded with the particular book. For example, I am doing the same in books' imprints:

ISBN xxxx-xxx-xxx-xxx
ISBN xxxx-xxx-xxx-xxx (pdf)
ISBN xxxx-xxx-xxx-xxx (epub)
ISBN xxxx-xxx-xxx-xxx (mobi)

This provides the interesting information for readers [long but useful when citing] (hey, they have published that in these formats, I could buy the pdf/epub/mobi too!

Is it possible to do something similar in the OPF file? In the way of refining tags for example....

In general one can put an identifier on the relation element and to refine it somehow as in the following example, but you have to look into details about terms of DCMI and you have to take into account, that even this might be formally correct, it will be ignored by user-agents anyway, because they have the tendency to ignore metadata anyway and especially complex metadata not explained in EPUB being of specific importance:
<dc:relation id="i1">URI/IRI</dc:relation>
<meta refines="#i1" id="ii1" property="dcterms:identifier">ISBN-Number</meta>
<meta refines="#ii1" property="identifier-type">ISBN</meta>
<meta refines="#i1" property="dcterms:format">text/plain</meta>

(use MIME/Media/Content-Type of the referenced resource as content of the property
dcterms:isFormatOf might be interesting for this purpose as well, but you have to look into details how to express your intentions right and complete.
I think, it is ok to refine everything you think it is useful to refine, but you have to find the right properties and vocabluaries to get the right expression. EPUB itself does not mention relevant restrictions on this, but it provides the method to refine. If you align your efforts here to structures of the usual triples of RDF(a), this should be ok at least in theory ;o)

Note that typically metadata is lost in conversion to other formats using the limited capabilities of conversion tools.
And due to the limited capabilities of the usual suspects of user-agents concerning metadata and other issues, if such information might have some use for normal readers, consider always to write some script, that creates an additional XHTML-file (for example expressed as definition lists for human readers) from the metadata section of the OPF-file and to add this to the normal content of the book, else most information will be lost for the normal user.

Just for advertising other formats, there might be no need to mention them in the OPF-file at all,
the XHTML-file might be already sufficient. Such complex metadata in the OPF-file is more meaningful for
a) testing capabilities of conversion tools and user-agents (what if you put some relevant license conditions here and a conversion tool or user-agent does not expose this to the user? It fails and the reader can get problems due to this).
b) conceptual theoretical efforts how to due it finally right, maybe for the better future (that might never appear ;o)

Thanks! :)

The short answer: If you have two renditions of the same publication which have different ISBNs assigned to them, and you want to use the ISBN as the unique identifier, then you must create two versions of the publication with the identifier in each set accordingly.

You could (and maybe should) go to the trouble of adding all the metadata to define the relationships between various renditions and their identifiers, but as O.H. points out, this information is often thrown away during format conversion or is simply not exposed by systems. Having some sort of imprint that lists the various renditions and their identifiers is probably a good idea, especially for an academic text.

Should different renditions of the same publication have different identifiers? That is a more debatable point and I could make equally good cases for both sides of the argument.

Hi,as for me, I am testing the related ISBN generator these days. Do you have any ideas about it? Or any good suggestion? I am totally a green hand on ISBN generating field. Any suggestion will be appreciated. Thanks in advance.

Secondary menu