Your SlideShare is downloading. ×
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Rfp catalogue version 1.0
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rfp catalogue version 1.0

987

Published on

RFP nationaal titelbestand bevat de specifieke requirements die uitgevers en boekverkopers hebben opgesteld om te bepalen aan welke voorwaarde titelinformatie voorziening in het nationaal titelbestand …

RFP nationaal titelbestand bevat de specifieke requirements die uitgevers en boekverkopers hebben opgesteld om te bepalen aan welke voorwaarde titelinformatie voorziening in het nationaal titelbestand moet voldoen.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
987
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Request for Proposal for the catalogue of all Dutch works “BRAM”RFP Dutch catalogue, version 1.0, October 2011 Page 1
  • 2. Change history Date Version Author(s) Changes August 29th 2011 0.1 PR Start of document September 1st 2011 0.3 PR / FD Adding structure and overview rd September 3 0.5 PR / FD Aligned requirements and goals/introduction th September 8 0.7 MK Adding comments and additional requirements th September 26 0.9 MK Processed comments work group, adding GEU requirements & ameliorate use cases October 2011 1.0 PR Status of RFP due to outcome joint GAU – KBb steering committee made finalDocuments referencedName ReasonAuthorizationName, function Place, dateRFP Dutch catalogue, version 1.0, October 2011 Page 2
  • 3. Contents1 RFP PROCESS / SCHEDULE OF EVENTS .......................................................................................... 4 1.1 CONTENTS OF THE RFP ..................................................................................................... 4 1.2 PRE-PROPOSAL CONFERENCE .............................................................................................. 5 1.3 LIST OF SUPPLIERS ........................................................................................................... 5 1.4 QUESTIONS FROM THE SUPPLIER .......................................................................................... 5 1.5 TERMS AND CONDITIONS ................................................................................................... 5 1.6 SCHEDULE OF EVENTS ....................................................................................................... 62 GENERAL INFORMATION ............................................................................................................. 7 2.1 DEFINITIONS.................................................................................................................. 7 2.2 PURPOSE...................................................................................................................... 7 2.3 BACKGROUND ................................................................................................................ 7 2.4 OBJECTIVES AND SCOPE OF THE PLATFORM .............................................................................. 8 2.5 CONCEPTUAL OVERVIEW OF THE CATALOGUE SYSTEM / APPLICATION ................................................ 9 2.6 CONCEPTUAL MODEL OF THE CONTENTS OF THE CATALOGUE ........................................................ 10 2.7 PHASING OF IMPLEMENTATION OF THE CATALOGUE .................................................................. 113 REQUIREMENTS ....................................................................................................................... 12 3.1 TECHNICAL SOLUTION OF THE CATALOGUE ............................................................................. 12 3.1.1 Catalogue structure and features ......................................................................... 12 3.1.1.1 Phase 1 requirements ..............................................................................................................................................12 3.1.2 Feeding the catalogue content ............................................................................. 13 3.1.3 Maintaining the catalogue content ...................................................................... 13 3.1.3.1 Phase 1 requirements ..............................................................................................................................................13 3.1.4 Accessing the catalogue content .......................................................................... 14 3.1.4.1 Phase 1 requirements ..............................................................................................................................................14 3.1.4.2 Phase 2 requirements ..............................................................................................................................................14 3.1.4.3 Phase 3 requirements ..............................................................................................................................................14 3.2 CATALOGUE MANAGEMENT .............................................................................................. 15 3.2.1.1 Phase 1 requirements ..............................................................................................................................................15 3.3 DUTCH CATALOGUE CONTENT ........................................................................................... 15 3.3.1.1 Phase 1 requirements ..............................................................................................................................................154 TECHNICAL DESIGN / NON-FUNCTIONAL REQUIREMENTS ............................................................ 16 4.1 ARCHITECTURAL GOALS AND CONSTRAINTS ........................................................................... 16 4.2 PRINCIPLES ................................................................................................................. 16 4.3 USABILITY ................................................................................................................... 17 4.4 SECURITY & PRIVACY ..................................................................................................... 17 4.5 SCALABILITY AND PERFORMANCE ........................................................................................ 17 4.6 SOURCING & TECHNICAL AVAILABILITY ................................................................................. 18 4.7 INTEGRATION............................................................................................................... 18 4.8 FLEXIBILITY ................................................................................................................. 19 4.9 DATA INTEGRITY ........................................................................................................... 195. EDUCATIONAL MARKET ............................................................................................................ 20APPENDIX 1: USE CASES .................................................................................................................. 22APPENDIX 2 DAILY IRRITATIONS RETAILERS CURRENT TITLE METADATA .............................................. 27RFP Dutch catalogue, version 1.0, October 2011 Page 3
  • 4. 1 RFP process / schedule of eventsThe purpose of this RFP is to solicit competitive, sealed, proposals and a demo-version to establish acontract for the development, maintenance & support and running of an Infrastructure (System) or aService for the catalogue of all Dutch works / titles both digital and print.The RFP for this catalogue consists of 3 separate parts: 1. A technical solution for the catalogue. This includes the database and required functionality to feed, store, maintain and access the catalogue. 2. A maintenance service for the catalogue. This includes a team of skilled people that maintains the completeness and correctness of the catalogue. 3. Content for the catalogue. This includes catalogue content for all Dutch works / titles.This RFP is sent to <<xxxx>>. Vendors are free to work together and submit a combined proposal if seen fit.N.B. In the joint GAU – KBb steering committee of October 2011 it was decided that ePagine should be the primary vendor for the catalogue (both for the required functionality as for the update and content). This RFP is for now only discussed with ePagine.1.1 Contents of the RFPThe requested information concerning this RFP consists of the following elements: 1. Applicant’s view / ideas on the ideal demand-supply (publisher / retailer – applicant) operating organization for the catalogue and the leadership role you would like to fulfill. Please explain how you would like to lead GAU-KBb on innovation and enable them to stay competitive in an ever faster changing world. 2. Detailed functional and technical description of the solution at hand including the development roadmap. Applicant should describe his model and explain why that model is best to achieve the goals of GAU / KBb. 3. A statement of compliance for every single requirement stated in this document (see chapter 3 and 4). Please state either ‘fully compliant’, ‘partially compliant’, ‘custom’ or ‘non compliant’ together with a further explanation. 4. The basic shape of a project, implementation & test plan for the development and implementation of this catalogue outlining the breakdown of activities, products and required workforce (both on a timescale and as milestones) plus the proposed way to organize this project and what preconditions are to be met. 5. A cost proposal / business – pricing model consisting of a. The project costs stated in separate items with a distinction in design, build, implementation and conversion. Project management is to be listed separately.RFP Dutch catalogue, version 1.0, October 2011 Page 4
  • 5. b. Investments being any costs for items (not being licenses) that run for longer than 1 year (e.g. specific hardware) c. Operating / running costs (e.g. licenses, hosting costs, maintenance (of hard- and software), support, costs of FTE to run Operations) 6. A demonstration of vendors’ ability to meet the requirements stated in this RFP. To this end Use Cases are given in Appendix 1. The demonstration is meant to be a live display of functionality on existing components Applicant has available.Applicant is kindly requested to submit items 1, 2, 3 and 4 by the end of xxxx.1.2 Pre-Proposal ConferenceA mandatory pre-proposal conference is scheduled in the week of xxx. Each potential applicant may send amaximum of two (2) representatives. Specific questions concerning the RFP should be submitted in writingprior to the pre-proposal conference. Additional questions may be entertained at the conference; however,responses may be deferred and answered at a later date. Written copies of all questions and officialresponses will be supplied to all potential applicants.1.3 List of suppliersThis RFP will go to the following suppliers:Centraal BoekhuisLibrekaEpagineNBD BiblionNDC –VBK ism IcontactBoekenbank.beN.B. In the joint GAU – KBb steering committee of October 2011 it was decided that ePagine should be the primary vendor for the catalogue (both for the required functionality as for the update and content). This RFP is for now only discussed with ePagine.1.4 Questions from the supplierIf you have any questions, please contact Pieter Ruempol, pruempol@orangeswan.nl (mobile phone: +31651 56 74 29).1.5 Terms and ConditionsThe contents of this RFP document and your response is both by you and by the KBb / GAU consideredconfidentially. It is prohibited to use information from this document for other purposes than answeringthis RFP.Any cost made by a supplier due to this request for proposal will not be compensated in any way.RFP Dutch catalogue, version 1.0, October 2011 Page 5
  • 6. 1.6 Schedule of EventsEvent Date(s) / timeRFP Release Date xxxDeadline for Receipt of Written Inquiries xxxPre-proposal conference xxxDemonstrations xxxEvaluation Period xxxAnticipated Contract Award xxxAnticipated start of project xxxN.B. In the joint GAU – KBb steering committee of October 2011 it was decided that ePagine should be the primary vendor for the catalogue (both for the required functionality as for the update and content). This RFP is for now only discussed with ePagine.RFP Dutch catalogue, version 1.0, October 2011 Page 6
  • 7. 2 General Information2.1 Definitionsterm definitionBISG Book Industry Study GroupDRM Digital Right Management (e.g. Adobe for e books)DOLCI Working Title for digital platformBRAM Working title for the project to realize the catalogue of all Dutch workse book Electronic version of a book. Also: all kinds of digital productsISBN International Standard Book Number (ISBN) is a 13-digit number that uniquely identifies books and book-like products published internationallyISTC International Standard Text Code (ISTC) is a numbering system developed to enable the unique identification of textual works.ONIX the international standard for representing and communicating book industry product information in electronic formBisac The BISAC Subject Headings List, also known as the BISAC Subject Codes List, is a standard used by many companies throughout the supply chain to categorize books based on topical contentwork Content of a publication, independent of its appearanceappearance Appearance of a work on a specific medium, e.g. pocket, hard cover, ePub e-book, audio book.edition Over time, the contents of a work change leading to new editions of a workKBb Koninklijke BoekverkopersbondNUV Nederlands UitgeversverbondGAU Groep Algemene Uitgevers (part of NUV)Applicant the company (or consortium of companies) that makes a proposal to this RFPGEU Groep Educatieve UitgeversKPI Key performance indicators both for system performance and all business transactionsPrincipal any natural or legal person for whom a project is carried out; here: KBB / GAURFP Request for ProposalWebsite/webshop Online marketing and sales platform of the retailer.FRBR RDA Functional Requirements for Bibliographic Records Resource Description and Access2.2 PurposeThe purpose of this RFP is to solicit competitive, sealed, proposals and a demo-version to establish acontract for the development, implementation, maintenance and operation of an Infrastructure (System)or a Service for the catalogue of all Dutch works / titles both digital and print.2.3 BackgroundThe contents and quality of the current catalogue of Dutch works is poor. It is incomplete, ambiguous (e.g.multiple spellings for the same author) and redundant (e.g. multiple ISBN’s for the same appearance of awork). Consumers / end-users can therefore not conduct proper search and find queries, do not have anRFP Dutch catalogue, version 1.0, October 2011 Page 7
  • 8. overview of the complete offer of Dutch works / titles and are ill informed. Consequently publishers andbooksellers miss sales.Furthermore the maintenance of the current data is labor intensive and inefficient and therefore costly forboth publishers and booksellers.Parallel to this Request for Proposal a similar project is running to select and realize one, unambiguousdigital platform that supports and helps customers (end-users) in an attractive and simple way to find, buy,use and read digital products. A good catalogue of all works at offer is hereby essential and indispensable.The to be selected digital platform and the catalogue are inextricably linked.2.4 Objectives and scope of the platformThe main objective of the Dutch catalogue for all works is: “To realize one, for consumers / end-users, complete, unambiguous, reliable, amenable overview of the Dutch supply of both physical and digital content”.And secondary objectives are: a) A good catalogue of all Dutch works will create and enlarge insights in the search behaviour of customers and therefore enabling a more targeted offer of content and also the ability to create relevant content. b) A good catalogue of all Dutch works will support the selection (and creation) of relevant content for specific customer / user groups or for own use. c) A catalogue of all Dutch works will enable to optimize the selection and search & find of the complete offering for all stakeholders (a.o. relevant search results independent of the search). d) A catalogue of all Dutch works will reduce costs (no redundancy, less procurement costs, central and unambiguous storage of content and metadata) and increase the efficiency of data management / maintenance.The initial scope of the catalogue is: • Primarily focused on only the Dutch offering of both print and digital content (i.e. at first not the foreign offering of content on the Dutch market) • Primarily focused on the so called general book (fiction and non-fiction) and secondary on educational and scientific content (albeit that specific requirements for these types of content will be taken into account) • In scope is the complete current and available (ready for delivery) supply of content including new arrivals from 2010 onwards (estimated 80.000 titles, in Dutch A-books)Out of scope are:  Foreign offering of content (works / titles)  Non current and available titles prior to 2010RFP Dutch catalogue, version 1.0, October 2011 Page 8
  • 9. 2.5 Conceptual overview of the catalogue system / applicationThe data for the catalogue originate either from a publisher feed (a publisher entering new data in bulk) orfrom a third party feed (relevant data made available by external parties like KB, NBD Biblion and foreignparties) or from manual entry.On all data a rights management system will be of use, and all persons who can enter data will be logged,as to be able to quickly find the correct data owner in case of data inconsistencies.The content is maintained, changed and enriched, depending on the type of data, by publishers, retailers,authors and librarians. In the future (phase 3) further enrichment of the catalogue data with usergenerated content is foreseen, whereas the user is the retailer. Also is foreseen that all users can makesuggestions for data improvement, where the central catalogue operator will contact the correct dataowner to follow up suggestions.The catalogue itself will not contain the actual files. The storage of the digital (naked) file will be on theDolci digital platform and the physical book delivery is dependent upon the chosen logistic fulfillment routeof the retailer.Retailers can use assortment management to use a specific subset of the catalogue to support theirbusiness and exploit certain specialized niches. In a later phase, white label services will be offered tointegrate catalogue search and browse functionality into a web shop. White label services will also supportsemantic web support.RFP Dutch catalogue, version 1.0, October 2011 Page 9
  • 10. Community interaction through the retailer will be foreseen on web 3.0 social media tools. This couldpertain for instance in the author data, twitter address, web address, Facebook page. Such data fields areforeseen.2.6 Conceptual model of the contents of the catalogueThe primary interest or search entry of customers while searching for a product is the author, the work or asubject. Both author and work should be uniquely identifiable (with no redundancy or duplicates). From theauthor or the work the published formats (appearances) or specific editions should be accessible. This isdifferent from a logistic oriented model where the published format of a specific edition is the main entry.Nevertheless, the customer-focused catalogue should be able to synchronize with / connect to the logisticinformation such that both types of information can be made available to retailers in an integrated way ifnecessary.Author should fall under a broader unique person entity. A person can be any contributors to a work, e.g.authors, illustrators, translators etc.. Topical specific searches on subject are foreseen, which can be usedeither through the NUR or BISAC coding of books, or the tagging which is applied by the retailer or even insome cases the end consumer.All data entry should be traceable to unique persons and specific feeds, keyed to the entering publisher orother party. Normalization should take place on all entries, independent of the entry manner.Each entity in the catalogue has its own specific metadata or content and can be re-used when new worksor published formats (appearances) are added to the catalogue.RFP Dutch catalogue, version 1.0, October 2011 Page 10
  • 11. Retailers can connect logistic fulfillment routes, independent of the catalogue to the different appearancesof books inside the webshop.Retailers can make relevant selections through an assortment management module of the total offering ofthe catalogue to make their commercial offering to the end consumer relevant.Special attention should be given to problems which occur around the registration of series and serials,which currently are not registered in a consistent manner. Webshops should be able to display correctlycorrelating books, series, such as trilogies, but also long term numbered serials, such as Donald Duckpockets. In the normalization of data special attention should be given to these recurring problems.The model presented above is a conceptual model only. Applicant should describe his model and explainwhy that model is best to achieve the goals of GAU / KBb (as requested in paragraph 1.1 Contents of theRFP).2.7 Phasing of implementation of the catalogueFor the implementation of the catalogue there are currently 3 phases defined: 1. Basic functionality and content based on international standards for all Dutch works from 2010 onwards to incorporate the contents of the current catalogues Titelbank and CBonline for use by the digital platform Dolci. And also the implementation of centralised maintenance and support of data. Rights management and amelioration suggestions for all data should be supported. A good search engine should be supported. All data should be filled, normalised and identified in a unique manner. 2. Further enrichment of catalogue data with (copyright-protected) enriched content & third party feeds (e.g. journal reviews) and enabling white label services (e.g. search & find) for web shops. 3. Further enrichment of catalogue data with user generated content (e.g. tagging, retailer reviews) and semantic web support. This user generated content can be exploited by the uploader, thus not only rights, but also a pricing & payment model should be enabled to support this data layer.RFP Dutch catalogue, version 1.0, October 2011 Page 11
  • 12. 3 RequirementsFor the sake of intelligibility the specifications are numbered continuous. As mentioned in chapter 1Applicant is requested to provide a statement of compliance for every single requirement stated in thisdocument.3.1 Technical solution of the catalogue3.1.1 Catalogue structure and features3.1.1.1 Phase 1 requirements1. The catalogue should adapt to international standards as much as possible. Important standards are Onix for books (http://www.editeur.org), ISTC, FRBR RDA, NUR and Bisac. New developments within the standardisation community relevant to the catalogue need to be adapted (easily).2. The catalogue should support different kinds of metadata: a. Basic metadata identifying a work and person. b. Enriched metadata like a description or a bibliographic author description. c. Different types of content like reviews and press releases related to a catalogue entry. d. Snapshots of the product itself like a table of contents or first chapter. e. Multi-media files with photos, videos and other media.3. The metadata should be stored in a normalized way (relational model). This means that persons (such as author, translator and illustrator), publishers and works-related metadata is stored only once (no duplicate records of this information for different titles/products). Please specify the logical model of the entities and metadata supported by your solution.4. The catalogue should support every possible digital format and relevant metadata. Please specify the types of digital products supported and corresponding metadata.5. The catalogue should support all folio format related metadata such that folio can also be included in the catalogue. Please specify the types of physical products supported and corresponding metadata.6. The catalogue should support product variants (grouping of product around a work). This includes different media, different formats and different languages of a product.7. The catalogue should support easy identification of correlated books, both series and serials.8. Metadata and content that enrich the catalogue can be stored multiple times. For each variant of the metadata, the source (feed or user that enters the metadata) of the metadata is stored.9. Identifying metadata fields can be stored only once. No duplicates.RFP Dutch catalogue, version 1.0, October 2011 Page 12
  • 13. 3.1.2 Feeding the catalogue content10. The catalogue should implement a feed conform the ONIX for books standards (both the interchange formats and ftp interface) for digital products.11. Publisher and retailer should be able to deliver (new or modify) digital product information to the catalogue in ONIX 3.0 format.12. Publisher and retailer should be able to deliver (new or modify) digital product information to the catalogue in ONIX 2.1 format.13. Publisher and retailer should be able to deliver (new or modify) digital product information to the catalogue through a simple web interface or with standard im- and export formats, such as excel or .csv files.14. A polling model for information instead of a feed model should be possible for smaller webshops15. A plug-in architecture should be supported to connect third party feeds with different formats.16. Please specify the additional feeds (external sources) that are already imported into the catalogue on a regular basis. Per feed specify what content is used and the update frequency.3.1.3 Maintaining the catalogue content3.1.3.1 Phase 1 requirements17. The catalogue needs to be maintained in a decentralised manner (each publisher and /or retailer delivers its information and can make suggestions for data improvement).18. Central maintenance of the catalogue should be supported (consistent view on all data). Please specify the available functionality for this task.19. Ownership of metadata should be configurable. Only the owner of metadata can modify the metadata. Others can make suggestions for improvement to the owner/ central catalogue management.20. Rights on the meta-data fields should be configurable such that groups and users can view, edit, delete or suggest improvements based on the settings of the owner of the metadata.21. It should be possible to integrate the rights management model for the catalogue with that of the digital publishing platform Dolci. Please specify how this could be supported.22. Data quality. The quality of the information in the catalogue should be guaranteed, both syntactical and semantical. This can be done either by automated or manual means. Please specify available features (e.g. protocols, business rules) in the catalogue that support this.RFP Dutch catalogue, version 1.0, October 2011 Page 13
  • 14. 3.1.4 Accessing the catalogue content3.1.4.1 Phase 1 requirements23. Catalogue information can be made available to retailers in a restricted way (as defined by the publishers and retailers). It should be possible to differentiate at publisher, retailer, metadata and product level.24. Catalogue information can be selected by retailers to use a subset to make a better niche offering to differentiate with competitors.25. Only catalogue entries and metadata that are available for a retailer may be accessible for that retailer.26. Subsets of the catalogue can be made available to retailers in ONIX 3.0 format.27. Subsets of the catalogue can be made available to retailers in ONIX 2.1 format.28. Subsets of the catalogue can be made available to retailers in a simple format. Please specify.29. A web-service is available to request the required subset of the catalogue and the exported format.30. A web-service is available to manage the size of the delivery (all content, all content with changes from a specific date, only the changes from a specific date).31. A search on the catalogue should be supported through a web-service which can easily be integrated in the retailer’s website. This service facilitates the consumer to execute search queries. These queries will be input for the central platform search service. The results are presented to the consumer via the retailer website. The retailer can add it’s own search engine filters.3.1.4.2 Phase 2 requirements32. A webshop can easily integrate functionality in its platform to offer services to customers to find and view digital content to support the sales process. Please specify the features available for this purpose. For instance, read first chapter or table of contents or full text search.33. Retailers are able to add tags to content and manage this within their metadata collection and be able to share this with selected retailers and publishers and use this to better serve their end consumers.3.1.4.3 Phase 3 requirements34. User generated, social and purchased content can be included in the metadata that can be accessed. Including payment & pricing of UG content when shared with other retailers.35. Semantic web support should be made available in the white label services for webshops. Please specify your roadmap on this subject or the initiatives / languages you plan to support.RFP Dutch catalogue, version 1.0, October 2011 Page 14
  • 15. 3.2 Catalogue management3.2.1.1 Phase 1 requirements36. Please describe the organisation available to manage and improve the quality and completeness of the catalogue. Please specify the number of employees and their skills.37. Please describe the activities performed by this organisation.38. Please describe the subset of the products in and out scope of this RFP that are currently supported by this organisation.39. Please describe the metadata fields that are currently in scope of the maintenance activities.40. Please describe accompanying reporting tools, which are available to all parties on relevant data on feeds, processing of feeds, suggestions, search behaviour, data & content changes and any further available reports.41. Please suggest how this organisation can support the maintenance of the catalogue of all Dutch works.3.3 Dutch catalogue content3.3.1.1 Phase 1 requirements42. Please describe the subset of the titles in and out scope of this RFP that can be offered as a start collection for the catalogue of all Dutch works (titles, metadata, format).43. Please describe the quality of the content in terms of 1) completeness, 2) available entities and meta- data and 3) duplication level.44. Please specify the additional feeds (external sources) that have been included in the content.RFP Dutch catalogue, version 1.0, October 2011 Page 15
  • 16. 4 Technical design / non-functional requirements4.1 Architectural Goals and ConstraintsThe overall architecture goal of BRAM is to provide a standards-based highly available and scalable onlineplatform for the “consumers” of the catalogue.A key Architectural goal is to leverage industry best practices for designing and developing a scalable,enterprise-wide application. To meet this goal, the design of BRAM need to be based on proven designpatterns as well as industry standard development guidelines.Standards and principles provide a starting point to describe the target architecture for the platform. Someof the guiding principles that should be applied for BRAM will be followed during the design anddevelopment are outlined below.4.2 PrinciplesBest practices and design principles need to be applied in different areas: 1. The diversity of applications and techniques must be limited a. to support a uniform integration between the (functional) domains b. to improve manageability and flexibility 2. Model Driven architecture is the preferred application development framework a. Applying abstract models with translations to more detailed models b. Where models are executed instead of code creation of code generation 3. Business Rules (engine) should be applied within the application development framework a. Business rules will need to be separated from the presentation and database frameworks b. Server applications are based on event-based systems. c. Standard frameworks for encoding business rules and events will need to be used d. Adoption of a component based framework needs to be considered to promote reuse of information objects 4. Presentation Services to devices or desktops should be uncoupled: a. Presentation services are delivered to web browsers. Support for modern browsers and devices is required b. A common look and feel for BRAM and the BRAM user interface must be designed in such a way that common user interface functionality will be implemented in a similar manner across the platform.45. The catalogue services will comply with established industry standards. The standards-compliance will not only apply to application development but also to design, platform/infrastructure and other parts of the catalogue. Examples of standards include HTML, XML, J2EE, Database standards (modern, up-to- date, industry standardized DBMS) et cetera.RFP Dutch catalogue, version 1.0, October 2011 Page 16
  • 17. 4.3 UsabilityUser interfaces of the catalogue should be consistent, uniform and easy to use to facilitate a seamlessoperation of the catalogue.46. Attractiveness and user friendliness: for acceptance of the system by various groups of users, the systems front-end is attractive (for both ‘the eye’ and functionality) and easy to use.47. Usability: for the usability of the system by all kinds of end-users the front-end of the system is clear and understandable; all functionality is found and understood intuitively by the users; there are no long (or steep) learning curves for people using the system.48. Multilingual: the system must support multi languages both at the front-end of the system as well as for digital products themselves.4.4 Security & PrivacyBRAM will be used by different target groups; authors, publishers, retailers et cetera. This requires a propersecurity model where “Chinese walls” are present that ensure that users can never access the informationthey are not authorised to. Strict security and authorization roles need to be applied. Besides thisrequirement information that contains privacy information needs to be encrypted.49. Authorization: it is guaranteed that access to information is restricted to users and groups that are authorised to access this information.50. Authentication: each user needs to authorise him / herself to gain access to the services, unless specified otherwise. It should be possible to integrate the authentication system with that of Publishers and Retailers (Single Sign On). using SAML 2.0 standards.51. Security. Publishers should not be able to access consumer-specific information.52. Security. BRAM should be protected against unauthorised access to information including hackers and DOS attacks.4.5 Scalability and performanceScalability is the ability of the platform to scale both up and down to support varying numbers of users ortransaction volumes without performance penalties. The application should be able to scale horizontally(by adding more servers) or vertically (by increasing hardware capacity or software efficiency).53. Capacity and scalability: The catalogue should initially contain around 80.000 entries and will be used by a few thousand users on a regular basis. Initial number of connected retailers will be 250. This will grow in future, especially when white label services are connected to the catalogue. The scalability of the solution should be specified in terms of concept, quantities and pricing.54. Performance: The solution has to meet the following performance requirements.  User interface functions directly response to the user. Maximum response time (user experience) is 2 seconds.  Upload and download through feeds should be processed with a minimum speed of 1000 entries per minute.RFP Dutch catalogue, version 1.0, October 2011 Page 17
  • 18. 55. Performance: Users of the catalogue experience no degradation of service when feeds are being processed.56. Performance: Users experience no degradation of service as long as the load is within the required limits. These limits need to be specified by the vendor.4.6 Sourcing & technical availabilityBRAM will be outsourced to a professional data centre or service provider to ensure that the highavailability requirements can be met. The technical availability concerns the availability of the completeplatform including hardware and connectivity. No Single Point of Failures should exist that could causefailures.BRAM will contain different functions or modules that can require different performance or service levelse.g. shop access will require high availability guarantees while portal service to maintain master data couldrequire normal availability guarantees. The platform should support that availability guarantees onindividual modules, (Web)services or functions can be made and that this is reported on a monthly basis.57. Availability: Availability of the white label services should be 7x24 @ 99.95%. The maintenance interfaces should also be available close to 7x24 @ 99.95%.58. Availability: The catalogue should be accessible from any location world-wide (internet).59. Disaster recovery. In case of disaster the service should be recoverable within <<xx>> hours with a maximum data loss of <<yy>> hours.4.7 IntegrationBRAM integrates with publishers (feeds), external feeds, retailers and DOLCI. Integration with consumers orpublishers will be applied using modern integration methods like web services, rest as well as traditionalmethods and transports like file-based and ftp. This level of flexibility to map documents to differentformats and using different transports should be foreseen by applying an Enterprise Service Bus (ESB) andor Service Orient Architecture (SOA).The following characteristics are expected from the catalogue infrastructure:  Reliability and flexibility in integration solutions  Support for Business Process Management and Business Activity Monitoring  Routing and mapping of messages or information across different applicationsAn important subject of the platform is to adopt, develop and implement Web Services DescriptionLanguage (WSDL) standards. The exact of operations or services will be based on the adopted marketstandards and processes that need to be supported.60. Interfaces of the catalogue infrastructure should be based on SOA and ESB principles.61. Traditional file-based interfaces should be supported where relevant.62. Each interface of the catalogue infrastructure should be defined in terms of protocol used, capacity, reliability, monitoring and reporting features.RFP Dutch catalogue, version 1.0, October 2011 Page 18
  • 19. 4.8 FlexibilityThe market and technology is changing rapidly putting new demands to BRAM every year.Flexibility is the ability of the application to adapt and evolve to accommodate new requirements withoutaffecting the existing operations. This relies on a modular architecture, which isolates the complexity ofintegration, presentation, and business logic from each other in order to allow for the easy integration ofnew technologies and processes within the application.63. Flexibility: the architecture and implementation should be setup in such a way that the catalogue infrastructure can easily adopt new developments. These developments include but are not limited to: a. New industry standards relevant to the catalogue like ONIX b. New types of digital products c. New metadata fields and content (multimedia)4.9 Data integrityBRAM will handle a large amount of transaction on the catalogue. These should be handled in a secure andreliable way. Integrity of the catalogue information should be guaranteed at any time.64. Reliability: The atomicity of transactions and integrity of data should be guaranteed, also in cases of failure.RFP Dutch catalogue, version 1.0, October 2011 Page 19
  • 20. 5. Educational marketThe educational publishers have shown interest in both a digital distribution platform and a broadcatalogue for distribution & sales in the educational market. These educational publishers are united in theGEU (Groep Educatieve Uitgevers), which is one of the groups represented by the NUV (NederlandsUitgevers Verbond), just as the GAU. In the educational market different standards & processes areapplicable. The extra requirements are stated in this chapter. Compliancy on these standards is a bonus,but not a requirement to qualify for “BRAM”.The educational market is mostly served through the educational publishers which offer content throughtheir own platforms or through independent websites as www.leermiddelenplein.nl. Educationalinstitutions can use either a subscription model or a direct sales model. The business model is outside thescope of “BRAM”, but it may influence price information and the source of this information.The paragraphs and numbered requirements mentioned below correspond with those mentionedpreviously and should be regarded as an extension of the specific requirement from an educational point ofview. A separate statement of compliance is requested for these extended requirements.Paragraph 3.1.11. For educational content, the most relevant standard in the Netherlands is NL-LOM+. NL-LOM is a Dutchimplementation of the international IEEE-LOM. The + indicates a (not yet formalized) extension of the NL-LOM standard. For identification purposes different identification scheme’s are supported, like ISBN, DOIand Handle, the latter being the preferred one.7. In educational content a different form of grouping can be used to, called “lesmethoden”, withcorrelated content. Multiple (multimedia) types of content can be combined into new sellable products.Paragraph 3.1.210. The feed with educational content should be conform the OAI-PMH 1.4 standard for metadataharvesting (http://www.edustandaard.nl/afspraken/003).12. Publisher and retailer should be able to deliver (new or modify) educational content information to thecatalogue in NL-LOM 1.0.1 format and support the NL-LOM+ extensions.(http://www.edustandaard.nl/afspraken/nllom and http://vocabulairebank.edustandaard.nl )The educational market also uses a different classification model instead of NUR or Bisac. Each educationalphase (primary, secondary, ...) has its own specific classification models, reflecting the way that education isorganized in that phase. For one phase it can be a breakdown in courses, for other phases it can be abreakdown of competences. (More info: http://vocabulairebank.edustandaard.nl). These variety of modelsshould be added to enable subject search within the catalogue.Paragraph 3.1.426. Subsets of the catalogue can be made available to retailers in NL-LOM+ format.28. This web-service supports OAI-PMH.31. This service supports the SRU/SRW standard (http://www.edustandaard.nl/afspraken/004)RFP Dutch catalogue, version 1.0, October 2011 Page 20
  • 21. Paragraph 4.448. In educational content environments Single Sign On is used with SAML 2.0 standards.RFP Dutch catalogue, version 1.0, October 2011 Page 21
  • 22. Appendix 1: Use casesIntroductory Presentation subjectsPlease present your solution for the database: a. How would the datamodel of the database look like? b. How would the high level functional design look like? c. How will you guarantee all phase 1 requirements on the GO –Live date in cooperation with the DOLCI platform? d. How & where will the daily operations run of the catalogue? e. Which content do you already have and for which content would you be prepared to be putting in an extra effort? f. How would the business model for exploitation & maintenance look like? What would be the pricing for users of the catalogue? g. How is your vision on the development of the semantic web and how would you support publishers and retailers with semantic web support on metadata fields? h. Describe your vision & strategy on enriched & social metadata for the future and how will this help the members of GAU-KBb to compete in the ever faster changing world.In addition please provide a test user account of your title catalogue, both from publisher and retailerperspective, to Pieter Ruempol, as to test several of the use cases through objective users externally.RFP Dutch catalogue, version 1.0, October 2011 Page 22
  • 23. Use case 1 Registration & feeds a. Demonstrate how you would import current book data and clean up all the field and data entry errors? b. Demonstrate how & which protocols are used to guarantee consistency of the registered metadata c. Demonstrate how the different (enriched) catalog elements can be registered and how a distinction can be made between the different contributors of this information and when and how the feed was updated d. Demonstrate available reporting tools and a relevant report. e. Demonstrate available alerting system for the metadata owner when metadata is inconsistent f. Demonstrate how metadata information can be provided via ONIX and via a web interface and delivered via ONIX and a simple format (e.g. Excel). g. Demonstrate how a polling model for metadata would work instead of a push model with a feed for webshops?RFP Dutch catalogue, version 1.0, October 2011 Page 23
  • 24. Use Case 2 Search & FindSearch on author a. Demonstrate how all (available) books (physical and digital) of this author and other information (for example co-author, biography, movies from the book, etc.) can be found (despite the fact that the author name is not uniform)Search on work b. Demonstrate how a work in all its expressions (hardcover, paperback, ebook, audiobook, English edition) and correlated information (for example co-author, biography, movies from the book, etc.) can be found.Search on publisher c. Demonstrate how all available books of this publisher, concerning this tag, (physical and digital) and other information (for example co-author, biography, movies from the book, etc.) can be foundSearch on series and serials d. Demonstrate how all available books in a series or a serial can be found.Search on subject or category e. Demonstrate how all available books on a certain subject can be found or filtered.More developed webshops have their own search engines which can be programmed to present certainresults to the end consumer with more commercial relevance. f. How would the catalogue search engine present the catalogue results to the webshop search engine? g. And how would you offer a search engine for smaller webshops, which they can also program to a certain degree in the white label services?RFP Dutch catalogue, version 1.0, October 2011 Page 24
  • 25. Use Case 3 Maintenance and differentiated distribution of the catalog with digital products a. Demonstrate how retailer A gets all the available data elements in the catalog and retailer B only a designated subset of this information. b. Demonstrate how a retailer can select a relevant niche selection for his webshop and change that any time through assortment management. c. Demonstrate how the maintenance of this catalog can be as much automated and decentralized as possible, taking into account that a permanent (central) consistency check is a must. d. Demonstrate how any user can make a suggestion for amelioration of a data entry and how this process would run to finalize this suggestion? e. Demonstrate (your vision) how a retailer could upload his own tagging or social review data and share that with a restricted number of other retails, possibly with a pricing model? f. Demonstrate (your vision) how a webshop might poll paid content on search bases, such as a pay per review model for journal reviews?RFP Dutch catalogue, version 1.0, October 2011 Page 25
  • 26. Use Case 4 GEU / NBB educatiefThis use case will be supplied by the GEU and/or NBb Educatief in the final version.RFP Dutch catalogue, version 1.0, October 2011 Page 26
  • 27. Appendix 2 Daily irritations retailers current title metadataThe KBb did a short inventory of the top irritations or wishes of the biggest retailers on a dailybase of the title catalogue. This information can be regarded as extra background information andserve as an indication of the importance of correct title data and the processing of new metadataon a daily bases, which have led to the requirements in this RFP. These irritations cost sales on adaily bases, for both the retailer & the publisher, and a lot of extra effort to correct on the respec-tive web shops of the different retailers. The following lists are unedited and are direct input fromthe retailers.Retailer 1 irritations  Book is in stock according to the database and thus can be ordered, but in reality is not in stock (sometimes by wrong information from the publisher)  Titles or authors names are not spelled in a uniform way, and are not found in the data- base (through typo’s or incorrect files by the publisher etc.), especially a uniform way of spelling of names such as ‘Van der’ ‘Vander’ ‘Van’ ‘De Groot’ ‘Groot, de’, etc.  Wrong NUR coding, especially in childrens books, or only with the indication children, in- stead of an age indication  Marketing packages are in the database and end up in the webshop, though they are not meant for the end consumer, but for the retailer (e.g. a display with 10 copies of a book)Retailer 2 irritations  No book description, or inappropriate description for direct publishing on the webshop  No book description in CB online, but book description is available at the publisher  No total number of pages, or incorrect number of pages  Spelling of author names differentiates or is incorrect  Bad quality book cover picture  Book has not appeared on publishing date, but this incorrect publishing date is still regis- tered in CB online  Name publisher appears in multiple forms  Book is briefly not in stock, this affects stock information on the website for 24 hours  E-books, no book description, or inappropriate description for direct publishing on the webshopRetailer 3 wishes  All books should have a book description and cover photo, including back list titles.  Author names should be written in full per book title  Offer preview (first pages) versions per book title  Always register serials and series  Offer temporary sales prices in the logistic metadata  Offer state ‘in reprint’ if the book is really in reprint within an acceptable period, not when it is actually a backlist titleRFP Dutch catalogue, version 1.0, October 2011 Page 27
  • 28. Retailer 4 irritations  No uniform spelling of both author names and titles (titles; especially serials)  Lack of a ‘superisbn’, which makes it difficult to offer the end consumer all possible ap- pearances of a book  Metadata mistakes, such as publishing date  Lack of unique ID for authors, which would make differentiating between authors with a similar name easier and solve spelling mistakes  Identify every form of appearance consequently, e.g. pockets , hardcover, ebooks , paper- back, ‘dwarsligger’, etcRetailer 5 Irritations  Unnecessary spelling mistakes in critical metadata, such as the title (This makes searching for the end consumer impossible)  Registered metadata does not match information in or on the phsyical copy of the book  Incredible diversity of mistakes in the spelling of author names (e.g. Annie M.G. Schmidt the current winner with 14 variations in spelling)  No unique ID in authors, to differentiate between authors with similar names, e.g. we re- ceive a 100 titles of CB, all with author "King, S.", but in this there are 15 different authors with this name and there is no way to determine which titles belong to which "King, S.".  Titles which have a commercial state “To be published”, but with a publishing date in the past  Titles with a very unlikely publishing date, such as 90 years in the future, Publisher wants to enter “2010”, but slippery fingers enter “2100” and there is no system alert to this non re- alistic date.  Invalid ISBN numbers.  ISBN numbers which are in use on other book titles (this happens with eBooks, which reuse old ISBN numbers, which is against the standard rules)  Differentiating tax percentages, other than 6% or 19%.  Book titles without appearance information (hardcover, paperback, eBook, etc.).  Book titles without cover picture or book description, etc.Retailer 6 wishes  All contributors of the book should be identified with an ID number  Books which have multiple editions and formats should be identified with the one ID num- ber; Harry Potter 1 Paperback, Harry Potter 1 ebook, Harry Potter 1 imprint 2, etc  Books in a series should be identified under one ID number; Harry Potter 1 , Harry Potter 2, Harry Potter 3, etc  Books should be categorized with NUR and Bisac  Full table of contents should be deliveredRFP Dutch catalogue, version 1.0, October 2011 Page 28

×