Abstract
Digital publishing in the humanities presents specific challenges that general-purpose platforms do not fully address: complex bibliographic conventions, the central role of image-text relationships, editorial workflows that remain largely manual, and a scholarly culture that has been slow to adopt integrated digital tools. This paper presents PubLink, a modular toolset designed to bridge these gaps by connecting existing systems and standards rather than replacing them. Built around an intermediate exchange layer, the platform supports article ingestion in JATS XML, bibliographic reference resolution through external APIs, IIIF image annotation with privacy controls, and automated export to OJS for publication. The design prioritises interoperability with established formats and workflows, minimizing dependency on any single platform. We discuss the architectural decisions, the practical bottlenecks they address, and the lessons learned from deploying the system in a real editorial environment, including limitations encountered with hosted OJS instances and the constraints of project-based funding.
1 Introduction
PubLink 1 is an online system designed to address routine problems and limitations in the digital publication of research contributions in the humanities. It has been created to facilitate the enrichment of scholarly content digitally published within our institution, the Bibliotheca Hertziana — Max Planck Institute for Art History, later BHMPI. It also addresses the bottleneck generated when publishing on the Open Journal Systems (OJS)[23, 35] publishing platform when the editorial workflow is managed outside OJS and articles are uploaded only at the final stage via the Quick Submit Plugin [19]. The project idea stemmed from the initial experience with the publication of the first volume of the series Hertziana Studies in Art History [16]. At the time we were working together with the developers of SciFlow [25] to add the export for the Journal Article Tag Suite (JATS) XML [33] format. When we started uploading the papers to our OJS platform, maintained by Ubiquity Press [31], through the Quick Submit Plugin, we realised that manually inputting all metadata and dependent files was a long and tedious process that would often cause mistakes. The initial grant application was submitted in Fall 2021 and the project started in Spring 2023. The landscape of both digital publishing and software development in general has changed greatly since then, but we believe that we have created a system which has the flexibility to accommodate new or upgraded software components, as we have done already with the release of OJS 3.5 or TEI Publisher 10[10].
2 Background
The BHMPI is situated in Rome and encompasses an extensive library of books on the history of art and a collection of more than a million physical photographs, which have also been digitised and are now available online [8, 18], alongside two main Research Departments and several Research Groups. Its tradition for scholarly publishing dates back at least to 1937, when the first volume of what is now the Römisches Jahrbuch der Bibliotheca Hertziana [13] was printed. The institute's publications are highly regarded in the art history scientific community, with a clearly established editorial workflow. The digital publications were officially added in 2019[3]. Since their inception, the digital publishing infrastructure has been designed to integrate directly with the extensive digital collections of books, photographs and data held in the institute. PDFs are the most commonly used digital format in Art History, because the content relies on a layout where text and image need to be in a direct visual relationship. Moreover, bibliographies use a complex set of editorial rules to ensure the identification of bibliographic references in the absence of unique identifiers such as DOIs. On the author side, the research papers in Art History are usually submitted as plain text/text editor documents, with formatted bibliographic and caption lists and not in an integrated format with text and connected bibliography and images such as LaTeX. These submissions require extensive post processing to be published, either for print or digital typesetting. The digital publications, in addition to the standard editorial workflow, require the conversion of the bibliography to a structured format and its integration in the text body, making it more complex than traditional publishing in print. The PubLink project is part of the efforts to ease the additional workload. Digital Publishing is central to the Open Access and Open Science operations of the institute, which include a plan for a comprehensive Knowledge Graph and ongoing projects [1]. Publishing in XML/XHTML rather than PDF is essential to these goals, as it enables structured metadata, linked data integration, and enriched content that static formats cannot support. In the last years the BHMPI has been slowly moving the hosting of all digital contents on the Max Planck Society's own servers rather than outsourcing them to an external provider. This will provide the Institute with the necessary flexibility to address the requirement for advanced encoding in the humanities, which has not been fully met by the hosted platform, where shared rendering templates and limited customization options constrain the display of complex humanities bibliographies and enriched content. The work described in this paper was funded by a grant from DFG aimed at building infrastructure for digital scholarly publishing [7].
3 Design Philosophy
When designing PubLink we initially wanted to create an OJS plugin that imported JATS XML and metadata. This would have meant a continuous work of maintenance to keep up with any subsequent upgrade of the platform (we started with 3.3 and finished with 3.5), and this was not sustainable for a limited funded grant project like ours. This approach would also have limited the scope, as it would not include most of the scripts and tools already in use. In general, we made a conscious effort to avoid duplicating existing software solutions by integrating them into PubLink rather than reinventing them. For the parts of the workflow that are performed in a separate platform, like the conversion of the edited file with SciFlow [25] and the integration of the bibliography with Zotero [36], we created guidelines for straightforward import/export between them and our system. In line with this philosophy we have integrated a customised version of the Mirador IIIF viewer [17] that uses existing plugins to annotate images, and an instance of TEI Publisher to render the JATS XML on the fly. In other cases we have prepared a GUI for command line scripts that were already developed but not easy to use for an editor without coding experience, often adding functionalities that could not be handled by the command parameters [4, 5, 6, 28]. Moreover, we focused on exchanging files that were already encoded in established formats, such as JATS XML, IIIF manifests, Bib TeX bibliography files or OJS Native XML [21, 22] to import the final paper in OJS. PubLink acts as a sort of glue connecting the various components and pathways of our digital publishing pipelines that are already functioning well. This includes external platforms like SciFlow for encoding, OJS [23] as publishing portal and a customised version of TEI Publisher [10]. While the JATS export in SciFlow was commissioned prior to this project, most of the TEI Publisher JATS integration was developed in collaboration with e-editiones specifically for PubLink. It is available as a standard Jinks profile [9] and can not only provide a native interface for displaying JATS XML (see Figure 2), but also lets users annotate the article text directly, while retaining the native IIIF image handling already in use for TEI XML critical editions.
4 System Architecture
When analysing the workflow involved in publishing digital content at the BHMPI, many operations in our pipelines involve the transformation of files from one representation to another (or to an alternative version of the existing representation). However, while this is something that can easily be achieved with XSLT or Python based transformations, we also needed users to be able to review and edit the metadata and content prior to processing them. One of the core steps in importing JATS encoded articles as galleys and metadata into OJS [28], as well as improving and integrating references, required the system to be able to read and if necessary write to the XML prior to the conversion into OJS Native XML. Therefore, at the centre of the platform there is a File System for each registered user that enables the upload and processing of different file types.
4.1 Interoperability
A key design requirement was interoperability with the heterogeneous document formats and systems already in use in scholarly publishing workflows. Rather than imposing a single format, the platform acts as an intermediate exchange layer across the publishing pipeline, supporting ingestion, transformation, and export across the formats and services listed in Tables 1 and 2.
Table 1: Supported document formats.
Format | Direction | Role |
|---|---|---|
JATS | Import | Article ingestion and processing |
Bib TeX | Import | Bibliographic reference loading |
CSL | Rendering | Citation style formatting |
OJS XML | Export | Publication to OJS instances |
DataCite XML | Export | Metadata deposit to DataCite |
IIIF Manifests | Export | Image region and annotation display |
Table 2: Internal / External service integrations.
Service | Protocol | Role |
|---|---|---|
ORCiD | OAuth | User authentication |
CrossRef, Alma, Google Books | REST APIs | Bibliographic resolution |
Mirador | IIIF | Image annotation |
IIIF Manifest Server | IIIF | Image publication |
PubLink supports digital publications at various stages of the editorial workflow, up to the OJS-ready publication and DOI metadata. JATS files are typically produced outside the platform using SciFlow [25], which also handles conversion from authors’ edited text editor documents, reference annotation, and metadata management [6]. It is possible, in the future, that JATS files might be generated and edited directly inside PubLink, either with the support of TEI Publisher or with a local SciFlow Open Source [26]. Once imported, article metadata and bibliography are extracted from the JATS ref-list, exposed for review (see 5.1), and can be enriched through external bibliographic services (see 5.2). Bibliographic curation by editors and authors can also happen upstream, by loading a Bib TeX file in preparation for reference annotation in SciFlow. The JATS XML article is usually just one of several galleys published for a paper, and needs to be combined with attachments and dependent files to generate OJS Native XML [22]. Moreover, since the Native XML schema changed between OJS versions 3.3, 3.4, and 3.5, the platform generates version-specific exports to ensure compatibility with the target instance. One benefit of accessing the full bibliography in a structured format is that the platform can export DataCite "cited by" metadata to supplement the standard OJS DataCite export, which is not content-aware. This gives published articles richer cross-citation in their DOI records without the need for paid services. Last but not least, it is important for authors and editors, especially in art history, to be able to annotate images and create manifests in IIIF, as this makes it possible to establish direct links between text descriptions and annotated details. Simple standalone interfaces are also available for creating image comparisons [5]. It is crucial that annotations and manifests can be stored and shared, as this information is often an integral part of an article and needs to be safely accessible from the Simple Manifest Server (see 5.3, 5.4).
A flowchart that shows the way all parts of the workflow are integrated together
Figure 1 illustrates the overall system architecture. The platform is organised around three main components: Article Processing, Image Annotation, and Job Processing. Imported JATS articles are serialised into an intermediate object model from which format-specific adapters generate the required outputs. This design allows new input and output formats to be added at low cost by implementing additional adapters. An asynchronous job queue handles background tasks flexibly, while the annotation server integrates tightly with the Mirador viewer and annotation client.
4.2 Authentication
The system uses ORCiD for user authentication, enabling users to log in with their existing scholarly credentials. This requires the institution to register for ORCiD API keys. Local password-based accounts are also supported for testing and local Docker deployments — for example, to allow anonymous access for grant reviewers evaluating the platform — but are discouraged in production unless a mail confirmation service is available to verify user identity.
5 Core Functionalities
OJS is one of the most used Open Access publishing platforms [11], and it incorporates the submissions, the peer review and the editorial management of articles. Unfortunately the idea of connecting with authors and reviewers through an anonymous technical interface is still frowned upon in the humanities, and even more in Art History, where all the steps, included double blind peer review which is often managed according to practices that have been established for decades if not a century. For this reason, the import into the platform is often a task carried by the managing editor at the end of the editorial process. This means that all the data and files are entered and uploaded as a last step, usually through the Quick submit plug-in: this is a very long process when multiple galleys and images need to be uploaded. The only way to upload all files and information together is through the import/export options natively included in the OJS platform for backup management. A related approach [32] was to generate the XML file that would incorporate the attachments as Base64 and mimic the actual export from the platform, starting from a spreadsheet and a folder structure. However, since we needed to include multiple galleys and our content already had all the necessary information embedded in the JATS XML metadata, the spreadsheet-based approach was not sufficient. We decided instead to use the JATS metadata as the basis for generating our Native XML file by exposing each piece of information directly.
5.1 Article Processing
The JATS upload option is offered to users first, as it is the main source for many subsequent steps. Once a JATS article has been uploaded, it is automatically validated against the official DTD and processed. This step creates an object model of the article that is stored in the underlying platform database in serialised form. This format was developed to enable users to edit the article metadata, author information, article abstract and keywords via a GUI and to add data not already available in the JATS front section. The serialised article lies at the heart of the export process, as it pre-fills all the metadata that would usually be entered manually in OJS. From this interface, it is possible to combine files uploaded through other forms that are needed as dependent files of the article (e.g., images or tables) or alternative galleys (e.g., PDF or HTML) prior to generating the final Native XML. This step is useful because OJS stores each element directly in the database in Base64 format, and the process of uploading and converting takes a long time, with the risk of losing track of how many images have already been loaded. Also, extracting the metadata from the JATS article eliminates errors that occur when re-entering information manually — in practice, entering metadata for multiple articles in sequence led to author information from one article being inadvertently applied to another. Not only is the Native XML significantly faster, but a single file that can be assembled from a simple interface can also help reduce such errors.
From the same interface, it is also possible to generate the DataCite XML ’Cited by’ section, which needs to be manually included in the DOI of each paper. However, we only export the seeded section, as DataCite is now fully integrated with OJS for DOI management — especially after version 3.5 — and the section can easily be pasted via the Fabrica interface.
5.2 References and Reference Resolution
Working with author-provided references often requires verifying that spelling is correct and that all bibliographic information is present. Sometimes information is missing in the JATS itself because the export from SciFlow removes page numbers from articles; in other cases, new DOIs have been added through retro-digitalisation of historical books and articles and need to be included. In addition, standalone scripts [4] address recurring structural errors in the JATS XML produced by upstream encoding tools — such as incorrect element usage across publication types, dropped contributors, or broken citation key mappings — that would otherwise require manual correction for every article. These scripts fix mechanical errors automatically and flag ambiguous cases for editorial decision, so that the article imported into PubLink starts from a clean baseline. The integration of these repair scripts directly into the PubLink interface is currently underway.
To further enrich the references, we have integrated three external APIs: CrossRef, Alma (an institutional library catalogue) and Google Books (used for resolving book and chapter references). The reference resolution system works both from the JATS XML ref-list and the Bib TeX as follows:
For any individual reference the user can check against any or all of the services offered on the fly by clicking a button to execute the search.\
The user is also able to apply all searches to all references in an article in a single action. While the search is ongoing, the article is locked to prevent conflicts, as the asynchronous job queue processes multiple API calls in the background.\
Once the search has completed, the user is presented with a panel of matches and can select and insert individual fields retrieved from the API into the reference record itself.\
The references can be enriched in this way and, if desired, a Bib TeX representation of the reference information can be generated and attached to the article as a galley file. To improve readability, it is possible to preview the bibliographic items using a CSL [14] rendering engine [20]: the styles displayed by the system can be configured in the system's config file.
Screenshot of an actual article annotated with semantic information
A screenshot of the user interface showing how the reference management works
5.3 IIIF Image Annotation
The relationship between text and images is central to art history scholarship: the ability to reference a specific detail within a larger image, compare works held in different repositories, and annotate visual content with curated information are essential to the discipline. The IIIF protocol suite supports all of these operations, but its use in article publishing remains experimental and is not yet fully integrated into the JATS standard. We identified that the first step toward publishing such enriched content was to provide authors and editors with a stable platform for creating and sharing annotations and manifests during the editorial process.
A survey of existing IIIF annotation tools and servers [2, 24] identified the Mirador viewer and its annotation plug-in [17] as a mature solution for creating annotations, but no available annotation server fully met our requirements for persisting them. In particular, most servers lacked support for private annotations — a critical need during peer review, where an author may wish to share annotations only with collaborators rather than making them publicly accessible. We therefore implemented a lightweight annotation server directly within PubLink, tightly integrated with a locally deployed Mirador instance. When launched from within the PubLink interface, the Mirador client receives the user's session credentials and the address of the PubLink annotation server API. Annotations created in Mirador are stored via this API and appear simultaneously in both the Mirador client and the PubLink interface, where they can also be deleted and shared with other platform users.
The annotations are persisted in the IIIF Web Annotation format and can be embedded into IIIF manifests for publication. For example, a manifest generated through PubLink can display annotations superimposed on the source image in compatible viewers such as Theseus [27]. The interface can also generate direct links to zoomed regions of annotated images, which has proved useful during the editorial review of illustrations. PubLink can also extract graphics references and captions from the article's JATS metadata to generate an initial manifest of all images in the article. This manifest can be saved to the Simple Manifest Server and imported into the comparison generator to build multi-image layouts, or loaded into the annotator as a starting point for editorial review.
In addition to annotation, a standalone IIIF manifest and comparison generator [5] was developed to support common editorial tasks involving image analysis.2 The tool runs entirely in the browser with no server requirement; working sessions are stored locally and can be exported as JSON. It allows users to create structured comparison layouts — such as side-by-side, grid, or storyboard arrangements — from images held across different IIIF repositories, and to generate valid IIIF Presentation 3 manifests directly in the browser. A layer alignment mode enables the precise positioning of images on a shared canvas, with per-layer opacity, rotation, and mirroring controls; this supports use cases such as reintegrating a detail with its source image or comparing states of a work across time. Generated manifests can be published directly to the Simple Manifest Server via its API or to GitHub Pages. By enabling scholars to create meaningful visual arrangements where spatial relationships carry interpretive value, these tools strengthen the semantic linking capabilities of the IIIF ecosystem in the context of scholarly publishing. 3
A potential future development is the use of ontology-based structured annotations in place of free text, which would require collaboration with authors working on publications where such formal vocabularies are already in use.
5.4 Simple Manifest Server
Once annotations and manifests are ready for publication, they need to be served alongside the finished article. To address this, we developed the Simple Manifest Server [30], a lightweight service for uploading, validating and hosting IIIF manifests. Manifests are validated against the IIIF schema [12] before publication — documents that fail validation cannot be published. Published manifests are openly accessible without authentication, while uploading requires credentials. The server is integrated with PubLink: manifests generated within the platform can be published in a single step. However, the server also operates independently — manifests produced outside PubLink, for instance image comparisons created with standalone IIIF tools [5], can be uploaded and managed through a separate interface. This flexibility has led to its adoption beyond the original scope of the project, supporting the publication of manifests for critical digital editions that combine IIIF images with TEI-encoded texts at the institute.
5.5 Asynchronous job processing
Several operations in the platform — such as resolving references against external APIs, serializing articles from JATS XML, or extracting embedded images — can be time-consuming or unpredictable in duration. To prevent these from blocking the interface, PubLink processes them through an asynchronous job queue. Tasks are executed in the background and the user is notified upon completion, but can continue working in the meantime. In most cases the process is fast enough to feel immediate; the asynchronous architecture ensures that the system remains responsive regardless. The queue is designed to be extensible: new document transformations can be added as self-contained units with defined input and output formats, without modifying the core platform. This has allowed independently developed processing steps to be integrated into the pipeline incrementally as needs evolved over the course of the project.
6 Conclusion
Since the start of the project we have had the opportunity to present PubLink and share the public instance with both researchers and experts in the digital publishing field. The need to import complete articles into OJS is clearly shared with other institutions, whether to upload historical collections where the submission steps were fulfilled long ago, or in institutes that are not yet fully embracing digital publication. The main use case of our work has been, so far, our own digital publications, where the Native XML import has significantly reduced the time and errors associated with article preparation. The IIIF tools have also found adoption beyond the original scope, supporting critical digital editions at the institute.
Several practical limitations emerged during deployment. The Native XML import works reliably only when the file size is manageable for PHP processing, unless direct server access is available for local import. More significantly, when an OJS instance is heavily customised by an external service provider, the generated XML may not be fully compatible — in our case, after an upgrade to OJS 3.4, we were unable to upload files until the provider revised their customisations. For IIIF annotations, the Simple Manifest Server solved the problem of publishing manifests alongside articles, but the annotations can only be fully showcased when the editorial team has complete control of the display interface, which was not possible on the externally hosted OJS instance. These experiences underscore a broader challenge in open standards adoption: interoperability depends not only on adherence to published specifications, but also on the degree of control institutions have over their own infrastructure.
Looking ahead, the system's modular architecture positions it well to adapt to a changing landscape. The announced integration of SciFlow Open Source as the internal JATS editor in OJS 3.6 [15, 26] validates one of the core assumptions of our design — that JATS XML would become central to the OJS publishing workflow. However, this addresses in-platform text corrections rather than the upstream encoding and import pipeline; the need to enrich bibliographic data, assemble multiple galleys, and generate validated Native XML remains. Some components, such as the optimisation of SciFlow's bibliography output, have become less relevant as AI-assisted tools have changed reference management practices. Others, like the JATS XML display through TEI Publisher, were developed late in the project following the release of version 10 in January 2026 and have not yet been fully tested in production. Nevertheless, each component of the platform addresses a real and transferable need in scholarly digital publishing that extends beyond art history.
Notes
1
2The IIIF manifest and comparison tool was significantly expanded after the initial submission to include comparison layouts and layer alignment capabilities.
3Examples of multi-image canvases generated by this tool are already published [34].
Source
Imported from ACM’s structured HTML source. ACM Reference Format: Elisa Bastianello and Christopher David Tomlinson. 2026. Bridging Digital and Publishing in the Humanities: Connecting Editorial Workflows through Open Standards. In 37th ACM Conference on Hypertext (HT '26), September 14--18, 2026, London, United Kingdom. ACM, New York, NY, USA 7 Pages. https://doi.org/10.1145/3800935.3830875
References
[1] Alessandro Adamou and Polina Voronova. 2025. Mediating Art History Data Models for Native Linked Data Construction using ResearchSpace. In Digital Heritage, Stefano Campana, Daniele Ferdani, Holger Graf, Gabriele Guidi, Zackary Hegarty, Sofia Pescarin, and Fabio Remondino (Eds.). The Eurographics Association, Siena Italy, 4. https://doi.org/10.2312/dh.20253276
[2] Annotot n.d. Annotot. https://github.com/PenguinParadigm/annotot/tree/main
[3] Elisa Bastianello. 2022. Digital Editions at the Bibliotheca Hertziana. Journal of Art Historiography 27s (2022), 7.
[4] Elisa Bastianello. 2024. Jats Refactoring Tools. https://github.com/biblhertz/jats_refactoring
[5] Elisa Bastianello. 2025. IIIF Editorial Toolkit. https://github.com/biblhertz/iiif-editorial-toolkit
[6] Elisa Bastianello, Christopher Tomlinson, and Alessandro Adamou. 2024. PubLink: Editorial Workflow for Digital Scholarly Publications in the Humanities. In Proceedings of the 35th ACM Conference on Hypertext and Social Media. ACM, Poznan Poland, 318–322. https://doi.org/10.1145/3648188.3677051
[7] Deutsche Forschungsgemeinschaft (DFG). 2022. DFG - GEPRIS - PubLink: A Toolset for Enriching Scholarly Digital Publications. https://gepris.dfg.de/project/501142032
[8] Digital Library n.d. BHMPI Digital Library. https://dlib.biblhertz.it/
[9] e-editiones. 2026. Jinks. https://github.com/eeditiones/jinks
[10] e-editiones. n.d. TEI Publisher Documentation and Demo. https://teipublisher.com/index.html
[11] Brian D. Edgar and John Willinsky. 2010. A Survey of Scholarly Journals Using Open Journal Systems. Scholarly and Research Communication 1, 2 (June 2010), 22. https://doi.org/10.22230/src.2010v1n2a24
[12] IIIF n.d. IIIF Presentation Validator. https://github.com/IIIF/presentation-validator
[13] Jahrbuch n.d. Römisches Jahrbuch der Bibliotheca Hertziana. https://www.biblhertz.it/en/pub/roemisches-jahrbuch
[14] Citation Style Language. n.d. Citation Style Language. https://citationstyles.org/
[15] Magnus Lu. 2026. OJS 3.6: Bringing Manuscript Editing and Production under One Roof. Public Knowledge Project. https://pkp.sfu.ca/2026/05/26/ojs-3-6-bringing-manuscript-editing-and-production-under-one-roof/
[16] Tanja Michalsky and Martin Thiering (Eds.). 2022. Walking Through History. An Interdisciplinary Approach to Flavio Biondo's Spaces in the "Italia Illustrata". Hertziana Studies in Art History, Vol. 1. Bibliotheca Hertziana — Max Planck Institute for Art History, Munich-Rome. Vol. 1 (2022) pages. https://doi.org/10.48431/HSAH.0100
[17] Mirador n.d. Project Mirador. https://projectmirador.org/
[18] Photo Collection n.d. Bibliotheca Hertziana Fotothek. https://foto.biblhertz.it/
[19] PKP. 2024. OJS QuickSubmit. https://github.com/pkp/quickSubmit
[20] PKP. 2026. pkp/citeproc-php. https://github.com/pkp/citeproc-php
[21] PKP. n.d. Import and Export - Admin Guide - PKP Developer Docs. https://docs.pkp.sfu.ca/admin-guide/en/data-import-and-export.html
[22] PKP. n.d. Native XML Import/Export. https://github.com/pkp/ojs/blob/main/plugins/importexport/native/native.xsd
[23] PKP. n.d. Open Journal Systems. https://pkp.sfu.ca/software/ojs/
[24] SAS n.d. Simple Annotation Server. https://dev.gdmrdigital.com/
[25] SciFlow. n.d. SciFlow - Writing and Publishing Simplified. https://www.sciflow.net/en/
[26] SciFlow. n.d. SciFlow Open Source. https://sciflow.org/
[27] Theseus n.d. Theseus IIIF viewer. https://theseusviewer.org/
[28] Christopher Tomlinson. 2023. JATS to OJS. https://github.com/biblhertz/jats_to_ojs
[29] Christopher Tomlinson. 2024. PubLink. https://github.com/biblhertz/PubLink-Public
[30] Christopher Tomlinson. 2026. PubLink Simple Manifest Server. https://github.com/biblhertz/PubLinkSMS
[31] Ubiquity-Site n.d. Ubiquity Press. https://ubiquitypress.com
[32] University of Alberta Library. 2026. ualbertalib/ojsxml. https://github.com/ualbertalib/ojsxml
[33] U.S. National Library of Medicine. n.d. Journal Article Tag Suite. https://jats.nlm.nih.gov/
[34] Cecilia Vicentini. 2025. Pirro Ligorio e la cultura antiquaria alla corte e ‘attorno’ alla corte di Alfonso II d'Este. In Pirro Ligorio e l'Italia. Antichità locali e cultura antiquaria, Antonia Di Tuccio and Marina Guarente (Eds.). Hertziana Studies in Art History, Vol. 4. Bibliotheca Hertziana — Max Planck Institute for Art History, Munich-Rome. https://doi.org/10.48431/hsah.0410
[35] John Willinsky. 2005. Open Journal Systems: An example of open source software for journal management and publishing. Library Hi Tech 23, 4 (Jan. 2005), 504–519. https://doi.org/10.1108/07378830510636300
[36] Zotero. 2006. Zotero. Your personal research assistant. https://www.zotero.org
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime