The digital infrastructure of online catalogues raisonnés

Digital catalogue raisonné publication depends primarily on reusable infrastructure rather than independently commissioned software. Among the 112 records in the analytical set, 77, or 68.8%, are delivered through a specialist catalogue platform, a shared institutional publishing framework, or a general collections platform adapted for catalogue publication. Only nine, or 8.0%, are bespoke web applications. The field is therefore better understood as an ecology of shared, adapted, and layered systems than as a progression from improvised tools to custom development.

Eva Gonzalès, La Plage de Dieppe: Vue prise du château, c. 1871-72. Oil on canvas, 28.5 x 70 cm. Château-Musée de Dieppe; in the public domain.

The analytical set comprises 93 live catalogues raisonnés, 10 partial catalogues or digital corpora, eight projects in progress or accepting submissions, and one record whose publication status remains unclear. Their public delivery systems fall into eight categories:

  • 52 specialist catalogue-raisonné platforms, 46.4%

  • 16 CMS-led publications, 14.3%

  • 15 shared institutional publishing frameworks, 13.4%

  • 10 general collections platforms adapted for catalogue-raisonné publication, 8.9%

  • 9 bespoke web applications, 8.0%

  • 5 hybrid systems, 4.5%

  • 3 static or legacy sites, 2.7%

  • 2 systems whose current delivery category remains unknown, 1.8%

Specialist platforms form the largest category, although they do not constitute a majority of the dataset. They provide environments designed around the requirements of catalogue-raisonné publication, including structured object records, bibliography, provenance, exhibition history, image management, and mechanisms for revision. Their prevalence indicates that a substantial part of the field now depends on reusable technical services rather than applications commissioned for a single catalogue.

This part of the field is also concentrated. The two most common specialist systems support 46 of the 112 records. A count of catalogues is therefore not equivalent to a count of independent technical systems. Multiple catalogues may share a codebase, hosting arrangement, maintenance cycle, or vendor. Record-level percentages describe how catalogue scholarship is delivered, but they do not represent the number of distinct applications or development decisions.

A further 31 records, 27.7% of the analytical set, use CMS-led publications, adapted collections platforms, or hybrid systems. These categories demonstrate that catalogue publication frequently proceeds through the configuration and combination of existing technologies. A CMS-led publication organizes the public interface primarily through a general content management system. An adapted collections platform begins with software designed for museum or collection management. A hybrid combines components whose functions remain technically distinct. These approaches occupy different positions between standardization and local control, and they require different forms of maintenance and technical expertise.

The 15 shared institutional publishing frameworks represent another model of reuse. Here, a single institution provides a common technical environment for several scholarly publications. Such frameworks pool hosting, development, maintenance, and preservation capacity across projects. Their importance lies less in a particular software stack than in the organizational structure that allows technical resources to be shared.

Bespoke development accounts for nine records. Three additional records are static or legacy sites, while two cannot be classified confidently from the available public evidence. These groups should not be collapsed. A bespoke application is supported by positive evidence of development for a specific publication. A legacy site describes an older or largely static mode of delivery. An unknown system is one for which the evidence does not support a responsible architectural conclusion. The absence of a recognizable platform or CMS signature is not, by itself, evidence of custom development.

Current front-end frameworks are more common in reusable systems than in individually commissioned applications. Twenty-nine records expose Angular, React-based frameworks including Next.js, or Nuxt in their public delivery layer. Twenty-four of those 29 belong to specialist platforms or shared institutional frameworks. Five are bespoke or hybrid applications. In this dataset, contemporary JavaScript frameworks appear most often where one technical system can serve several catalogues.

Framework choice alone does not determine whether a catalogue is sustainable. A current front end does not guarantee durable infrastructure, while WordPress, Drupal, PHP, or a server-rendered interface does not necessarily indicate technical fragility. Long-term viability also depends on maintenance, documentation, security practice, data portability, contractual continuity, institutional knowledge, and preservation planning. Most of these conditions cannot be inferred from the public website.

The demographic fields associated with the retained records identify 12 women, 10.7% of the analytical set, and nine artists coded as people of colour, 8.0%. Three of the nine are coded as being of African descent. These provisional, aggregated variables cannot represent the full complexity of identity and should not be treated as a complete demographic account of the dataset.

Six of the 12 women are documented through specialist catalogue platforms. Two are associated with bespoke applications, two with shared institutional frameworks, one with an adapted collections platform, and one with a CMS-led publication. Seven of the nine artists coded as people of colour, including all three coded as being of African descent, are documented through specialist platforms. The remaining two are divided between a bespoke application and an adapted collections platform.

These distributions do not demonstrate that specialist platforms cause greater representation. They do show that the records associated with women and artists coded as people of colour are not concentrated in bespoke systems. Specialist and shared infrastructure may lower some organizational barriers to publication, but testing that proposition would require evidence about costs, contracts, selection practices, funding, staffing, and project governance.

The dataset does not establish a causal relationship between an artist's market position and the technical architecture of a catalogue. It contains no systematic data on auction results, market valuations, foundation endowments, project budgets, staffing levels, or maintenance costs. Technical categories may be consistent with unequal access to institutional and commercial resources, but they cannot explain those inequalities on their own.

What the results establish is that digital catalogue scholarship is materially organized through different forms of technical and institutional capacity. Specialist platforms provide purpose-built services. Shared institutional frameworks pool resources across publications. Collections platforms and content management systems are adapted to catalogue-specific purposes. Bespoke applications provide greater local specificity but represent a small part of the dataset. These arrangements influence what can be published, how records can be revised, which forms of searching and linking are possible, and what kinds of maintenance a project requires.

Methods: Identifying the public technology stack

Each catalogue URL was examined as a layered public application rather than assigned a category from visual appearance alone. The technical analysis combined direct HTTP requests, inspection of page source, browser developer tools, network activity, and first-party documentation. It recorded separately the identifiable platform or vendor, content management system, front-end framework, data-delivery layer, and hosting or infrastructure signals. This separation was necessary because a single publication may use, for example, an institutional website as its editorial shell, a specialist application for catalogue records, an API for structured data, and a third-party service for hosting or image delivery.

The principal forms of evidence were:

  • HTTP response headers. Requests to the catalogue and its principal application routes were inspected for fields such as Server, X-Powered-By, X-Generator, Via, cache headers, and CDN-specific headers. These can identify a web server, application framework, proxy, or hosting layer. Because headers may be removed, rewritten, or inherited from an intermediary service, they were treated as supporting evidence rather than definitive identification.

  • HTML metadata and source structure. Rendered HTML and page source were checked for generator metadata, structured comments, manifest references, script and stylesheet locations, canonical URLs, and other implementation markers. Content management systems often expose recognizable directory conventions or generated asset patterns even when their names do not appear in the visible interface.

  • JavaScript bundles and static assets. Asset paths and application bundles were used to identify delivery frameworks. Paths such as /_next/static/, /_nuxt/, /wp-content/, and /core/ can indicate Next.js, Nuxt, WordPress, or Drupal respectively. Bundle names and publicly exposed build information supplied additional corroboration. Such evidence identifies the public front end or CMS layer; it does not necessarily identify the underlying research database.

  • Network requests and data endpoints. Browser network activity was examined for fetch and XHR requests, GraphQL endpoints, REST routes, JSON payloads, search services, image APIs, and calls to external domains. These observations helped distinguish a largely static publication from a client-rendered application and showed whether catalogue data was embedded in pages, requested from a CMS, or delivered through a separate service.

  • Public credits and first-party documentation. Footer credits, platform acknowledgements, institutional documentation, vendor case studies, and official project descriptions were used to confirm relationships that could not be established from code signatures alone. Where a technical arrangement had been directly confirmed by a researcher or project representative and that confirmation was documented, it was used as corroborating evidence.

No single fingerprint was assumed to identify an entire stack. Signals were compared across layers and against first-party statements. A CMS marker could identify an editorial shell without identifying the catalogue database; a JavaScript framework could identify the interface without revealing the software used to manage records; and a hosting header could identify infrastructure without establishing who developed or maintains the application. When public evidence was incomplete, contradictory, blocked, or accessible only through manual interaction, the classification was assigned a lower confidence level rather than inferred from absence.

The classifications concern the public delivery layer. Among the 112 retained records, 106 are classified with high confidence, five with medium confidence, and one with low confidence. They do not describe private research workflows, unpublished databases, contractual arrangements, staffing, or the scholarly authority and completeness of catalogue content.

The dataset is curated and purposive rather than representative. Without a defined sampling frame for the full population of online catalogues raisonnés, its percentages cannot be treated as estimates for the field as a whole. They describe this analytical set and identify patterns that can be tested through broader research.

Within those limits, the dominant pattern is clear. Online catalogue-raisonné infrastructure is not arranged as a ladder from improvised tools to bespoke systems. It is an ecology of specialist platforms, institutional frameworks, adapted collections systems, general content management systems, and a small number of custom applications. Reusable and shared systems account for most of the catalogue delivery represented in the dataset.

The central question is therefore not simply who can afford a custom website. It is who can secure durable participation in the technical systems through which a catalogue remains available, revisable, portable, and intellectually accountable.

Previous
Previous

What a confidence score can’t tell you: AI and the authorship of paintings

Next
Next

Frequently asked questions: Digital catalogue raisonné software and technology