In the second of two blogs about ways to improve metadata, EDItEUR’s Graham Bell looks at the presentation of contents and reviews
In my recent blog
on the importance of metadata we looked at subject coding and keywords. These are, for the most part, kept ‘behind the scenes’ by retailers: used to guide shelving, merchandising, browsing and searching, but not directly displayed within an online store. But some descriptive text that publishers often provide is
usually displayed, ranging from short descriptions of 40 words or so to long descriptions or abstracts, the text of reviews or even extracts from a book itself.
Because this text is on display, publishers should think about its formatting and markup, using HTML tags within the text to specify how it should be displayed. This is an area that is often poorly executed when the data is supplied using ONIX, possibly because there is a choice of methods to use.
The best method by far is to use XHTML markup. The ONIX should include tags like <p> and </p> for paragraphs, and <ul> and <li> for bullet point lists. This markup should be familiar to many publishers, as these tags are the most basic building blocks of web pages. Stick to basic tags like these; ensure that all are lower case and properly closed and nested; and make sure your data management software adds textformat="05" to text fields that include markup.
If you are unable to use XHTML, you can surround your text and markup with ‘CDATA’ tags. This is only necessary if you can’t guarantee that the markup consistently follows the three points above—and you should still ensure textformat="02" appears in your ONIX. EDItEUR has more help about this here
Without markup you are limited to a single paragraph of plain text for each description or review. But with it, you can supply multiple paragraphs, and more structured text like a table of contents. Here’s what a table of contents might look like if you are delivering your data using ONIX with XHTML markup:
<Text textformat="05"><ul><li>Part 1<ol><li>Subject coding</li><li>Keywords</li></ol></li><li>Part 2<ol><li value="3">Tables of contents</li><li>Reviews</li></ol></li></ul></Text>
If you are using HTML and CDATA, it might look like this:
<Text textformat="02"><![CDATA<[ul><li>Part 1<ol><li>Subject coding<li>Keywords</ol><li>Part 2<ol><li value="3">Tables of contents<li>Reviews</ol></ul>>></Text>
Of course, it could be neatened up with a few new lines, but they should make no difference to the way the table of contents will be used.
You might also check the ‘data supply chain’ between you and the retailer. How does the data get handled, and is your markup preserved or filtered out at each link in the chain? Once you are sure that your product data manager application can supply ONIX data including text with the right markup, and that your data supply chain is robust, then does including a table of contents in the metadata really matter? Do retailers use tables of contents? Some do. Broadly, they are only useful for academic and non-fiction works, though fiction anthologies might also benefit. And whatever you do, your chapter titles won’t be visible on every website, though Amazon for example will show them. But it is likely that some sites that don’t display the chapter titles will still mine the table of contents for extra keywords. Anecdotal evidence suggests that supplying the table of contents is powerful, boosting search rankings within an online store and increasing sales by giving consumers the confidence to buy—and this is doubly true because so few publishers supply this metadata.
Now, tables of contents can be highly detailed. ONIX can include a block of data elements that can include not only chapter titles but different authors for each chapter, separate chapter abstracts and so on. But excepting some specialised types of academic books like conference proceedings, it is unlikely that going beyond a simple list of chapter titles in the ordinary marketing text is worthwhile for most publishers.
ONIX marketing metadata can also include extracts of reviews, which can help to guide and validate a reader’s choice of book. In this example (taken from the ONIX 3.0 guide
), there is no need for any HTML markup, because the quotation is just plain text:
<Text>‘a deeply felt and intelligently told tale, expressed in the taut style of an experienced journalist.’</Text>
For those not familiar with ONIX, it is the TextType = 08 that marks this out as a review, where a short description might be TextType 02 and a table of contents would be 04, and both would omit the <TextAuthor> and <SourceTitle> elements.
The most common issues seen with reviews are multiple reviews squished together and supplied as a single data element, instead of each being listed separately; and the source of a review either included within the text of the review instead of in the separate fields or omitted altogether: the separate data elements for <TextAuthor> and <SourceTitle> (<TextSourceTitle> in ONIX 2.1) should be used whenever possible.
Avoid duplicating review snippets in your long description field; that way, online retailers who wish to present reviews separately can do so. This principle applies more generally too. It can often seem like a smart idea to incorporate data from one field in another—adding the series title into the title field for example, or some marketing message in the subtitle—in an attempt to gain a more prominent display position for that chunk of data. But in general I’d advise against it, since it usually leads to a confusing display of the data in the online store.
Graham Bell is executive director of EDItEUR