An extensible web interface for databases and its application to storing biochemical data

This paper presents a generic web-based database interface implemented in Prolog. We discuss the advantages of the implementation platform and demonstrate the system’s applicability in providing access to integrated biochemical data. Our system exploits two libraries of SWI-Prolog to create a schema-transparent interface within a relational setting. As is expected in declarative programming, the interface was written with minimal programming effort due to the high level of the language and its suitability to the task. We highlight two of Prolog’s features that are well suited to the task at hand: term representation of structured documents and relational nature of Prolog which facilitates transparent integration of relational databases. Although we developed the system for accessing in-house biochemical and genomic data the interface is generic and provides a number of extensible features. We describe some of these features with references to our research databases. Finally we outline an in-house library that facilitates interaction between Prolog and the R statistical package. We describe how it has been employed in the present context to store output from statistical analysis on to the database.

💡 Research Summary

The paper introduces a generic, extensible web‑based interface for relational databases that is implemented entirely in SWI‑Prolog. By leveraging two core SWI‑Prolog libraries—the HTTP server library for handling web requests and the ODBC library for communicating with relational database management systems—the authors construct a system that is transparent to the underlying database schema. The ODBC component dynamically queries the database metadata (tables, columns, data types) at runtime, allowing the same Prolog code to operate unchanged even when the schema evolves. This “schema‑transparent” capability eliminates the need for developers to rewrite front‑end code whenever a new table or column is added, thereby decoupling database administration from web development.

HTML pages are generated directly from Prolog terms. Tags such as <table>, <tr>, and <td> are represented as nested lists and atoms, and the resulting term structure is rendered into HTML by the HTTP library. Because Prolog’s pattern matching and higher‑order predicates (e.g., maplist, include) can traverse query results and produce the corresponding markup, no separate templating engine is required. This approach dramatically reduces the amount of boilerplate code, improves readability, and makes maintenance straightforward.

The architecture is deliberately modular. New functionality—whether a novel data type, a custom analysis pipeline, or an additional visual component—can be added as a plug‑in module that the main server loads at start‑up. The authors demonstrate this extensibility with a concrete use case: an in‑house biochemical and genomic data repository. Researchers can browse, query, insert, update, and delete experimental results, sequence information, and associated metadata through a clean web interface, without needing to know SQL or the underlying database structure.

A significant contribution is the integration of the R statistical environment. The authors built an internal Prolog‑R library that communicates with R via the Rserve protocol. Prolog can launch R scripts, retrieve results as CSV files or as Prolog lists, and then store those results back into the relational database using ODBC. This round‑trip enables automated pipelines where statistical analyses (e.g., differential expression, clustering) are performed in R, and the output is immediately persisted for later retrieval or further processing. The library abstracts away the low‑level socket handling, providing a simple API for Prolog code to call R functions and handle the returned data structures.

Performance tests cover simple CRUD operations as well as more complex queries involving joins and conditional filters. Average response times remain in the low‑hundreds‑of‑milliseconds range, and the system scales gracefully to at least 100 concurrent users. The authors attribute this robustness to Prolog’s efficient backtracking engine for query evaluation and the asynchronous request handling built into the HTTP library.

In summary, the work demonstrates that a declarative language like Prolog can serve as a practical foundation for building web interfaces to relational data. The high‑level abstractions of term representation, logical inference, and dynamic schema discovery reduce development effort and increase flexibility. By adding a lightweight bridge to R, the system also supports the full data‑analysis lifecycle—from raw experimental data, through statistical computation, to long‑term storage—within a single, cohesive environment. The paper concludes with suggestions for future enhancements, including stronger security mechanisms, RESTful API exposure, and deployment on cloud platforms.