Communicatie. Digitale. gebruikershandleiding

Transcriptie

1 gebruikershandleiding Digitale Communicatie Informatie over o.a. Aanleveren artikelgegevens via ONIX Versie Auteur: Margot Kersaan, CB Schema s: Niels Verkaart, Verkaart Automatisering Hetty Liewerink, CB Aanleveren artikelgegevens via ONIX versie 2.4 Pagina 1

2 INHOUDSOPGAVE 1. Inleiding Opbouw document Uitgangsdocumentatie Aanlevering ONIX 3.0 metadata en content via FTP Verwerking van het ONIX bericht en de content Covers en Eboek bestanden apart indienen Covers Eboek bestanden XSD validatie Wie mag wat indienen? Levenscyclus van een titel Doorgeven van akkoord voor vrijgave Vrijgeven fysiek boek Vrijgeven eboek Vrijgeven op een specifieke datum Omgaan met prijswijzigingen Inleiding Uitgangspunten Verwerking prijswijzigingen Opbouw van een ONIX bericht Message declaration Headerrecord Product record Productrecord fysieke boeken Record reference number, type and source Product identifier composite Block descriptive detail Product form Product form description Measure composite (afmetingen) ProductClassification: Fondsgroep ProductClassification: BTW Classificatie Collection Part Title Composite Authorship Edition Commercieel druknummer Herdruk of heruitgave Language Extents and other content Extent type code ExtentValue ExtentValue in Roman numerals ExtentUnit Illustrated /not illustrated flag Subject NUR BISAC Trefwoorden 48 Pagina 2

3 Leeftijdscategorie (AVI codes) Block 2: Collateral detail Wat is collateral detail? Ondersteunende teksten: flapteksten, promotionele teksten, annotaties, recensieteksten, auteursbiografie Linkjes naar recensies Covers, back covers, leesfragmenten, full content bestanden Block 4: Publishing Detail Uitgevergegevens en verschijningsdatum Imprint: commerciële en bibliografische imprint Commerciele eigenaar Plaats van uitgave Global publishing status/ copyright PublishingStatus Publishing date composite Territorial rights/ sales restrictions Territoriale verkoopuitsluiting Verkoopuitsluiting Block 5: Related Material Related Works Related Products BLOCK 6: ProductSupply Titels vrijgeven op een specifieke datum Supplier composite Product availability Statusovergangen in beschikbaarheid doorgeven SupplyDate Embargo Price composite Titels direct aanmelden voor PublishingOnDemand Aanvullingen voor ProductRecord eboeken Product form Kort verhaal indicatie ProductSupply Supplier composite Pre-sales Onderhouden beschikbaarheid e-book Eboek prijzen Ebook abonnementsmodellen en het communiceren van prijsafspraken Vital Source Bookshelf Aanmelding non-boeken (niet-bibliografische werken) via ONIX Product Identifier Composite (Paragraaf 11.2) Block descriptive detail (Paragraaf 11.3) ProductClassification: Fondsgroep (Paragraaf 11.4) ProductClassification: BTW Classificatie (Paragraaf 11.5) Collection Part (Paragraaf 11.6) Title Composite (Paragraaf 11.7) Authorship (Paragraaf 11.8) Edition (Paragraaf 11.9) Language (Paragraaf 11.10) Extents and other content (Paragraaf 11.11) Subject (Paragraaf 11.12) Collateral detail (Hoofdstuk 12) 86 Pagina 3

4 Imprint (Paragraaf 13.2) Eigenaar (Paragraaf 13.3) Global publishing status/ copyright (Paragraaf 13.4) Territorial rights/ sales restrictions (Paragraaf 13.5) ProductSupply (Hoofdstuk 15) Bijlage I ProductForms fysieke titels Bijlage II ProductForms digitaal Bijlage III Taalcodes Bijlage IV Metadatering Welke gegevens vallen onder redactionele controle? NUR wijzigen Bijlage IV Apple prijzen Bijlage V BTW Classificaties Bijlage VI Territories voor eboek distributieplatformen Bijlage VII Contentsoorten bij Supporting resources 111 Pagina 4

5 Pagina 5

6 Wijzigingen in versie 1.2 Epub versie toegevoegd p. 66 Wijzigingen in versie 1.3 RelatedWorks composite toegevoegd en ISTC p. 59 voorbeeld verbeterd Typefout verbeterd bij ProductAvailability Remainderd p. 55 Bij P.15.8 xml reference name verbeterd p. 48 P ResourceForm P.14 verbeterd naar P. 17 p. 49 Voorbeelden van P <DateFormat> die Diverse pagina s deprecated is vervangen door P16.14 Date Verklaring betekenis ContentdateRole p. 46 Collateral Detail: diverse waardes codelijsten voor Diverse pagina s aanlevering content in tabellen verwerkt VitalSource Bookshelf toegevoegd p. 74 Verschijningsvormenlijst aangevuld met: SA voor p. 76 samengesteld pakket, PP voor stickers, LA voor eboek licenties Wijzigingen in versie Verkeerde PriceType 01 bij huurprijzen verbeterd naar PriceType 02 Specificaties MagBoox als extern distributieplatform verwijderd Wijzigingen in versie p. 73 p. 94 Nook toegevoegd als extern distributieplatform p. 94 Foute waardes in tabel Supporting resources verbeterd p. 50 Wijzigingen in versie Hoofdstuk met algemene uitleg over stadium p. 31 levenscyclus en stadium dienstverlening laten vervallen Aantal posities bij BTW classificatie verwijderd uit tabel p. 35 Verplichtheid PrimaryNameType gecorrigeerd p. 41 Resource version feature note uit de voorbeelden p. 49 verwijderd omdat deze niet wordt ingelezen door CB Tekst PublishingStatus aangepast p. 55 Tekst ProductAvailability aangepast p. 63 Tekst O-boek korting aangepast p. 65 Website adres gecorrigeerd p. 69 MarketDateRole (presales) toegevoegd p. 71 Hoofdstuk onderhouden beschikbaarheid e-books p. 72 toegevoegd Tekst huurprijzen geactualiseerd p. 74 Tekst aanmelding Bookshelf geactualiseerd p. 76 Hoofdstuk over Bibliotheek.nl toegevoegd p. 77 Apple price tiers uitgebreid p. 92 Specificaties licentiebericht Bibliotheek.nl toegevoegd p. 100 als bijlage VIII Index toegevoegd p. 106 Pagina 6

7 Wijzigingen in versie 1.4 Diverse fouten m.b.t. verplichtbaarheid en herhaalbaarheid, tagnummers en ontbrekende sluittags in de specificatietabellen verbeterd Hoofdstuk 3 herschreven en uitleg over de p. 12 bewaartermijn van de MessageNumbers voor de uniciteitscontrole toegevoegd In hoofdstuk XSD validatie toegevoegd tot en met welke p. 17 issue CB de codelijsten heeft geimplementeerd Hoofdstuk over omgaan met prijswijzigingen p. 22 herschreven Oude hoofdstuk 8 laten vervallen (is herhaling t.o.v. hoofdstuk 3 Schema s Niels Verkaart met toegestane p. 19 statusovergangen ProductAvailability toegevoegd Validatieschema in de Message declaration voor short p. 26 tag berichten gewijzigd naar reference Tekst over secundaire auteursnamen verwijderd p. 35 <Illustrated> flag in specificaties aangepast volgens p. 41 XSD Mappingstabel voor de verwijzingen naar meegeleverde p. 48 content aangepast naar de waardes zoals die zijn gebouwd (deze wijken af van de specificaties van Editeur) <SalesRights> composite specificaties aangepast p. 54 volgens XSD Tag PriceStatus (vrijgave-akkoord) toegevoegd aan p. 64 specificaties Price composite Tag TaxAmount toegevoegd aan specificaties p. 64 resp. 75 Mogelijkheid om titels voor POD aan te melden p. 67 toegevoegd Tekst over Shorts toegevoegd p. 70 Price condition composite toegevoegd aan de p. 75 specificatietabel en uitleg over de toepassing ervan bij huur en koop ebooks herschreven Hoofdstuk 18 voor aanmelden niet-bibliografische p. 79 werken toegevoegd Bijlage IV vervangen door Werkbeschrijving ISBN p. 95 In overzichtsschema platformen PDF als mogelijkheid p. 108 toegevoegd bij Google Wijzigingen in versie 1.5 Verwijzing naar inkijktekst weggehaald uit hoofdstuk 2 p. 12 Hoofdstuk 3 over verwerkingsproces CB herschreven en p. 13 schema s van Hetty Liewerink toegevoegd Pagina 7

8 Schema Hety Liewerink over vrijgaveproces toegevoegd p. 26 CB beleid m.b.t. XSD validatie toegevoegd p. 18 Verwerking prijswijzigingen in tabel opgenomen p. 28 Verwijzingen naar inkijkteksten weggehaald uit de Links p. 51 to Supporting Resources composite Voorbeelden van PriceComposite vervangen door p. 61 nieuwe voorbeelden waar TaxRatePercent en TaxAmount in zijn opgenomen. PriceConditionTypeCode toegevoegd voor fysieke p. 65 boeken Specificaties EBLIMO bericht van uitgever naar CB verwijderd Wijzigingen in versie 2.0 Aanleveren van AVI codes toegevoegd p. 46 Opbouw <SalesRights> composite aangepast conform p. 59 XSD ONIX Epub versienummer aangepast conform XSD ONIX p Uitleg berekening deelprijzen bij gecombineerd BTW p. 68 toegevoegd Waardes ResourceContentType, ResourceForm en p. 53 ResourceMode in Links tosupporting resources aangepast conform codelijsten Amazon toegevoegd als extern distributieplatform p. 111 Wijzigingen in versie 2.1 Schema beschikbare statusovergangen van fysieke p. 23 boeken vervangen ivm wijziging ProductAvailability voor Uitverkocht Vrijgeven op specifieke datum toegevoegd aan p. 29 hoofdstuk 8 Aanleveren trefwoorden toegevoegd aan Subject p. 46/47 composite Voorbeelden aanleveren Links to supporting resources p. 54 aangepast Tekst NSTC geactualiseerd p. 62 Vrijgeven op specifieke datum (MarketDate) p. 64/65 toegevoegd in blok ProductSupply ProductAvailability 51 toegevoegd p. 67 Pagina 8

9 Wijzigingen in versie 2.2 Kort verhaal indicatie toegevoegd in <TradeCategory> p. 74 <Subtitle> toegevoegd in Title composite met TitleType p (commerciele ondertitel) Fotograaf toegevoegd als aparte contributor role p. 41 Plaats van uitgave toegevoegd p. 57 Aanleveren BISAC codes voor fysieke boeken p. 46 toegevoegd Originele titel toegevoegd p. 41 Bibliografische gegevens en redactionele controle p. 101 geredigeerd Foute omschrijving hoog BTW code verbeterd p.73 Verwijderen aanmelding externe ebook platforms p. 75 Wijzigingen in versie 2.3 Verwijderen functionaliteit m.b.t. ebook huurprijzen p. 81 en 82 Toevoegen Price coded composite aan specificaties p. 80 Toevoegen communiceren prijskenmerk dmv p. 81 en 82 PriceCoded composite Toevoegen Currency Code tag aan prijskenmerk p. 82 Specificaties aanlevering ebooks voor Samsung en p. 110 Nook verwijderd Wijzigingen in versie 2.4 Toegevoegd dat tekenset in MessageDeclaration p. 29 leidend is voor CB verwerking Auteursbiografie toegevoegd aan Contenttypes p. 51 Verkeerde <MarketDateRole> bij vrijgeven op p. 66 specifieke datum hersteld Onderhouden beschikbaarstelling ebooks per p. 75 webwinkel via CB Online toegevoegd Voorbeeld Block ProductSupply Bookshelf Only p. 83 toegevoegd ProductForms Luisterboeken fysiek en digitaal gewijzigd p. 89 en p. 91 naar AA resp. AJ met <PrimaryContentType> Bijlage IV geredigeerd p. 103 contact voor nadere toelichting, vragen en informatie kunt u contact opnemen met: CB BV Erasmusweg AK Culemborg Afdeling Content mangement content@cb.nl Pagina 9

10 copyright copyright 2015, CB BV Niets uit dit rapport mag worden openbaar gemaakt en/of verveelvoudigd door middel van druk, fotokopie, microfilm of welke andere wijze dan ook zonder voorafgaande toestemming van CB BV. Pagina 10

11 Pagina 11

12 1. Inleiding 1.1. Opbouw document Dit document beschrijft de aanlevering van artikelgegevens van de uitgever naar Bureau ISBN en CB. Deze gegevensaanlevering is gebaseerd op de internationale ONIX 3.0 standaard, die wordt beheerd door EDItEUR. In deze ONIX 3.0 handleiding voor het aanleveren van artikelgegevens aan CB worden de verschillende aspecten van de gegevensuitwisseling tussen uitgevers en het CB beschreven met betrekking tot: Interpretatie van het ONIX bericht. Welke gegevens zijn nodig om welke artikelgegevens op te nemen in het artikelbestand van Bureau ISBN, CB en/of Digitale distributie Omgaan met mutaties Welke soorten mutaties kan een uitgever doorsturen op zijn titels en wanneer moet dat gebeuren Verwerking en foutafhandeling Op welke manier worden de ONIX berichten verwerkt en gecontroleerd en hoe vindt hierover terugkoppeling plaats. Zowel over de technische als de inhoudelijke verwerking Afspraken over aanlevering Op welke wijze en via welk communicatiemedium worden de berichten aangeleverd. Welke activiteiten rondom het onderhouden van artikelgegevens kunnen niet worden aangeleverd via ONIX 1.2. Uitgangsdocumentatie De volledige documentatie betreffende de ONIX 3.0 standaard is te vinden en te downloaden op Voor ontwikkeling van de berichtuitwisseling gaan we uit van de onderstaande versie van de ONIX standaard: ONIX for Books, Product Information, Format Specification Release 3.0, Revision 2, January 2014 ONIX Code Lists, Issue 33, gepubliceerd Interpretatie van het ONIX 3.0 bericht. In de ONIX 3.0 bericht standaard is een zeer groot aantal gegevens opgenomen. In Nederland en Vlaanderen is een ONIX gebruikersgroep actief die gezamenlijke afspraken hebben gemaakt over de set van gegevens uit de volledige ONIX 3.0 standaard die in de onderlinge uitwisseling van gegevens gebruikt kunnen worden. Deze set gegevens is vastgelegd in het document: Aanleveren Artikelgegevens in ONIX 3.0.2; Handleiding ONIX-Werkgroep. Dit is een levend document; de ONIX Werkgroep komt 2 x per jaar bij elkaar en bespreekt de nieuwe marktontwikkelingen die eventueel kunnen leiden tot afspraken om nieuwe velden of nieuwe waardes uit de bestaande ONIX 3.0 standaard in gebruik te nemen of tot verzoeken aan Editeur.org om nieuwe velden of nieuwe waardes toe te voegen. De documentatie van de ONIX Werkgroep vormt de basis voor de ONIX 3.0 verwerking van het CB en is te vinden op de website van de ONIX Werkgroep, Pagina 12

13 Titelregistratie De werkwijze en regels voor titelregistratie bij Bureau ISBN zijn terug te vinden op Onder het tabblad Informatie onder het kopje Handleiding ISBN bevindt zich een link waardoor u de handleiding kunt downloaden. Pagina 13

14 2. Aanlevering ONIX 3.0 metadata en content via FTP De uitgever heeft bij CB de beschikking over een FTP account met een in-box en een uit-box. Via een gebruikersnaam en wachtwoord, krijgt de uitgever toegang. Een ONIX 3.0 bericht met metadata en eventueel daar bij behorende content wordt aangeleverd als een zip file. In dit ZIP file zitten de metadata in de vorm van het ONIX bericht en de bijbehorende bestanden (content) waarnaar wordt verwezen in het ONIX bericht. Voorgeschreven bestandsnaam: 1. Voor het ZIP file: _onx.zip 2. Voor het ONIX bericht dat in het zip file zit: _onx.xml 3. Voor de content bestanden die in het zip file zitten: Eboek bestand: <ISBN>_ebfc.pdf <ISBN>_ebfc.epub <ISBN>_ebfc.xps <ISBN>_ebfc.mp3 Inkijktekst: <ISBN>_hfd.pdf <ISBN>_hfd.epub <ISBN>_hfd.mp3 Cover en backcover: <ISBN>_cvr.jpg <ISBN>_bcvr.jpg Voor het ophalen en verwerken van de cover en de back cover moet er een verwijzing in het ONIX 3.0 bericht aanwezig zijn naar het meegeleverde bestand. Pagina 14

15 3. Verwerking van het ONIX bericht en de content De content en het ONIX bericht met de metadata worden opgehaald van de FTP server en gescheiden verwerkt, maar in dezelfde queue geplaatst qua prioriteit. Als eerste stap worden de bestanden door het Berichten Verwerkings Systeem (BVS) van CB gecontroleerd. De output hiervan is een.err of een. ok bestandje dat wordt teruggeplaatst op de FTP server in de outbox van de uitgever. <?xml version="1.0" encoding="iso "?> <ONTBEV xmlns=" <bericht> <cb_bericht_nr> </cb_bericht_nr> <afzender_bericht_id>31674</afzender_bericht_id> <type>onix30</type> <file>cb _onx.xml</file> <ftp_dir> \in</ftp_dir> <relatie_id> </relatie_id> <ontvangen> </ontvangen> </bericht> <melding> <line> Bericht 31674(cb _onx.xml) is correct verwerkt in de CB-systemen, zonder meldingen. </melding> </ONTBEV> </line> Door middel van dit.ok berichtje is het verband te leggen tussen de berichtidentificatie die het systeem van de uitgever heeft toegekend aan het bericht en de berichtidentificatie die het systeem van CB heeft toegekend aan het bericht. Na de verwerking van het bericht door BVS worden de afzonderlijke ProductRecords individueel verwerkt. Iedere 10 minuten wordt door het verwerkingssysteem de status van verwerking van het ProductRecord gecheckt en waar nodig bijgewerkt. De status wordt via een XML bestandje dat wordt teruggeplaatst op de FTP server van de klant gerapporteerd. In dit.xml bestandje wordt de koppeling met het originele ONIX 3.0 bericht gelegd door de interne berichtidentificatie van CB. <?xml version="1.0" encoding="utf-8"?> - <O30AMLDNG xmlns=" - <Header> <HeaderID>1</HeaderID> <MessageType>O30AMLDNG</MessageType> <SenderID> </SenderID> <SupplierID> </SupplierID> <SentDate> </SentDate> </Header> - <Detail> <ProductIdentifier> </ProductIdentifier> <MessageSequenceNumber> </MessageSequenceNumber> <TimeStamp> </TimeStamp> <Melding> Bij de brutoprijs ontbreekt CondtionType "00". </Melding> <Melding>Assortimentsmutatie is ingediend</melding> <Melding>Content is succesvol verwerkt</melding> <Melding> Mutatie bibliografische gegevens is succesvol verwerkt</melding> </Detail> </O30AMLDNG> Pagina 15

16 Hieronder zijn de diverse processtappen en de controlemomenten schematisch weergegeven. (auteur van de schema s is: Hetty Liewerink, CB) Pagina 16

17 Pagina 17

18 4. Covers en Eboek bestanden apart indienen 4.1. Covers Het is ook mogelijk om covers als losse bestanden in te sturen. Het ISBN moet reeds aanwezig zijn in de CB systemen en commercieel zijn aangemeld voor het CB assortiment omdat het ISBN tijdens de verwerking van de cover en back cover moet kunnen worden herkend Bij het los insturen van de bestanden is een afwijkende bestandsnaam voorgeschreven dan geldt in combinatie met een ONIX 3.0 bericht in een zip file.. Voor cover en backcover geldt: <ISBN>_covr.jpg <ISBN>-bcovr.jpg. Na verwerking van de cover wordt een.xml bestandje met het resultaatvan de verwerking teruggeplaatst op de FTP server. Voorbeeld: <?xml version="1.0" encoding="iso "?> <ONTBEV xmlns=" <bericht> <cb_bericht_nr> </cb_bericht_nr> <afzender_bericht_id></afzender_bericht_id> <type>onix_cover</type> <file> _covr.jpg</file> <ftp_dir> \in</ftp_dir> <relatie_id> </relatie_id> <ontvangen> </ontvangen> </bericht> <melding> <line> Bericht ( _covr.jpg) is correct verwerkt in de CB-systemen, zonder meldingen. </melding> </ONTBEV> </line> Alle covers worden opgeslagen in drie formaten : 1400 x 1400 pixels, 800 x 800 pixels en thumbnail (150 x 150 pixels) Eboek bestanden De eboek bestanden kunnen ook los worden aangeleverd. Een voowaarde is dan wel dat het ISBN op dat moment bekend is in het eboek assortiment en dat de commerciële aanmelding succesvol is verwerkt. De voorgeschreven bestandsnamen zijn: Pagina 18

19 Voor een EPUB: <ISBN>_eboek.epub Voor een PDF: <ISBN>_eboek.pdf Voor een downloadable luisterboek: <ISBN>_eboek.mp3 Pagina 19

20 5. XSD validatie ONIX berichten moeten qua structuur voldoen aan de algemene standaard voor XML berichten, dat wil zeggen de berichten moeten valide XML bevatten. Bijvoorbeeld, de ampersand en het kleiner-dan teken hebbeneen specifieke betekenis binnen XML. Wanneer deze in een tekst worden gebruikt, zoals bijvoorbeeld in de titel van een boek of bij een boekbeschrijving, leidt dit tot niet valide XML. Een ONIX bericht is opgebouwd uit voorgeschreven dataelementen in een voorgeschreven volgorde. Veel van deze dataelementen worden gevuld met waardes uit voorgeschreven codelijsten. Codelijsten kunnen worden gezien als eenduidige vocabulaires waardoor wordt bewaakt dat er bij het doorgeven van artikelgegevens in het gehele kanaal geen interpretatieverschillen en misverstanden ontstaan. Om te garanderen dat een ONIX berichten aan de voorgeschreven opbouw van de dataelementen en inhoud voldoet zijn er schema s ontwikkeld waarmee de validiteit van het ONIX bericht gecontroleerd kan worden. Deze schema s zijn gratis te downloaden vanaf de website van Editeur, Door deze schema s te plaatsen in een directory waar ook het te valideren bericht wordt neergezet kan met behulp van een XML editor de validatie worden uitgevoerd. Vanaf ONIX 3.0 zijn er 3 verschillende schema s in omloop waarmee het bericht gevalideerd kan worden, RNG, DTD en XSD schema. RNG en XSD valideren op basis van de combinatie van structuur van het bericht en codelijsten en hebben daarom de voorkeur. CB valideert de binnenkomende ONIX 3.0 berichten op basis van het XSD schema. CB heeft momenteel de codelijsten geïmplementeerd tot en met issue 33. Dat wil niet zeggen dat wij ook alle codes uit issue 33 actief gebruiken. De partij die het ONIX 3.0 artikelbericht genereert voor het melden van artikelgegevens bij het CB wordt verzocht om zelf ook een validatie uit te voeren. Er zijn 2 systematieken om de naam van de diverse elementen in een ONIX 3.0 bericht aan te geven die equivalent aan elkaar zijn maar niet door elkaar zijn te gebruiken. Voor elk van deze 2 systematieken bestaat een specifiek validatieschema. Iedere partij die gegevens aanlevert in ONIX formaat moet een van deze twee systematieken kiezen en doorvoeren in het volledige bericht. De voorkeur van CB gaat uit naar reference names bij deze systematieken wordt in tekst aangegeven wat de inhoud van de tag is. Het is echter ook mogelijk om gebruik te maken van short tags, hierin wordt dmv een voorgeschreven codering aangegeven wat de inhoud van de tag is. Bij Editeur is desgewenst een script verkrijgbaar om long tag berichten te converteren naar short tag berichten vice versa. Voor informatie over het DTD schema zie: XML Standard: W3C Recommendation Extensible Markup Language (XML) 1.0 (Fourth Edition) see Voor informative over de XML Schema Definition (XSD) format zie W3C Recommendation XML Schema Part 1: Structures (Second Edition) see / Het RELAX NG (RNG) format is gedefinieerd in een ISO standard: ISO/IEC :2008, published by ISO,Geneva 4 x per jaar publiceert Editeur een nieuwe issue van de codelijsten en ook een nieuwe issue van de XSD validatie waarin de nieuws codelijsten zijn verwerkt. CB gaat hier als volgt mee om: Pagina 20

21 Bij nieuwe codelijst Binnen 2 weken kijkt CB naar de impact Vervolgens gaan we binnen 3 tot 6 maanden over Aankondiging 2 maanden van te voren Wij ondersteunen altijd 2 XSD versies voor inkomend bericht Voor het uitgaande bericht kiezen we de meest recente Pagina 21

22 6. Wie mag wat indienen? In het ONIX bericht wordt op twee plaatsen informatie meegeleverd die in de verwerking wordt gebruikt om te cotroleren dat de indiener van het bericht mag optreden namens de eigenaar van het ISBN. In het Message Header record zit de relatie die het bericht indient. In het productrecord zit de relatie die de eigenaar van het artikel is of wordt. We kennen twee relaties tussen een uitgever en een artikel. Aan een artikel is altijd een prefixhouder gekoppeld. Als een artikel tot het CB assortiment behoort, is er tevens een artikel eigenaar. Deze twee hoeven niet hetzelfde te zijn. De prefixhouder is eigenaar van een prefixrange waarbinnen ISBN s worden uitgegeven. Deze prefixhouder wordt geregistreerd door bureau ISBN. De artikeleigenaar heeft het artikel in eigendom en is degene voor wie CB dienstverlening verricht. In principe is het zo dat alleen de prefixhouder een ISBN registratie mag aanmelden bij bureau ISBN. De prefixhouder moet bij CB aangeven wie eigenaar wordt van het artikel. In de praktijk blijkt dat met name binnen concerns artikelen worden aangemeld door uitgevers die niet zelf de prefixhouder van het ISBN zijn. Voorbeeld: Uitgeverij A en B vallen beide binnen concern Z. Een artikel valt binnen de prefixrange van uitgeverij A, maar wordt door uitgeverij B als artikel in het assortiment opgenomen en verkocht aan de boekhandel. Om het artikel automatisch te kunnen verwerken moet vastgelegd worden wat de relatie is tussen uitgever A en uitgever B. Bij de verwerking door bureau ISBN en CB is voor de volgende oplossing gekozen: Uit het ISBN is de prefix af te leiden en daarmee de prefixhouder. Een ISBN registratie mag alleen door de prefixhouder worden uitgevoerd, of als de indiener van het bericht met de prefixhouder van het artikel een commissionairrelatie heeft. Een uitgever mag een titel bij CB aanmelden indien hij prefixhouder is, of als hij met de prefixhouder van het artikel een commissionairrelatie heeft. Een uitgever mag artikelgegevens wijzigen indien hij eigenaar is van het artikel, of met de eigenaar van het artikel een commissionairrelatie heeft. Bij het indienen van het bericht wordt per artikelrecord gecontroleerd of de registratie en/of aanmelding of de wijziging door de betreffende indiener mag worden uitgevoerd. Indien dit niet het geval is, wordt het productrecord niet verwerkt. De controles zijn: Mag de indiener van het bericht ISBN s aanmelden voor deze prefixhouder? Mag de indiener van het bericht titels aanmelden voor deze eigenaar voor het assortiment van CB? Mag de eigenaar die bij het product record is aangegeven titels aanmelden voor het assortiment van het CB van de prefixhouder van het ISBN Pagina 22

23 7. Levenscyclus van een titel Een titel begint zijn levenscyclus in het CB assortiment altijd met de status Aangekondigd, ongeacht wat de uitgever voor beschikbaarheidsstatus meegeeft in het ONIX bericht. CB signaleert dat een titel klaar is om uitgeleverd te worden. Bij een fysiek boek is dit het moment waarop de voorraad is binnengekomen, is ingeslagen in de magazijnen, de uitgever vrijgave accoord heeft gegeven voor uitlevering, en de overeengekomen datum voor eerste uitlevering is aangebroken. Bij ebooks is dit het moment waarop de ebook bestanden zijn ingediend, zijn goedgekeurd door de epub checker, en de uitgever vrijgave accoord heeft gegeven voor uitlevering. Bij POD titels is dit het moment waarop de POD bronbestanden zijn ingediend, zijn goedgekeurd, zijn doorgestuurd naar en opgeslagen in het digitaal archief van Joint Book Services., en de uitgever vrijgaveaccoord heeft gegeven voor uitlevering CB initieert daarmee automatisch de statusovergang van Aangekondigd naar Verschenen. Vanaf dat moment kan de uitgever zelf de beschikbaarheidsstatus van zijn titels onderhouden via ONIX. Niet alle statusovergangen zijn logisch en mogelijk. De mogelijke statusovergangen voor fysieke boeken, POD titels en ebooks zijn door Niels Verkaart van Verkaart automatisering schematisch hieronder weergegeven. In oranje is aangegeven welke statusovergang CB initieert, in groen welke statusovergangen de uitgever kan initiëren. Het doorgeven van een statusovergang via ONIX 3.0 gebeurt via de ProductAvailability (voor de specificaties zie par ). In de schema s is aangegeven welke ProductAvailability bij welke status hoort. Pagina 23

24 Pagina 24

25 Via de ProductAvailability kan een uitgever een fysiek boek omzetten naar een POD boek vice versa. Pagina 25

26 Pagina 26

27 8. Doorgeven van akkoord voor vrijgave Voor het vrijgeven ( = beschikbaar stellen voor uitlevering) van zowel fysieke boeken als eboeken is toestemming nodig van de uitgever. Deze toestemming heet vrijgave-akkoord Het vrijgave-akkoord kan direct worden meegegeven bij de commerciële aanmelding of kan ook achteraf door de uitgever worden gegeven op het moment dat CB heeft geconstateerd dat er voorraad voor de titel is ingeslagen; dit is natuurlijk alleen van toepassing bij een fysiek boek. Ook voor een eboek is een vrijgave akkoord nodig. Het doorgeven van een vrijgave-akkoord kan plaatsvinden d.m.v. een mutatierecord in het ONIX bericht. De werkwijze daarvoor is als volgt: Zolang er nog geen vrijgave-akkoord is geeft u de titelaanmelding voor het CB assortiment en evt. assortimentmutaties op deze titel door met een PriceStatus 01 in de SupplyDetailComposite. Zodra er een vrijgave-akkoord is geeft u een assortimentsmutatie op deze titel door met een PriceStatus 02 in de Supplydetail Vrijgeven fysiek boek Nadat de voorraad is aangeleverd bij het CB door de binder wordt de voorraad ingeslagen in het magazijn. Als de uitgever nog geen vrijgave-akkoord heeft gegeven, ontvangt hij via CB Online Uitgever een melding dat de voorraad is ingeslagen en een verzoek om het vrijgave-akkoord te verlenen en de juistheid van de prijs te controleren. Bij aanwezigheid van een vrijgave-akkoord gaat het Bedrijfsbureau van het CB de logistieke uitlevering inplannen en dat is onder meer afhankelijk van het aantal in nota s en of het een titel betreft met vooraanlevering. Het Bedrijfsbureau Logistiek zet dan ook de titel op de status Verschenen met een ingangsdatum. Hieronder is het proces van het vrijgeven van een fysiek boek schematisch weergegeven (schema: Hetty Liewerink, CB) Pagina 27

28 8.2. Vrijgeven eboek Ook voor een eboek is een vrijgave-akkoord nodig. De uitgever is niet verplicht om het doorgeven van akkoord voor vrijgave via ONIX te doen; hij kan hiervoor ook CB Online Uitgever gebruiken. De eboek bestanden die zijn gecontroleerd en goedgekeurd worden 1 x per dag op de server van de hosting partner geplaatst. Daarna werken CS medewerkers handmatig de artikelstatussen bij. Als er vrijgave-akkoord is gegeven, komen de titels daarna via een automatische job op de status Verschenen. 8.3 Vrijgeven op een specifieke datum Het is mogelijk om ook via ONIX 3.0 aan te geven dat een fysiek boek of ebook pas mag worden uitgeleverd vanaf een door de uitgever bepaalde, specifieke datum. Dit gebeurt door het aangeven van een MarketDate. De specificaties hiervoor staan beschreven in hoofdstuk 15 (ProductSupply). Pagina 28

29 9. Omgaan met prijswijzigingen 9.1. Inleiding Bij de verwerking van de prijzen die worden doorgegeven in een ONIX 3.0 bericht mag de uitgever zijn volledige prijshistorie doorgeven. CB vist de actuele prijs hier uit en de eerstvolgende toekomstige prijs Uitgangspunten Gedurende de hele periode dat een titel actief is in het CB assortiment moet er een geldige standaardprijs zijn. Dat betekent dat een actieprijs voor een beperkte periode alleen kan worden ingediend als er in diezelfde periode ook een standaardprijs aanwezig is in de assortimentsdatabase of wordt aangemeld in het ONIX bericht. De huidige en de eerstvolgende toekomstige prijs worden uit het ONIX bericht gehaald. De huidige prijs wordt beëindigd met de datum van de toekomstige prijs -/- 1 dag. De toekomstige prijs gaat in op de meegegeven datum 9.3. Verwerking prijswijzigingen Fysieke boeken: Ingangsdatum prijsmutatie Verleden Heden Toekomst Afhandeling Controle dat bedrag in ONIX bericht identiek is aan bedrag in CB artikeldatabase. Indien ja: negeren Indien nee: => parkeren en handmatig afwijzen door CS medewerker Controle dat bedrag in ONIX bericht identiek is aan bedrag in CB artikeldatabase. Indien ja: negeren Indien nee: => parkeren en handmatig afwijzen door CS medewerker Huidige prijs in CB database wordt beëindigd per ingangsdatum toekomstige prijs 1 dag, en nieuw prijsrecord wordt aangemaakt met ingangsdatum toekomstige prijs Ebooks: Ingangsdatum prijsmutatie Verleden Heden Toekomst Afhandeling Controle dat bedrag in ONIX bericht identiek is aan bedrag in CB artikeldatabase. Indien ja: negeren. Indien nee: huidige prijs wordt beëindigd per vandaag en nieuw prijs gaat in per morgen Controle dat bedrag in ONIX bericht identiek is aan bedrag in CB artikeldatabase. Indien ja: negeren. Indien nee: huidige prijs wordt beëindigd per vandaag en nieuw prijs gaat in per morgen Huidige prijs in CB database wordt beëindigd per ingangsdatum toekomstige prijs 1 dag, en nieuw prijsrecord wordt aangemaakt met ingangsdatum toekomstige prijs Pagina 29

30 10. Opbouw van een ONIX bericht Een ONIX bericht is opgebouwd uit 4 componenten: Message declaration (waarin wordt aangegeven dat het bericht start). Header record één of meer Product records Berichteinde </ONIXMessage> voor reference en </ONIXmessage> voor short Message declaration De inhoud en de structuur van de Message declaration is voorgeschreven door de XML standaard. De tekenset die is aangegeven in de MessageDeclaration is leidend voor de verwerking van het ONIX bericht in de CB-systemen. Indien er geen tekenset is aangegeven wordt er van uitgegaan dat de tekenset UTF-8 is. Voor reference: <?xml version="1.0" encoding="utf-8"?> <ONIXMessage release="3.0"> Voor short tags: <?xml version="1.0" encoding="utf-8"?> <ONIXmessage release="3.0"> Let wel, bij short tags ONIXmessage met een kleine M Hieraan kan evt. worden toegevoegd op basis van welk schema het bericht gevalideerd is; de message declaration komt er dan als volgt uit te zien: Voor reference: <?xml version="1.0" encoding="utf-8"?> <ONIXMessage release="3.0" xmlns=" Voor short tags: <?xml version="1.0" encoding="utf-8"?> <ONIXmessage release="3.0" xmlns=" Let wel, bij short tags ONIXmessage met een kleine M CB zet een short tag bericht in de eerste stap van de verwerking direct om naar een long tag bericht. Alle ONIX 3.0 berichten worden vervolgens gevalideerd met het schema voor de reference names Headerrecord Na de Message declaration volgt het headerrecord. In de header is aangegeven van wie het bericht afkomstig is. Tevens bevat de Message Header een uniek berichtnummer (een volgnummer) en een timestamp. Hiermee kan de ontvanger van het bericht monitoren dat de diverse mutatieberichten in de juiste volgorde worden ingelezen in zijn eigen systeem. Hieronder een voorbeeld van een Message declaration in combinatie met een Message header van een ONIX 3.0 bericht dat aan CB is gericht. <?xml version="1.0" encoding="utf-8"?> Pagina 30

31 <ONIXMessage release="3.0" xmlns=" <Header> <Sender> <SenderIdentifier> <SenderIDType>10</SenderIDType> <IDValue> </IDValue> </SenderIdentifier> <SenderName>De Boekerij</SenderName> <ContactName>Pier Post</ContactName> </Sender> <Addressee> <AddresseeIdentifier> <AddresseeIDType>10</AddresseeIDType> <IDValue> </IDValue> </AddresseeIdentifier> <AddresseeName>CB B.V.</AddresseeName> </Addressee> <MessageNumber>30481</MessageNumber> <SentDateTime> T1237</SentDateTime> </Header>Toelichting: Sender identifier composite In de Sender Identifier Composite wordt de afzender van het bericht geïdentificeerd door middel van het Relatie_ID bij CB. Dit is een uniek identificatienummer gebruikt door het CB om zowel leveranciers als boekhandels te identificeren. De velden worden als volgt gevuld: H1 <SenderIDType> : waarde 10 uit Code-list 44 duidt aan dat het een CB Relatie_ID betreft. H3 <IDValue> : hier wordt het Relatie_ID geplaatst van de indiener, in het voorbeeld Sender name Dit vrije tekstvelden geeft informatie van de afzender. H4 <SenderName> H5<ContactName> H6 < Adress> : Bedrijfsnaam van de afzender (lengte :22), in het voorbeeld: Uitgeverij De Bezige Bij B.V. : Contactinformatie voor inhoudelijke vragen, in het voorbeeld: Marcel : Contactinformatie voor inhoudelijke vragen, in het voorbeeld: Ed@ed.de Message number Op het MessageNumber wordt door CB een uniciteitscheck uitgevoerd bij de verwerking van het bericht. De MessageNumbers blijven een maand bewaard. Als dezelfde indiener binnen die maand een nieuw ONIX 3.0 bericht indient met hetzelfde MessageNumber, dan wordt dat tweede bericht niet verwerkt, indien het eerste bericht wel succesvol is verwerkt. Deze controle is ingebouwd om dubbele verwerking en fouten in de volgordelijkheid te van de verwerking van gegevens te voorkomen. SentDateTime Dit is de datum en de tijd waarop het bericht verstuurd werd, samengesteld uit jaar, maand, dag, uur en minuten (a.h.v 24 uurs klok, voorafgegaan door een T). YYYYMMDDTHHMM (in het voorbeeld: T1511) Product record Na de Message header volgen 1 of meerdere Product records. Een Product record bestaat uit 1 of meerdere blokken. Pagina 31

32 Structuur van een block Ieder Block is opgedeeld in 1 of meer composites. Een composite is een groepering van verwante velden (data elements). Een composite kan ook andere, onderliggende composites bevatten. Pagina 32

33 Voor elk besproken veld (data element) van het bestand worden in een tabel volgende punten aangegeven: DATA ELEMENT FIELD XML REFERENCE NAME M/O Onix A/S CB LIST A N POS. Waarbij: Data Element Field XML Reference Name Short tag M/O Onix M/O CB List A N POS Naam van het veld (data element) Referentiecode gebruikt in Onix 3.0 -documentatie Naam van het veld zoals gebruikt binnen het bericht Naam van de short tag zoals gebruikt binnen het bericht Verplicht of optioneel (Mandatory / Optional) volgens Onix Geeft aan of in de aanmelding van titelgegevens aan het CB dit veld altijd (mandatory) of soms (optional) aangeleverd moet worden In sommige velden wordt door middel van een waarde uit een Editeur codelist aangegeven wat er in de betreffende composite wordt doorgegeven, bijvoorbeeld of het om een cover of een back cover gaat. In de kolom List wordt aangegeven welke codelist van toepassing is. Alfanumeriek of Numeriek Aantal posities Indien een composite herhaald kan worden, staat achter het data element een (R) (=repeatable). Verplicht geldt op twee niveaus; een composite kan zelf optioneel zijn, maar indien toegevoegd in het bericht, moeten specifieke velden binnen die composite wel ingevuld worden. Daarom staat bij deze composite een O, maar voor velden binnen de composite een M. Hetzelfde geldt voor de M en O waarden van het CB. Voor de individuele velden wordt verklaard welke gegevens deze moeten bevatten en het formaat van het veld (numeriek, alfanumeriek en aantal posities). In Onix zelf worden slechts zeer beperkt veldtypes en lengtes gedefinieerd; binnen CB gelden hierop echter wel bepaalde beperkingen. Wanneer het CB afwijkt van een richtlijn of een aanzienlijk kortere lengte kan verwerken wordt dat opgemerkt bij het veld. Het volledige Product record bevat: <Product> Record metadata Group P.1 Product numbers Group P.2 <DescriptiveDetail> </DescriptiveDetail> Block 1 <CollateralDetail> </CollateralDetail> Block 2 <ContentDetail> </ContentDetail> Block 3 <PublishingDetail> </PublishingDetail> Block 4 <RelatedMaterial> </RelatedMaterial> Block 5 <ProductSupply> </ProductSupply> Block 6 </Product> Het blok Record metadata en Product numbers geeft aan over welk ISBN de daarop volgende gegevens uit het ProductRecord betrekking hebben. Block 1: DescriptiveDetail Pagina 33

34 Bevat de verschijningsvorm van het ISBN en de basistitelgegevens zoals titel, reeks, auteursvermeldingen, druk/editievermeldingen, de taal waarin de publicatie is uitgegeven, de omvang, en de verschillende onderwerpscoderingen zoals NUR en AVI leesniveau (voor kinderboeken) Block 2: CollateralDetail Bevat vermeldingen van cover, backcover, flapteksten en andere promotionele teksten, verwijzingen naar bestanden met leesfragmenten, filmpjes, gesproken teksten die gerelateerd zijn aan de publicatie Block 3: ContentDetail Bevat vermeldingen over individuele hoofdstukken uit een publicatie, wordt volgens de afspraken van de ONIX Werkgroep niet gebruikt in Nederland/Vlaanderen. Block 4: PublishingDetail Bevat gegevens over de imprints, de eigenaar, het stadium levenscyclus en de verschijningsdatum Block 5: RelatedMaterial Bevat gegevens over vervangende ISBN s en ISBN s van een fysiek boek, waarvan een eboek is afgeleid Block 6:ProductSupply Bevat alle commerciële gegevens rondom de dienstverlening van de distributeur, zoals stadium dienstverlening, prijsgegevens, BTW en boeksoorten. Pagina 34

35 11. Productrecord fysieke boeken Een overzicht van de gebruikte velden (data elements) en composites Record reference number, type and source Na de Message header begint het Product record. Het begin van het Product record is het RecordReference Number. Hierin wordt een referentienummer aangegeven voor de gegevens die volgen in het betreffende Product record DATA ELEMENT FIELD XML REFERENCE NAME M/O Onix M/O CB LIST A N POS. Record Reference Number P.1.1 <RecordReference> M M N 13 Notification or Update Code P.1.2 <NotificationType> M M 1 Voorbeeld: <Product> <RecordReference> </RecordReference> <NotificationType>04</NotificationType> Record reference number Een record met titelgegevens wordt geïdentificeerd aan de hand van de GTIN-13 (vroeger EAN-UCC13). Dit is een referentienummer voor het record, niet voor de titel die in dit record is opgenomen, deze staat in P 2.3. Echter deze twee zullen in het ONIX bericht dat wordt aangeleverd aan CB altijd dezelfde waarde bevatten. Notification or update type code Door middel van waarde 04 uit codelijst 1 wordt aangegeven dat het product record is opgebouwd uit Block updates. Alleen de blocken uit het product record waarin gegevens gewijzigd zijn worden doorgegeven en bevatten de volledige nieuwe waarheid. Bij een nieuwe titel wordt impliciet het volledige product record aangeleverd omdat alle blocken dan nieuw zijn Product identifier composite De Product identifier composite wordt gebruikt om de identificatie van de titel aan te geven in het product record. Voor CB wordt het GTIN-13 (EAN, UCC-13) van de titel opgenomen Deze composite zal per artikel altijd worden aangeleverd en precies 1 keer. DATA ELEMENT FIELD XML REFERENCE NAME M/O Onix M/O CB LIST A N POS. Product Identifier Composite (R) <ProductIdentifier> M M Product Identifier Type Code P.2.1 <ProductIDType> M M 5 Identifier Value P.2.3 <IDValue> M M N 13 End of Product Identifier Composite Pagina 35

36 In PR.1. <RecordReference> wordt deze EAN reeds opgenomen, maar daar gaat om een (uniek) referentienummer voor het record, in deze composite over de bibliografische identificatie van de titel. Ze zullen in het ONIX bericht dat de uitgever aanlevert aan CB altijd hetzelfde zijn. Waarbij: PR.2.1 <ProductIDType> : waarde 03 uit Code-list 05 duidt aan dat het om een GTIN-13 (EAN.UCC13) gaat. PR.2.3 <IDValue> : het eigenlijke EAN/ISBN-13 van de titel. Pagina 36

37 11.3. Block descriptive detail Product form Het begin van het Block Descriptive Detail zijn de gegevens met betrekking tot de verschijningsvorm van de titel. Voorbeeld van een fysiek boek: <ProductComposition>00</ProductComposition> <ProductForm>BC</ProductForm> DATA ELEMENT FIELD XML REFERENCE NAME M/O Onix M/O CB LIST A N POS. Product Composition P3.1 <ProductComposition> M M 2 A 2 Product Form Code P.3.2 <ProductForm> M M 150 A Product Form Detail P.3.3 <ProductFormDetail> O O 175 A 5 ProductForm Description P.3.8 ProductFormdescription O O A 255 <Product Composition> wordt gevuld met waarde 00 uit codelijst 2. Dit betekent dat het een enkelvoudig artikel betreft. Samengestelde artikelen kunnen alleen als enkelvoudig artikel worden aangemeld. De samenstelling van een titel moet handmatig worden ingevoerd door een medewerker van Customer Service van CB. De tag <ProductForm> wordt gevuld met een waarde uit codelijst 150. De waardes die CB ondersteunt treft u aan in Hoofdstuk 15, Bijlage Product form description Het veld <ProductFormDescription> kan worden gebruikt om in een vrij tekstveld aan te geven als er bijlagen of specifieke kenmerken bij de titel horen. Voorbeeld van een babyboekje, hardback : <DescriptiveDetail> <ProductComposition>00</ProductComposition> <ProductForm>BB</ProductForm> <ProductFormDescription>luierflapjes</ProductFormDescription> Measure composite (afmetingen) De measure composite hoeft niet te worden aangeleverd door de uitgever. De afmetingen van fysieke boeken worden vastgesteld bij het inslaan van een nieuwe titel ProductClassification: Fondsgroep In veld PR.3.22 wordt de fondsgroep aangegeven die de uitgever aan het artikel heeft toegekend. Deze fondsgroep geeft een uitgeverspecifieke indeling aan ten behoeve van het indelen van het fonds van de uitgever voor zijn eigen verslaglegging en zal in de meeste gevallen ook alleen bruikbaar zijn voor de uitgever van de titel. Hier toe zijn de volgende velden gevuld: Pagina 37

38 P.3.21 <ProductClassificationType> : waarde 06 uit Code-list 09 duidt aan dat het hier een Fondsgroep: CB free classification field for publishers betreft P.3.22 <ProductClassificationCode> : de fondsgroep van 000 t/m 999 In het navolgende voorbeeld heeft een titel fondsgroep 998. <ProductClassificationType>06</ProductClassificationType> <ProductClassificationCode>998</ProductClassificationCode> </ProductClassification> ProductClassification: BTW Classificatie DATA ELEMENT Product Classification Composite (R) Product classification type code Product classification code <Percentage> FIELD End of Product Classification Composite (R) XML REFERENCE NAME M/O Onix M/O CB <ProductClassification> O M LIST P.3.2 M M 9 2 <ProductClassificationTyp e> P.3.2 M M N 3 <ProductClassificationCo de> P.3.2 <Percent> M M 4 A N POS. Om ervoor te zorgen dat CB de juiste BTW kan bepalen op artikelfacturen tussen uitgevers en afnemers, moeten artikelen ingedeeld worden in een Product BTW Classificatie. Met behulp van deze classificatie kan onder andere worden bepaald welk BTW-tarief geldt in een bepaald land. Dat geldt ook voor artikelen die uit meerdere onderdelen bestaan (gemengd BTW), zoals een boek met een CD. Een artikel mag uit maximaal 3 classificaties bestaan, maar moet minimaal in één classificatie zijn ingedeeld. Een overzicht van de toegestane Product BTW Classificaties treft u aan in bijlage V. Bij de classificatie wordt een percentage doorgegeven dat aangeeft voor hoeveel procent het artikel uit de betreffende classificatie bestaat. Met dit percentage en de totale prijs wordt vervolgens de deelprijs berekend. Om hierin zo min mogelijk afrondingsverschillen te krijgen, kan het percentage met 5 decimalen worden doorgegeven. Bij een artikel met meerdere classificaties moet de optelsom van de percentages gelijk zijn aan 100%. Een percentage moet tussen 0 en 100 liggen. <ProductClassification> <ProductClassificationType>07</ProductClassificationType> <ProductClassificationCode>BK_ALG</ProductClassificationCode> <Percent>100</Percent> </ProductClassification> Pagina 38

39 Zie paragraaf voor een toelichting op de berekening van deelprijzen Collection Part In de Collection Composite kan worden aangegeven dat een titel is opgenomen in een bibliografische reeks. De gebruikte velden zijn: DATA ELEMENT FIELD XML REFERENCE NAME M/O Onix M/O CB LIST A N POS. Collection Composite (R) <Collection> O O Collection Type Code P.5.1 <CollectionType> M M 48 N 2 Title detail Composite (R) <TitleDetail> O O Title type P. 5.6 <TitleType> M M 15 2 Title element composite (R) <TitleElement> M M Title element level P.5.7 <TitleElementLevel> M M Part number P5.8 <PartNumber> O O A 10 Title text P5.10 <TitleText> O M 255 End of Title element composite End of Title detail composite End of collection composite CollectionType 10 uit codelijst 48 geeft aan dat er een bibliografische reeks volgt. Hierna volgt de TitleDetailComposite. In de TitleDetail Composite wordt aangegeven wat de reeksnaam is (deze moet altijd gevuld zijn als de CollectionComposite is opgenomen). Verplicht binnen ONIX 3.0 is ook om het <TitleElementLevel> op te nemen. Door het TitleElementLevel wordt aangegeven dat de reeksnaam in relatie staat tot de hoofdtitel van het werk. In de databank van Bureau ISBN bestaat de reeksnaam uit 1 veld. Er wordt geen onderscheid gemaakt tussen evt. hoofdreeks of subreeks. Dit heeft tot gevolg dat <TitleElementLevel> voor het doorgeven van een bibliografische reeks altijd moet worden gevuld met waarde 2. Het veld PartNumber is een optioneel veld, hierin komt het deelnummer van de reeks te staan. Een deelnummer doet zich niet bij alle reeksen voor. Het veld PartNumber kan ook Romeinse cijfers bevatten. Hieronder een voorbeeld van de vermelding van deel 86 uit de reeks Merian live! TitleType 01 uit codelijst 15 geeft aan dat het om de reeksnaam gaat zoals die op de titelpagina of colofon van het boek voorkomt. TitleElementLevel 02 geeft de relatie tussen de reeks en de hoofdtitel van het boek aan. <Collection> <CollectionType>10</CollectionType> <TitleDetail> <TitleType>01</TitleType> <TitleElement> <TitleElementLevel>02</TitleElementLevel> <TitleText>Merian live!</titletext> </TitleElement> <TitleElement> Pagina 39

40 </Collection> <TitleElementLevel>02</TitleElementLevel> <PartNumber>86</PartNumber> </TitleElement> </TitleDetail> Title Composite In de Title Composite worden alle gegevens opgenomen met betrekking tot de titelvelden van de publicatie waarover het ProductRecord gaat. De velden van de TitleComposite zijn: DATA ELEMENT FIELD XML REFERENCE NAME M/O Onix M/O CB LIST A N POS. Title detail composite (R) <TitleDetail> M M Title Type P6.1 <TitleType> M M 15 N 2 Title element composite <TitleElement> M M (R) Title element level P6.2 M M 149 N 2 <TitleElementLevel> Part number P6.3 <PartNumber> O O A 10 Title text P6.5 <TitleText> M M Afhank elijk van TitleTy pe Subtitle P6.8 <Subtitle> O O End of Title element composite (R) End of Title detail composite (R) De Uitgever kan vier verschillende varianten aanleveren: Bibliografische titelomschrijving verplicht Title composite met TitleType 01 uit codelijst 15 -, max posities Titelgegevens zoals ze voorkomen in de bibliografische bronnen van het boek zelf: titelpagina, colofon en evt. cover. Aan de hand hiervan voert Bureau ISBN bij het verschijnen van het boek de redactionele controle uit. Hoofdtitel, deeltitel, sectietitel en ondertitel worden vastgelegd in gescheiden velden. De boekhandel of webwinkel heeft de mogelijkheid om naar eigen inzicht uit de losse velden de gewenste samenstelling en volgorde van de gegevens te concateneren. Bij educatieve boeken worden de verschillende onderdelen van de titel als volgt opgebouwd:: Titel van de methode op TitleElementLevel 03 (hoofdtitel) Nummer van het deel binnen de methode op TitleElementLevel 02 (deeltitel) Pagina 40