Thread: Metadata link element urls not being updated
View Single Post
Old 11-10-2018, 10:50 PM   #10
thiago.eec
Wizard
thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.
 
Posts: 1,250
Karma: 1419583
Join Date: Dec 2016
Location: Goiânia - Brazil
Device: iPad, Kindle Paperwhite, Kindle Oasis
Quote:
Originally Posted by KevinH View Post
FWIW, I have never seen a commercial epub3 that used it in that way. Instead the extra logistics/manufacturing metadata was hosted externally.
Actually, the ONIX record is not just about logistics/manufacturing. Its a full metadata record, that carries a lot more info about the book then its possible to register on the metadata section of the opf file.

But, to be honest: I'm just an enthusiast and not a publishing professional, so I don't really know how Publishers and Reading Systems really use those records.

Quote:
Originally Posted by KevinH View Post
Update: Yes the href attribute does allow a relative iri in the opf metadata link tag so we will have to special case this when opening the epub. I just never saw it used that way and therefore Sigil does not handle it now, but it soon will.
Thank you very much for the quick response and possible correction!


Quote:
Originally Posted by Doitsu View Post
So far I haven't seen embedded Onix files in epub3 books either. AFAIK, Onix references are mostly used to indicate 13 digit ISBN numbers. For example:

Code:
<dc:source id="src-id">urn:isbn:9780141194523</dc:source>
<meta property="identifier-type" refines="#src-id" scheme="onix:codelist5">15</meta>
<dc:identifier id="book_id">urn:isbn:9780141963624</dc:identifier>
<meta property="identifier-type" refines="#book_id" scheme="onix:codelist5">15</meta>
(ONIX code list 5 contains product identifier types. 15 = ISBN-13.)
The main reason why I gave ONIX a try was the direction the specs seemed to be taking. Epub 3.1 revision deprecated REFINES atribute, keeping a more restrict set of metadata available directly on the opf file. The specs encouraged authors to use linked records for provindig more complete metadata info. Also, now, LINKED RECORDS take precedence over PACKAGE METADATA. So, I thought it would be wise to provide a full record via an onix file.

Epub 3.2 is intended to update 3.1 in order to maintain backward compatibility with 3.0.1, wich was broke with 3.1. Now, REFINES is back, but it will retain the precedence definition of 3.1 (linked metadata > package metadata). So, for now, using REFINES allows me to provide great metadata on the PACKAGE. But, the specs are clearly encouraging authors to use linked records to improve metadata info, leaving just the basics on the opf.
thiago.eec is offline   Reply With Quote