Library metasearch: how federated search works and how it differs from discovery

The problem: a library is several systems, not one

A typical university library runs at least four separate systems: the catalog of its integrated library system (Koha, for example), the open-access institutional repository (DSpace), a set of subscribed commercial databases (the likes of EBSCO, Scopus, JSTOR or ProQuest) and, increasingly, its own journals published on OJS. Each one has its own interface, its own search syntax and, for commercial databases, its own login.

The practical result is that a student researching "climate change and public policy" has to decide where to search before typing anything. The catalog, in case there is a book? Scopus, in case there is an indexed article? The repository, in case a professor has already written about it? Most do not choose well: they try one source, find nothing relevant there and give up. It is the most common, and least discussed, reason why the databases a library pays for every year are underused. They work fine; almost nobody reaches them.

How library metasearch works: federated search vs a pre-built index

There are two ways to build a single search box, and the difference is not cosmetic. The first is real-time federated search: the metasearch engine receives the user's query, forwards it in parallel to each connected source using the protocol each one exposes, and assembles the combined results on the spot, against what each system holds right now. The second is the pre-built index of classic discovery services: the system periodically harvests metadata from each source (daily or weekly) and stores it in its own database, so each search queries that index rather than the original sources. Commercial discovery services such as EBSCO Discovery Service, Primo and Summon, often grouped under the label web-scale discovery, follow this index-based model.

The advantage of a pre-built index is speed: it does not depend on several external systems answering in time. Its cost is currency: something added to a database yesterday may take days to appear, and something a provider withdrew can keep showing as available for a while. Real-time search inverts the trade-off: what the user sees is exactly what each source holds at that moment, with no staleness window, but the response depends on the connected sources being up and answering quickly.

BiblioMeta is built on the real-time model: it queries sources live instead of relying on a pre-established index, so results reflect what the library has available now, not a snapshot from last week. Repositories and OJS journals are usually integrated through OAI-PMH, which means their metadata is harvested in scheduled cycles; repositories change slowly enough that users do not notice the difference.

Federated search vs discovery: which one fits your library

Neither model is better in the abstract. A central index offers broad coverage of commercial full text and very fast responses, which is valuable for institutions with very large subscription portfolios. Real-time search wins on currency, on the visibility of the institution's own content, which commercial indexes tend to cover least well, and on independence from the agreements a third party holds with each publisher.

If your priority is results that are always current, with no index to maintain, metasearch is the stronger option. If you handle enormous volumes and response speed is the most critical factor, an index-based discovery service may fit better. They are different decisions, not a ranking, and the right one depends on your sources and your users.

Which sources a metasearch engine can unify

In a typical implementation, the connected sources are the integrated library system catalog, the open-access institutional repository, subscribed commercial databases, the library's own journals on OJS and, for universities, open aggregators such as LA Referencia or OpenAIRE. The more separate sources a library has, the more value unifying them brings, because the problem a metasearch engine solves grows with the number of systems that coexist today without talking to each other. If you do not have a repository yet, our guide to the institutional repository explains what it adds.

The protocols that make integration possible

None of these connections is automatic: each source exposes, or does not, a standard way for an external system to query it. The most common in libraries are:

• Z39.50 and its web-era successor SRU, to query bibliographic catalogs in real time. Koha exposes both natively.
• OAI-PMH, to harvest metadata from repositories and journals such as DSpace and OJS.
• REST APIs, specific to each commercial database when the provider offers one, each with its own authentication and usage limits.
• SPARQL, for linked-data sources in more advanced integrations.

When a source exposes none of these, integrating it stops being configuration and becomes custom development, with a different cost and timeline. Some providers expose an API on request; others only allow deep links into their own interface. BiblioLabTech verifies which protocol each source really exposes, and whether its license allows automated queries, before quoting any project, because promising that "everything will be connected" in phase one is how integrations break at go-live.

From Boolean syntax to natural language

Beyond unifying sources, a metasearch engine can change how people ask. Traditional systems, catalogs and commercial databases alike, still rely heavily on Boolean operators and thesauri that a first-year student does not know and should not need to know. BiblioMeta Académico lets users search in natural language, with no technical syntax, ranks the combined results by relevance with AI support, and turns the question into an optimized Boolean search string. That string stays visible and editable, so experienced searchers can refine it and students can see how their question translates into search syntax.

User education changes as a result: instead of spending a session on syntax and wildcards, librarians can teach what matters, such as how to evaluate a source or how to spot a predatory journal.

Metasearch does not replace your catalog or your databases

Precision with vocabulary matters here: a metasearch engine does not replace the catalog or the databases; it joins them. Each source keeps existing, with its own content and access rules; what changes is that users no longer need to know which one holds what they are looking for.

The cost of not having one is concrete: annual database subscriptions the library keeps paying and most users never open, because they never reach them. In BiblioLabTech projects, the argument that most convinces a finance office is not user experience, although it matters, but the return on subscriptions already paid for. A usage dashboard makes that visible: what people search for, which resources they actually open and which searches return nothing. Zero-result searches are often the most useful figure, because they point to real gaps in the collection or in how it is described.

BiblioMeta and BiblioMeta Académico: same base, two audiences

BiblioMeta is designed for libraries in general (public, school and special libraries) with centralized search, real-time results, exploration by topic, resource type and audience, branding with the institution's identity and a usage-statistics dashboard.

BiblioMeta Académico adds what a university needs on top of that base: natural-language search, integration through standard protocols with catalog, repository, databases and aggregators, an interface built to WCAG 2.1 AA accessibility guidelines with multilingual support, integrated remote access (proxy) so students can use paid databases from off campus, and an AI research assistant included at no extra cost. When BiblioLabTech implements this for a university, the starting point is almost always BiblioMeta Académico, because it already solves remote access, the question students raise first at any kickoff meeting. Our guides to the library proxy for remote access and to the AI research assistant cover those two layers.

A real case: four systems, one search box

At the Escuela Colombiana de Ingeniería Julio Garavito in Bogotá, BiblioLabTech implemented BiblioMeta on an infrastructure that already included Koha, DSpace and a conversational reference assistant. The metasearch engine was published as the single search entry point, with an administration panel and real-time usage statistics, so the library can see what people search for and which resources they actually use, not just which ones it pays for.

When metasearch makes sense, and what it costs

A metasearch engine is justified when the library already has more than one source worth unifying: catalog and repository, catalog and subscribed databases, or all three. If the library has only a catalog and no active subscriptions, there is nothing real to federate yet, and the sensible move is to wait until that second system exists.

Cost depends on how many sources must be integrated, not on the software itself. These are the reference ranges BiblioLabTech publishes for initial implementation:

• BiblioMeta: projects that integrate a catalog and a handful of well-documented standard sources usually fall between USD 2,000 and 4,000, excluding hosting and recurring support.
• BiblioMeta Académico: projects that add natural-language search, the AI research assistant and integrated remote access across several commercial databases typically fall between USD 4,000 and 9,000, with the upper end for institutions with many subscribed databases and several providers to coordinate.

Typical timelines are two to three months for BiblioMeta, and three to four months for BiblioMeta Académico, including a pilot with researchers. Connecting a Koha catalog or a DSpace repository is direct; a commercial database may require steps with the provider that do not depend on us. Hosting and recurring support, which covers monitoring connections and adjusting them when a provider changes its interface, are quoted as separate, explicit lines. BiblioLabTech quotes source by source on your real inventory, so proposals can be compared fairly. Send us your list of sources and we will scope your project.