It is clear that not all distributors and publishers are following this guidance at present; and they are encouraged to inform BIC of all codes currently in use as a matter of urgency.

Full details of the scheme and the current list of codes can be found at http://www.bic.org.uk/13/Discount-Group-Codes/.

ONIX 3.0

Notes for senders of ONIX 3.0 files to Nielsen Book, October 2009

Nielsen are working towards acceptance of ONIX 3 files from suppliers while continuing to accept series 2.* ONIX files for the foreseeable future. Our initial intention approach is to accommodate the variations and key additional elements in ONIX 3 into our existing database and products with minimal disruption. We will move to ONIX 3 outputs at a later stage in consultation with our data customers.

Work on ONIX 3 implementation is underway. We expect to be able to accept test files by the end of the year, and live files in Q1 2010.

Record Type “Block Updates”

In accordance with the statement of UK practice by the UK ONIX Group, Nielsen will accept EITHER Full Update Records as usual OR Block 6 (P&A updates) only, for initial implementation of ONIX 3; these may be mixed in the same file (the notification type is provided at record level) but we prefer separate files for each type.

Message Header

In accordance with the amended schema, Nielsen require ONIX3 files to include the mandatory ‘release’ attribute, with the value ‘3.0′ in the top-level element.

P5 Collection / P6 Product title detail

Nielsen will use Collection and Title data in existing fields on our database, and in products, to create well-formed title strings that avoid duplication of data.

P20 Global publishing status & dates / copyright

Nielsen will continue to recommend the statement of publishing status and publication date at item (global) level using P20, in addition to market-specific details as required. If a global publication date is not provided, we will use instead the market-specific date that matches the Country of Publication.

P21 Territorial rights and other sales restrictions

We are concerned about the introduced facility to state what rights DO NOT apply in a given territory with no requirement to state what rights DO apply. As we hold Rights information as a table, we need a clear indication of the situation (Non-Exclusive Rights, Exclusive Rights, or NFS) for each territory included.

We require senders, if using the “Countries Excluded” structure in a Sales right composite (eg Exclusive Rights for Word excluding US and Canada) to send an additional composite specifying the rights position for the excluding country/ies (eg NFS in US, non-exclusive rights in Canada, etc)

P22 Related works

Nielsen will expand our list of relation types to accommodate include links to Works identified by ISTC.

P24-26 Product Supply

We re-assert the position that met with general acceptance on a Listserv discussion in favour of mutually exclusive markets in Product Supply composites. Having overlapping markets (eg because one supplier serves two markets) is effectively organising the markets to fit the supplier. We can see this might be attractive for publishers, but for all recipients of the data, ie aggregators organising data for retailers in specific markets and retailers operating within specific territories, there is a strong requirement to receive all the supply data that is pertinent to a given market, including all suppliers to that market (rather than being presented with all markets that are served by each supplier).

]]> http://anko.ie/blog/?feed=rss2&p=90 http://anko.ie/blog/?p=82 http://anko.ie/blog/?p=82#comments Thu, 12 Nov 2009 15:25:35 +0000 admin http://anko.ie/blog/?p=82

We are pleased to announce that we will be speaking at Publishing Irelands’ upcoming ‘Online Marketing, Onix, and Rights’ seminar.

Topic: Making Bibliographic ONIX data and XML work for you in the digital age

Our presentation is designed to explain and demystify ONIX and XML and demonstrate that, with a little XML knowledge and the right tools you can use XML data to create eBooks’, AIs, catalogues, fuel websites, generate press releases and marketing campaigns, provide rich, contemporary bibliographic title information for supply chain partners, thereby saving time, money, resources and increasing sales opportunities.

Unfortunately, because the standard is potentially trying to cover all aspects of the supply chain it has to be fairly complex to cover all eventualities. In addition it is a technical standard that requires a technical IT solution which immediately creates a barrier to entry for most small publishers who do not have a team of dedicated IT support staff and developers standing by.

So do you have to do it? Can you just ignore it and continue on as you always have. Increasingly the answer to that is no. All the big distributors are now pushing for publishers to submit their title data in an ONIX form (for them it is a major cost saving not to have to send copies of AI sheets to India to be re-keyed!) and whilst they currently do not directly impose punitive financial penalties for not conforming there is a price to be paid. That price is exposure of your work to your target audience the customer. If you do not have rich bibliographic data available on the major book selling web sites putting your work forward in its best possible light then some other publisher will and their work will appear before yours in any online searches and they will get the sale.

Some little factoids might put this in perspective:

1. Bowkers customer data suggests that online ads are now better than print ads (9%) for driving sales. Online ads (16%) are the second biggest driver of book awareness in US second only to in-store displays (44%).
2. 67% of customers who bought a book because of a review, read the review online.
3. In 2005 Barnes & Noble found that a book is 60% more likely to sell if it has a cover image yet 63.7% of the titles in their database didn’t have one or indeed complete descriptions.

So implementing ONIX can potentially be a competitive advantage in the short/medium term but in the end it will be a necessity especially as books/content are delivered over digital media. No longer does a customer just buy a paper book. The same content can be presented and delivered in potentially hundreds of different formats either as a complete piece or in small chunks. If you are going to attempt to manage and track this explosion of varying formats your little word document and spreadsheet collection will quickly start to look a little pedestrian if not woefully inadequate.

Consider, ONIX 3.0 has just been released and will start to be widely adopted next year. It is no coincidence that it is the first version of the standard that is not backwardly compatible with previous versions and that one of its primary focuses is dealing with digital media. So the problem of managing complex data and tracking your products in their myriad new forms is just going to get worse!

And the answer… a good solid database. A database will force you categorise and sort your title information and the very act of breaking down the information will lend the database to producing ONIX messages. Indeed most title management systems these days offer ONIX support as standard.

Of course just purchasing a database is not the whole answer. The biggest, generally the most expensive, element of such an endeavour is your time. Every minute spent sorting your title information ready for loading into a database is time lost not producing/selling books and initially your instincts will be to postpone that task. However, if you do see it through not only will you massively improve the chances of selling more of your work you will gain efficiencies in your internal work flows (you’ll only ever have to key things once and there will only ever be one version of the truth) thereby saving money, you will also potentially be able to automate tasks such as catalogue production, AI production, automated reports and updating your web sites. All because you have a central database that can drive the data that drives your business.

It is just unfortunate that in these hard financial times that the old adage “you have to spend money to make money” is as true as ever.

With QuickTime installed, you can import the following file types into a graphic field:

FlashPix (.FPX); GIF (GIF); JPEG/JFIF (JPG); MacPaint (MAC); PDF
(PDF, Mac OS X only); Photoshop (PSD); PICS (PCS); PICT (PCT);
PNG (PNFG); QuickTime Image File (QT); SGI (SGI); Targa (TGA);
TIFF (TIF); Windows bitmap (BMP)

Note - on Windows, FileMaker imports Windows bitmap (BMP), MacPaint (MAC, .PNT), and TIFF (TIF) files without using QuickTime.

File Types – Not suitable for importation Tiff files that have been saved from Adobe Photoshop with the LZW compression option selected cannot be imported. In addition, JPEG files saved with CMYK format will not import.

To import these files re-save the image file without the LZW compression. Tiff or JPEG files saved with a CMYK format on the Windows platform (but these files types are supported on Macs). The solution is to re-save the  file in RGB format.

How to mark a task as complete in a schedule.

You may add as many publishers as you need to your APM - This is how …