Expanding Your Research Hub: How to Catalog Articles and Chapters in Koha

From Books to Research Hub: Cataloging Articles & Analytics in Koha

Adding articles—such as journal papers, book chapters, or seminar presentations—alongside your monographs is a powerful way to enhance your Sirah Research Database. In library science, these are referred to as Analytics or Component Parts.

To integrate these into Koha, you must link the article to its "host" (the parent journal or book) using specific MARC tags and adjust your display settings to make them stand out in the OPAC.

1. The Core MARC Tags for Articles

When cataloging an article, the most significant changes occur in the Leader and the 773 field.

A. The Leader (Position 07)

This position identifies the bibliographic level of the record. Changing this tells Koha: "This is a part of a larger work, not a standalone book."

• Leader/07: Change from m (monograph) to a (Monographic component part).

B. The 773 Field (Host Item Entry)

This field creates the bridge between your article and the host record.

• 773 $t: Title of the host (e.g., Journal of Islamic Studies).
• 773 $g: Relationship info (e.g., Vol. 5, No. 2 (2024), pp. 10-25).
• 773 $w: The Biblio Number of the host record in your Koha system. This creates a functional, clickable link in the OPAC.

2. Differentiating Articles from Books in the OPAC

Researchers need to know at a glance if they are looking at a 500-page book or a 10-page article. Here are three ways to achieve that:

Method 1: Using Item Types (Recommended)

Create a specific Item Type for articles in Administration > Item Types. Assign it a "document" or "page" icon. When users see the icon next to the search result, they will immediately recognize the material type.

Method 2: Custom Visual "Badges" via CSS

You can add a visual highlight to article results using the OPACUserCSS system preference:

/* Highlight 'Article' results with a green border */
.results_summary.itemtype_ARTICLE {
    border-left: 5px solid #2ecc71;
    background-color: #f9fff9;
}
    

Method 3: XSLT Customization

For a professional finish, modify your OPACXSLTResultsDisplay. You can set a condition: If Leader/07 = 'a', display the Host information (773) prominently instead of the standard publisher info.

3. Comparison: Book vs. Article Cataloging

Feature	Book (Monograph)	Article (Component Part)
Leader/07	m	a
Main Title (245)	Title of the Book	Title of the Article
Source Information	260/264 (Publisher)	773 (Host Journal/Book)
Identifier	020 (ISBN)	022 (ISSN of the Host)

4. Essential System Preferences

To ensure your "One Point" database functions smoothly, enable these settings:

• ShowComponentRecords: Set to "Show". This adds a "Components" tab to the parent book record, listing all chapters inside.
• EasyAnalyticalRecords: Set to "Display". This simplifies the process of linking articles to parents in the staff interface.

By following these steps, you provide your researchers with a deeper, more interconnected view of scholarly literature.

Overriding the "Text" Label in Koha: A Step-by-Step Guide to Customizing XSLT Display

If you’ve ever looked at your Koha OPAC and wondered why your carefully cataloged Theses or Articles are simply showing up as the generic label "Text," you aren't alone.

While many believe this requires "pasting" raw XSLT code into a text box (like you might do with JavaScript), Koha actually handles XSLT through server-side files and administrative mappings. To change "Text" to "Thesis," you need to tell Koha to prioritize your custom descriptions over its default internal logic.

Here is exactly how to fix the "Text" label in the Koha Administration panel.

Step 1: Check Your Current XSLT Configuration

Before making changes, identify which display file your system is currently using.

1. Navigate to Koha Administration $\rightarrow$ Global System Preferences.

2. Search for the preference: OPACXSLTResultsDisplay.

3. Analyze the value:

   • default: Koha is using its internal "Standard" display.

   • File Path (e.g., opac-main.xsl): Your library is using a custom file located on the server.

Step 2: The "Authorized Values" Solution (The Easiest Fix)

Most Koha XSLT files are programmed to look at your Item Type Descriptions first. If the display shows "Text," it usually means your Item Type "Description" is either empty or literally set to "Text."

1. Go to Koha Administration $\rightarrow$ Item Types.

2. Find the code for your category (e.g., THE for Thesis).

3. Click Edit.

4. In the Description field, type exactly what you want the user to see (e.g., Thesis).

5. Crucial: Look for the Search category dropdown. If it is set to "Books" or "None," try changing it to a custom category or leaving it blank to see if the display updates.

6. Repeat this for other types like BIB (Citation) or ART (Article).

Why this works: The XSLT logic is essentially: "If an Item Type Description exists, show it. Otherwise, fallback to the default 'Text' label based on the MARC Leader." By filling this in, your custom label "wins."

Step 3: Mapping 942$c (The Framework Fix)

For the XSLT to "see" the description you just created, your Bibliographic record must be properly linked to the Item Type.

1. Go to Koha Administration $\rightarrow$ MARC Bibliographic Framework.

2. Select your framework (e.g., Default) and click MARC structure.

3. Search for Tag 942 and click Edit Subfields.

4. Locate Subfield c and ensure the "Koha field" is mapped to biblioitems.itemtype.

5. Save your changes.

Step 4: The Server-Side "Nuclear Option"

If you have access to the Linux terminal (via PuTTY/SSH) and the above steps don't yield the desired result, you can edit the physical XSLT file on the server.

• File Path: /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/en/xslt/MARC21slim2OPACResults.xsl

• Action: Search for the term "Material type." You will find a code block starting with <xsl:choose>. This is where you can manually insert logic to override the "Text" string with your preferred terminology.

---

Your Implementation Checklist

To ensure your changes take effect immediately, follow this quick checklist:

• [ ] Item Types: Does the "Description" for THE say "Thesis"? (Check Admin > Item Types)

• [ ] Framework Mapping: Is 942$c correctly mapped to biblioitems.itemtype? (Check Admin > Framework)

• [ ] Index Refresh: After making these changes, you may need to run a rebuild of your search index from the terminal:

  koha-rebuild-zebra -v -f [instancename]

From "Broken" to Brilliant: Fixing Urdu and Arabic Search in Koha’s Elasticsearch

If you’ve recently moved to Koha 24.11 or 25.11, you might have noticed something frustrating: out of the box, Elasticsearch can feel "broken" for Urdu and Arabic collections.

While it handles English flawlessly, the default settings often treat Right-to-Left (RTL) text like Western languages. It struggles with diacritics (Harakat), fails to understand linguistic roots, and ignores the unique logic of our scripts.

However, for a specialized project like a Sirah Research Hub, Elasticsearch is actually a massive upgrade over the old Zebra engine—provided you install the "missing piece."

1. The Essential Upgrade: The ICU Analysis Plugin

The primary reason your search results might feel inaccurate is the lack of the ICU (International Components for Unicode) plugin. Without this, Elasticsearch cannot "read" the nuances of our languages.

By installing this plugin, you enable three critical functions:

• Character Normalization: It recognizes that Alif with Mad (آ) and a plain Alif (ا) should be treated as the same character during a search.

• RTL Logic: It correctly tokenizes Urdu and Arabic words regardless of punctuation or sentence structure.

• Diacritic Independence: It allows researchers to find terms without having to type the exact Zer, Zabar, or Pesh used by the cataloger.

How to Install (Server Side):

If you have terminal access to your server, run the following commands:

Bash

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
sudo systemctl restart elasticsearch

2. Configure Your Analyzers

Once the plugin is live, you must tell Koha to use it. Navigate to:

Koha Administration $\rightarrow$ Search Engine Configuration (Elasticsearch)

Ensure your Urdu and Arabic metadata fields are explicitly mapped to the arabic or icu_analyzer. This step ensures the search engine applies the correct linguistic rules to your specific records.

3. Comparison: Why Make the Switch?

If you are managing a large digital library in Pakistan, the benefits of Elasticsearch over the aging Zebra engine are clear:

Feature	Zebra (Old)	Elasticsearch (New)
Urdu/Arabic Search	Requires manual .chr file hacking.	Excellent (with ICU Plugin).
Performance	Slower with 14,000+ records.	Instant (Millisecond response).
Fuzzy Search	Basic.	Advanced (Handles spelling variations).
Stemming	Not native for Arabic.	Dedicated Arabic Stemmer available.

The "Fuzzy" Advantage for Sirah Research

In a Sirah-focused collection, titles often mix English, Urdu, and Arabic. Elasticsearch’s Fuzzy Searching is a lifesaver here. It bridges the gap between different transliterations, allowing a researcher to find "Sirah" even if they type "Seerah" or "Sira."

Final Verdict

Without the analysis-icu plugin, Elasticsearch is indeed "useless" for Urdu and Arabic scholarship. But with it, it becomes the most powerful tool available for modern digital libraries in the region.

Next Step: Check with your technical team today to see if the ICU plugin is active. It is the single most important toggle for the success of your digital catalog.