Library automation: Koha and SOUL

In short

Library automation is the use of computers to carry out a library's routine "housekeeping" work — acquisition, cataloguing, circulation, serials control and the public catalogue — through one integrated database, so a record created once is reused everywhere. Koha is a free, open-source, web-based integrated library management system (ILMS), and SOUL (Software for University Libraries) is the proprietary ILMS developed by the INFLIBNET Centre, Gandhinagar (an Inter-University Centre of the UGC) for Indian universities and colleges. The topic is examined in B.LISc/M.LISc "Library Automation / Information Technology Applications" papers and in UGC-NET Library & Information Science Paper II, and it is the single most tested practical skill in interviews for Library Assistant, Library Trainee, Professional Assistant and Semi-Professional Assistant posts (universities, IITs/IIMs/NITs, DRDO, ISRO, CSIR labs, KVS/NVS, Delhi Public Library, state public library networks). Employers expect hands-on answers: creating a MARC21 record, framing a circulation rule, importing records over Z39.50, taking a backup.

Explained

What library automation is, and what it automates

• Definition: mechanisation of library operations using computer hardware, software, networks and databases to reduce repetitive manual work and improve speed, accuracy and access. It is *not* a digital library (which deals with digital content) — automation manages the *library's* records about physical and electronic holdings.
• Integrated system (ILMS / LMS / ILS): one bibliographic database shared by all modules, so an order placed in acquisition becomes a catalogue record and then an issuable item without re-keying.
• Housekeeping modules (the standard syllabus list):
  1. Acquisition — suggestions, pre-order search for duplicates, order placement, budget/fund allocation and commitment, receipt, invoice, accession register.
  2. Cataloguing — descriptive cataloguing in MARC21 using RDA (which replaced AACR-2) or AACR-2, subject headings (SLSH/LCSH), classification (DDC/CC/UDC), authority control, item (holdings) records, barcode and spine-label printing.
  3. Circulation — issue, return, renewal, reserve/hold, recall, overdue notices, fines, stock verification, inter-library loan.
  4. Serials control — subscription, prediction patterns, check-in of issues, claiming missing issues, binding, renewal.
  5. OPAC / Web OPAC — public search by author, title, subject, keyword, ISBN, class number; facets; "my account" renewals and reservations.
  6. Administration and reports — users and permissions, library parameters, statistical and MIS reports, SQL reports.
• Benefits: single data entry, 24×7 remote catalogue access, union catalogues, accurate statistics, resource sharing, staff time released for reader services.
• Limitations: high initial cost of retroconversion and tagging, dependence on power/network/AMC, data migration and Unicode issues for Indic scripts, staff training and resistance, obsolescence of versions.

Koha — architecture, features and administration

• Origin: developed in 1999 for the Horowhenua Library Trust, New Zealand, by Katipo Communications; released in January 2000 as the first free/open-source ILMS. Now maintained by a global community at koha-community.org under the GNU GPL (version 3), with roughly two major releases a year (numbered by year and month, e.g. 24.05).
• Technology stack (LAMP-style): GNU/Linux (Debian/Ubuntu preferred), Perl with Template Toolkit, Apache2 (often with Plack for speed), MariaDB/MySQL database, and Zebra or Elasticsearch as the search/indexing engine. Nothing is installed on the user's PC — it runs in a browser.
• Two interfaces, two ports: the staff interface (default 8080) and the OPAC (default 80/8081), served from the same database as separate virtual hosts.
• Installation outline (Debian/Ubuntu): add the Koha community repository, apt install koha-common, edit koha-sites.conf, then koha-create --create-db <instance> to build an instance; enable Apache modules rewrite, cgi, headers, proxy_http; complete the web installer (database check, schema, mandatory + optional sample data), choose MARC flavour (MARC21 or UNIMARC) and create the superlibrarian account.
• Key configuration vocabulary: system preferences (several hundred global switches), frameworks (MARC templates per material type), authorised values, item types, patron categories, libraries/branches, circulation and fine rules (a matrix of patron category × item type × library giving loan period, renewals, holds, fine amount and grace period), notices and slips, message queue.
• Cron jobs that make it work: fines.pl (accrue overdue charges), overdue_notices.pl, process_message_queue.pl (email/SMS), rebuild_zebra.pl or koha-rebuild-zebra, cleanup_database.pl, koha-dump for backups.
• Interoperability: acts as a Z39.50/SRU client for copy cataloguing (Library of Congress, OCLC, other Koha sites) and as a Z39.50/SRU server; SIP2 and NCIP for self-check kiosks and RFID; OAI-PMH data provider; MARC/ISO 2709 and MARCXML import–export through "Stage MARC records for import"; a REST API and a report engine where any SQL SELECT can be saved as a report.
• Strengths: no licence fee, full source control, multi-branch and multi-lingual (UTF-8, including Indian languages), large community. Watch-outs: needs Linux and MARC21 skill in-house or a paid support vendor; upgrades must be tested; "free software" is not "free project" — budget for implementation, training and AMC.

SOUL — INFLIBNET's software for Indian academic libraries

• Developer and purpose: built by the INFLIBNET Centre (Information and Library Network, an IUC of the UGC, Gandhinagar) specifically for Indian university, college and R&D libraries, with documentation, training and support in Indian conditions.
• Versions: SOUL 1.0 released in 2000 (launched at the Mumbai World Book Fair era of INFLIBNET's automation drive); SOUL 2.0 released in 2009, standards-compliant, client–server and web-enabled. INFLIBNET has continued to issue service packs and has been working on a later release — confirm the version and the current licence fee from INFLIBNET's circular, as both are revised periodically (software licence/AMC attracts GST at 18%).
• Technology: Microsoft platform — Windows Server, .NET/ASP front end, MS SQL Server back end, client–server architecture with a web OPAC; licensed (proprietary), supplied at a concessional fee to member institutions, so source code is not modifiable by the library.
• Modules: Acquisition, Catalogue, Circulation, Serial Control, OPAC/Web OPAC, Administration, with add-ons for article indexing, stock verification, barcode/RFID support and MIS reports.
• Standards claimed: MARC21, AACR-2, ISO 2709, Z39.50 for copy cataloguing, Unicode for Indian-language data, and NISO/ANSI circulation practice.
• Strengths: familiar Windows GUI, low training barrier, central support and training by INFLIBNET, forms and reports already matched to Indian university practice (accession register, UGC returns), useful for contributing data to INFLIBNET union catalogues/IndCat. Limits: licence and AMC cost, Windows/MS SQL licence cost, closed source, customisation only through the developer, slower release cycle than Koha.

Standards and codes that make automation work

• MARC21 (Machine-Readable Cataloguing) — the dominant bibliographic format; fields are tags (3 digits) with indicators and subfields ($a, $b…). Learn these: 020 ISBN, 040 cataloguing source, 041 language, 082 DDC number, 100/110 main entry (personal/corporate author), 245 title statement, 250 edition, 260/264 publication, 300 physical description, 490/830 series, 500 general note, 650 topical subject, 700 added entry, 856 electronic location, 942 Koha item type, 952 Koha holdings/item data.
• ISO 2709 — record exchange format (the .mrc file); MARCXML is its XML expression; Dublin Core is the simpler 15-element set used for OAI harvesting.
• Z39.50 (ISO 23950) and its web successors SRU/SRW — search and retrieve records from remote catalogues for copy cataloguing.
• SIP2 and NCIP (Z39.83) — protocols between the ILMS and self-check/RFID/kiosk equipment.
• OAI-PMH 2.0 — metadata harvesting (used by NDLI and union catalogues).
• RFID: HF 13.56 MHz tags per ISO/IEC 15693 / ISO/IEC 18000-3, with the library data model in ISO 28560 (parts 1–3). Barcodes: Code 39 and Code 128 are standard for accession/borrower numbers.
• Cataloguing codes: RDA (current, replaced AACR-2), ISBD for description, CCF for exchange in some Indian projects.
• Character encoding: Unicode UTF-8 for Devanagari, Tamil, Malayalam and other Indic scripts; legacy ISCII/ISFOC data must be converted on migration.
• Indian legal/policy context: state Public Libraries Acts (Tamil Nadu 1948 onwards; Kerala 1989; Karnataka, Maharashtra, West Bengal and others) govern public library systems and library cess; the Delivery of Books and Newspapers (Public Libraries) Act, 1954 requires legal deposit in four libraries notified under it — the National Library, Kolkata plus three public libraries (Connemara Public Library, Chennai; Central Library, Mumbai; Delhi Public Library); Copyright Act, 1957 section 52 permits defined library copying; borrower data is personal data — the Digital Personal Data Protection Act, 2023 is enacted and the DPDP Rules, 2025 are notified, but the Data Fiduciary duties (notice, consent, breach intimation, erasure) apply only from 13 May 2027, so until then IT Act section 43A and the SPDI Rules, 2011 govern reasonable security practices for patron records.

Running an automation project — step by step

1. Feasibility and needs study — collection size, annual additions, transactions per day, users, staff IT skill, budget.
2. Software selection — define requirements, compare ILMS (Koha, SOUL, eGranthalaya, NewGenLib, LibSys/SLIM21, Evergreen), run a demo/trial on your own sample data; issue a GeM/RFP for support services if proprietary or vendor-supported.
3. Hardware, network, power — server (on-premises or cloud/VPS), LAN/Wi-Fi, OPAC terminals, barcode or RFID hardware, UPS, printer; plan for backup media.
4. Database creation / retroconversion — convert the existing card catalogue: original cataloguing for unique titles, copy cataloguing via Z39.50 or vendor MARC files for the rest; validate against the shelf list.
5. Item processing — accession numbers, barcode or RFID tagging, shelf-wise verification.
6. Parameter setting — branches, item types, patron categories, loan periods, fines, notices.
7. Staff and user training; print user manuals and a quick-reference card.
8. Parallel run — manual and automated circulation together for a few weeks; reconcile counts.
9. Go-live, then OPAC publicity; enable email/SMS notices.
10. Backup and maintenance policy — daily database dump off-site, version upgrades on a test instance, AMC, periodic data quality audit (duplicate records, missing 942/952 fields).

Barcode, RFID and self-service

• Barcode: cheap (₹1–3 per label), needs line of sight, one item at a time, no security function; a separate EM strip plus gate is used for theft control.
• RFID: tag read without line of sight, several items at once, doubles as a security tag, enables self-issue/return kiosks, drop boxes and handheld shelf-management readers for stock verification in hours instead of days; capital cost per volume is an order of magnitude higher, and tags must follow ISO 28560 so a future ILMS can read them.
• Both talk to Koha/SOUL through SIP2/NCIP; Koha also has an in-built offline circulation tool for network outages.

Key points

• Library automation - computerising housekeeping operations on one integrated database; distinct from digitisation.
• ILMS modules - acquisition, cataloguing, circulation, serials control, OPAC, administration/reports.
• Koha - first open-source ILMS, 1999, Horowhenua Library Trust (New Zealand), GPL v3, web-based.
• Koha stack - Linux + Perl + Apache + MariaDB/MySQL + Zebra or Elasticsearch; staff interface on 8080, OPAC on 80.
• SOUL - Software for University Libraries from INFLIBNET, Gandhinagar; 1.0 in 2000, 2.0 in 2009; Windows/.NET/MS SQL, proprietary and licensed.
• MARC21 - tag-indicator-subfield bibliographic format; 245 title, 100 author, 650 subject, 952 Koha item data.
• ISO 2709 - the exchange record format; MARCXML its XML form; Dublin Core for harvesting.
• Z39.50 / SRU - remote search protocols used for copy cataloguing; Koha and SOUL are both clients.
• SIP2 / NCIP - ILMS-to-self-check and RFID communication protocols.
• OAI-PMH - metadata harvesting protocol; Koha can act as a data provider.
• RDA - current cataloguing code, successor to AACR-2; ISBD governs description.
• Retroconversion - converting legacy card records into machine-readable form; the costliest step of automation.
• Circulation rules matrix - patron category × item type × library decides loan period, renewals, holds and fines in Koha.
• Authority control - a single controlled form for each name/subject, linked from bibliographic records.
• Unicode UTF-8 - essential for Indic scripts; legacy ISCII data needs conversion on migration.
• Other Indian systems - eGranthalaya (NIC, government libraries), NewGenLib (India's first open-source ILMS, GPL from 2008), LibSys/SLIM21, Libsuite; Evergreen and ABCD abroad.
• Open source ≠ zero cost - implementation, training, hosting and support are real budget lines.
• Backup discipline - daily koha-dump/SQL Server backup kept off-site is the only protection against total loss.

Formulas and examples

• Example 1 — retroconversion with and without copy cataloguing. A college library has 60,000 titles to convert. Original cataloguing in MARC21 runs at 20 records/person-day; copy cataloguing over Z39.50 runs at 60 records/person-day, with a 70% hit rate.
  • All original: 60,000 ÷ 20 = 3,000 person-days.
  • With Z39.50: hits = 0.70 × 60,000 = 42,000 → 42,000 ÷ 60 = 700 person-days; misses = 18,000 → 18,000 ÷ 20 = 900 person-days; total = 1,600 person-days (a 1,400 person-day saving).
  • At ₹900 per person-day: ₹27,00,000 against ₹14,40,000 — a saving of ₹12,60,000; cost per record falls from ₹45 to ₹24.
• Example 2 — Koha fine calculation. Circulation rule: loan 14 days, fine grace period 3 days, fine ₹2 per day, charge period 1 day, overdue fine cap ₹50. A book due 1 November 2026 is returned on 12 November 2026.
  • Days late = 11; chargeable days = 11 − 3 = 8; fine = 8 × ₹2 = ₹16 (below the ₹50 cap, so ₹16 is posted by fines.pl).
  • If the same book came back on 30 December 2026: 59 days late → 56 chargeable × ₹2 = ₹112, but the cap applies, so the borrower owes ₹50.
• Example 3 — database and disk sizing for a Koha instance. 1,00,000 bibliographic records at 1.5 KB; 1,20,000 item records at 0.5 KB; 40,000 borrowers at 2 KB; circulation history of 1,50,000 issues/year for 5 years at 0.3 KB.
  • Bib 150 MB + items 60 MB + borrowers 80 MB + circulation (7,50,000 × 0.3 KB) 225 MB ≈ 515 MB of data.
  • Zebra/Elasticsearch index at ~2× bibliographic data ≈ 300 MB → working set ≈ 0.8 GB; with logs, uploads, cover images and 14 daily dumps, provision 20–40 GB of disk — modest, so the usual bottleneck is RAM and CPU, not storage.
• Example 4 — barcode versus RFID for 50,000 volumes.

• RFID costs about 5.5× as much here, but stock verification of 50,000 volumes drops from roughly 40 person-days (manual/barcode) to about 3 person-days with a handheld reader, and self-issue removes counter queues — so RFID is justified by transaction volume and stock-taking frequency, not by the catalogue itself. Prices are indicative and move with tag volumes; add GST at 18%.
• Example 5 — circulation counters needed. 1,200 transactions a day over 8 hours, 25% falling in the peak hour, 30 seconds per barcode transaction.
  • Peak hour = 0.25 × 1,200 = 300 transactions → 300 × 30 s = 9,000 s of work; 9,000 ÷ 3,600 = 2.5 → 3 counters at peak (or 2 counters plus one self-check kiosk).
  • Turnover ratio for this library with 50,000 volumes: (1,200 × 300 days) ÷ 50,000 ≈ 7.2 issues per volume per year.

Koha versus SOUL at a glance

Where it is used

• Universities and colleges: central libraries of universities, IITs, NITs, IIMs and affiliated colleges run Koha or SOUL for circulation and web OPAC; INFLIBNET-member institutions use SOUL and contribute to union catalogues such as IndCat.
• Government and research libraries: NIC's eGranthalaya (current generation is web/cloud-based) is used in ministries, departments and district libraries; CSIR, DRDO and ICAR institute libraries run Koha or commercial systems.
• Public and school library networks: state public library systems — Kerala's library network is a prominent Koha user — and large school groups (KVS, NVS, CBSE schools) use Koha for multi-branch catalogues.
• Job roles: Library Assistant / Professional Assistant / Semi-Professional Assistant (UGC-pattern posts), Systems Librarian, Cataloguer (MARC21/RDA), Digital Library Assistant; Koha implementation and AMC work with Indian LIS service firms and with vendors supplying LibSys, SLIM21 and RFID solutions.
• Service providers and hardware: RFID and self-check integrators, barcode/label vendors, cloud-hosting providers offering Koha as a managed service to colleges.
• Resource sharing: automated catalogues feed union catalogues, inter-library loan and discovery layers, and support e-ShodhSindhu/N-LIST access management in academic libraries.

Interview questions

• Q: What makes a library system "integrated"? A: All modules — acquisition, cataloguing, circulation, serials, OPAC — read and write one shared bibliographic and patron database, so data entered once flows through every operation without re-keying.
• Q: Name the Koha technology stack. A: GNU/Linux with Perl and Template Toolkit, Apache2 (often under Plack), MariaDB/MySQL, and Zebra or Elasticsearch for indexing; it is used entirely through a browser.
• Q: Which MARC21 fields hold the title, the personal author and a topical subject? A: 245 for the title statement, 100 for personal name main entry and 650 for a topical subject heading.
• Q: What are MARC21 tags 942 and 952 used for in Koha? A: 942 carries Koha's biblio-level data such as item type and classification scheme; 952 carries the holdings/item record — barcode, home branch, collection code, call number, price and status.
• Q: What is Z39.50 and why does it save money? A: It is the ISO 23950 search-and-retrieve protocol that lets your ILMS pull existing catalogue records from remote libraries; copy cataloguing is around three times faster than original cataloguing, cutting retroconversion cost sharply.
• Q: Who developed SOUL and for whom? A: The INFLIBNET Centre, Gandhinagar — an Inter-University Centre of the UGC — developed it for Indian university, college and R&D libraries; version 1.0 appeared in 2000 and 2.0 in 2009.
• Q: Koha or SOUL for a new college library? A: Koha if licence budget is tight and Linux/MARC21 skill or a support vendor is available, because it is GPL and fully customisable; SOUL if the library wants a Windows interface with central INFLIBNET training and support and is willing to pay licence, AMC and Microsoft platform costs.
• Q: How does a self-check kiosk talk to Koha? A: Through SIP2 (or NCIP), which carries patron validation, issue, return and renewal messages between the kiosk or RFID middleware and the ILMS.
• Q: What is retroconversion and what is the main risk? A: Converting the legacy card catalogue into machine-readable records; the main risks are duplicate or low-quality records and mismatch with the actual shelf stock, so shelf-list verification must accompany it.
• Q: Where are loan period and fine decided in Koha? A: In the circulation and fine rules — a matrix of patron category, item type and library that sets loan period, renewals, holds, fine amount per charge period, grace period and the fine cap; fines.pl then accrues the charges.
• Q: Which Koha cron jobs must be scheduled? A: fines.pl, overdue_notices.pl, process_message_queue.pl, index rebuild (koha-rebuild-zebra), cleanup_database.pl and a daily koha-dump backup.
• Q: Is library automation the same as a digital library? A: No — automation manages records and transactions about the collection, while a digital library stores and delivers the digital content itself; a library commonly runs Koha for automation alongside separate repository software.

Common mistakes

• Treating automation and digitisation as the same thing, or calling Koha a digital library platform.
• Saying Koha is "free" without mentioning implementation, hosting, training and support costs — interviewers probe this.
• Confusing MARC21 (the format) with ISO 2709 (its exchange encoding) and with Z39.50 (a search protocol).
• Forgetting the 952 item field in Koha, so a catalogued title cannot be issued because no item record exists.
• Ignoring the grace period or the fine cap when calculating overdue charges in an exam problem.
• Entering Indic-language data without UTF-8 (or migrating legacy ISCII data unconverted), producing unreadable records.
• Skipping shelf verification during retroconversion, and skipping off-site daily backups after go-live.

Related topics

• Digital libraries and institutional repositories · Computer fundamentals and office automation · Cataloguing practice: RDA, AACR-2 and MARC21 · Classification systems: DDC, CC and UDC · Library networks and consortia: INFLIBNET, DELNET, e-ShodhSindhu · Information retrieval and OPAC search techniques.