¿Cómo agrupar varias versiones de un libro en un mismo <Product>?
59 views
Skip to first unread message
Jesús Peraita
Oct 20, 2011, 6:50:32 AM10/20/11
to onix-es
Hola,
Os copio un interesante cruce de mensajes que se ha producido en el
grupo ONIX_IMPLEMENT respecto a la posibilidad de "agrupar" en un
único bloque <Product> distintas manifestaciones de una misma obra:
p.ej. la versión impresa y tres versiones digitales en distintos
formatos.
La respuesta de Graham Bell, responsable de la arquitectura ONIX, es
sencilla: NO se puede hacer.
Cada formato necesita un ISBN y un <Record> distinto.
Un saludo,
Jesús Peraita
------------------------------------------------------------------
On 18 Oct 2011, at 23:10, Jonathan Gordon wrote:
>
>
> What is the best practice for creating an ONIX record for a Product
> that has a print version (e.g., ProductForm of "BB") and several
> Epublications (i.e., ProductForm of "DG") with multiple EpubTypes
> (e.g, PDF, HTML, Open Ebook), all sharing the same EAN? Is this one
> Product record, ProductForm of "BB" with three RelatedProduct
> composites with EpubType (PR.23.27) using a RelationCode of 13:
> "Epublication based on (print product)"? Or two Product records, one
> having a ProductForm of "BB", the other with ProductForm of "DG" with
> one EpubType specified at (PR.4.1) with two RelatedProduct composites?
> Something else entirely?
>
> Thanks for your help,
>
> Jonathan
Re: [ONIX_IMPLEMENT] Multiple EpubType and ProductForm instances for a
single EAN
Hi Jonathan
There are three parts to this answer.
First, you have to view the hardcover and the e-book(s) as at least
two separate Products. After all, they are likely to carry separate
prices, they have different fulfillment processes, and they clearly
have different product forms (BB and DG in ONIX 2.1, BB and ED in ONIX
3.0). And that means they have two or more separate <Product> records.
In ONIX, you simply cannot have a single 'product' with multiple
different product forms -- different product forms by definition means
different Products.
And an ISBN always identifies a 'product' too. ISBNs should never be
assigned to 'a group of products'. Most people take this for granted
in the physical world -- when faced with hardcover and softcover books
with the same content, they are given different ISBNs. Even two
distinct softcovers, one rack -sized and one trade paperback, get two
different ISBNs. And so it should be with e-books -- if you have a
hardcover and an e-book, they should never share an ISBN.
[NB you mention EANs, and of course ISBNs are just a particular
small subset of EANs that are reserved for identifiying book and book-
like products. ISBNs are EANs that begin with 978... or 979... And
these days, EANs are more properly called GTIN-13s.]
So the ISBN is used to distinguish between different products which
have the same content. It also, of course, distinguishes between
similar products that have different content -- for example the
hardcover versions of the first and second editions of a particular
title should always have different ISBNs.
And in ONIX, you'll have something like this:
<Header>
...
</Header>
<!-- product A, hardcover -->
<Product>
Product ID A (ISBN #1)
Product form A (BB)
...
</Product>
<!-- product B, e-book -->
<Product>
Product ID A (ISBN #2)
Product form B (DG)
...
</Product>
...
Second, there is an understandable wish to bring together (or to
'collocate') different products that contain the same content. You
want some way of identifying all the different products, and you do
this with a 'work ID'. Now the standards-based way of doing this is
the ISTC (see <http://www.istc-international.org>). Think of this
(very loosely) as an 'identifier for content'. If two different
products have the same content, they have the same ISTC (and this is
true even if the products come from different publishers). But the
ISTC is relatively new, and few publishers have implemented it yet.
For those that haven't, you can use a 'proprietary work ID'. This
would be some ID that is shared between the hardcover, the softcover
and all the e-book versions that contain the same content. It may be
an ID that comes from your internal IT systems, and be pretty
meaningless to everyone else. Ideally, the first and second editions
would not share the same work ID, but for a proprietary identifier
that's somewhat flexible.
In ONIX 2.1, you can include work IDs in PR.7.17. For a proprietary
work ID, you also need a name (such as 'ShambhalaWorkID') in PR.7.16.
Some publishers choose to use the ISBN of the first published product
(eg the hardcover) as the work ID. So the second product gets a new
ISBN as its product ID, but shares the first ISBN as its work ID.
Publishers sometimes call this the 'head ISBN' or the 'title ISBN' --
and it is, in effect, a proprietary work ID. And so in ONIX you get
something like this...
<Header>
...
</Header>
<!-- product A, hardcover -->
<Product>
Product ID A (ISBN #1)
Product form A (BB)
Work ID A (ISBN #1)
...
</Product>
<!-- product B, e-book -->
<Product>
Product ID B (ISBN #2)
Product form B (DG)
Work ID B (ISBN #1)
...
</Product>
...
Now in terms of best practice, if you look at Codelist 16 which is
used to specify different types of work ID you'll see that you can use
an ISBN as a work ID in this way (code 15). My advice would be --
don't. If you use an ISBN as a work ID, it is too easy for someone
else to misunderstand the context and start treating it as a product
ID. So if you're using an ISBN as a work ID, label it as a proprietary
work ID, and prefix it with a couple of letters or something so it
doesn't look quite so much like an ISBN any more...
<WorkIdentifier>
<WorkIDType>01</WorkIDType> <!-- proprietary -->
<IDTypeName>ShambhalaWorkID</IDTypeName>
<IDValue>SWID9781590307465</IDValue>
</WorkIdentifier>
You mentioned also the <RelatedProduct> composite. Within the Product
record for the hardcover, you might list the e-book ISBN as an
'alternative format', and in the Product record for the e-book, you
might list the hardcover ISBN with the relation 'E-publication based
on...'.
Third, there is the question of several different e-book products
sharing an ISBN. There is -- it has to be said -- some disagreement
within the book trade about how to handle some of the details of this,
but there is reasonable consensus about the particular case you cite.
If you as a publisher are creating multiple e-books with the same
content, and they are in quite different file formats (you list PDF,
HTML, OEB) then they are different products. They should have
different <Product> records and -- if they are given ISBNs as product
IDs -- they should each have different ISBNs (different from each
other as well as different from the hardcover).
The International ISBN Agency published an FAQ at the end of 2010 that
covers exactly this question -- see <http://www.isbn-international.org/
faqs/view/17>. And the Book Industry Study Group in the USA is in the
late stages of preparing a policy document on the application of ISBNs
to e-books. While I cannot speak for BISG, I believe they are likely
to endorse this approach too.
[NB it need not be the publisher that assigns all these ISBNs to
different e-book file formats. If a publisher creates a single 'master
file' and a third-party conversion service turns that master file into
the various different products that go on sale, then either the
publisher OR the conversion service can take responsibility for the
ISBNs and the rest of the metadata.]
So in ONIX 2.1, you get...
<Header>
...
</Header>
<!-- product A, hardcover -->
<Product>
Product ID A (ISBN #1)
Product form A (BB)
Work ID A (ISBN #1)
Related Product Ai (alternative format ISBN #2)
Related Product Aii (alternative format ISBN #3)
...
</Product>
<!-- product B, PDF e-book -->
<Product>
Product ID B (ISBN #2)
Product form B (DG)
E-publication type B (002)
Work ID B (ISBN #1)
Related Product Bi (e-publication based on ISBN #1)
Related Product Bii (alternative format ISBN #3)
...
</Product>
<!-- product C, HTML e-book -->
<Product>
Product ID C (ISBN #3)
Product form C (DG)
E-publication type C (001)
Work ID C (ISBN #1)
Related Product Ci (e-publication based on ISBN #1)
Related Product Cii (alternative format ISBN #2)
...
</Product>
...
[NB The publisher I believe you're associated with, Shambhala, appears
to be publishing mostly in EPUB format, so you'd actually use e-
publication type code 029 for those.]
Of course, this does make your ONIX a bit bigger -- you have more
products, and more product records. A large part of each product
record is the same, because ONIX has a pretty flat structure (it's
'denormalised'). But this doesn't mean that your internal IT systems
need to have the same flat structure. A good design of internal IT
system would be more hierarchical (more normalised), and would allow
you to manage much of the data for each product at 'work' level, so if
you need to change the spelling of an author's name, you only do it
once. The data is then flattened for transmission as an ONIX message
(and the hierarchy might then be rebuilt by the ONIX recipient, to
match their internal IT system).
[Bonus question -- why is ONIX flattened like this? Two reasons.
First, because not everyone has the same hierarchical structure, and
second because often, only the publisher needs to manage most of this
data. Highly normalised structures are good for data management, but
if all you want to do is use the data (without editing it or managing
it in any way) then a partly denormalised structure is simpler and
usually has better performance.]
Hope this clarifies things for you.
Regards
Graham
Graham Bell
EDItEUR
Tel: +44 20 7503 6418
The information contained in this e-mail is confidential and may be
privileged. It is intended for the addressee only. If you are not the
intended recipient, please inform the sender and delete this e-mail
immediately. The contents of this e-mail must not be disclosed or
copied without the sender's consent. We cannot accept any
responsibility for viruses, so please scan all attachments. The
statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the company.
EDItEUR Limited is a company limited by guarantee, registered in
England no 2994705. Registered Office: 2 Bloomsbury Street, London,
WC1B 3ST. Website: http://www.editeur.org
Os copio un interesante cruce de mensajes que se ha producido en el
grupo ONIX_IMPLEMENT respecto a la posibilidad de "agrupar" en un
único bloque <Product> distintas manifestaciones de una misma obra:
p.ej. la versión impresa y tres versiones digitales en distintos
formatos.
La respuesta de Graham Bell, responsable de la arquitectura ONIX, es
sencilla: NO se puede hacer.
Cada formato necesita un ISBN y un <Record> distinto.
Un saludo,
Jesús Peraita
------------------------------------------------------------------
On 18 Oct 2011, at 23:10, Jonathan Gordon wrote:
>
>
> What is the best practice for creating an ONIX record for a Product
> that has a print version (e.g., ProductForm of "BB") and several
> Epublications (i.e., ProductForm of "DG") with multiple EpubTypes
> (e.g, PDF, HTML, Open Ebook), all sharing the same EAN? Is this one
> Product record, ProductForm of "BB" with three RelatedProduct
> composites with EpubType (PR.23.27) using a RelationCode of 13:
> "Epublication based on (print product)"? Or two Product records, one
> having a ProductForm of "BB", the other with ProductForm of "DG" with
> one EpubType specified at (PR.4.1) with two RelatedProduct composites?
> Something else entirely?
>
> Thanks for your help,
>
> Jonathan
Re: [ONIX_IMPLEMENT] Multiple EpubType and ProductForm instances for a
single EAN
Hi Jonathan
There are three parts to this answer.
First, you have to view the hardcover and the e-book(s) as at least
two separate Products. After all, they are likely to carry separate
prices, they have different fulfillment processes, and they clearly
have different product forms (BB and DG in ONIX 2.1, BB and ED in ONIX
3.0). And that means they have two or more separate <Product> records.
In ONIX, you simply cannot have a single 'product' with multiple
different product forms -- different product forms by definition means
different Products.
And an ISBN always identifies a 'product' too. ISBNs should never be
assigned to 'a group of products'. Most people take this for granted
in the physical world -- when faced with hardcover and softcover books
with the same content, they are given different ISBNs. Even two
distinct softcovers, one rack -sized and one trade paperback, get two
different ISBNs. And so it should be with e-books -- if you have a
hardcover and an e-book, they should never share an ISBN.
[NB you mention EANs, and of course ISBNs are just a particular
small subset of EANs that are reserved for identifiying book and book-
like products. ISBNs are EANs that begin with 978... or 979... And
these days, EANs are more properly called GTIN-13s.]
So the ISBN is used to distinguish between different products which
have the same content. It also, of course, distinguishes between
similar products that have different content -- for example the
hardcover versions of the first and second editions of a particular
title should always have different ISBNs.
And in ONIX, you'll have something like this:
<Header>
...
</Header>
<!-- product A, hardcover -->
<Product>
Product ID A (ISBN #1)
Product form A (BB)
...
</Product>
<!-- product B, e-book -->
<Product>
Product ID A (ISBN #2)
Product form B (DG)
...
</Product>
...
Second, there is an understandable wish to bring together (or to
'collocate') different products that contain the same content. You
want some way of identifying all the different products, and you do
this with a 'work ID'. Now the standards-based way of doing this is
the ISTC (see <http://www.istc-international.org>). Think of this
(very loosely) as an 'identifier for content'. If two different
products have the same content, they have the same ISTC (and this is
true even if the products come from different publishers). But the
ISTC is relatively new, and few publishers have implemented it yet.
For those that haven't, you can use a 'proprietary work ID'. This
would be some ID that is shared between the hardcover, the softcover
and all the e-book versions that contain the same content. It may be
an ID that comes from your internal IT systems, and be pretty
meaningless to everyone else. Ideally, the first and second editions
would not share the same work ID, but for a proprietary identifier
that's somewhat flexible.
In ONIX 2.1, you can include work IDs in PR.7.17. For a proprietary
work ID, you also need a name (such as 'ShambhalaWorkID') in PR.7.16.
Some publishers choose to use the ISBN of the first published product
(eg the hardcover) as the work ID. So the second product gets a new
ISBN as its product ID, but shares the first ISBN as its work ID.
Publishers sometimes call this the 'head ISBN' or the 'title ISBN' --
and it is, in effect, a proprietary work ID. And so in ONIX you get
something like this...
<Header>
...
</Header>
<!-- product A, hardcover -->
<Product>
Product ID A (ISBN #1)
Product form A (BB)
Work ID A (ISBN #1)
...
</Product>
<!-- product B, e-book -->
<Product>
Product ID B (ISBN #2)
Product form B (DG)
Work ID B (ISBN #1)
...
</Product>
...
Now in terms of best practice, if you look at Codelist 16 which is
used to specify different types of work ID you'll see that you can use
an ISBN as a work ID in this way (code 15). My advice would be --
don't. If you use an ISBN as a work ID, it is too easy for someone
else to misunderstand the context and start treating it as a product
ID. So if you're using an ISBN as a work ID, label it as a proprietary
work ID, and prefix it with a couple of letters or something so it
doesn't look quite so much like an ISBN any more...
<WorkIdentifier>
<WorkIDType>01</WorkIDType> <!-- proprietary -->
<IDTypeName>ShambhalaWorkID</IDTypeName>
<IDValue>SWID9781590307465</IDValue>
</WorkIdentifier>
You mentioned also the <RelatedProduct> composite. Within the Product
record for the hardcover, you might list the e-book ISBN as an
'alternative format', and in the Product record for the e-book, you
might list the hardcover ISBN with the relation 'E-publication based
on...'.
Third, there is the question of several different e-book products
sharing an ISBN. There is -- it has to be said -- some disagreement
within the book trade about how to handle some of the details of this,
but there is reasonable consensus about the particular case you cite.
If you as a publisher are creating multiple e-books with the same
content, and they are in quite different file formats (you list PDF,
HTML, OEB) then they are different products. They should have
different <Product> records and -- if they are given ISBNs as product
IDs -- they should each have different ISBNs (different from each
other as well as different from the hardcover).
The International ISBN Agency published an FAQ at the end of 2010 that
covers exactly this question -- see <http://www.isbn-international.org/
faqs/view/17>. And the Book Industry Study Group in the USA is in the
late stages of preparing a policy document on the application of ISBNs
to e-books. While I cannot speak for BISG, I believe they are likely
to endorse this approach too.
[NB it need not be the publisher that assigns all these ISBNs to
different e-book file formats. If a publisher creates a single 'master
file' and a third-party conversion service turns that master file into
the various different products that go on sale, then either the
publisher OR the conversion service can take responsibility for the
ISBNs and the rest of the metadata.]
So in ONIX 2.1, you get...
<Header>
...
</Header>
<!-- product A, hardcover -->
<Product>
Product ID A (ISBN #1)
Product form A (BB)
Work ID A (ISBN #1)
Related Product Ai (alternative format ISBN #2)
Related Product Aii (alternative format ISBN #3)
...
</Product>
<!-- product B, PDF e-book -->
<Product>
Product ID B (ISBN #2)
Product form B (DG)
E-publication type B (002)
Work ID B (ISBN #1)
Related Product Bi (e-publication based on ISBN #1)
Related Product Bii (alternative format ISBN #3)
...
</Product>
<!-- product C, HTML e-book -->
<Product>
Product ID C (ISBN #3)
Product form C (DG)
E-publication type C (001)
Work ID C (ISBN #1)
Related Product Ci (e-publication based on ISBN #1)
Related Product Cii (alternative format ISBN #2)
...
</Product>
...
[NB The publisher I believe you're associated with, Shambhala, appears
to be publishing mostly in EPUB format, so you'd actually use e-
publication type code 029 for those.]
Of course, this does make your ONIX a bit bigger -- you have more
products, and more product records. A large part of each product
record is the same, because ONIX has a pretty flat structure (it's
'denormalised'). But this doesn't mean that your internal IT systems
need to have the same flat structure. A good design of internal IT
system would be more hierarchical (more normalised), and would allow
you to manage much of the data for each product at 'work' level, so if
you need to change the spelling of an author's name, you only do it
once. The data is then flattened for transmission as an ONIX message
(and the hierarchy might then be rebuilt by the ONIX recipient, to
match their internal IT system).
[Bonus question -- why is ONIX flattened like this? Two reasons.
First, because not everyone has the same hierarchical structure, and
second because often, only the publisher needs to manage most of this
data. Highly normalised structures are good for data management, but
if all you want to do is use the data (without editing it or managing
it in any way) then a partly denormalised structure is simpler and
usually has better performance.]
Hope this clarifies things for you.
Regards
Graham
Graham Bell
EDItEUR
Tel: +44 20 7503 6418
The information contained in this e-mail is confidential and may be
privileged. It is intended for the addressee only. If you are not the
intended recipient, please inform the sender and delete this e-mail
immediately. The contents of this e-mail must not be disclosed or
copied without the sender's consent. We cannot accept any
responsibility for viruses, so please scan all attachments. The
statements and opinions expressed in this message are those of the
author and do not necessarily reflect those of the company.
EDItEUR Limited is a company limited by guarantee, registered in
England no 2994705. Registered Office: 2 Bloomsbury Street, London,
WC1B 3ST. Website: http://www.editeur.org
Reply all
Reply to author
Forward
0 new messages