Background Information

Institution Documentation

National Library System Project (NLS/OKR)

Abridged Technical Description

5

5.1

5.1.1

FUNCTIONAL REQUIREMENTS OF THE SYSTEM

Libraries (separately used modules of libraries)

Acquisitions (ACQ)

The task of the ACQ component is to serve the entirety of functions supporting accession and reduction (by weeding) of the library holdings. It assists the following procedures: preacquisition (desiderata management), order, arrival of publication and invoice, handling of budgets, registry of vendor data, claims, admission into holdings, the stock, the administration of call numbers, the use of RFID and/or barcodes.

It is related to the following components: administration of holdings and assets (PRG), query (DRY), cataloging (CCQ), circulation (CIR), supervision of stacks and holdings (WHM), handling of periodical publications (PER), electronic resource management (ESM), and statistics (STA). The module must be connected to the financial system of the library or its parent organization – either directly or via an API. The specific demand of the NSZL is the collaboration with the document arrival system (GTE).

The module has a refined system of authorizations. This can be configured by the user possessing the highest level of authorization. Certain procedures (eg, modification of budget allocations, installation of tables of conversion rates) are assigned to the highest level of authorization.

Acquisitions are conducted in separate fashion per library (member library and branch library) beyond the reach of other libraries. The general settings of the module are mounted at the member library level, for instance, the table of currency and exchange rates (with the use of decimal points or signals), while other settings are available at member library and branch library levels: rules of claiming, setting of budgets, recalculation of allocated budget amounts (in case of rate change).

In the acquisitions module an option must be enabled at the setting of cost centers and at each order item for the differentiation of the purchase price and the so-called estimated value. (In general, the estimated value is the antiquarian booktrade value of the publication and it is needed only when the publication does not carry its price and the order transaction does not have any other indication featuring the price, for instance, a receipt, an invoice, a sale and purchase contract value The money value featuring in the invoice must be separated into net and collateral expenses if the invoice contains the gross price only, with the indication of percentage of the turnover orvalue-added tax. The collateral expenses must be partitioned into turnover or sales tax and other expenses (eg, postage, and packing or wrapping).

Similar to the ACQ module a multifaceted opportunity must exist in the statistical module (STA) for constructing statistics, analyses and reports. The statistics and reports related to acquisitions must be configurable and their content adjustable by library as well as regarding all the libraries operating in the entire NLP.

In order to administer the library holdings as assets and possessions, there should be an option linked to items to record the codes and code groups necessary for the accounting management and to retrieve items and print them into file or on paper according to the specific codes.

In every procedure where the module has to communicate with an external partner it is an option to install boilerplate text (eg, letter of order, claim letter) in diverse languages; when the procedure is set off the system will offer the version of the language that is installed in the vendor data as a ’language’ setting. The default is Hungarian.

The registry of vendors is able to operate both at the library and the central levels so that aggregated anyalyses and reports with respect to vendors can be composed at a later date. Upon recording the vendor data the system must perform a check if the vendor already resides in the system or not (even at other libraries) and present an option of taking over existing vendor data to the given library. The control of duplicate records can be configured. The duplicate control does not exclude that the vendor may have different data in the local list by member library and branch library, yet the prime aim is the costruction of a common stock of partners, no matter what differences there can be. An option must be present for query per vendor, for administration of the total value of items procured from the individual vendors (eg, for recording of exchange of publications), for exporting vendor data to other databases. The system should ensure through the statistical module the examination and analysis of the vendors at the library and the NLP level alike.

The system supports the procurement of all types of library documents, including online and offline electronic documents as well.

A new order item can be drawn up from the data directly loaded by the vendor (for instance, following an internet-based offer), from records already existing in the catalog, from data transposed from other databases by direct data capture. If the record of the document to be ordered does not occur in the catalog, its description can also be initiated from the acquisitions module.

The module handles the bibliographic records made for the purpose of preacquisition (proposal for procurement, desiderata), with the option per member library to display the desiderata records in the public catalog or not. The proposals for procurement can be made up not only with privileges related to acquisitions. The acquisitions librarian should automatically receive notification of the arrival of a new proposal for procurement. There must be an opportunity to create a desiderata list, to be written in a separate file. Of the

endorsed desiderata an order item should be created.

The module treats the various types of order (individual order, list of orders, standing order, approval, etc); the various modes of acquisition (purchase, exchange, gift, deposit, own fabrication, etc.); the various types of payment (invoice, advance payment, gratuitous, etc.). It enables the suspension (cancellation) of the order. It can handle in a unified manner the data necessary for the order item from the linked bibliographic records (common data and volume data) of multivolume sets and other documents.

It is possible to append or tag remarks of non-bibliographic type to the order item which can optionally be printed out for the order. (These are not part of the bibliographic record describing the item.)

When saving the order item, in the event of incompatibility, the system must send an error message. For example, if the mode of acquisition is ’purchase’, then it cannot have a ’free’ type of payment attached to it.

The items of order can be printed one by one or in a list, or can be written into file. They can be sent electronically, directly from the acquisitions module.

Cancelled orders, the list of vendors and cost centers can also be printed.

At intervals set in the rules of claiming the system is able to set in motion the claiming procedure: automatic notice on the necessity of claiming. The order items sorted for claim can be listed written into file or printed out. It can be set by library that the unfulfilled orders are deleted or preserved.

It must be possible to shape up flexible workflow processes on the basis of those described in the workflow management module (WFL). There should be an option if required to ’skip’ certain actions of the ordering procedure (eg, in case of bookshop purchase the creation of a desideratum is not needed nor is the launch of the ordering process and, by skipping these the publication can be checked for arrival, admitted to the stock holdings and the invoice can be handled).

It is possible to check the arrival of copies in numbers less than the ordered quantity, the order stays ’in progress’ until arrival of all the ordered copies, or it can be terminated with modification of the number of copies. The checking of arrival can be withdrawn (in case of a mistaken arrival).

The arrival and ’payment’ of incoming invoices is interconnected with the maintenance of budgets. At the time of arrival of the invoice there must be an option to administer divergences between the price of order and that of the ivoiced one, and the budgets must be recalculated according to the invoice price. It is an option to admit electronic invoices too. It is an option to print an ’invoice’ drawn up in the system. Following the admission into holdings – with the option of setting per library – the invoices completed with the inventory

numbers are to be printed on paper or electronically sent to the fiscal section of the library or its parent institution. The system must ensure the protocols of data furtherance and data acceptance toward the libraries’ financial systems via standard conduits or pipes which can be configurable.

Ensuing the inclusion of the data in the inventory registration of the holdings there should be an option to archive the fulfilled orders and paid invoices, the archived records can be viewed without the system librarian’s assistance by authorized users. The archived order items can be printed into file or on paper in a configurable way.

In the event of non-accomplished orders or payment default the system must handle the credits/encumbrances (debits/credits).

The module must enable the administration of inventory numbers and call numbers or topographical location numbers and their automatic allocation to incoming publications. There should be a registry of more such identifiers: inventory number, call number, temporary call number (in case of free shelf). The identifiers can be printed on labels or into lists. It is also a must – if need be - to print the RFID and barcode onto a self-adhesive label and to fix the barcode of a preprinted barcode label.

In a configurable way per library and per branch library, the module makes possible the inspection of the holdings and item information: it keeps track of what happened to a particular item (who, when and in what way altered the item record), it can produce a report on the totality of item data belonging to one title (how many copies belong to a given title in the holdings, is there an order in progress on it and was it recommended by someone for procurement).

In the module the ’ordering’ of binding (protection of holdings) or digitization of the copies can be handled.

The bibliographic record and the item status (eg, at the bibliographic record: desideratum, ordered, claim in progress, in processing, processed; at Items: on binding, in digitization, misplaced, lost, to be deleted) must be displayed in a unified manner in each module. The retrieval and listing of items can be performed on the basis of status.

To the module’s highlighted data contents and records files can be assigned (eg, scanned invoice, etc) the existence of which must be indicated to the user in the form of an icon and enable the opening of the attached files with the management software preinstalled and associated on the user’s working tool.

It is possible to print a variety of lists into file or on paper. Such as these: accession list on new procurements (with configurable content), list on copies found missing in the holdings supervision or according to the RFID or barcode; list of deletion from the data of designated copies in case of holdings diminution (with configurable content, etc.).

5.1.2 Management of Periodical Publications (PER)

Logically, the module is a submodule to the ACQ which is to support the following major functions: ordering of and subscription to periodical publications, their arrival claim, collation (arrangement into binding units), binding, the handling of electronic publications, the detailed administration of holdings of periodical publications.

Here we take stock of the requirements that, beyond those written in the ACQ module, specifically apply to the handling of periodical publications.

When periodical publications are ordered, the initiation of a subscription should be ensured as well as their renewal without the need for making a new order item. In the order item related to subscriptions an option must be present to keep track of changes occurring in the data of the subscribed periodical publication (eg, material changes in the bibliographic data, in the periodicity of appearance, in the number of partial units belonging to one volume.) The duration of the subscription can be set. The subscription can be extended to several libraries with the apportioning or sharing of the costs.

It is enabled to order individual issues, partial units as well, even retroactively, regarding individual or several part units and volumes. The retroactively ordered and arrived issues should be inserted to the copy data belonging under the given volumes, without issue-by- issue check-in.

To support the subscription of periodical publications (via public procurement) it should be configurable to print lists narrowed down to branch libraries and arranged by vendor.

In the case of electronic journals a connection must be ensured to the electronic resource management (ESM) in a manner that the financial management of the subscription must take place in the PER module. In the event of database subscription an option must be for the batch or bulk upload of records and their bulk deletion. With respect to the electronic sources and databases it is possible to perform temporary acquisition, access purchase and handling of license invoices, that is, to handle subscriptions without check-in of partial units and their admission to the holdings.

To one order item several cost centers can be allocated and thus to share the invoice among cost centers or among libraries. To an order item one can assign a location site in case of multicopy orders.

Schemata of arrival, ’cardex sheets’ can be created according to the installed periodicity. The system must hearken to the expected arrival of the component units. It must spot the unarrived units and give a warning about the necessity of claim according to the set rules of claiming. It is possible to compile lists of non-arrived issues and the claim can be forwarded electronically to the email address included in the vendor’s data.

It is required that the system be capable of arriving and handling special and unusual part units (merged or conracted issues, combined volumes, year-spanning volumes, transient,

special issues, irregular issues).

It must handle copies of the same periodical publication simultaneously acquired from various resources.

It is capable of contracting copy data of the arrived part units into one single item record; of displaying the holdings data in harmony with the contraction in every module, the catalog included. It can break down the merged volume on display into binding parts, then into issues.

In the module, the binding units are definable and modifiable. The binding instructions belonging to the individual units can be captured. The volumes and the binding units do not necessarily match (from one volume several binding units can be composed, several volumes can be merged into one binding unit). If need be it must be able to handle issues of different periodical publications. It must support binding procedures, such as transforming item data into units of binding and, pertaining to this, the handling of the RFID or barcode. It should be possible to assemble binding lists.

The module must help the weeding of periodical publications, by means of lists drawn up from items to be eliminated from the holdings, and, in addition, it should be able to automatically delete the holdings and copy data of discarded titles, volumes, part units. Also, lists for circulation and lists of surplus or redundant copies can automatically be compiled.

Statistical data on usage of the periodical publications can be retrieved by means of the statistical module (STA) by different aspects (eg, by the number of loans in case of circulable periodical publications) and the compilation of analyses and reports can be generated.

Data of the periodical publications can be retrieved according to various aspects, as, for instance, types of acquisition, vendors/publishers, budgets. The number of claims relating to individual journals in a given interval can be queried. The running of the associated reports can be initiated either at central level or in a manner including several libraries.

The module must ensure the automatic adjustment of item data of the publications to the bibliographic record in the catalog according to location code.

5.1.3 Control of Stacks and Holdings (WHM)

The task to be carried out by the support of the component: the checking and supervision of the existence of copies recorded in the registry of library holdings. The component, therefore, is to warrant and automate the workflow processes of holdings control. A precondition for realizing automated holdings control is that the copies have individual barcode or RFID label in them and the codes figure in the catalog as well. In the course of supervision the identification data of copies can be fed in in batch with a barcode collector or RFID reader, then the batch loading of the identifiers from the created file, and the data of a selected set of documents (a particular location or document type) can be inspected in

bulk. In addition, an option must be enabled to enter or key in the holdings by copy and, on the basis of identification data of existing copies, to inspect the data by location and holdings unit.

Upon entering, an error list must be generated by collating the data of copies and those of location concerning documents belonging to a misplaced spot of stacks or improper range of call numbers. The data content of the error list is configurable. It should signal copies spotted in the course of the feeding in and deleted earlier.

The data of missing copies are to be gleaned in a separate list. The data content of the error list is configurable, editable, printable and exportable. A list of deletions can be made up from the error list.

When RFID is applied, it is an option to locate a lost (not found in its location) copy by means of an external scanning unit according to identification data.

It is set that during stacks and holdings control the system must not automatically handle the copies not found in their locality as missing but it is to follow the status changes of the copies, the final or temporary restriction on their availability (eg, deleted copies, copies in binding, on loan, on hold). The copy statuses and restrictions of availability can be configured during holdings control, then the settings can be erased.

The WHM component must be closely related to the PRG component. According to the assembled data, the date of holdings control, the code of the performing person must be visible at the item level. These should be handed over to the software component, to the registration of holdings and assets. The program for stacks control must amalgamate the quantity (number of pieces) and value of the missing documents.

The control program can handle the periodical publications, that is, the specialities thereof that a library unit is composed of several portion units.

To the holdings control program there must be attached a query program allowing for a multiple-angled retrieval which helps select the holdings portion designated for supervision (eg, search or query of date of admission into holdings according to initial and final date, location, selecting stacks locality from a list, search for a given document type, for a given range of call numbers).

It is possible to collate and compare data of documents located in the stacks and the holdings processed in the database (catalog) with a mobile tool.

5.1.4 Registration of Holdings and Assets (PRG)

The component must ensure the inventory administration of the entirety of the library holdings as well as the assets administration of cultural possessions belonging to national property from the library holdings in a form complying with the library’s balance (registry of accounting). The component must be closely related to the ACQ, PER, CCQ, and CAT

components.

Pursuant to the valid Hungarian law (3/1975. KM-PM joint decree) the holdings registry is an authenticated and certified document-like inventory recording which is to be realized primarily in electronic form. Its content: account in timeline of what document was procured by the library, when was it acquired from which vendor or other institution, private person etc, in what mode of acquisitions (purchase, exchange, gift, deposit, etc,) and for what price. The inventory record must show the aggregate value of the holdings and the number of pieces of library units. The holdings registry (inventory recording) must be conducted from the entire library holdings and from every collection.

The data of the library documents necessary for holdings registry are fixed in the acquisitions (ACQ) and periodical management (PER) module as well as in the cataloging (CCQ) module. It is a requirement that the data recorded upon acquisition be preserved after the closing of the acquisitions item. A receipt can be generated of the inventory data row which should be preserved in authenticated form either in a database or in another, electronic format. On the increment of the inventory registry a printed list (’inventory book’) can be produced at determined periods of time (eg, at the end of the year on the period between the first and last day of the year).

The purchase price and the so-called estimated value of the documents should be detached and manageable separately in the acquisitions module and in the holdings registry. The purchase price is related to the documents procured via purchase to which an actual vendor invoice belongs. The estimated value is related to modes of acquisitions behind which there is no transfer of money (exchange of documents, gift, deposit copy). As for a document adopted into the holdings in one of these modes, the estimated value of the publication can be the commercial price printed on it, or the basis of its determination might be the value in the antiquary trade or a price reached at auctions of similar documents. The purchase prices and the estimated values must be kept in separated columns in the inventory registry.

In the acquisitions module and in the holdings registry an option is enabled to break down the gross sum if needed into net purchase price and VAT (ÁFA) and costs of delivery (expenses of packing and/or postage).

The Hungarian legal regulations in force (Act CXCVI of 2011 on the national possessions, Act CXCV of 2011 on public financing, Govt Decree 4/2013 on accounting of public finances) prescribe that cultural treasures recorded in the collections of public institutions (libraries among them) maintained by the state or the local government belong to the national property. The library documents of antique value classified as antique must be registered as national property (in the case of OSZK the archived deposit copies as well).

The holdings parts belonging to the province of national property must be administered in a way in harmony with the detailed analytical registration of the balance prepared according

to the accounting regulations. The professional registration of the library (the inventory registry of the holdings) qualifies as a detailed accounting registration if its data contain also the data mandatory according to the above government decree. However, the items belonging to national property must be distinguished in the library holdings registry. Therefore, the group-forming codes or identifiers to be formed in the inventory registry should be able to separate items of national property from the other items.

The group-forming codes or identifiers are well-advised to be placed among acquisitions data or in the copy record, but whichever is their place, they must get into the holdings registry. The earmarked items must be searchable according to the codes or identifiers, and their detached appearance in the statistics must be ensured.

It is not only the data recorded during acquisition and cataloging that must be present in the holdings-registration tool/database, but the entry of data arising at a later phase must be secured in the registry. Such data are to be entered to the individual items when, for instance, they are discarded from the holdings, switched over to another location of the collection, received a new call number, were selected for holdings control, etc. It is necessary with respect to national property to keep a record, pursuant to the requirements of balance administration, of the value of manipulations of material protection (restoration, binding work, etc) done to the library document. On account of this, the authorized librarian handling the holdings registry tool/database should have editing privileges as well.

The holdings registry is administered by each NLP member library separately.

5.1.5 Library Administration (LMA)

The LMA component is the aggregate of all functions which constitute the library administration. Here belong those technical functions, too, which enable the setting of specific mode of management of the libraries within the NLP.

The LMA component is the administrative layer of the NLP member libraries. Here you can fix, in addition to the basic data, the structural layout of the given library and determine the policy of the library and handle the various privileges/access rights.

The component is in close connection with the CAD, UAD, and USM components.

An important requirement is that the system should enable a wide variety of configurations and parameters for the workflow processes, services and user interfaces handled by the various software components (modules). Our expectations of configurations in terms of the individual components are found in the list of requirements of the respective components.

The structural buildup of the library must be precisely mirrored so that a refined and granulated system of authorizations and privileges can be deployed. The structural hierarchy of the library must be maintained. Some parts of the hierarchy are to be registered in the CAD module as well: in order to operate the interlibrary loan services (ODR system) the

registration of libraries of complex structure should be at least at four levels. In the case of libraries with more sites and locations and branch libraries each place of service must appear with its respective data (eg, opening hours).

The LMA component handles the users’ privileges/access rights. The privileges are hierarchic, which means the privilege of higher level is allowed to perform activities assigned to lower-level privileges. Apart from the levels of privilege built into the system there must be an option to define and assign new privileges centrally as well as per library. Every activity can be assigned to the users. It should also be possible to establish spheres of role: the individual privileges can be stuck together corresponding to the individual single user scope of work and at the same time allocated to users. The single user privileges can be restricted ensuing from the structural hierarchy of the library (eg, they can borrow at certain places of service), or within certain workflow processes (eg, in the course of cataloging those engaged in formal description have a different privilege from those doing subject cataloging meaning that specific fields are edited by either group. The user identifiers must be unique together with the library’s identifier.

5.2 Users (modules at library – user level)

5.2.1 Circulation (CIR)

This is the totality of functions ensuring the circulation of library documents and the administration associated with the loan service. Characteristically, the component is at the library level which means that the NLP member libraries can use it separately and independently. It is coupled to central components such as the users’ central authentication system (USM) and the common catalog (CAT). The component supports all duties and tasks of the given library with respect to circulation. It couples with the LMA, UAD, USS, CLC, and PAY components.

Each working process needed for the circulation transaction must be manageable. The allocation of librarians’ privileges can be configured and, on the basis of this, the workflow processes and executable operations can be set. The system of authorizations and privileges should be multifaceted and multileveled: they can be allocated fixed to the competent structural units of the individual libraries and library structures (branch libraries, sites of services).

The rules of circulation and document distribution, the patron categories and the pertinent privileges, the settings related to circulation can be determined with the appropriate authorization: the number of loanable documents, duration of borrowing, renewal, sanctions ensuing delayed return (warnings, charge of delay, legal measures) hold requests, maintenance of opening and closing hours.

The creation of patron categories should be configurable: eg, the library and/or library

subunit of registration, the library/subunit concerning loan transactions, patron type, patron privilege, document type concerning loan transactions, maximum number of documents to be borrowed/placed on hold simultaneously, financial matters, etc. The limits to load/hold must be automatically tracked by the system and it mustn’t allow exceeding the limits.

Patron identification should be at multiple level. It is possible to join national authentication systems. It should be enabled in the NLP system, depending upon configuration, to register patrons applying for the overall NLP system which enables the patron – relative to their privileges – to log in to several libraries with the same username. The central user authentication system assigns unique, unalterable identifier to the patron and by virtue of this the patron data can be registered in the individual libraries. The patron data can be altered by the authorized librarian. Deletion of patron data can be started only after inspection, with certain conditions (deletion is not allowed if the patron has loan, hold, ban or money debt). Deletion is possible only for a given library, the patron’s data and identifier registered in the central administration are retained. These are deletable in turn if the patron does not have a loaned document in one single library and they have not resorted to the service of a library for a determined period of time (x years).

An option is enabled to register or delete a sponsor to a patron, to record the data of the sponsor. (Sponsor: patrons without independent earnings – typically children patrons, school-aged readers and students of full faculty in higher eduction - on behalf of whom the sponsor takes financial responsibility).

An option is possible for centrally managing the data of institutions with circulation capability.

The authorized librarian can display the loan transactions of the patron, their contingent debts, per library and per library unit (service site). The system takes into account the validity of the registration at release/loan, hold and renewal of loan time. At loan and at return, the authorized librarian should be able to alter the due date or return date given by the system.

The system must be able to administer the release/loan and return and, according to the installed conditions, the renewal of loan, the placing of hold on a copy in loan. The setting in association with working process of the hold and preparation of the document is configurable and there is an option to place a hold on a copy or a work (title). With respect to hold there is an option to give the validity of the hold, the place of pickup, the mode of use (loan, reading room usage). It is possible – relative to librarian privileges – to enter or alter item data in the process of circulation.

The release/return is enacted with the entry of the barcode or the RFID code of the copy item, and the manual feed-in of the necessary data is also possible. Upon return it is possible to print the return receipt or to send it in email.

The system, according to the settings, should charge delay fees at the time of a belated return, taking into consideration the opening hours of the given library or service site. The handling of transactions related to a lost book is possible by the system.

The librarian can execute the operations in association with the patron’s debts (deletion, alteration of the sum, registration of the payment, the handling of instalment, etc.). Also, it can handle the prohibitions and bans related to the patrons.

The notification related to the patrons should be configurable (notices, warnings, reservations, etc.). The retrieval of patrons to be warned is configurable, the generation of notices as well as the manner of sending the letter.

A fundamental requirement with respect to the circulation component is the handling of the copy data and the tracking of the copy statuses (on loan, on hold, etc.).

The system must provide the patrons with the execution of certain loan activities in self- service (issuance, renewal, hold request, launching of stacks request). The patron who logged in online should be able to view their patron account (eg, actual loan data, pending holds, dues, etc) (see also USS component).

The movement of the documents within the library should be registered with the assistance of the software component: the transfer and traffic of documents between the stacks and the reading room as well as the internal loan (request of copies from stacks to offices of the librarians). The reading room loan should appear in the patron’s list of loans similarly to a genuine loan.

It is possible to determine the charges that can be imposed on the patron pursuant to those defined in the circulation policy (registration fee, reservation fee, overdue fee, reimbursement refund of lost documents, postage, reimbursement of lost and valid patron reader card). The system must create an invoice of the fees to the patron and to the accounting.

An option must be enabled to query the loan data with a variety of viewpoints and to assemble statistics and analyses related to loan and document usage. The queries related to loan transactions must be configurable.

The more relevant requirements specific to the NSZL in relation to the module:

It can be configurable that how many loan requests can a user initiate, according to his or her category of privileges and by document type at a time or within a given interval. Upon submission of a request from stacks the system can handle how many requests are allowed for a patron with a patron card marked A, B, C, D to submit.

• The module can be connected to the library’s admission system. The module should send a signal to the admission system that the patron is not allowed to leave until a document is charged on them. The module should send a signal to the admission

•

5.2.2

system that the employee is permitted to take the book out of the building. The module and the admission system should signal if someone with a document with an expired permission is passing through the gate.

The system must handle that the patron may possess a document hold. If it is on hold, the gates must allow it to pass. The system can handle that a user is allowed to simultaneously have daily requests (requests from stacks) from different types of documents, holds at several locations (special collections included) and loans at the Special Library of Library Science in the building of the NSZL. The system can handle that multiple types of documents are put on reserve.

User Management (USM)

This comprises functions dealing with the general registrational and common central privileges of users of all levels of the entire NLP. A central identification system of the users should be related to other identification systems (eg, EDUID, NIIF federation containing data of high schoolers), and it must utilize the personal data figuring there for the identification and authentic registration of the patrons/users.

5.2.3 User Administration (UAD)

This is the entirety of the functions related to library level registration, library level privileges and library relations of the users affected in the system (patrons and staff members as patrons) as well as the actual state of fees of loans and services. It is closely related to the Circulation (CIR) and Library administration (LMA) modules.

5.2.4 Users’ Self-Service (USS)

The component contains system elements concerning the definition and realization of operations executable by the patrons. First and foremost, it provides convenience services to remote users.

It is an expectation to allow online registration for the patrons The logged-in patrons should reach their own surface where they can get customized services. On the patron surface it is possible to set individual parameters and to preserve the settings.

On the patron interface, in the user account the user is allowed to reach the related actual data (personal data of registration, password, contact data).

Services available on the patron interface for registered and logged-in patrons: online renewal of library membership, display of loan-related data, renewal of due date of loans, document request (request from stacks, interlibrary loan, proposal for procurement) fixing of holds on loaned documents, request for reading room reservation, loan of ebook, order of various services (eg, photocopy request, topic alert, SDI, RSS feed), online payment of registration fee and those of services etc. The patron should be enabled to an optimized

query and export of archive data related to services utilized (eg, documents used as a registered patron in a given period, money movements in a given period).

The user can establish an own library (virtual bookshelf) where they can handle their list of readings, can share it with others (eg, in learning systems, on social media pages) and export it. They can save the lists of hits received as a result of queries, send them in email, print them into file, preserve and alter the searching strategy. The search history can be stored and former queries can be reselected and viewed again. The patron is enabled to label, add or remove labels, and to search in the list of labels.

On the patron interface it is an option to order services bound to end-user approval, eg, newsletter.

The patron interface should provide an opportunity for communication between library and patron (email or chat), as well as a communicational tool for the patron with other systems (e-learning, systems of higher and public education, e-government systems, etc.).

5.2.5 Customer Relationship and Communication (CLC)

The CLC component is an assembly of functions which secure every element of the communication between end users (patrons) and the system’s professional users (librarians). The elements and forms of contact and communication should be configurable. Principally, the communicational elements are forms suitable for electronic contact and relationship.

In order to initiate and maintain contacts it is necessary at the patron’s authentication to complete patron’s data with required elements like telephone and email address. Also, the language of communication must be provided among the patron data. The surface of communication is to be shaped in a manner that upon patron login it is either in English or in Hungarian depending upon the default language. The choice of language should comply with the default even if the librarian initiates the contact. The system must allow for forming a surface and communicational tools in other languages as well.

An important element of communication is the handling of user feedbacks. User feedbacks, questions and requests as well as responses given to them should be recorded and registered.

From among the forms of communication email is the default one, but the patron has the option to prioritize his or her favorite form of communication: email, sms, Facebook message. The messages sent to patrons must be logged and the log is handled by the librarians.

There should be unconditionally sent messages, pushed messages which the patron cannot refuse and ones that are invited (or suppressed) by the patron (eg, list of new accessions). The timing and text of messages to be sent to patrons can be separately handled by library,

and the sender’s name and email address can be supplied by loan site.

In certain cases the system should automatically send notifications to the patron, eg, an email of warning about approaching expiry of the patron card, about approaching due date of borrowed documents, a notice of overdue loan if the patron has not returned the loaned document.

The sending of a circular or newsletter is possible to which the patron is to subscribe. The theme of the circulars or newsletters may be, for example, library events, documents recently procured, etc-. A similar role is to be performed by the news channels (RSS/Atom XML, HTML, in email format).

A chat service must exist. The patron is permitted to write a message to the library they are registered at. The incoming message is to be answered by the currently online librarian who will continue the exchange of messages with the patron. These exchanges of messages are logged.

There should be a mobile application created for the intercommunication of patron and library which can be handled by the patron according to their settings.

5.3 Modules used by the libraries as well as by the central services

5.3.1 Statistics (STA)

The STA component serves the production, collection and display of statistical data related to the use of NLP and various services of the library as well as the compilation of reports and statistical analyses drawn upon statistical data. It is a requirement that the module operates separately per library yet with a common catalog. Also, it must turn out statistical data with respect to the usage of the ODR system (interlibrary loan) and other central services.

The statistical component too must contain a variety of user authorization levels. And in this component the user interface should be user friendly, customizable, and graphic.

The statistical queries and output definitions can be configured and preserved so that the member libraries of the NLP can utilize each other’s statistical settings and patterns generated for statements.

An option is present for easily defining the creation of scheduled (daily/weekly/monthly) statistical statements. These timed jobs must be executed at determined dates by the system and the output should be conveyed to the authorized librarian. It is anticipated that no programmer competence or help from the informatics expert is needed for the generation of such statistical outputs and these can be created and run by the librarian administering the system.

Within a designated time-frame (eg, daily) the system must save the momentary values of data intermittently variable so the trends can be examined. The range of data involved in the

save can be determined. The data thus collected can be queried and retrieved as well.

Apart from the prebuilt queries there must be an option to define ad hoc queries and, if need be, to preserve the definitions and to reuse them at a later date.

The retrieved data can be printed and saved (in pdf and csv formats). The data of the statistical module can be exported into table-managing (eg, MS Excel) formats. The statistical component is capable of producing charts and diagrams from the queried data and the charts can in turn be exported into office programs. It should be possible to generate reports and accounts with configurable content in a wide variety of selectable formats (csv, excel, word, pdf, MARC, MARCXML, etc.).

The opportunity to create statistics is an imperative as far as all the components are concerned. For each workflow a statistical query can be defined. There should be statistics made on data of acquisitions and documents procured along varied aspects, on the usage of holdings, on the use of the catalog, on the number of bibliographic and authority records to be found in the catalog (by determined viewpoints and time frames), on registered patrons, on data concerning circulation and interlibrary loan, on transactions – also along a number of configurable viewpoints, on the usage of electronic sources with expenditure analyses, on the use of digital collections, on remote use, etc.)

5.3.2 Digitization (DIG)

In the National Széchényi Library a remarkable volume of digitization activity has been carried out over the past years, but simultaneously with the establishment and buildup of the National Library Platform (NLP) there are developments in the area of digitization as well which will result in a significant increase of digitizing capacity.

Digitization as a self-standing module cannot be identified, yet on account of its insertion and adaptation into the process as well as its integration into partial elements it is important to highlight the seminal correspondances.

Within the National Library Platform (NLP) it is first and foremost the ACQ and CCQ modules where the documents described in the catalog can be earmarked and flagged for digitization demand. This demand can be individual (as a service required or perhaps paid for by the end user) or group-based (eg, on bibliographic grounds or according to the hit list of DRY search). It is expected of the National Library Platform (NLP) that the state of documents thus earmarked for digitization can be traced during the process management of outside (non- NLP) application. At the end of the digitization process there are functions for linking the produced digital objects to the catalog entries.

The libraries using the National Library Platform (NLP) are allowed to see each other’s plans, their digitizations in progress and their digitized copies. To a catalog entry several digital contents can be assigned, insofar as more than one digitized version is produced either in

the same institution or in other institutions. These versions can be regarded as a kind of digital copy.

On the basis of the above the digitization is to be carried out by inception in a National Library Platform (NLP) process and, following a technical cycle of measures, it must return to the NLP process so that the necessary settings for linking can be fixed in the catalog. This process can be executed even between libraries as well.

Within the National Library Platform the digitization plans of libraries are to be recorded in a simple environment of project definition and this can be queried for all the libraries of the NLP. Thus, even collaborative digitization projects can be designed in the future.

5.3.3 Finances, Bank (PAY)

The PAY component is a module complying with the valid Hungarian legal regulations which provides for the implementation of different financial and banking operations within the NLP system, per library, per locality or site or places of services separated within it. It is not the same as the system managing the library’s fiscal and economic procedures, yet it must have a direct path of communication to the financial-accounting system of the library or its parent organization.

The component must be closely related principally with the CIR, USS and ILL components (see also requirements pertaining to these modules) as well as with the procedures run by the libraries and granting fee-based services.

Taking the actual technical potentials into account the system must be able to manage bankcard and online payment, the various techniques of payment (EFER, PayPal, bank card, etc.) and to support transactions involving cash-based payments. It can handle remittance payment (eg, Erzsébet voucher, and at the interlibrary loan with IFLA voucher).

The system must be able to handle signals received from the related financial system (eg, suspended transactions, invoices with overdrawn account, sums arrived without any antecedent) and to forward them to the authorized users. The system must give a warning about anomalies related to cashier management (failed closure, failed deposition of money, multiple deposition).

It can produce accounting receipts. It can release a simplified invoice matching the valid legal regulations and store it electronically. It can cancel an invoice that was drafted mistakenly. It should be able to produce and print proceedings related to financial transactions based on a pattern.

The system of privileges concerning the cash-registers and money management must be finely adjustable in granular fashion.

5.3.4 Electronic Resource Management (ESM)

The component herein handles electronic resources to which the library (or a group of libraries) purchases access rights only by subscription. The subscription is usually realized on the encumbrance of acquisition expenditure or purchase of service, but the subscribed sources won’t be admitted to the library’s holdings. The module must handle the electronic sources so that the license fee or the paid service can be equitably allocated to libraries of the joint subscription. The module is related to the acquisitions data (ACQ and PER) detached at the level of individual libraries.

The module can manage licenses concerning the electronic resources either at the central level or at a joint level of several libraries. It operates the notifications regarding the expiry of contracts on the basis of those written at the workflow management module (WFL). The electronic resources (’knowledge base’) are to be managed per library (or by a group of certain libraries) so that access to fulltext content is warranted to the end users (patrons) via the relevant service provider. The module enables the recording, storing, options for alteration and query of data describing the access to user guides, access data, contracts and institutions belonging to the sources or services.

The system ensures a tool for the provider of subscribed resources to the ongoing maintenance work related to the ’knowledge base’ and to automatically update these content alterations. On the result of updates it must send a configurable notification to the librarian in charge of the particular electronic source.

The access data, contracts and user guides belonging to the resources, services and providers should be kept and stored in a central place for every subscribing library and they should be accessible with the appropriate privilege in order to handle these subscribed services in a cost-effective manner for the NLP libraries. This information ranges to include what services and portfolios are available at which provider and what restrictions (embargo) are in place for the access to a particular title, partial units or articles.

For the handling of subscribed resources a configurable librarian’s surface should be ready in every library. The administration of subscriptions managed in the ESM module must be carried out in the ACQ module at the given library’s level in a way that the ACQ module is capable of handling new types of purchase-subscription patterns (eg, mini-collections with variable content, prepaid license fee, administration and management of licenses and contracts). An option must be present to activate access to the subscribed titles and update the pertinent services from the sources of a given global knowledge base in harmony with the library’s subscriptions. It should be possible for the library to add or delete a local provider, resource or service to the resource base thus formulated, to complete certain elements of the portfolio with local information, to insert and integrate the free sources into the assortment and to maintain these.

To the subscribed electronic resources there should be a definable link-resolver attached

which provides the address of access to the article, periodical and book on the basis of their characteristic features or attributes. On the Discovery interface the registered patrons of the library have access at their hit results to the fulltext documents by means of the link-resolver on the webpage of the relevant provider.

The managing surface of the data of electronic sources should grant an opportunity to compile searchable and browsable lists of accessible journals and books by alphabetic order, discipline, and vendor-provider in which the changes in the assortment can be followed. Also, the list of the library’s printed journal holdings can be incorporated into the list of ejournals generated from the knowledge base.

5.4 Central services (modules in pooled use)

5.4.1 Search Engine, Discovery (DRY)

The DRY component is an assembly of system services that enable query and retrieval in the catalog and in the text content. It is a joint search utility that searches in the common catalog of the NLP and it can arbitrarily be set for other catalogs, (external) databases, repositories and fulltext sources. The query can apply to collections formed within the catalog and narrowed down to virtual databases as well. The system supports the appearance on the semantic web both in a semantic database and in the HTML-pages of a catalog and, also, the appearance on the surface web, which means it displays catalog data in an indexable manner for internet browsers.

The search option in the NLP system should be configurable and customizable in correspndance with the individual librarian’s workflows and functions. Query groups or search groups can be put into shape in the Discovery system by each library and/or library group.

The indexing must be configurable in terms of the following:

• on the basis of what indexes can the end user search on the Discovery interface and the librarian on the interface of the NLP catalog,

  on the basis of which fields and subfields should the indexing be enacted and which index should admit the particular index item,

• a field or a subfield can get into several indexes and by dint of various rules.

  The manner of indexing should be configurable: eg, the article is taken into consideration at certain fields, or ignored at other ones, application of a stop list by language (the dictionary of characters to be ignored from indexing), the handling of lowercase and uppercase, and accentuated characters, etc.

  On the basis of certain criteria virtual fields can be generated from the fields and to and an index made up thereafter accordingly.

The search-tool must ensure a query or an option of queries by multiple aspects and criteria: browse – simple search – advanced search (search-fields can be added) – keyword search – command-language search (CCL), fulltext search. A quicksearch must be ensured too, that is, one-field textual search in all the fields of the bibliographic record.

When making up a query the Boolean operators should be an option. While entering the query the system should display if possible autocomplete suggestions, and ensure text completion on the basis of the index. The query can be generated in a URL as well. Also in the DRY component there should be an option to use a virtual keyboard, to choose and key in characters that are not available on the input instrument.

The search can be filtered and narrowed down according to various aspects (document types, language, date of publication, discipline, resource, etc.) in a way that code-like index contents are selectable from a menu. The options of narrowing can be configurable. On the query page there should appear labels applicable for narrowing down the hit list – and adjacent to them it is automatically shown how many hits will result from the narrowing on the particular label. In the query there is an option for various types of truncation, to word, root, and phrase or expression.

It can be configured what indexes should be included in the advanced or compound search, but in the event of a simple search one should have the ability to choose from 4-to-10 search indexes. When searching for a name the function author and contributor must be distinguished. In a search by topic the UDC classification notation (main table classes, auxiliary subdivisions) should also be searchable.

In the Discovery and NLP system an option must be for browsing – configurably, for choosing the index for browse. One can page forward and back, the number of rows to be shown in one page can be set.

The Discovery system ensures a fulltext search in holdings suitable for this and in the entire record content. Fulltext search and the metadata-based search can be combined.

In the Discovery and NLP system the display can be configured on the basis of a variety of data structures (bibliographic and holdings data) as well as administrational and service (acquisition, circulation) data pertaining to them.

In the Discovery system the character sequences matching the query criteria should be highlighted. One can choose records from the hit list for further operations (download, print, email delivery, etc). A configurable display format should be present for the bibliographic records (brief, full, labeled, card or bibliographic form, MARC code).

The display pursuant to the FRBR model should be resolved. In the list of hits there must be an arrangement by the level of work (eg, identical author and title, but different edition, different display form) and an option to unfold and view the elements of the group if need be. The full display pages of the records should have a permanent URL. It is an option to

retrieve bibliographic data in different formats (eg, marctext, marcxml, marcISO2709, atom, BIBFRAME) by keying the URL into the title bar of the browser.

In the course of the display of hits in the Discovery system an offer should be presented for the patron to reach similar sources. The digital records can be downloaded from the pertinent record if copyright prescriptions permit it.

The narrowing and filtering of clusters of hits should be configurable with filtering choices. The hit lists can be saved even temporarily, in a predifined record format. The lists of hits can be sent via email. The entire set, pages or individual records of the list of hits can be earmarked for download and to this various formats and character coding can be assigned. Upon download the records associated with the selected record must be downloaded as well.

The system must provide a configurational opportunity for determining the deduplication algorithm applied by the Discovery. The system must warrant API-links which grant services applicable to the hit list of the Discovery or certain elements thereof.

There should be an option to configure the arrangement of the list of hits and results in accordance with the criteria suitable for the user and to prioritize or set the rank of elements of the hit list.

The Discovery system can show detailed copy information and, in relation to this, handle the hold requests and reservations. The order of appearance of the call numbers can be configured.

The search engine can communicate with the major systems of citation management (EndNote, Mendeley, Zotero, Refworks, EasyBib, etc.) and export files directly into these. It is an option to export hits and results into RIS format.

The Discovery must ensure multiple services to the signed-in users, eg, access to their list of readings (loan) and certain functions of circulation (renewal, hold request, hold cancellation, etc) and the option to create a desiderata item. On the end user’s surface the patron must have the ability to join the cataloging process – eg, keying in subject terms and other points of access separated from the data fixed by the librarian.

The user interface of the search tool must be fully responsive and must provide the same opportunities of usage on the desktop computer and on a mobile device.

5.4.2 Workflow Organization (WFL)

The expected functions of the WFL module fundamentally correspond to those of a universal workflow tool with the provision that the WFL should be able to cooperate with all the substantial functions of the modules of NLP outlined herein.

The WFL warrants tools for predefining workflow processes which can operate at all levels of

the envisaged NLP model as well as between its levels. There must be an opportunity to conceive and run workflows the single stages of which are enacted outside of the NLP. The definition and setting up of the workflows must rely upon BPMN methodologies.

The WFL warrants workflow-monitoring support technically handled centrally yet logically matching the NLP’s levels of data mangement in order for the currently initiated or automatically started processes to be traceable and controllable.

The scopes of the workflows can be defined at least by the division below:

• Central processes which are built upon common elements of the system and emphatically upon the common catalog and only those users are affected that possess privileges needed for central data management;

• Processes operating between the central levels and a library which typically should be operating in events when the termination or completion path of a process started at the central level is to be carried out at a given library’s level;

• Complex processes when in the running of the process more than one library as well as central-level data management or process cycles are linked together. Such a process is interlibrary loan.

• Processes running within one library where each affected stage of process is enacted within one library or at most with the involvement of the library and one outside participant (see below).

• Technical processes that are carried on between nformatics systems and/or services. Typically such processes are those of data export/import or other batch jobs running without user involvement.

  In the WFL there is an option to set up event triggers. These triggers are tied to certain data recordings or user actions going on in the NLP modules, but it can also be an option to interpret it as a trigger for displaying the system contents (directories, files, etc.) defined outside of the NLP.

  The relationship of predefined workflows and the triggers can be determined within the module. The result of the steps of a workflow must prevail as a trigger for the following step of the process. In the course of the process definitions the conditions of branch-off points can be determined and during supervision expected from the system it must be guaranteed that no inconsistent process definition can come about.

  During the workflow definitions it is to be determined that the individual process steps are enacted by who or by what. For instance, in the course of handling a demand for procurement the recording of the demand can trigger a process of approval which process is made perhaps possible by more participants (approvers), and approval will come off when all the approvers have endorsed the demand. As the implementors (participants) of the

process steps can be programs too, it should be possible to define processes where the agent of the process step is a particular program of informatics or web-based service.

The participants of each of the steps of the workflows can be classified into two major groups:

1. a)  Users who play a role determined for the workflows, the types of users are not the same as the roles. The users by type are as follows:

   • NLP-level librarian users

   • Library-level librarian users

   • Users identified in other partner institutions

   • (Personified) named end users (patrons, researchers, etc.)

   • Anonymous users (users without sign-in accessing the system via the web)

   • NLP-level system administrators

   • Library-level system administrators

   • NLP-level technical users (external programs which effectuate their access to the system by means of personified user codes)

2. b)  Technical agents non-displayable as a user. These can be the following:

   • Programs installed in local server environment running the NLP and prepared for running

   • Programs that can be called as a webservice and accessible with a permanent URL

   • Programs accessible as a webservice through a link resolver

   • RSS-based webservices

     The above participants can be dynamically set up in the definition of the workflow. The participants belonging to group a) should appear in the system of privileges as authorized persons so that the system can concretely determine upon execution of the workflow the user who will be affected in the process step.

     The workflows can be initiated by the user and not only by triggers. As far as the workflow is initiated by the user, then a special protagonist will emerge who is the STARTER (or initiator). In the course of the definition of the workflow the STARTER should be an exceptional role- player so that the steps which at all events are to be executed by it or they should reach it eventurally can be identifiable. For example, when a request for acquisition is brought about by a librarian, then the librarian will be the STARTER, so when the process runs off and every approval has been granted then the STARTER will get notification that its demand has been

approved. It follows, then, that during the running of the workflows the individual logical role players (who are linked via privileges) must appear in the system as actual role players.

During the definition, the WFL is capable of sending forward notices linked to any of the steps to role players determined at the logical level whose factual accessibility should be determined or resolved by the system at the actual running.

It is an option that during definition of the workflows the triggering of another workflow defined earlier can be fixed as a step.

The system must provide workflow simulation in the period of defining to test how the defined process will run off in practice.

The execution of concrete workflows are monitored by the system and, also, reports and queries built upon the logs should be available the running of which, like that of the definitions, is assigned to a special privilege.

5.4.3 Cataloging, Authentication, Qualification (CCQ)

The cataloging module is enabled to allow the privileged user, following a search in the database, to create normal bibliographic, authority and copy records and to modify, print, display or delete them.

It is enabled to perform formal and material description of all types of library documents (printed, electronic, audiovisual, cartographic, musical, etc.).

The cataloging module can handle every entity and bibliographic level.

The tender announcer prefers cataloging relying on FRBR LRM (FRBR Library Reference Model) basis with the use of an editor suitable for generating the individual FRBR levels.

The system can handle the new cataloging standard (RDA) and the bibliographic formats of exchange (eg, BIBFRAME).

The system must have an option, by taking advantage of the fields of catalog structures defined in the CCM module, to generate and alter the catalog records and to control them accordingly.

For the input of bibliographic, authority and copy records there must be a MARC editor which makes it possible to type in, save and store the ever-current MARC21 fields and subfields without the developer’s assistance.

During cataloging the system employs the workflow processes set up in the WFL module and the rules of privileges defined in the CAD module.

It must provide functions of bibliographic and authority cataloging for the participating institutions – an option is present to constitute clusters according to demand by entering statuses (work state, partly completed, authentic, etc.).

Upon saving the record the system must place the record into „not public” status for the librarian and there should be an immediate opportunity to inspect the data in the patron view, as a preview. If the content is acceptable, the librarian can place it into a ’public’ state as a separate function. This function must take account of the relations and links too. Which is to say that if an article is linked to a source publication, then the link too can be set to ’public’ status only after supervision.

The flexible metadata treatment allows the distinction of the creator’s person, library, etc. and to arrange the records into groups by this as well.

It is enabled to perform original cataloging, copy cataloging and to support common cataloging.

The records’ carry-over from other databases, domestic or foreign catalogs is enacted embedded into the workflow. In the CCM module it should support data transfer between determined structures of cataloging according to the rules of data conversion.

The system stores the record identifiers of records coming in from the member libraries established in antecedent systems and returns them on occasions of queries, data export and API-based linkages, since the local pertinent services may be in need of them. This is a requirement also in the case of electronic documents: when digital documents are taken over from earlier systems, the storing and resolving of earlier record identifiers (EPA ID, MEK ID, DKA ID) is a must.

Upon record feed-in, when duplicate records are detected, the librarian should have the following options:

• to add the new record (adoption of the duplicate record);

• to reject feed-in (the take-over without any change of the record already existing in the catalog into the library’s catalog, ie, the utilization and derivation of the common record.);

• to add own extra data (eg, subject terms) in this case with the indication of the library entering the data).

  Apart from the standard publication identifiers (ISBN, ISSN) the module must be able to store and resolve other bibliographic identifiers (eg, RMK, RMNy, VD16, VD17, etc). Moreover, the handling of the identifiers of digital objects is also needed (eg, DOI, HANDLE, etc).

  The system supports the handling of record links (unidirectional, mutual) by automatically generating the links on the opposite side. It is possible too to fix undetermined relations and links. It is possible to formulate record links and relations between the analytical record describing the partial document and the main record describing the source document even if the source of the records is different; by this means it is possible to link up the analytical

records to the access data of the main record and to request directly through the various document-providing systems.

There is an option within the catalog, between the individual entries, to realize an N:M degree links (an article published in a publication can also be linked to its appearance in another publication).

At analytical processes special record links are needed:

a) part document – source document (there can occur a huge number, even tens of thousands, of linking part documents in the case of periodical publications): bidirectional (mutual) relations between article and source;

b) reviewed publication – part document as a review: mutual relations between records.

It is possible to handle several systems of subject headings, to apply ’central’, ’library’ or own subject words and in the course of application the subject system can be augmented; to use different subject system by discipline.

The system enables the handling of classification notations (eg, UDC).

The system must handle records without a copy (eg, common data records, main item of series, analytical items).

There should be a quality control and authentication of the records:

• mutifaceted (degree of processed state, degree of public access, etc) and multilayered (public, partially public, closed, etc) qualification of the records;

• authentication of records after quality control (revision), the protection of the authenticated records of the Hungarian National Bibliography (MNB): the altering of authenticated records must require special privilege;

• the option of syntactic (formal, structural) inspection when the bibliographic record is saved: to filter out elements conflicting with the given standard;

• it must check configurably the non-permitted characters (TAB, CRLF, etc.) in certain fields and filter them out when the record is saved.).

  The deletion of bibliograpic records is possible only after appropriate inspection (eg, no copy data belong to it, no records linking to it, no digital copy belongs to it, etc) – the cause of non-deletion must be in a message (NB: records belonging to the MNB can be deleted only by a designated NSZL staff member with high privileges. The member libraries are allowed to delete their own records, locality codes and copies from the catalog, if there is no other restriction regarding the catalog item.

  Flexible surface of data input, cataloging template:
  • transparent web-based cataloging interface, in several versions (eg, field named,

MARC-codes);

• a web-based surface customizable according to demand for the entry of metadata (eg, mandatory and repeatable fields, default field values, fixed and expandable lists, embeddable namespaces and dictionaries that can at least be queried with a query link in another window, the possibility of copying a filled-in data sheet, bulk or automatic data input/deletion/correction valid to a given field and records, depending on the privileges, with logging. In the event of a human error or sysem defect the recovery of earlier state(s).

It is possible to open more records in parallel.

Tools of aid flexibly helping data input must be at our disposal (drop-down menus, if not too long, predefinable autocomplete relying on a data set, manual data entry with location- sensitive format control, photocopy options for phrase, subfield, field and record – at the creation of bibliographic and authority records.

Character set:

• UTF-8 (Unicode) character set;

• storage of accentuated characters in precombined version, if it exists;

• the use of a virtual keyboard for selecting and typing the characters not readily available on the input device;

• the display of characters in sync on the cataloging template and on the public surfaces (which means there is no difference between the two surfaces regarding the display of characters).

  Display of Records in the Cataloging Module:

  Launching from a menu or by clicking a button on the cataloging surface one can select the record’s display form either according to standards, or in other formats. The possible choice of formats can be configured.

  It must be possible to show the linking records at once on a screen, and, in case of a massive number of links in quantified form too, then by separate opening.

  In case of periodical publications a hierarchy treatment must be present in the display: periodical – volume – issue. In analytical processing there must be a display of the source document in a table of contents-like form: a) periodical publication as a source document -> year, volume -> partial unit -> page number; b) monograph (volume of studies) as a source document -> page number.

  In the presentation the system must take account of the default settings regarding the display of data configured in the CAD and CCM modules (eg, applied system of subject headings, thesaurus), but it should be an option too while on display to dynamically modify

the settings to a particular format.

The display of enriched metadata: additional information beyond the usual metadata that can be assigned to the given digital document (eg, table of contents, imprint, book review/critique, preface/postscript, author’s biography, cover pictures/screen photos, non- standard keywords/labels aiding retrieval, further recommended works, links of related pages/documents, the link of place of origin, informational email address with respect to the work.

The URN address of the digital objects in the catalog record describing the analogous document should lead to the fulltext electronic document.

Authority Records:

The system enables the configuration of the thesaurus search according to the given library behind the appropriate fields of all the standard records (eg, MARC21, Dublin Core etc.) applicable during cataloging.

It is possible to store ’background’ authority records and to update these periodically from an external source (eg, tracking of Mesh versions).

The system must enable the substitute or placholder deletion of authority records in a way that it assigns the substitute authority record into all the links of the logically deleted record.

When an authority record is being created the system takes account of the namespace relationships and supports the generation of author’s data also in the course of cataloging (the creation of the bibliographic record) and not only in a separate workflow. During the creation of authority records the system must examine if the author exists in the catalog. If not, then it should examine on the basis of those described in the Namespace linking (NSL) if the author exists in the Namespace. If there is a match it must generate the author record and the Namespace identifier is to be linked to it. If there is no Namespace match, then it should offer its recording in the Namespace with respect to the actual work of the author by means of the NSL module.

There should be instruments for the authority records made earlier to be easily assignable to namespaces used during the new cataloging. The record import function must operate with the authority records as well. The external link identifiers (eg, Namespace) should be placed in the catalog.

The Handling of Holdings Data:

In handling the holdings data the ’MARC21 Format for Holdings Data’ can be employed.

The system must handle the holdings data at the member library level: creation, alteration, deletion of a copy record; the transfer of the copy to other bibliographic records.

It is an option to produce a full-value copy record as part of different workflows and modules

(cataloging, acquisitions, loan).

Beside the original call numbers the temporary call numbers (eg, labels of free shelving) can be handled in the copy record.

The system must provide various functions (and linking data) for fixing information of holdings protection and its query. It should be possible to utilize these data in the queries of the statistical module (STA).

It is possible to store copy-specific data and comments or notes (eg, specific data of antique documents) in the copy record; to store data needed for their turnover in the copy data of electronic documents (data determining legal, financial, circulation policies, etc.) The vendor should provide suggestions as for the handling of system technique of digital copies and for forming proper solutions of identification.

The system enables functions for storing detailed holdings data of periodical publications in a manner that the data content of the stored binding units can be configured.

It supports the handling of functions of user privileges solved in the USM module that ensures the entry of copy data for librarians of libraries not using the NLP (a request in association with the handling of the central catalog of periodicals is an independent templated input surface for the management of holdings data).

5.4.4 Catalog (CAT)

The central element of the NLP is the module ensuring the functions of the catalog, the jointly built database of libraries. The catalog consists of bibliographic, authority and holdings records as well as reference items. The expectations related to the creation and handling of records are contained in the description of the cataloging, authentication, qualification (CCQ) component.

The catalog records can be displayed one by one, on the basis of location codes per library and it can offer a cluster of records belonging to a location site as the given library’s ’own’ catalog among its services.

The fundamental principle of the common catalog is that the libraries that moved into the NLP should not preferably create duplicate records in the course of current cataloging but complement the already existing records if need be (eg, with subject headings of their own) and assign their location code and copy data to them.

This anticipation, however, will not preclude the existence of duplicate records in the catalog. On the contrary, it is a pronounced wish or claim that a separate bibliographic record by copy can be generated in some of its partial clusters (antique library documents). This anticipation requires from the information system that it have an instrument for indicating duplicate records, eg, by semblance control of outstanding, important data elements. The data elements to be involved in the control can be configured on the basis of

those described in the Catalog-configuration and management (CCM) component. The duplicate inspection must be carried on while the bibliographic record is being created and upon saving the record. In the event of duplicate suspicion the control program should send a message to the librarian and place the suspect record into a work file. Depending upon the librarian’s decision the record to be independently retained is transferred by the system from the workfile to the catalog.

A tool must be present for the ongoing or regular inspection of links (URLs) placed in the catalog records alluding to electronic documents which will send notification to the assigned competent librarian if the link fails to work or when the electronic document is no longer available at the alluded locus.

The catalog of the NLP takes over the role of the central catalog hitherto in operation (MOKKA, Hungarian National Common Catalog) of Hungary’s libraries. The libraries moving into the NLP system which replace their own integrated library system (ILS) with the new- generation library platform and execute every workflow of theirs as a member library of the NLP, ’bring’ their earlier catalogs and databases with themselves. It implies a device is needed by means of which, upon conversion of records from formats used in their earlier ILS to MARC21 format, the records are loaded into the common catalog. This conversion software must be configurable so that it can migrate several input formats (eg, earlier versions of HUNMARC, USMARC, MARC21) into the most up-to-date version of the MARC21 format on the one hand, and, on the other, it can handle the diverse peculiarities or specific properties of data holdings extracted from the ILSs. The conversion of the earlier catalog of each and every migrating library is to be planned and executed individually.

The catalog and other databases of the Library for Library and Information Science that constituted part of the National Széchényi Library yet operated as an independent structural unit building its own catalog in its ILS at the inception of the NLP, are to be loaded in. The conversion of these is not expected from the system’s vendor. The vendor’s task will be the load of the converted data holdings.

It is planned that earlier data holdings of the MOKKA’s libraries are to be taken over to the NLP directly from the catalogs of the libraries, and for this purpose it may be needed to execute the conversion between formats. During loads all records are allowed to be adopted by the NLP, or it is up to the choice of every library how it will handle its records appearing as duplicates in relation to the NLP’s record holdings. The method suggested for the handling of duplicate records is similar to the procedure spelled out above at current cataloging.

The detached administration of antique library documents (pre-1851 old Hungarian documents and foreign ones of Hungarian relation as well as pre-1701 foreign documents is prescribed in a legal provision (22/2005, NKÖM Decree). This function is also taken over by the NLP, therefore, the records existing in the current administration system of antique documents must be loaded. The NLP is to provide a cataloging surface where the proprietor

libraries can catalog the antique documents directly in the common catalog. It is necessary to ensure the option of record upload for libraries which would upload the pertinent records from their own catalog. These opportunities are to be granted to libraries that are not members of the NLP.

The administration in the central catalog of descriptions and copy data of periodical publications of Hungarian libraries’ holdings is also prescribed by law (7/1985. MM Decree). The National Periodical Database (NPA) will operate in the NLP in the way that it is only the National Széchényi Library that is allowed to create a bibliographic record or it is up to its decision to upload records of periodical publications from the catalog of other libraries. The holdings data belonging to the bibliographic records are handled by every library, so a surface or working layer is needed where data input and maintenance can be executed pursuant to the appropriate privilege by libraries that are not members of the NLP.

It is our wish to solve within the framework of the NLP the processing of articles released in periodical publications and studies or papers published in volumes of studies which has so far been done in a mixed manner, in the catalogs of libraries and in separate databases. A part of this processing job is going on in consortial form with the collaboration of libraries and other institutions. Here, too, the adequate surface of processing is to be ensured which can be utilized pursuant to privileges by non-NLP –member libraries.

The common catalog of the NLP must secure the operation of the National System of Document Supply (ODR) the central element of which is the support of interlibrary loan and the administration of the transactions (see ILL component). For this the administration of the petitioning and providing libraries as well as the administration of copies in the libraries which also shows the actual status of copies on the catalog interface. The administration of libraries for the NLP system is conceived to be realized pursuant to those written in the Central administration (CAD) component, therefore the CAT and CAD components must collaborate.

The administration of copy data is going to be solved in the NLP system according to the format ’MARC21 Format for Holdings Data’, but the system must handle those copy data that are entered into the MARC fields 850 and 852 of the bibliographic record.

It is imperative in the common catalog that so-called collections and virtual databases can be built from selected records. There is no limit to the number of partial collections. The descriptions can belong to several partial collections at a time. The partial collections can be bound to the holdings of a member library, but they can span several libraries too. We wish to formulate a virtual database for the Hungarian National Bibliography, the administration of antique library documents, the central catalog of periodical publications, the national article-processing, electronic libraries etc. The record holdings of the individual partial collections can be shown in the framework of a self-contained service.

5.4.5 Namespace Integration (NSL)

In the NLP project the Hungarian National Namespace is established as part of the national system of library profession but not within the framework of the National Library Platform. It is highly necessary, however, that the two systems closely collaborate.

The National Széchényi Library as a national public collection responsible for the production of the Hungarian National Bibliography has a stake in the foundation and maintenance of namespaces. It carries into effect its so-called local namespaces within the framework of cataloging with software running the catalog and in a database. Likewise, the other libraries too handle the name elements belonging to the namespace as part of their catalog.

It is to be accomplished in the NLP that the two systems (Hungarian National Namespace and NLP) can interact with one another via standard protocols. It is expedient if the National Namespace can receive the libraries’ authority records in the formats (MARC21, Dublic Core) used by the libraries.

There is a need for a one-time upload of data existing in the catalogs and databases into the database of the Namespace, then for the ongoing record export from the catalog to the namespace.

Another task is the elaboration of the workflow process by which elements of the National Namespace can automatically be carried over/upoloaded into the central catalog (or can be referred to) during cagtaloging work. While creating the authority record of an author not present in the catalog the system must examine whether the author exists in the Namespace. In the event of concordance the system must link into the authority record the author’s identifier in the namespace. Should the author be still non-existent in the Namespace, the authority record created in the catalog together with the link to the actual work can be handed over to the Namespace.

The content of the National Namespace has to be accessible in the NLP’s Discovery function at the search and display of both the records and the digital contents.

5.4.6 Interlibrary Loan (ILL)

The basic rules associated with interlibrary loan (with the National System of Document Supply) are laid down in a government decree in Hungary (73/2003. Govt Decree) The ILL software component is to be shaped so that it complies in full with the regulations of the cited decree. Essentially, it means that the document supply effected via interlibrary loan must be accomplished on a nationwide level relying on the administration of national locations or sites. This is assisted by the administration system jointly used by the libraries the two main elements of which is the central administration of the ODR’s petitioning and providing libraries and the ever-current copy administration of holdings of the providing libraries reflecting the actual status of the document copies including the specific

prescriptions related to the use of the documents. The central administration of libraries is realized in the framework of the CAD component, the description of their service policy in the framework of the Library administration (LMA), while their copy administration is effected within the CAT component. Thus, the central administration component supporting interlibrary loan must fundamentally be built upon these.

The appropriate privileges to the component are to be fashioned for the librarian users.

The mission of the ILL software component is to cater to tasks of administration concomitant with bidirectional (petitioner and provider functions) interlibrary loan: to help attend to and administer the loan transactions between libraries to secure the loan of documents between two or more libraries, to serve photocopies and electronic copies as well as mediation of interlibrary requests and their full administration. The component must be in close relations, apart from those indicated above, with the UAD, PAY, STA, CLC, CIR components.

It is a fundamental requirement that the system should be ready to handle interlibrary loan, to send and accept requests and documents. The administration, sending and reception of requests between the libraries within the NLP is a vital service, but the system is to be suitable for handling requests from outside of the NLP (launched or received in email, in request template or any other route).

The administration of requests: it should be possible to classify the interlibrary requests into categories (request of location, document request from Hungary or from abroad, photocopy request, can be accomplished in photocopy only, not requested from abroad, local location, etc.) or to forward them to other localities or service sites as well as to delete them.

In interlibrary loan, the document types determined in the circulation policy of the individual libraries are involved, take part, their service or ban in interlibrary loan are indicated by the libraries in a record describing each copy. It is practical if the handling of concrete copies characteristic of the library’s service policy is marked with icons or other graphical solutions on the surface of the interlibrary loan template. It is also needed to ensure the option of photocopy request in the event of document types that are not circulated in their original (eg, reading-room open shelf or the periodical holdings in most libraries) or do not possess independent copy records (journal article, a study in a volume of studies, part of a book). The service layer of the ILL should enable the handling of these photocopy requests and services as well.

To launch an interlibrary loan request the system should automatically place the bibliographic data of documents in the NLP common catalog into the appropriate slot of the interlibrary loan template. It can initiate requests related to documents that are not in the NLP catalog. In this case the system must offer a blank, unfilled template.

The request slip should be configurable, the characteristic features of the request can be selected in the proper fields and from predefined lists: the potential versions of the

fulfillment (eg, in the original, in photocopy, in electronic copy, printout, etc), other relevant settings and notations (eg, only the flagged edition is needed, required from abroad or not, request of price quote before fulfillment). The provider library can indicate the rules pertaining to the service of the document, eg, where is the sent document allowed to be used (eg, permission of reading room use only), in case of a service concerning a photocopy it can be retained or has to be returned, the usage can be prolonged or not, in case of non- fulfilled request the reason thereof.

In the administrative system of interlibrary loan requests the administration of both the petitioner library and the provider library is needed. The data of the petitioner library should automatically appear in the request template. If the request is launched from the catalog on a document to which only one locality belongs, then the data of the library matching the locality should be automatically loaded as well. If there are several localities of the required document in the catalog, the list of the localities must come up so that the petitioner library can select to which locality it wants to send the request. If there are more localities attached to the document, and the first library picked for provision is unable to fulfill the request, there is a way to forward it to another locality. It is an option too to designate a library outside of the NLP as a potential provider.

Every petitioner and provider library must be able to keep track of their requests and sent documents, that is, there is a need to administer transactions of interlibrary loan step by step and to show these. (eg, the bibliographic data and location number/call number, due dates, option to renew interlibrary loan, to place a hold in case of a document on loan, to send notifications and warnings to belated libraries and patrons to register the return and acknowledgement from the provider library, to keep record of unfulfilled requests). The status codes needed for tracking the requests must be selectable from a drop-down list. Apart from the tracking of requests in progress there must be an option to archive closed interlibrary transactions for both the petitioner and the provider library.

The notifications necessary regarding interlibrary loan and dedicated to partner libraries and patrons can be configurable.

The patron is allowed to indicate their claim of interlibrary loan on an item found in the catalog, but they must have at their disposal an online template for indicating a claim for a document not found in the catalog.

If the request concerns a document not found in Hungary, then it can be forwarded to some Hungarian libraries mediating interlibrary loans, primarily to The National Széchényi Library. For the administration of requests sent abroad and received from there the National Széchényi Library should have an own, special ILL interface not public for other libraries.

The interlibrary loan component is to be prepared for making contacts with other library systems (eg, SUBITO, OCLC).

The financial transactions and invoices related to interlibrary loan and photocopy service can be administered. In the loan administration of patrons the expenses associated with interlibrary loan services granted them should appear. The invoices can be administered and the data needed for administration can be configured as well.

The indispensible elements of the ILL component are the statistical data retrievable by library as well as the reports compiled with the utilization of the statistical data, since these are the basis of the provider libraries to get support from the budget as a result of their services in the National System of Document Supply. Such data, for instance, the number of launched and received requests in a given period, the number of documents received and sent in the original or in copy in a given period, by document type as well, the number of documents received and sent from Hungary and from abroad in the original or in replica; copy number of locality requests in total and by patron, the number of unfulfilled requests. The statistical data can be queried also in their national aggregation.

5.4.7 Bibliography Management (BIM)

The aim of the BIM component is dual:

• an option for forming virtual database (collection) in the catalog for the goal of thematic bibliographic services on the one hand. It is a preeminent aim to establish a collection from records belonging to the system of the Hungarian National Bibliography detached from the catalog functions, that is, the records without a copy and appearing only in the Hungarian National Bibliography mustn’t be shown in the catalog. We wish to make the virtual database of the HNB accessible on a self- contained website homepage (the formation of this is not expected from the Vendor);

• the existence of a bibliography-producing function, with configuration options.

  The second indicated aim of the component is the existence of a software tool which, in order to provide various bibliographic (national, local, professional etc) tasks and their information services

  • -  can generate a bibliographic publication from records marked and produced in the bibliographic database (catalog),

  • -  can generate a structured list (ad hoc bibliography) from the cluster of hits produced as a result of a query in the bibliographic database,

  • -  can complement the records extracted from the database for the bibliographic publication with data originating from other sources either by record adoption or by direct data entry.

    To accomplish the task it is necessary that certain operations can be performed by way of

preparing the editing work of the bibliography during cataloging and retrieval.

At cataloging it is a requirement that we can earmark in the database the records needed for the bibliographic service in a data field dedicated for this, or we can glean them in a virtual collection set up for this purpose (for the given publication or service). The number of virtual collections are unlimited, but depending on the aim of the service its content can be preserved and continuously expandable or, in the event of records marked for the periodically released bibliographic publications, following the run of an ’issue’, the collection can be emptied for the material of the next issue.

The records flagged or gleaned in a collection can be extracted from the database at intervals corresponding to the periodicity of the bibliographic service, that is, to load over to the bibliography-producing component where by means of the software the records can be processed in a form matching predefined requirements and published.

The clusters of hits arising during query can also be transferred if need be to the bibliography-producing component in order to compile extemporanous bibliographies.

The bibliography-generating component should be able to perform the following functions with the cluster of records to be processed:

• parameters of the operations: the module is able to preserve the settings created for the permanent publications and services and to run them on every occasion needed. The saved settings can be altered if necessary;

• The sorting of records according to a particular aspect (arrangement in professional groups and in alphabetic order within it, or merely arrangement in alphabetic order);

• The item numbering of the sorted records in harmony with the given bibliographic publication;

• The indexing of sorted and item-numbered records on the basis of various fields (name, title, subject, ISBN/ISSN index, etc) – the index items refer to the item number and not to the record identifier of the database/catalog;

• Standardized display of the records in a predefined and configurable form;

• Following the editing operations (or without these if required) the records are to be entered into a textfile in a form manageable in a text editor, in selectable format (txt, doc, docx, odt, etc.);

• Following the editing operations the creation of publications for online surface (html) on the basis of prescribed typographical commands or in a format allowing for printing as well (pdf).

  As far as the bibliography-generating component is concerned, a prioritized request from the NSZL is the production of issues of online periodical publications published in the framework

of the branches of the current HNB (MNB-WWW).

The component is necessary for the creation of the special bibliographic publications of the Library for Library and Information Science operating in the organization of NLs but also as an independent unit. One of these periodical publications is self-contained and downloadable as an electronic publication, while the others appear as columns of printed special journals.

The information service of the NSZL receives many orders for the compilation of extempore bibliographies which can be of large size depending on the topic and the period to be processed which calls for the generation of a bibliographic product supplied with adequately structured and supplied with indexes either in printed or in electronic form.

The bibliography-generating component must satisfy in configurable fashion the needs of every library joining the NLP.

5.4.8 Digital Collection Management (Digital Repositories) (DCM)

The NLP must support the handling of digital objects, their identification, the formation of collections from electronic and digital (digitized) objects and their service. The handling of digital objects is in harmony with that of the conventional, analogous library documents, taking account of the peculiarities of electronic and digital documents in the workflow process. The module is built upon the OAIS model. It is closely related to the GTE component. The storage places of the archival and service copies per necessity made up of digital objects are the digital repositories. The functions of the module include the version management, the optimal formation of metadata structure to the document types and partial collections, the conversion of metadata into standard formats, firm identifiers and the presence of a reference resolver. There is a need to display the collections of the digital library system as an independent service.

5.4.9 Access Management (ACC)

The component secures the management of profiles of general access which allows for the treatment (creation, modification, deletion) of rules restricting the access to the content of the catalog and the analogous and digital collections. Its obligation is to support the innovation of library content service (e-loan, document delivery, legitimate digitization of works under copyright) and to fix record restrictions associated with objects available via catalog entries and the ensuring of user access matching the rules in the library, on the internet or in the closed network system.

The rules of restriction can be set by the authorized library staff-members. The data needed for the rules can be conveyed by the authorized librarians and persons entitled to disclose data (eg, publishers, right owners).

The technical solution to the restrictions is to be handled by DRM methods. The grounds of rules restricting access can be:

● legal provision
o Act LXXVI of the year 1999 on copyright

o pertinent legal rules and directives of the EU ● license, statement

o Creative Commons (https://creativecommons.org/)

o Open Access
● restrictions determined by private persons, bodies, institutions

o restriction on personal or privacy rights o conditions set from donor
o institution’s business policy

Types of restrictions
● restrictions on data

o the visibility and editability of individual bibliographic data can be configurably adjusted for colleagues and end users

● temporal restrictions

o keep a tab on the expiry of the time of restriction and the automatic modification and dissolution of the restriction (eg, keeping track of the time-limit of copyright and the automatic modification and dissolution, keep the information on access permissions (licenses) updated ensuring the input of data concerning copyright and commerce accessibility and the ability to query these from other systems in compliance with the procedure of copyright clearance supported at the European level (138/2014 Govt Decree on the detailed rules of utilization of orphan works).

o in case of time-based documents the setting of possible duration of broadcasting permitted by copyright.

● spatial restriction

o it is a restriction which fixes the use of an analogous or electronic document to a location. For instance, documents in the collections of the national library can be used only in the library building. It is characteristic of digital objects that they can be provided in service within one or more buildings.

● age-bracket restriction

o as in the case of some documents the access bound to age-bracket might emerge, the system must signal the restriction on age-bracket or age limit at

least in the form of a sign and/or message. ● handling restriction bound to copyright

o The component must ensure that in the procedures of acquisition and processing and thereafter too those entitled can record fix information on the copyright status of the work (under copyright protection, orphan work, public domain) and/or licenses, or Open Access.

• ▪  identification of orphan works in a manner integrated into the workflows of copyright clearance;

• ▪  it is a need to form the option of automated exchange of data with the orphan works register of EUIPO;

  ▪

• ▪  the option of handling documentation on rights ownership and fee collecting with respect to restrictions.

● technical restrictions (limitations to the usage of end users) o In the event of digital documents

• ▪  downloadable,

• ▪  printable/non-printable,

• ▪  a screen capture can be made of the document or not,

• ▪  only a part of the document is to be published,

• ▪  only image of reduced quality, perhaps image with watermark.

● restriction on the copy level

o In case of an analogous document the restriction on copy can be interpreted when one or more copies of an edition is under restriction of turnover for some reason.

o In case of digital documents it must be secured that a publication may be in use in as many copies in the online space (closed network, internet or downloaded form) as is permitted by legal regulations or the copyright holder.

5.5 Central technical services

5.5.1 Service Management (SMG)

This is an assembly of functions supporting the administration and configuration of library- level or central services in the NLP system. This module ensures that electronic or business services can be attached to the system, or to regulate them centrally. It warrants also the

the shaping of tight nesting with determined internal and external

components (eg, ISBN management) in order to keep legal and access data

updated

;

administration of pertinent systems of content management, education support and reference.

The system to be developed is to provide the individual libraries with the opportunity for configuring services of reprography (digital and printed photocopy production) and other ordered ones (document preparation, hold request). in accordance with the policy of each library. The technical parameters of the reprographic services (eg, digital, printed, quality, size, packing, binding etc), the modes of payment (bankcard, PayPal, etc) as well as the manner of pickup (pickup locally, delivery, online, etc.) are configurable.

As a central service the Service managment system should secure what digital objects and data can be accessed from the NLP system by services related to the NLP system. Such services are the content management systems (CMS – eg, Drupal, WordPress, Yoomla etc.), education support systems (LMS – eg, Moodle etc) and publishing aid systems (eg, Open Journal System (OJS), Open Monograph Press etc).

The content services to be realized in the framework of the NLS Project can adapt themselves to the NLP system through the support of the Service management module. This can be the route to the generation of the so-called virtual exhibitions as well. The system’s task is to ensure ways to bring about web-based compilations from a cluster of documents defined by authorized staff members with the help of schemata and stylesheets customable according to needs with an option for posterior editing.

The NLP system has to ensure the collaboration with the major reference (citation) systems (eg, MTMT; EndNote, RefWorks, Zotero, etc.)

The system is able to communicate in a configurable manner with the various frame systems of learning (higher and public education), e-learning and e-government (eg, Neptun, Coospace, Modulo, etc.).

The Service management module should provide a tool for the collation of texts.

The enrichment of bibliographic items (Enrichment Catalog) can be configured even with the involvement of the community (crowdsourcing) (eg, book-jackets, covers, display of topographical data on a map, georeferral, timeline, labeling, table of contents service, text- recording, pattern recognition, associated sources, etc.).

It must be warranted that the user can initiate various services (eg, reprographic order, preparation in reading room, sending, sharing, comment, etc) from a list of hits in a configurable manner.

The system must implement the ’Ask a Librarian’ function and provide tools for the realization of services of professional literature (literature research, theme alert, etc.)

To assist the library information work a database must be set up which will store the patrons’s requests and the responses given to them, enable the allocation of responses

given to earlier requests to a new request and support the organization of the work of the information service (allocation of patrons’ requests to the librarians).

5.5.2 Central Administration (CAD)

In this component the registration of libraries involved in the NLP and those coming into contact with it is enacted.

To handle the component, central administrators are to be effectuated and their data and privileges managed. It is desirable to set up at least a three-layer system of administration: central, library and local (for some partial duties within a library). The component must be related to the LMA component. Every operation and alteration carried out in the system must be logged, and the log should be handled by the central administrators.

The central administration component provides an opportunity for registering the member libraries of NLP, entering their data and maintaining them. Upon creation of a new library a library administrator too must automatically be created and assigned to it. It is desirable that following the entry of the library the data maintenance is performed by the given library’s own administrator.

This is the component where the library codes are assigned which are used by libraries in the common catalog and in interlibrary loan (in the ODR system). The library codes are handled and distributed by the National Széchényi Library and dispensed with.

The component takes stock not only of the NLP member libraries but also the data of libraries providing as well as those petitioning interlibrary loan in the National System of Document Supply. According to requirements of the National System of Document Supply (ODR) the administration of libraries should be of four-level (library – point of service – collection –location) to properly reflect the libraries of more complex structure (eg, university libraries).

It is desirable that the list of Hungarian libraries (http://ki.oszk.hu/magyarorszagi- konyvtarak-adatbazisa) be accessible in the component and an option is present to search, browse and sort the hits in the database. All data of the flagged library should be displayed. The site of the libraries are to be shown in a map and they should be searchable in a map.

This component allows for the NLP member libraries to shape their own image. The vendor of the system should warrant opportunities for configuration regarding the library’s image elements by which an indvidual facade can be produced without programing skills for the libraries joining the NLP. Nevertheless, the entire system should have a unified image.

The component enables the setting and maintenance of central parameters needed for the operation of the other modules (eg, the parameters of narrowing capabilities applicable by the search engine can be configured at both the common central and the library level.

The system allows for the institutions to effectuate services granted at the institution level

according to groups (library groups) as well both in the area of data and privilege.

5.5.3 Catalog Configuration and Management (CCM)

The CCM component clamps together those functions by means of which the settings of the Cataloging module (CCQ) and the common catalog (CAT) as well as their various modes of appearance can be implemented.

As for the cataloging it is expected that the system is suitable for processing library and archival (manuscript department) material and analogous and electronic documents. To ensure this, it must support the application of a variety of regulations and different data exchange formats (eg, MARC21, Dublin Core, BIBFRAME). There should be an option to choose a format for cataloging and a set of elements matching the selected format is to be brought up in the cataloging module. The librarian user can generate shemes saved with their choice and other settings for cataloging.

The system must have an instrument for data conversion between the cataloging structures and support the data carry-over in harmony with the rules of conversion.

There must be an opportunity in this component to set the cataloging surface and to formulate cataloging templates. The topical layout of the cataloging template can be configured by an authorized user without the vendor’s inteference.

In this component the content of all the lists is to be determined that are offered up by the system in a drop-down menu in the course of catalonging for the cataloging librarian so that it can choose the appropriate value. It should be an opportunity to draw up such lists independent of the vendor. Here one can define the tools flexibly assisting data input.

In this component the qualification and authentication levels of the catalog records can be determined and the values set here can be offered up in a drop-down menu in the cataloging template. It is also configured here the elements of syntactic control necessary at the save of the bibliographic record, eg, the rules of inspection of non-permitterd characters.

The system must provide a tool in case of every unit of information (in the case of bibliographic data, subject heading etc., on a field level with common records) for administering which librarian/library submitted the statement.

The lists of subject headings and thesauri employed in the common catalog can be administered.

It is possible to define non-MARC21 fields which enable the typing in of non-bibliographic data in the cataloging record (eg, control codes necessary in the records to be gleaned for the bibliographic publication for the editing of the publication; administrative data necessary for the arrangement and management of analytical processing of periodical publications). The definition of these data fields is possible for the authorized librarian.

Fields are needed also for storing and resolving identifiers of certain documents (eg, incunabula, old books) recorded in bibliograpic databases and handbooks and cited in the literature (eg, RMK, RMNY, VD16, VD17). Also, it is necessary to store and resolve earlier system identifiers taken over from former systems (eg, EPA ID, MEK ID, DKA ID).

It is possible to determine data elements to be involved in the duplicate inspection of records by virtue of which the system will perform the collation examination among the records.

Standard, individually desired and unique formats of display must be freely defined for the virtual collections as well. Apart from the predefined formats the definitions of individual presentation modes can also be preserved.

By marking the records one can constitute partial collections and ’virtual’ databases in unlimited numbers and search for the records narrowed down into collections and to show the partial collection as part of thematic services (eg, ’database’ of the HNB, special bibliographies, catalogs of assorted collection parts, certain elements of the central catalogs: administration of antique documents, National Periodical Database). The list of the partial collections and the description of their characteristics are contained in the CCM component.

5.6 Technical Services

5.6.1 General Expectations of Information Technology

The NLP software should support the data storage to be brought about in a (geo)redundant manner in terms of the handled contents, and the reserved operation, that is, in the event of service outage the redundant site is capable of taking over the functions in a short period of time and the recovery won’t involve data loss or inconsistent state. The live service is invariably secured by a (primary) NLP installation running on a given locality, while there is a backup site installed in another locality with full functionality that can be run automatically or by manual intervention.

The system is of full modular structure. This allows for several basic configurations and the changing thereof:

- libraries participating in the system may use even a module divergent from the basic module, ie, the system makes it possible to operate in parallel several versions of the same module,

• the modules can be freely replaceable, their upgrade to more state-of-the-art versions is possible;

• the modules can communicate with one another on standard interfaces, that is, the change of the module won’t debilitate the operation of other modules;

• the modules themselves are independent of the programming language, ie, they can be written in any language.

The linguistic appearance of the modules (screens, images of printing) is freely selectable from among the languages offered, by installation and by user too. The number of languages available can be freely expanded, the system gives assistance to translations via user functions without a programmer’s interference.

The effectuation of the system is independent of the database manager. In the system, any database handling tool can be used the replacement of which is possible in the technical advancement.

As for the functions, in each function (catalog, treatment of privileges and users, institutional namespaces, etc.) several layers are to be materialized:

• common layer: participants handle common data on the commonly used software;

• central layer: data generated by software differing by institutions are synchronized

  and uploaded into the central data storage or downloaded from it by the systems;

• shared layer: the NLP system is capable of reaching data stored in the institutions’ own systems without taking them over or harvesting them using them for view or listing. In this case both the application software and the data remain within the scope of the related institutions and won’t merge with the NLP system.

  In the course of data processing the catalogers have access to the data on the basis of levels of qualification and authentication. In a complex system they are enabled to move the data forward in the procedure, to raise them on higher level of qualification and authentication or relegate them on a lower level, to delegate tasks and assignments, to publish data, etc. The system warrants access to the data across the whole spectrum along this logic.

5.6.2 Display, User Interface, Facade (UIX)

The UIX component contains those functions which display the given contents to users according to parameters fixed by the configurational modules. All functions of the system can be accessed and handled via internet browsers guaranteeing the same quality of appearance in the most frequently used browsers. The rendering surface should adapt itself to the capabilities of the various (eg, mobile) devices and browsers. The user surface can be partially or fully written into other languages and the user can shift the language any time. As a baseline, the system must be in Hungarian and in English.

The entire system will have a unified facade with the employment of a unified suite of icons. In addition, this component should ensure the appearance of an individual image for the libraries without programming/encoding, with parameters. On its own surface a member library should have the opportunity to feature the institution and its logo, configurable color

schemes and fonts. On the emerging surface there should be available a virtual keyboard for the input of special characters.

There is an option to form an accessible user surface in compliance with level ’AA’ of the W3C Accessibility Standard, eg, a mode of operation of oversize contrast for the visibility disabled, a loudspeaker help, the embedding of a text reciter, option of setting and enlarging font size.

Across the entire system there is a regularly updated context-sensitive help for the user surfaces. Also, the use of QR codes is possible (eg, mobile help, display of information, a map of building for easy roaming). There are push-based notifications, configurable at the level of institution and by member library, on the events, useful information, contingent problems. There is an option to keep news, associated curiosities on perpetual display. The user surface must have an option for web-based update.

Access to the functions is possible according to privileges, in a configurable manner (at the institutional level and at the workflow level within it). The state of being logged-in should be finely visible on the opening page and, pursuant to the privileges of the signed-in user, the functions associated to them must come up (or get into active status). It is possible to use several functions in parallel, with passability, and the navigation between the individual functions should be clearly viewable. While the function given in the user account is being used the other functions too can be viewable/accessible. The user can set the various elements of the display (opening of some functions on a new page, in a new window, a set of tools with parameters, etc.). Among data accessible within the functions there should be an option for query and sorting of hits.

In the NLP and Discovery system the display can be configurable. The data must be displayable concerning all types of documents, together with special data, and in every function configurably depending on the special treatment. It is possible to formulate brief and detailed forms of display for the bibliographic, authority and copy data.

In a number of functions of the NLP system (acquisitions, cataloging, circulation, etc.,) the formats of display should be configurably crafted and customizable according to the specifics and data of the tasks.

In the Discovery system it is possible to determine various formats (eg, display of clusters of hits in formats with the determination of fields and field groups). In the patron settings too there must be an option to choose a format for saving and printing into the patron’s library and for forwarding. The patron can choose from a list of predefined formats, or from a predefined list of data elements. The system is able to show indexed data originating from other databases via the standard API. There is an option for graphic display or data visualization on the basis of a list of hits (eg, charts on the percent division of hits, the placement of data on a timeline).

When the digital contents are shown, it should be possible to create flexible visualizing pages(s) and to form various display surfaces according to document types and partial collections. There are to be customizable user surfaces: layers formed individually by partial collection (appearance, functions, helps, headers, footers).

The display of digital objects must be enacted according to rules of restriction (cf ACC component). The service of works under copyright protection is enacted on the basis of permissions set in the administration of copyrights (DRM protection).

The accessibility of client programs necessary for reading the documents must be ensured on the surface. When displaying the documents stored as images an option must be presented for enlargement, swiveling and mirroring. In the case of books scanned as pictures there should be an online book-reading function, that is, display without download in the browser with turning pages, zooming and search (bookmarking) options.

The webpage displaying the document can be shared in the major social media pages and its link sent via email. There must be an option for displaying documents similar to the hit, flexibly defined on the basis of metadata.

5.6.3 Export/Import, Linking (EIL)

The content of the component: an assembly of functions handling standard export and import data exchange standards which make it possible to form standard relations with other systems. There is an option to perform data manipulations different from other communication panels of the system: the upload, modification or deletion of bibliographic authority and copy data of the documents, electronic documents and user data one by one and bulk. The export and import of cataloging data of documents typically in MARC21 and HUNMARC formats as well as in MARCXML environment. Character coding into UTF8, in case of API functions as well. As regards user data there is an option for standard data exchange and linking to external administration systems.

The system is enabled to publish its public data onto the semantic web utilizing the internationally used standards and dictionaries.

The migrational upload of the system must be enacted not through the EIL module but the vendor must surrender the migration tool applied by it as part of the range of shipping so that the NLP-based affiliations can be managed at a later date.

5.6.4 Metadata Conversion, Uploader and Downloader (MDC)

The module enables the upload and download of metadata and catalog entries related to digital objects between systems as well as their conversion between formats. The module uses standard data exchange protocols and formats for data export and import. The conversion optinally ranges to include bibliographic, authority and holdings data, those of

the acquisitions, serials management and circulation modules as well as the necessary character code conversion. It can pass on record links and preserve the original relations. The functions ensure automatic and manual handling of metadata and the download clusters of object metadata determined by means of filters.

5.6.5 Help Desk (HDS)

This module provides the classical help-desk functions in which context-sensitive tickets can be brought about and managed irrespective of which level of the NLP unit the particular ticket refers to. A multilevel currently updated help desk is needed in Hungarian and English. A system of request for assistance between the library and its patrons, between the librarians and the developers and a system for trouble reporting and for suggestion of development between librarians and developers. The help designed for patrons and librarians must be context-sensitive and messages can be sent, in association with chat service. The incoming questions/demands can be delegated within the library and among them and the colleagues can choose and perform tasks not yet allocated to an accessible staff member.

5.7 Storing services

5.7.1 Temporary Storage of Electronic Documents (EDS)

In this storage are placed those files which arrive either from digitization or via other channels, but with the arrival the related workflows have not been terminated yet. The fast- access temporary stores linked to the workflow administration make the electronic document available during execution of the individual work phases (eg, arrival check-in, porcessing) pinned to authorization, and with remote access as well and a minimal need of mandatory metadata. In the process it is possible to assign qualification and authentication levels to documents, automatically during the procedures of upload, load and machine processing or by staff members too with tools and surfaces adequately shaped for this purpose. Upon execution of the proper administration, processing, cataloging tasks the objects will get into the archive storage or the deposit of service copies warranting long- term preservation.

The temporary provisional storage does not separate physically from the database and the sorting layers it is simply a logical view of the complex procedures of the qualification and authentication of data.

5.7.2 Long-Term Preservation (LTP)

The software effectuating the function of long-term preservation is part of the range of this RfP. As a result of the realization of the function it is expected that the NSZL can satisfy its obligations of long-term preservation specified in legal rules (Act 140/1997 On the antique

institutions, the public library supply and public learning 134. § 5; 30/2014 (IV.10.) EMMI Decree 8 § (1) 4). The hardware infrastructure necessary for long-term preservation is supplied by the tender announcer.

The task of the system warranting long-term preservation is to maintain the digital documents and data of the collection of the National Széchényi Library in the long run. In the NLP, long-term preservation is the duty of the National Széchényi Library, so this function is not to be attained for other libraries by the Vendor.

The types of digital objects to be treated in the LTP module: still, motion picture, text (of binary coding [eg, doc, ppt, xls stb.], (html, xml, ALTO xml, TEI etc.) voice, audio, 3D and the combination of these. The most frequently used formats: JPEG2000, JPG, HTML, XML, PDF, PDF/A, e-pub, VAW, MP3 etc. The preservation of backups and saves generated during web harvesting is the duty of this module as well.

The system of the NLP uses standard metadata and de facto digital formats. The treatment of digital objects in the NLP system takes place according the the OAIS model (ISO 14721:2003).

The creation of a software-based solution supporting the multiplication and storage necessary for the long-term preservation of digital objects is also an expectation from the module. It must enable the identification, integrity, software-supported readability of the digital documents and objects the integrity of its structure and the execution of operations related to the objects (control, supervision, migration, conversion, compression, etc.).

The handling of the LTP module is performed by staff members and/or programs with the appropriate privilege. It is guaranteed that the state prior to the execution of an operation can be restored and recovered, even concerning multiple operations as well.

The handling of the metadata necessary for long-term preservation is to be solved by the vendor, eg. on the basis of Preservation Metadata: Implementation Strategies [PREMIS], Metadata Encoding and Transmission Standard [METS] or other de facto standards.

The module can handle the metadata pertaining to the history of digital objects (eg, migration, conversion, compression, control etc.).

5.7.3 Standard Storages and their Conduits (SSI)

The component must enable the coupling to repositories which are not in the pooled storages of the NLP and to which direct access is to be secured via the catalog entry. Therefore, the NLP is to communicate with the software programs of repositories (Eprints, Dspace, Jadox) to ensure the transfer of metadata between repository and catalog, to yield the documents’ access data to the query system. It must collaborate with other systems (eg, Open Journal Systems, Magyar Tudományos Művek Tára – MTMT).

5.8 Modules specific to the National Széchényi Library

5.8.1 Document Reception System (GTE)

The specific national library function of the National Széchényi Library is the management of international publication identifier numbers (the maintenance of the ISBN/ISMN and ISSN national agencies) and the reception aand distribution of analogous and electronic deposit copies among authorized libraries. The GTA component supports activities with respect to these functions and the maintenance of administration (except for the tasks of the ISSN national agency). The GTA component is an upfront system of the NLP used only by the NSZL. In view of the fact that the NSZL itself is entitled to get deposit copies, thus the GTE component is a software element in close relations with the acquisitions module (ACQ) and the system of digital collection management.

The NSZL wishes to solve the allocation and administration of ISBN and ISMN international identifiers (ID number of publishers and publications) through this. Also, the processing of the check-in and adoption into inventory of the incoming deposit copies. The administration of the deposit copy service is similar to that of the library holdings (’inventory book’) but not the same.

Into this process do we wish to integrate the submission process of electronic publications arriving in the NSZL either as a deposit copy, or as a copy prescribed in the EMMI decree 30/2014.

The procedures described herein precedes the conventional libraray holdings management, holdings acquisitions and does not affect the other libraries. They can nonetheless come into relationship with this upfront system as publishers or deposit copy providers

The process rolls out with the publisher’s registration where the publisher supplies (and maintains later) its own data and records the fundamental bibliographic data of its publication in progress and thereby asks for a publication identification number. To this is attached the copyright management and a part of access management: the publisher gives a statement on the copyright owner of its publication and, also, conveys the permissions regarding the use of electronic documents (eg, how many simultaneous uses are permitted at the national library points to be formulated in the closed network of libraries entitled to deposit copies.

The bibliographic data given by the publisher are controled and complemented at the arrival of the publication, then lifted over into the NLP system they constitute the first cataloging record that is utilized also in the ACQ module for the generation of an order item. The component ensures MARC21 compatibility.

For the administration of publishers the GTE component uses the partner database established within the framework of the NLP system which must be formed in a way that

one of the potential roles of institutions to be admitted is that of the publisher. In the GTE component, for the entry and display of data of partners of the publisher role, a self- contained surface is to be shaped that makes visible the pertinent data and contact persons, the publisher identifier assigned by the agency included. Access must be granted to the publishers for the maintenance and modification of their data. Among the publishers public bodies as well as private persons may appear, and distinction must be made between their public and non-public data.

The task of the software component is the treatment of ISBN and ISMN identifiers: the allocation, administration of ranges of numbers, the previous allocation and automatic generation of publication identifiers (by means of a determined algorithm), on web-based interface too, the transformation of ISBN identifiers from 10 to 13 digits, compilation of lists and statistics. Since the NSZL has to provide lists of Hungarian publishers for the international agencies at certain intervals, the format of the component should be compatible with the standard-based format ONIX (Online Information Exchange).

The GTE’s additional task is to check in the arrival of analogous and electronic (offline and online) publications as deposit copies, to control ISBN/ISMN identifiers, to handle the data of publications released without identifiers. A web-based interface is to be shaped for data of the publications to be adopted through which the registration of the publications can be enacted as well as the claim for publications not submitted, the compilation of various lists and the recording of the distribution of the deposit copies. The data of the database administrating the deposit copies must at designated intervals be printed into a (paper- based) log of arrivals.

The preliminary bibliographic records having been inspected, they should be loaded into the NLP after conversion to MARC 21 format and the record identifier created in the NLP should be sent back to the deposit copy administration.

The deposit copy adminstration database must be prepared for financial transactions (these are needed when the allocation of publication identifiers will be fee-based) and for recording data needed for the national statistical stock-taking of publications.

To submit the deposit copy of electronic documents on the web-based interface the submitter is to fill in a template on which the metadata of the publication can be typed. Beside individual upload there has to be an option for batch upload as well. The upload is possible via multiple protocols, eg, FTP, SWORD, SCP. In case of batch upload it is ensured that the submitters feed in in bulk the metadata of the documents in a variety of viable formats (MARC, qDC, ONIX, Excel). An automatic virus-search must be performed on the uploaded documents. In case of bigger upload the system ensures the control of the integrity of the upload package. The upload system must automatically read the documents’ technical metadata (eg, file type, size, date) which it attaches to the descriptive data. When a submission package is being arrived, the system should send an automatic feedback to the

submitter and a signal to the basket of those in charge of e-document management. Should some defect or error arise upon supervision, or for some reason the submitted document is rejected, a response of this content must be ensured by the system. The system is able to receive various versions and formats of a document as well as individual documents and periodical publications of hierarchic structure (consisting of partial units).

The system receives the various multiple versions of documents digitized by the libraries. It should handle a variety of formats (eg, TIFF, JPG, PDF). A limit can be set concerning the size of the submission package and the number of objects in it which warrants the acceptance of packages of big size, complex and containg many objects. If the size of a submission package or the number of its objects exceeds the values manageable by the system, then it must send an automatic feedback to the submitter.

The accepted, controlled and approved documents are to be handed over by the Document receiving system to the system managing digital collections where if need be the service version is produced.

Beside acceptance the system is able to download electronic documents accessible online if the submitter supplies only a URL, an address of oversize file delivery or other sources.

5.8.2 Web Harvesting (HAR)

The functional content of web harvesting is not the subject of this acquisition, while the access and treatment in the NLP of the web archive arising from the result thereof must be realized the same way as the treatment of images, videos, etc.

The self-contained project of web harvest development, which is going to be effected separately, aims to create the concept, structural frames and information infrastructure of a would-be Hungarian internet archive (webarchive) and to set up a test archive.

The ultimate goal of the web harvest development project pointing far beyond the NLP project is the creation of a system which, in addition to the task of preserving Hungarian and Hungary-related cultural heritage appearing on the internet in the long run, will serve the requirements of education, scientific research, state organizations, business sphere and some internet users.

The public service of metadata and fulltext search engine of the web archive and the service of archived web pages within the NSZL and the NSZL and NAVA points on dedicated computers must be coupled up to the NLP as any other storage of digital objects. In the course of the handling of the NLP catalog an option must be present for supplying the html- based digital objects placed in the web archive with metadata (for cataloging), or for transferring metadata into the catalog by means of the MDC module and with the help of these metadata the queries of the DRY module must expand to include the web archive. The running of fulltext retrieval by special software and the delivery of the results while retaining

the storage of data in the web archive is a sufficient and acceptable solution.

The web archive is substantially related to the access managing module (ACC) ensuring access to the contents by privileges registered in the system. The maintenance of a part of the privileges takes place in the web archive, and this is related to the ACC module. It must be able to regulate belated or delayed accesses related to the age of the archived contents.

The secure storage of archived oversize files and their readability is solved by its integrated relation to the long-term preservation system (LTP).

 Links

.Attachments