Benchmarking and Lessons Learned from Using SharePoint as an Electronic Lab Notebook in Engineering Joint Research Projects

Abstract

The adoption of Electronic Lab Notebooks (ELNs) significantly enhances research operations by enabling the streamlined capture, storage, and dissemination of data. This promotes collaboration and ensures organised and efficient access to critical research information. Microsoft SharePoint^® (SP) is an established, widely used, web-based platform with advanced collaboration capabilities. This study investigates whether SP can meet the needs of engineering research projects, particularly in a collaborative environment. The paper outlines the process of adapting SP into an ELN tool and evaluates its effectiveness compared to established ELN systems. The evaluation considers several categories related to data management, ranging from data collection to publication. Six distinct application scenarios are analysed, representing a spectrum of collaborative research projects, ranging from small-scale initiatives with minimal processes and data to large-scale, complex projects with extensive data requirements. The results indicate that SP is competitive in relation with established ELN tools, ranking second among the six alternatives evaluated. The adapted version of SP proves particularly effective for managing data in engineering research projects involving both academic and industrial partners, accommodating datasets for around 1000 samples. The practical implementation of SP is demonstrated through a collaborative engineering research project, showing its use in everyday research tasks such as data documentation, workflow automation, and data export. The study highlights the benefits and usability of the adapted SP version, including its support for regulatory compliance and reproducibility in research workflows. In addition, limitations and lessons learned are discussed, providing insights into the potential and challenges of using SP as an ELN tool in collaborative research projects.

1. Introduction

1.1. Motivation

The advent of open science [1,2] has significantly accelerated the digitalisation of research processes, fostering efficient knowledge exchange and transparency within the research community, as well as across society and the economy. This paradigm shift not only enhances the accessibility of research outcomes but also ensures that all stakeholders—academics, policymakers, industry, and the public—can benefit from the advancements of prior research endeavours. To fully achieve the goals of open science, it is essential to provide free access to scientific publications through open access [3] and unrestricted access to research data in accordance with the FAIR data principles [4]. These principles advocate for research data to be findable, accessible, interoperable, and reusable by any interested party. Findability in research data is crucial, as data that cannot be easily located—via persistent identifiers or descriptive keywords—may not be verified, reused, or further developed. Accessibility extends beyond mere storage; it ensures that authorized individuals can retrieve both data and metadata using standardized, open protocols (e.g., HTTP and RESTful APIs) and that the data is stored in a non-proprietary format. Interoperability guarantees that data generated in one context can be integrated or combined with data from other sources, such as different laboratories, instruments, or institutions, by adopting shared vocabularies and taxonomies. Together, these principles already enhance the reusability of data. However, effective data reuse also requires clear licensing, high-quality metadata, and robust version control. Furthermore, the implementation of these principles supports reproducibility and accountability in research, thereby fostering trust and collaboration among global research communities. This emphasis on accessibility and usability of data underscores the need for robust systems and tools, such as Electronic Lab Notebooks (ELNs), which can streamline data management and align with open science objectives by ensuring that data is not only stored securely but also shared and used effectively.

The European Union (EU) has established clear mandates to align with the principles of open science, particularly through its research and innovation funding programs Horizon 2020 [5] and its successor, Horizon Europe [6]. Beneficiaries of these programs are required to ensure that publications resulting from funded projects are made freely accessible via the open access model, enabling unrestricted access to research findings. Since 2016, these programs have also obligated recipients to make research data freely accessible in accordance with the FAIR data principles, except in cases where valid reasons, such as intellectual property protection, commercial exploitation, ethical concerns, or safety issues, apply. Furthermore, Horizon Europe introduces additional requirements, including the submission of a comprehensive data management plan [3,6] and the storage and dissemination of data in suitable repositories. Similarly, the German Research Association (DFG) [7] has implemented parallel requirements for the research projects it funds. These include the preparation of a research data management plan that details metadata usage, data quality control, storage protocols, and software employed for data documentation [8]. These measures collectively emphasise the critical importance of structured and transparent research data management to support the goals of open science, ensuring accessibility, interoperability, and reusability of data for the broader scientific community and beyond.

Electronic Lab Notebooks (ELNs) are sophisticated systems designed to operate within distributed communication networks for the creation, storage, management, retrieval, and sharing of fully electronic records [9]. These systems are developed to comply with stringent legal, regulatory, technical, and scientific requirements, ensuring their reliability and utility across diverse research settings [9]. As such, ELNs are instrumental in fulfilling the requirements outlined in data management plans and in supporting the principles of open science by facilitating transparent and accessible data handling [10].

ELNs are categorised based on their target audience and functionality [11]. Domain-specific ELNs are tailored to meet the unique needs of particular scientific disciplines, such as biology or chemistry. These ELNs often include specialised tools, such as plasmid or DNA sequence editors, which are essential for managing domain-specific data and workflows [12]. Conversely, generic ELNs are designed for multidisciplinary use, offering a versatile platform that integrates tools from various scientific domains. This flexibility makes them suitable for a wide range of research applications, promoting collaborative efforts and efficient data management across diverse fields [11]. The adaptability and functionality of ELNs underscore their importance in modern scientific research, particularly in addressing the challenges of managing increasingly complex datasets and ensuring compliance with evolving data governance standards. Their role in bridging domain-specific requirements with broad scientific utility highlights their potential as central tools in advancing research efficiency and collaboration.

1.2. Requirements and Challenges

A study conducted by the University of Southampton explored the requirements for Electronic Lab Notebooks (ELNs) among its researchers, identifying a set of generic features essential for laboratory and organisational applications [10].

Table 1. Overview of desired features for ELNs from the perspective of researchers [10].

Category	Desired Features
Recording notes	Simple to install, post-it notes (comments), tasks lists, setting of default values, easy to write in as a paper notebook, template creation, adaptable to different workflows
Organising notes	Can be indexed, spellchecker, tag/classify notes and experiments, storage of metadata, standard vocabularies
Searching data	Filtered search, data traceability, voice searches, sortable results
Linking data	Upload files to notes and link to reference managers
Writing reports	Generating reports, integrate and store different document types, export function
Performing scientific functionality	Notifications for approvals and non-editable entries
Accessibility in labs	Web-based, tablet/smartphone compliant, voice capture
Archiving and backing up	Secure storage, backup, downloads and printing
IT and data security	Secure access, different access levels for users
Collaboration in organisation	Shared files/notebooks, standardised lists, linking of notebooks and users, coordination for open source and open access
Project activities	Recent activity feeds with notifications and comments

provides a summarised overview of these features as identified by the researchers. Furthermore, Zinner et al. [13] present a comprehensive list of challenges and requirements for research data infrastructures from the perspective of researchers. Among these, the necessity of a common technical language is emphasised to ensure that all project participants have a clear and consistent understanding of the descriptions of recorded data, facilitating effective collaboration and data management.

For collaborative engineering research projects, additional requirements arise, based on empirical insights gained from the authors’ involvement in such projects, as follows:

• Collaborative access: Access must be provided to all project partners to ensure seamless collaboration.
• Access rights’ management: Managing access rights at the file or folder level necessitates the implementation of a role-based rights classification system. This system should consider legal and contractual obligations as well as the categorisation of data into designated protection classes.
• Workgroup formation: Establishment of workgroups to enable the rapid dissemination of information and data among partners.
• Transparent workflow structure: A clear model structure (workflow) must be in place to identify the project partner responsible for generating specific data at each stage of the project.
• Global identifier system: A comprehensive global item identifier (ID) system is required to facilitate the tracking and probing of items.
• FAIR data principles: Ensuring adherence to the FAIR data principles during data exchange between project partners and throughout the data publication process.

1.3. Problem Statement

Despite the increasing emphasis on open science and the implementation of open access policies to make research publications freely available, significant challenges remain in achieving the FAIR (Findable, Accessible, Interoperable, and Reusable) principles for research data. ELNs have emerged as pivotal tools to address these challenges by streamlining data management and fostering collaboration. However, the diverse requirements of multidisciplinary and domain-specific research environments, combined with the lack of standardised practices for integrating ELNs into open science frameworks, hinder the effective usage of ELNs for promoting the transparency, reproducibility, and accessibility of research data. This gap necessitates the exploration of adaptable ELN solutions capable of meeting the varied needs of open science initiatives while ensuring compliance with FAIR data principles.

1.4. Aim

This article evaluates the potential of Microsoft SharePoint^® (SP) as an ELN for collaborative engineering research projects by systematically comparing its functionalities with those of established ELN tools across a variety of application scenarios. The primary motivation for using SP as an ELN stems from the extensive integration of Microsoft products within academic and research institutions, including on-premises installations at the Technical University of Dresden (Technical University of Dresden: “MS SharePoint”, https://tu-dresden.de/zih/dienste/service-katalog/zusammenarbeiten-und-forschen/groupware/sharepoint?set_language=en, last accessed: 8 June 2025), the University of Hamburg (Sebastian Reinberg: “SharePoint University of Hamburg“, https://www.rrz.uni-hamburg.de/services/kollaboration/sharepoint.html, last accessed: 8 June 2025), and Heidelberg University (Heidelberg University: “SharePoint—A web-based collaboration platform for internal cooperation”, https://www.urz.uni-heidelberg.de/en/service-catalogue/collaboration-and-digital-teaching/sharepoint, last accessed: 8 June 2025). This widespread adoption fosters a high degree of familiarity among researchers, thereby removing the necessity to adapt to unfamiliar systems during collaborative research efforts involving SP. Additionally, with Office 365 subscriptions already common across most institutions, there are no extra licensing costs, making SP a cost-efficient choice. In addition, the study aims to contribute to the development of a standardised framework for assessing and benchmarking ELN tools, ensuring their suitability for different research contexts. Additionally, the analysis explores the opportunities and limitations of using SP as an ELN, with a focus on its alignment with open data initiatives and adherence to the FAIR data principles, thereby addressing the requirements for effective and transparent research data management.

Preliminary findings on this topic were presented at the Materials Science and Engineering Congress (MSE) 2024 in the form of a poster presentation [14].

1.5. Research Questions

RQ1: 

How does SP compare to established Electronic Lab Notebook (ELN) tools in terms of functionality and usability for collaborative engineering research projects?

RQ2: 

What are the strengths and limitations of using SP as an ELN in the context of open data and adherence to the FAIR data principles?

RQ3: 

How can SP be adapted to meet the specific requirements of data management in engineering research, particularly for projects involving both academic and industrial partners?

RQ4: 

What criteria can be developed to standardise the comparison and benchmarking of ELN tools across diverse research scenarios?

RQ5: 

In what ways can SP support regulatory compliance and enhance the reproducibility of research workflows in engineering domains?

1.6. State of the Art and Related Works

Only one ELN [15] specifically designed for engineering, mechanical, manufacturing, and physical product testing has been identified. Nevertheless, a wide variety of generic ELNs exist, with nearly every research field offering tailored solutions [16]. However, many of these options come with limitations and/or are not freely available from organisations, which can impose additional costs on research projects.

Several studies [10,17] and guidelines [18,19] have proposed criteria for evaluating ELNs or outlined systematic approaches for selecting ELNs tailored to specific needs. Additionally, resources like ELN Finder [20] support the identification of suitable ELNs by offering insights into a wide range of options. Some of these criteria, detailed in the Requirements and Challenges Section 1.2, are utilised in this study. Notably, none of the reviewed studies included SP as an ELN candidate or focused on its application in collaborative research projects. One study [21] did evaluate Microsoft OneNote^® linked to an on-premises Microsoft SharePoint 2013 setup, where OneNote files were stored under specific SharePoint configurations. In this comparison, OneNote^® met the majority of parameters and emerged as the preferred choice among the survey participants.

Further criteria for ELN comparison in this study were derived from the FAIR data principles [4,22] and specific requirements for joint research projects and process chains. The criteria were categorised according to stages of a typical data management workflow, such as data collection, data analysis, data publication, and data archiving, as well as organisational categories like general, administration, and support. Additionally, criteria for usage in process chains were grouped into a separate category.

Each criterion was assessed for its alignment with the FAIR data principles and assigned a weighting factor (“w”) determined by the authors’ expertise. It is important to highlight that these weighting factors, as well as the evaluation of whether a criterion is met, may vary depending on the specific application context. The evaluation presented here is based solely on the authors’ user experience. The ELNs compared in this study were selected for their suitability for collaborative engineering projects, as identified in a prior comparison study [17], and are listed in

Table 2. Selected ELNs and their acronyms.

Electronic Lab Notebook	Acronym
MS SharePoint® 2019 on-premises	SP
Karlsruhe Data Infrastructure for Materials Science (Kadi4Mat) 0.47.0	K4M
RSpace Enterprise	RSpE
SciNote Research Lab	ScRL
Labfolder Free	LfFr
Labfolder Advanced	LbAd

for reference. Their acronyms are used throughout the subsequent tables. A further selection criterion for the ELNs included in this study was the availability of a cost-free trial version. Additionally, Kadi4Mat was included as the authors have utilised this ELN in a collaborative project. It should be noted that not all evaluated ELNs are discussed in this paper. The complete evaluation in terms of Excel sheets is publicly accessible under an open source licence on Zenodo (Opatz, T.; Feldhoff, K.; Wiemer, H.: “ Electronic Lab Notebook Evaluation Tool”, https://doi.org/10.5281/zenodo.15241857, last accessed: 8 June 2025).

A comparative analysis between SP and established ELNs is presented in

Table 3. Comparison of the following ELN tools with respect to a set of given requirements: SP, K4M, RSpE, ScRL, LbFr, LbAd; reference date: 20 March 2024. The fulfilment of the requirements is indicated by “✔”, while unfulfilled requirements are indicated by “✗”. In instances where a specific requirement is not assessable, for example, in the case of a minor local installation that is not accompanied by the installation of additional software, the corresponding entry is marked with “NA”. Conversely, if the fulfilment of a requirement is unknown, the corresponding entry is marked with “?”. The assignment of the requirements to the FAIR data principles (columns “F”, “A”, “I”, “R”) is indicated by “•”.

Main Category	Requirement	F	A	I	R	w	SP	K4M	RSpE	ScRL	LbFr	LbAd
General	Collaborative platform		•			5	✔	✔	✔	✔	✔	✔
General	ELN tool				•	1	✗	✔	✔	✔	✔	✔
General	Domain-specific tool					0	✗	✔	✗	✔	✔	✔
General	Open source software					3	✗	✔	✗	✔	✗	✗
General	Without costs (basic version)		•			3	✗	✔	✗	✗	✔	✗
General	Widely used at German research institutes (>10)					1	✔	✔	✔	✗	✔	✔
Administration	Small effort w.r.t. local installation					0	✗	✗	?	?	NA	?
Administration	Small effort w.r.t. maintenance of local installation					0	✗	✔	?	?	NA	?
Administration	Extendable					5	✔	✔	✔	✔	✔	✔
Support	Support service			•		4	✔	✗	✔	✔	✔	✔
Support	Guiding tour			•		2	✔	✔	✗	✗	✗	✗
Support	Explanatory videos or pictures			•		2	✔	✗	✔	✔	✔	✔
Support	Trainings			•		2	✔	✗	✔	✔	✔	✔
Data collection	Web based frontend		•			5	✔	✔	✔	✔	✔	✔
Data collection	Mobile app		•			1	✔	✗	✗	✔	✗	✗
Data collection	Selection of favourites	•				1	✔	✔	✔	✗	✔	✔
Data collection	Creation of groups					2	✔	✔	✔	✔	✔	✔
Data collection	No requirement of IT knowledge in usage and expansion			•		2	✔	✗	✗	?	✔	?
Data collection	Full text search	•				2	✔	✔	✔	✔	✔	✔
Data collection	Assigning keywords for searching data	•				2	✔	✔	✔	✔	✔	✔
Data collection	Collaborative editing office documents		•			1	✔	✗	✔	✔	✗	✗
Data collection	Comment function					2	✔	✗	✔	✔	✔	✔
Data collection	Internal linking of projects/data records			•		2	✔	✔	✔	✔	✔	✔
Data collection	Integration of office tools			•		2	✔	✔	✔	✔	✔	✔
Data collection	Various user roles (administer, edit, read)		•			4	✔	✔	✔	✔	✗	✔
Data collection	Automatic query (e.g., content checks) and dual control principle					4	✔	✗	✗	✗	✗	✔
Data collection	Access rights at file level		•			3	✔	✗	✔	✔	✗	?
Data collection	File version management			•		3	✔	✗	✔	✔	✔	✔
Data collection	Standardised data entry through creation of data entry form			•		3	✔	✗	✔	✔	✔	✔
Data collection	Storage of large data volumes (>30 GB)					4	✗	✔	✔	✔	✗	✔
Data collection	Git integration					2	✗	✔	✗	✗	✗	✗
Data collection	Discussion forum					1	✔	✗	✔	✗	✔	✔
Data collection	Inventory/stock management					2	✗	✗	✔	✔	✔	✔
Data collection	Integrated design of experiments (DoE)					1	✗	✗	✗	✗	✗	✗
Data collection	Barcodes					2	✔	✗	✔	✔	✔	✔
Data collection	Template creation			•		3	✔	✔	✔	✔	✔	✔
Data analysis	Differentiation of protocols (machine, process, material)	•				1	✗	✔	✗	✗	✗	✗
Data analysis	Graphical differentiation of protocols (machine, process, material)	•				1	✗	✗	✗	✗	✗	✗
Data analysis	Textbox for metadata				•	3	✔	✔	✔	✔	✔	✔
Data analysis	Tables for constants (metadata)				•	2	✔	✔	✔	✗	✗	✗
Data analysis	Inserting of explanatory image files				•	3	✔	✔	✔	✔	✔	✔
Data analysis	Usage of taxonomies	•				3	✔	✗	✔	✗	✗	✗
Data publication	Assignment of persistent identifiers	•				4	✗	✔	✔	✔	✔	✔
Data publication	Added publication platform	•				3	✗	✔	✔	✗	✔	✔
Data publication	Assignment of deletion and retention periods		•			3	✗	✗	✗	✗	✗	✗
Data publication	Access via link for unregistered users		•			2	✔	✗	✔	✗	✗	✗
Data archiving	Locally installable/on-premises		•			5	✔	✔	✔	✔	✗	✔
Data archiving	Cloud solution		•			1	✔	✔	✔	✔	✔	✔
Data archiving	Cloud server in Germany					5	✔	✔	✔	✔	✔	✔
Data archiving	Backup of research data					5	✔	✔	✔	✔	✔	✔
Data archiving	E-signature of data					2	✗	✗	✔	✔	✗	✔
Data archiving	Two-factor authentication		•			2	✔	✗	✔	✔	✔	✔
Process chains	Mapping of workflows			•		3	✔	✗	✗	✔	✔	✔
Process chains	Graphical illustration of (internal company) workflows			•		2	✔	✗	✗	✔	✔	✔
Process chains	Global sample labelling	•				5	✔	✗	✔	✔	✔	✔
Process chains	Merging sample data from different experiments			•		4	✗	✗	✔	✗	✗	✗
	Points achieved						107	81	113	105	93	103

. The weighting factors (w) for the fulfilled requirements of each ELN were aggregated to calculate a total score for each tool. Basic functionalities, such as document storage, shared access to folders and documents, integration of external data sources, device independence, adaptability to various workflows, and a structured file system, are not included in Table 3, as these are considered fundamental prerequisites for ELN evaluation. The reference date for this comparison is 20 March 2024.

The results of the analysis highlight that the original version of SP already offers notable advantages over other ELNs, such as the capability to execute automated queries for content verification and the use of taxonomy. However, certain limitations are also identified, including restricted storage capacity and the absence of data publishing tools. Despite these drawbacks, SP demonstrates competitive parity with established market-leading ELNs, making it a viable alternative for specific applications.

1.7. Outline

The structure of this contribution is as follows: Section 3 describes the necessary steps for adapting SP to function as an ELN in collaborative engineering research projects. Section 4 provides a comparative analysis between the adapted and original versions of SP, detailing the implementation processes and associated efforts. Section 3.2 offers recommendations for potential applications of SP as an ELN. Additionally, an illustrative case study showcasing the implementation of SP within a collaborative research project is presented in Section 4.3. The limitations of this study, along with lessons learned, are discussed in Section 5. Finally, Section 6 concludes the study and outlines prospective directions for future research.

2. Adaptation of SP as ELN

In this section, SP will be adapted as an ELN and the methods and tools used for adapting SP will be described.

SP is a web-based application that is frequently provided by research organisations and enterprises for the storage, structuring, and dissemination of data, as well as for communication and coordination within working groups. Its web-based User Interface (UI) facilitates accessibility across various devices. A prominent feature of SP websites is the presence of document libraries, which enable the categorisation of data into discrete topics and are then displayed in a systematic ordered format. A further key feature of SP is its granular role-based access control. Rights can be assigned on a website, document, or even individual item level within SP lists. The user may select from a range of pre-defined roles, including “Owner” (which grants all rights), “Member” (which permits document editing), and “Visitor” (which allows only reading). Moreover, individual rights can be assigned to each document and individual researcher. Additional functionalities of SP encompass versioning and change tracking of data, as well as full-text search and indexing capabilities, which collectively facilitate the discoverability of data. In consideration of the fact that SP is usually available as an official service of the local computing centre of an institution, researchers are not required to undertake tasks such as the installation and maintenance of the software, user ID management, and the establishment of access procedures for the institution. Consistent with the definition of ELNs, SP already includes the ELN features listed above, including the ability to create, store, manage, retrieve, and share data. However, some modifications are necessary to ensure that these features meet the legal, regulatory, and scientific requirements for using SP as an ELN. Although SP was not designed to function as an ELN and is not open source, it can be modified to serve this purpose. The following ELN features are particularly important in the context of using ELNs for collaborative research and could be integrated into SP only by customizing and configuring SP:

• Identifier systems for items and processes: An identifier (ID) system makes it easy to link built items and the data associated. By adding a project global ID system for both items and for processes, items can be tracked along process chains. When the existing local laboratory item ID systems are connected to the implemented global ID system, project partners can use their own local item ID systems while maintaining interrelationships between data for items tested in different laboratories.
• Indexing with taxonomy: The possibility of indexing metadata in accordance with a pre-established taxonomy permits the use of a uniform terminology to describe data and the creation of standardised templates for collecting research data.

In summary, SP already provides a multitude of ELN functionalities simply through configurations. However, these functionalities are not always sufficient, e.g., if one wants to connect the SP website to an additional storage system which is located in different network segments of the organisation. ELN functionalities can be augmented through the extension of SP at both server and client sides. This could resolve concerns about storing data on external servers, thereby ensuring alignment with established security policies. At the server side, the extension of SP through the implementation of SP apps is a prevalent solution approach. However, when SP is centrally installed and maintained by a central unit within the organisation, the installation of SP apps is often not possible or even forbidden. Consequently, solutions that operate on the SP client side are preferred. One such solution involves extending SP in a specific manner by connecting it to an agent, which, in turn, connects to other RDM services, such as storage systems for the storage of research data and computing systems for the processing of research data. This concept is illustrated schematically in Figure 1.

It takes advantage of the fact that SP offers a suite of Application Programming Interfaces (APIs), encompassing Representational State Transfer (REST) API, Client-Side Object Model (CSOM), JavaScript Object Model (JOM), and Simple Object Access Protocol (SOAP) web services, by which objects at SP websites such as list items can be accessed and manipulated. Consequently, this method facilitates the establishment of connections between multiple SP websites and numerous storage and computing systems. In the interest of maintaining optimal IT security, the use of secure transmission protocols such as Hypertext Transfer Protocol Secure (HTTPS) and Secure Shell (SSH) and authentication methods are imperative during the establishment of these connections. In addition to the imperative of IT security, the run-time performance of the system is of equal importance. The system must demonstrate the capacity to establish connections with multiple SP websites across diverse storage and computing systems while maintaining efficient run-time performance. To address these demands, a scalable solution was designed. To this end, the web server is implemented within a virtual environment comprising a set of virtual machines. Within these virtual machines, RDMAGENT is implemented as a service, operating as a Docker (Authors of docker.com: “Develop faster, run anywhere”, https://www.docker.com/, last accessed: 5 April 2025) container within a Docker Swarm (Authors of docker.com: “Swarm mode”, https://docs.docker.com/engine/swarm/, last accessed: 5 April 2025) environment. Analogously, the established open source software tool Traefik (Authors of traefik.io: “Traefik”, https://doc.traefik.io/, last accessed: 5 April 2025) is also running as a containerised service within the Docker Swarm environment and employed as a reverse proxy and load balancer. The IT architecture of the web server is demonstrated in Figure 2.

The solution concept has been implemented using the self-developed software tools SPRDMJS as a JavaScript library on the client side and RDMAGENT as a web server. The subsequent subsections will provide a more detailed exposition of these tools, based on version 0.2.0 of SPRDMJS (Feldhoff, K.; Wiemer, H.; Ihlenfeldt: “SPRDMJS: JavaScript library for extending the Research Data Management functionalities of SharePoint(R) websites”, https://doi.org/10.5281/zenodo.15241857, last accessed: 8 June 2025) and version 0.14.0 of RDMAGENT (Feldhoff, K.; Wiemer, H.; Ihlenfeldt: “RDMAGENT: Agent for connecting SharePoint(R) websites with Research Data Management services”, https://doi.org/10.5281/zenodo.15241611, last accessed: 8 June 2025), both publicly available at Zenodo.

2.1. SPRDMJS

SPRDMJS is a JavaScript library designed to extend the functionality of SP websites, particularly focused on Research Data Management (RDM). SPRDMJS offers a range of functionalities related to RDM, thus positioning it as a valuable instrument for researchers and data managers operating on SP platforms. The operational dynamics of SPRDMJS are delineated in Figure 3. It capitalises on the capability to customise the appearance and functionality of SP websites on the client side through the manipulation of SP objects. Specifically, the tool uses the SP REST API to a significant extent for the purpose of manipulating SP objects.

SPRDMJS supports a number of scenarios in a researcher’s daily work, including the following ones:

• Synchronisation of data documentations: Research data often reside in external storage systems. SPRDMJS enables seamless access to data documentations in terms of text based files in JSON format from SP websites. It also allows users to update the documentation both on the SP website and the external storage systems through web forms, ensuring consistency and accuracy in data documentation.
• Triggering of compute workflows: Researchers often aim to extract meaningful insights from recorded data through detailed analysis. This process typically involves defining computational workflows and executing them on external computing systems. The SPRDMJS tool supports the integration of these workflows with external computing systems. Within SPRDMJS, each workflow can be configured by specifying the external computing system, the transmission protocol, and the shell scripts involved, assuming each workflow comprises multiple executable shell scripts. This setup allows researchers to initiate compute workflows, retrieve the results, and seamlessly store them within SP lists. Such integration significantly enhances the computational capabilities of SP websites, promoting the efficient processing and management of research data.
• Export of SP databases: Researchers often create user-defined SP lists to collect and manage research data, effectively using these lists as a database. SPRDMJS automates the collection of data from these user-defined SP lists, generates corresponding data documentation, and exports both the data and data documentation in a compressed ZIP file. This feature streamlines data management and facilitates data sharing and archiving processes. More specifically, it facilitates the export of data and metadata to alternative software for the purpose of publishing data in accordance with the FAIR data principles.

2.2. RDMAGENT

RDMAGENT is a web server implemented in JavaScript designed to facilitate seamless access to external services related to RDM from SP websites. The web server consists of a REST API with endpoints tailored to the documentation of research data and the processing of compute workflows. This way, RDMAGENT significantly enhances the efficiency and integration capabilities of research data management systems. Its development and ongoing enhancements promise to support a wide range of research data workflows, fostering greater collaboration and data accessibility within the scientific community.

• The web server is based on the established JavaScript framework Node.js (Authors of node.js: “Run JavaScript everywhere”, https://nodejs.org/en, last accessed: 5 April 2025).
• RDMAGENT operates within Docker containers, ensuring a scalable and flexible deployment environment. Thus, the installation process involves setting up Docker and related dependencies. In particular, it uses Docker Swarm functionalities. The Docker stack file needs customisation to fit specific deployment environments, particularly when connecting external data storage and computing systems.

RDMAGENT prioritises IT security to ensure the integrity and security of data transmissions. Additionally, it emphasises run-time performance to minimise overheads and consequently reduce delays in exchanging metadata between connected systems and SP websites. The IT security features include HTTPS transmissions, authentication, and rate limits. The performance features include a slim web server with adapted endpoints in the REST API and support for HTTP version 2. The software has been designed to be scalable in order to support the applications scenarios.

3. Methodology

The methodology employed in this study aims to systematically evaluate the suitability of SP as an ELN for use in collaborative engineering research projects. By adopting a benchmarking approach, the study compares the functionalities and performance of SP against established ELN tools, focusing on its ability to meet the requirements of joint research environments. Section 3.1 outlines the criteria used for evaluation and Section 3.2 the selected use case scenarios. Six application scenarios were defined to represent the different scales and complexities of engineering research projects.

3.1. Study Design

This section describes the criteria used for evaluation and the analytical processes applied to assess the effectiveness of SP in facilitating data management workflows.

The evaluation focuses on criteria such as document storage, collaborative access, workflow integration, compliance with FAIR data principles, and usability in process chains. The study is designed as follows:

• The criteria for the evaluation are fetched from multiple sources, including the existing literature, user feedback from engineering research projects, and empirical observations during the adaptation and implementation of SP as an ELN.
• The evaluation criteria are organised into categories corresponding to typical data management workflows (e.g., data collection, analysis, publication, and archiving) and organisational aspects (e.g., administration and support).
• Each criterion was assigned a weighting factor reflecting its significance, determined by the authors’ experience in collaborative research projects.
• Then, these criteria are scored for each ELN, and the results are aggregated to compute the total scores.

The study assumes that the use case scenarios defined in Section 3.2 are representative of typical joint engineering research projects. Limitations include the scope of ELNs evaluated and potential variability in user requirements across different projects.

3.2. Use Case Scenarios

The usage of SP as an ELN is best contextualised through specific use case scenarios that highlight its advantages and limitations.

Table 4. Description of the analysed scenarios (column “ID”) of collaborative engineering projects, detailing the respective project objectives (column “Goal”), the collaborators involved (column “Collaborators”), the domains from which these collaborators originate (column “Domains”), the types and number of processes implemented (column “ProcessTypes”), the quantity of samples recorded (column “SampleSize”), and the types of data collected (column “DataTypes”). The values provided in the columns “Domains,” “ProcessTypes,” “SampleSize,” and “DataTypes” are further clarified in Table 5.

ID	Goal	Collaborators	Domains	Process Types	Sample Size	Data Types
S1	Process optimisation in-house	Collab-Small-Mixed	Dom-Mech	Proc-3	Sample-Mass	Data-Basic
S2	Process development with many partners	Collab-Big-Mixed	Dom-Mixed-IT	Proc-5	Sample-100	Data-Basic+Sim +Ex
S3	Cooperative process optimisation	Collab-Small-Comp	Dom-Mech	Proc-Tree-Big	Sample-1000	Data-Basic+Sim
S4	Process development	Collab-Med-Mixed	Dom-Mixed	Proc-5	Sample-100	Data-Basic+Sim +Ex
S5	Research process development	Collab-Med-Research	Dom-Mech +Mat	Proc-5	Sample-1000	Data-Basic+Sim +Ex
S6	Online process parameter optimisation with continuous quality assurance	Collab-Med-Mixed	Dom-Mech+ Mat+IT	Proc-Endless-3	Sample-Mass	Data-Basic-Live

outlines six distinct scenarios, labelled S1 through S6, that were analysed to evaluate the application of SP. To ensure clarity, abbreviations are used throughout this document, with their full explanations detailed in

Table 5. Feasible values and their corresponding descriptions for the columns presented in Table 4.

Column	Value	Description
Collaborator	Collab-Small-Mixed	One company, one research organisation
Collaborator	Collab-Big-Mixed	Big joint research project from research and industry (>8 partners)
Collaborator	Collab-Small-Comp	Small joint research project with Original Equipment Manufacturer (OEM)
Collaborator	Collab-Med-Mixed	Medium joint research project (4–8 partners) from research and industry
Collaborator	Collab-Med-Research	Medium joint research project with research organisations (4–8 partners)
Domains	Dom-Mech	Mechanical Engineering (Mech. Eng.)
Domains	Dom-Mixed+IT	Mech. Eng., Material Sciences (Mater. Sci.), Physics (Phys.), Chemical Engineering (Chem. Eng.), Computer Sciences (Comp. Sci.)
Domains	Dom-Mixed	Mech. Eng., Mater. Sci., Phys., Chem. Eng.
Domains	Dom-Mech+Mat	Mech. Eng., Mater. Sci.
Domains	Dom-Mech+Mat+IT	Mech. Eng., Mater. Sci., Comp. Sci.
Process Types	Proc-3	Linear process chain with 3 process steps
Process Types	Proc-5	Linear process chain with 5–10 process steps
Process Types	Proc-Tree-Big	Process tree with >20 process steps
Process Types	Proc-Endless-3	Linear endless good process chain with 3 process steps
Sample Size	Sample-100	Small batch (<100 samples)
Sample Size	Sample-1000	Serial production (1000 samples)
Sample Size	Sample-Mass	Mass production (>20,000 samples)
Data Types	Data-Basic	Machine data, quality data
Data Types	Data-Basic+Sim+Ex	Machine data, quality data, simulation data, experimental data
Data Types	Data-Basic+Sim	Machine data, quality data, simulation data
Data Types	Data-Basic-Live	Online machine data, online quality data

, as some terms appear frequently. Each scenario in Table 4 is described across multiple dimensions as follows:

• Objective: This column summarises the primary challenges encountered within each scenario, with further elaboration provided in subsequent columns.
• Collaborators: This column details the types of project partners, such as companies or research organisations, and their level of involvement in the projects.
• Domains: This column contains the disciplines or fields involved in each scenario, providing insight into the interdisciplinary nature of the projects.
• Process types: This column offers an overview of the processes implemented, including their number and whether they are distributed across multiple entities.
• Sample size: This column contains information on the number of samples produced and measured during the project, illustrating the scale of data management required.
• Data types: This column specifies the types of data recorded in the project, emphasising the unique challenges associated with data handling and management in each scenario.

This structured analysis allows for a comprehensive understanding of the role and the effectiveness of SP as an ELN across diverse research contexts.

4. Results

In the following, the adapted version of SP is evaluated, similar to the evaluation in Section 1.6 for ELNs currently available on the market. The implementation of the identified requirements are categorised according to the required effort. The assessment of the implementation effort was based on the experience gained by the authors during implementation.

Table 6. Comparison of SP and the adapted SP version at TUD (abbreviation: SP@TUD) as an ELN, including implementation methods and efforts. The fulfilment of requirements is indicated by “✔”, while unfulfilled requirements are indicated by “✗”. ”. If the fulfilment of a requirement is unknown, the ELN will be marked with “?”. The assignment of the requirements to the FAIR data principles (columns “F”, “A”, “I”, “R”) is indicated by “•”.

Main Category	Requirement	F	A	I	R	w	SP	SP@TUD	Method	Implementation Level
General	Collaborative platform		•			5	✔	✔	Creation of a SP website	Small
General	ELN tool					1	✗	✗	None	None
General	Domain-specific tool					0	✗	✗	None	None
General	Open source software					3	✗	✗	None	None
General	Without costs (basic version)		•			3	✗	✗	None	None
General	Widely used at German research institutes (>10)					1	✔	✔	None	None
Administration	Small effort w.r.t. local installation					0	✗	✔	Official service of organisation	Small
Administration	Small effort w.r.t. maintenance of local installation					0	✗	✔	Official service of organisation	Small
Administration	Extendable					5	✔	✔	Via SP APIs and SP webpages	None
Support	Support service			•		4	✔	✔	At MS website	None
Support	Guiding tour			•		2	✔	✔	At MS website	None
Support	Explanatory videos or pictures			•		2	✔	✔	At MS website	None
Support	Trainings			•		2	✔	✔	At MS website	None
Data collection	Web based frontend		•			5	✔	✔	Included in SP	None
Data collection	Mobile app		•			1	✔	✔	Included in SP	None
Data collection	Selection of favourites	•				1	✔	✔	Included in SP	None
Data collection	Creation of groups					2	✔	✔	Included in SP	None
Data collection	No requirement of IT knowledge in usage and expansion			•		2	✔	✗	Programming and IT skills required	High
Data collection	Full text search	•				2	✔	✔	Included in SP	None
Data collection	Assigning keywords for searching data	•				2	✔	✔	Included in SP	None
Data collection	Collaborative editing of office documents		•			1	✔	✔	Included in SP	None
Data collection	Comment function					2	✔	✔	Included in SP	None
Data collection	Internal linking of projects/data records			•		2	✔	✔	Included in SP	None
Data collection	Integration of office tools			•		2	✔	✔	Included in SP	None
Data collection	Various user roles (administer, edit, read)		•			4	✔	✔	Included in SP	None
Data collection	Access rights at file level		•			3	✔	✔	Included in SP	None
Data collection	File version management			•		3	✔	✔	Included in SP	None
Data collection	Standardised data entry through creation of data entry form			•		3	✔	✔	Included in SP	None
Data collection	Automatic query (e.g., content checks) and dual control principle					4	✔	✔	Included in SP	None
Data collection	Storage of large data volumes (>30 GB)					4	✗	✔	Linked external network storage (group drive)	Medium
Data collection	Git integration					2	✗	✗	Not implemented	None
Data collection	Discussion forum			•		1	✔	✔	Included in SP	None
Data collection	Inventory/stock management					2	✗	✗	Not implemented	None
Data collection	Integrated DoE					1	✗	✗	Not implemented	None
Data collection	Barcodes					2	✔	✔	Included in SP	None
Data collection	Template creation			•		3	✔	✔	Included in SP	None
Data analysis	Differentiation of protocols (machine, process, material)	•				1	✗	✗	Not implemented	None
Data analysis	Graphical differentiation of protocols (machine, process, material)	•				1	✗	✗	Not implemented	None
Data analysis	Textbox for metadata				•	3	✔	✔	Included in SP	None
Data analysis	Tables for constants (metadata)				•	2	✔	✔	Included in SP	None
Data analysis	Inserting of explanatory image files				•	3	✔	✔	Included in SP	None
Data analysis	Usage of taxonomies	•				3	✔	✔	Included in SP	None
Data publication	Assignment of persistent identifiers	•				4	✗	✔	Added unique IDs for samples in each SP list	High
Data publication	Added publication platform	•				3	✗	✗	Not implemented	None
Data publication	Assignment of deletion and retention periods		•			3	✗	✗	Not implemented	None
Data publication	Access via link for unregistered users		•			2	✔	✔	Included in SP	None
Data archiving	Locally installable on premises		•			5	✔	✔	Included in SP	None
Data archiving	Cloud solution		•			1	✔	✔	Included in SP	None
Data archiving	Cloud server in Germany					5	✔	✔	Included in SP	None
Data archiving	Backup of research data					5	✔	✔	Included in SP	None
Data archiving	E-signature of data					2	✗	✗	Not implemented	None
Data archiving	Two-factor authentication		•			2	✔	✔	Included in SP	None
Process chains	Mapping of workflows			•		3	✔	✔	Included in SP	None
Process chains	Graphical illustration of (internal company) workflows			•		2	✔	✔	Included in SP	None
Process chains	Global sample labelling	•				5	✔	✔	Included in SP	None
Process chains	Merging sample data from different experiments			•		4	✗	✔	Added unique IDs for samples in each SP list	High
	Points achieved						107	112

compares the original SP version to the adapted SP version based on the previously defined categories. For each category, the effort for implementing the corresponding feature in the adapted SP version is given. In comparison to the standard SP, the adapted SP demonstrates enhanced capabilities, such as merging sample data from various experiments and preparing this data for publication by organising it into ZIP files. This preparation facilitates the assignment of persistent identifiers to the ZIP files at external data repositories, such as Zenodo. In summary, the adapted SP is rated slightly higher than the standard version. Although not evaluated as free software, the adapted SP is provided by the TUD as an on-premises solution to individual researchers and projects at the university at no cost.

A systematic comparison was performed between SP and other ELNs, using a set of predefined criteria derived from FAIR data principles and requirements specific to joint engineering research projects. The fulfilment of requirements is indicated by “✔”, while unfulfilled requirements are indicated by “✗”. In instances where a specific requirement is not assessable, for example, in the case of a minor local installation that is not accompanied by the installation of additional software, the ELN is marked with “NA”. Conversely, if the fulfilment of a requirement is unknown, the ELN will be marked with “?”. The complete evaluation in terms of Excel sheets is publicly accessible under an open source licence on Zenodo (Opatz, T.; Feldhoff, K.; Wiemer, H.: “Electronic Lab Notebook Evaluation Tool”, https://doi.org/10.5281/zenodo.15241857, last accessed: 8 June 2025).

4.1. Comparison of Original SP and Adapted SP Versions

In order to further evaluate SP as an ELN and identify potential market niches for it, it is necessary to demonstrate the ways in which the features of SP could be beneficial in various application scenarios.

4.2. Use Case Scenarios

In

Table 7. Analysis of use case scenarios S1–S3 for the ELN implementation SP@TUD is presented. If a requirement is fulfilled within a scenario, the column “Available” is marked as “✔”; otherwise, it is marked as “✗”. The original weighting of each requirement is displayed in the column “w”. Columns “wS<n>”, where $n\in \{1,2,3\}$, indicate the differences in weighting factors assigned to the requirements, with feasible values ranging from $\{-5,-4,-3,-2,-1,0,1,2,3,4,5\}$. The reasons for deviations from the original weighting factors are elaborated in the columns “Reason for wS<n>”, where the key argument for the divergence is highlighted in bold. All corresponding abbreviations and values are further clarified in Table 5.

Requirement	w	Available	wS1	Reason for Difference	wS2	Reason for Difference	wS3	Reason for Difference
Without costs (basic version)	3	✗	0	—	+1	Collab-Big-Mixed	0	—
Widely used at German research institutes (>10)	1	✔	0	—	+2	Collab-Big-Mixed	0	—
Creation of groups	2	✔	0	—	+3	Collab-Big-Mixed	0	—
No requirement of IT knowledge in usage and expansion	2	✗	0	—	−2	Dom-Mixed+IT	0	—
Full text search	2	✔	+1	Sample-Mass	0	—	0	—
Assigning keywords for searching data	2	✔	0	—	+2	Data-Basic+Sim+Ex	+1	Data-Basic+Sim
Comment function	2	✔	0	—	+2	Collab-Big-Mixed	0	—
Internal linking of projects/items/data records	2	✔	0	—	0	—	+3	Proc-Tree-Big
Access rights at file level	3	✔	+1	Collab-Small-Mixed	+1	Collab-Big-Mixed	+1	Collab-Small-Comp
File version management	3	✔	0	—	+2	Collab-Big-Mixed	0	—
Standardised data entry through creation of data entry form	3	✔	0		+1	Collab-Big-Mixed	0	—
Discussion forum	1	✔	0	—	+1	Collab-Big-Mixed	0	—
Inventory/stock management	2	✗	+1	Sample-Mass	0	—	0	—
Barcodes	2	✔	+2	Sample-Mass	0	—	+1	Sample-1000
Template creation	3	✔	0	—	0	—	+1	Proc-Tree-Big
Storage of vector-valued data	-	✗	0	—	+3	Data-Basic+Sim+Ex	+3	Data-Basic+Sim
Storages of >5000 items per list	-	✗	+5	Sample-Mass	0	Sample-100	0	Sample-1000
Differentiation of protocols (machine, process, material)	1	✗	0	—	0	—	+1	Proc-Tree-Big
Graphical differentiation of protocols	1	✗	0	—	0	—	+1	Proc-Tree-Big
Usage of taxonomies	3	✔	0	—	+1	Dom-Mixed+IT	0	—
Added publication platform	3	✗	0	—	0	—	+1	Proc-Tree-Big
Two-factor authentication	2	✔	+1	Collab-Small-Mixed	+1	Collab-Big-Mixed	+1	Collab-Small-Comp
Shibboleth authentication	0	✔	0	—	0	—	0	—
Storage of data with increased IT protection requirements	-	✗	+5	Collab-Small-Mixed	+5	Collab-Big-Mixed	+5	Collab-Small-Comp
Mapping of workflows	3	✔	0	—	+1	Proc-5	+2	Proc-Tree-Big
Graphical illustration of (internal company) workflows	2	✔	0	—	0	—	+1	Proc-Tree-Big
Merging sample data from different experiments	4	✔	0	—	0	—	+1	Proc-Tree-Big
Sum of possible points			68		76		75
Absolute score			45		57		52
Relative score			0.66		0.75		0.69

and

Table 8. Analysis of use case scenarios S4–S6 for the ELN implementation SP@TUD is presented. If a requirement is fulfilled within a scenario, the column “Available” is marked as “✔”; otherwise, it is marked as “✗”. The original weighting of each requirement is displayed in the column “w”. Columns “wS<n>”, where $n\in \{4,5,6\}$, indicate the differences in weighting factors assigned to the requirements, with feasible values ranging from $\{-5,-4,-3,-2,-1,0,1,2,3,4,5\}$. The reasons for deviations from the original weighting factors are elaborated in the columns “Reason for wS<n>”, where the key argument for the divergence is highlighted in bold. All corresponding abbreviations and values are further clarified in Table 5.

Requirement	w	Available	wS4	Reason for Difference	wS5	Reason for Difference	wS6	Reason for Difference
Without costs (basic version)	3	✗	0	—	0	—	0	—
Widely used at German research institutes (>10)	1	✔	0	—	+2	Collab-Med-Research	0	—
Creation of groups	2	✔	+2	Collab-Med-Mixed	+2	Collab-Med-Research	+2	Collab-Med-Mixed
No requirement of IT knowledge in usage and expansion	2	✗	0	—	0	—	−2	Dom-Mech+Mat+IT
Full text search	2	✔	0	—	0	—	+1	Sample-Mass
Assigning keywords for searching data	2	✔	+2	Data-Basic+Sim+Ex	+2	Data-Basic+Sim+Ex	0	—
Comment function	2	✔	+1	Collab-Med-Mixed	+1	Collab-Med-Research	+1	Collab-Med-Mixed
Internal linking of projects/items/data records	2	✔	+1	Proc-5	+1	Proc-5	0	—
Access rights at file level	3	✔	+1	Collab-Med-Mixed	0	—	+1	Collab-Med-Mixed
File version management	3	✔	+1	Collab-Med-Mixed	+1	Collab-Med-Research	+1	Collab-Med-Mixed
Standardised data entry through creation of data entry form	3	✔	+1	Collab-Med-Mixed	+1	Collab-Med-Research	+1	Collab-Med-Mixed
Discussion forum	1	✔	+1	Collab-Med-Mixed	+1	Collab-Med-Research	+1	Collab-Med-Mixed
Inventory/stock management	2	✗	0	—	0	—	+1	Sample-Mass
Barcodes	2	✔	0	—	+1	Sample-1000	+2	Sample-Mass
Template creation	3	✔	0	—	0	—	0	—
Storage of vector-valued data	-	✗	+3	Data-Basic+Sim+Ex	+3	Data-Basic+Sim+Ex	+5	Data-Basic-Live
Storages of >5000 items per list	-	✗	0	—	0	—	+5	Sample-Mass
Differentiation of protocols (machine, process, material)	1	✗	0	—	0	—	0	—
Graphical differentiation of protocols	1	✗	0	—	0	—	0	—
Usage of taxonomies	3	✔	+1	Dom-Mixed	0	—	0	—
Added publication platform	3	✗	0	—	0	—	0	—
Two-factor authentication	2	✔	+1	Collab-Med-Mixed	0	—	+1	Collab-Med-Mixed
Shibboleth authentication	-	✔	0	—	+1	Collab-Med-Research	0	—
Storage of data with increased IT protection requirements	-	✗	+5	Collab-Med-Mixed	+2	Collab-Med-Research	+5	Collab-Med-Mixed
Mapping of workflows	3	✔	+1	Proc-5	+1	Proc-5	0	—
Graphical illustration of (internal company) workflows	2	✔	0	—	0	—	0	—
Merging sample data from different experiments	4	✔	0	—	0	—	0	—
Sum of possible points			73		71		77
Absolute score			53		54		51
Relative score			0.73		0.76		0.66

, specific requirements derived from comparisons with other ELNs are reassigned weights, which differ from the original weights (“w”) provided in Table 6. Additionally, new requirements have been formulated based on practical experience with SP, tailored to the characteristics of each specific scenario, to facilitate a comprehensive evaluation of SP across various contexts.

The rationale for each scenario-specific weighting (denoted as wS1 through wS6) is detailed using abbreviations from Table 5, with key aspects emphasised in bold for clarity. For instance, in scenarios involving a larger number of collaborators requiring licenses, the significance of the “without costs” requirement is proportionally increased. As a result, the weighting wS2 for the large-scale collaboration in scenario S2 is incremented by one, with the “Reason of wS2” column indicating the abbreviation “Collab-Big-Mixed” for the collaborators in scenario S2. Here, the term “Big” is highlighted in bold to underline that the size of the collaboration was the decisive factor in adjusting wS2 compared to the original weighting “w” for this particular requirement.

Table 7 provides an analysis of scenarios S1 to S3, while Table 8 focuses on scenarios S4 to S6.

The results of the scenario analysis indicate that the adapted SP version demonstrates strong applicability for large process chains and projects with significant diversity in specialisations—enabled by the use of taxonomies—and a broad scope of potential collaborations. This is particularly evident in scenarios S2, S4, and S5, which achieved higher scores compared to the other scenarios. However, SP may not be the most suitable solution for projects requiring the storage of live vector-valued data for managing more than 5000 samples, as observed in scenarios S1 and S6.

4.3. Use Case Scenario AMTwin

To illustrate the viability of the adapted SP version, its implementation within the joint research project AMTwin [23], which shares characteristics similar to those of scenario S5, is presented in this section.

The project AMTwin is a collaborative research project involving six research organisations. Its primary objective is to develop a data- and model-based methodology for predicting the fatigue behaviour of the additively manufactured titanium alloy Ti-6Al-4V. The employed additive manufacturing technique, Laser Powder Bed Fusion (LPBF), is characterised by numerous influencing variables that interact in complex ways, significantly affecting the material’s quality. To address the extensive range of influencing factors and measurement methods, the project required a multidisciplinary team of researchers. Figure 4 illustrates the primary processes, with colour coding used to represent the involvement of different project partners in each process.

The integration of SP as an ELN within the project AMTwin has delivered a robust solution for collaborative data management and exchange among the project partners. In this implementation, SP has been tailored to meet the specific demands of a multidisciplinary engineering research environment, ensuring effective data sharing, traceability, and adherence to the FAIR data principles, which are essential for maintaining transparency and reproducibility in research workflows.

SP was chosen as the project-wide ELN due to several key advantages. Firstly, as an official service provided by the computing centre of the project partner TUD, SP ensures secure data storage on TUD servers located in Germany, with backups managed by TUD at no additional cost to the project. Secondly, SP’s global accessibility and independence from specific device requirements made it a practical choice for collaboration. This setup also allowed external institutions to be seamlessly authenticated and authorised via the user identity management system of the TUD. These factors eliminated the need for additional software installations and enabled researchers to use an ELN environment that they were already familiar with.

In the following, a selection of features will be presented which have been employed in the adapted SP version used for the joint research project AMTwin.

4.3.1. Common Technical Language

A domain-specific standardisation process was established through the creation of the “Ontology for Additive Manufacturing” (OFAM), an application ontology derived from the “Elementary Multiperspective Material Ontology” (EMMO) developed by the “European Material Modelling Council” (EMMC). The collaborative development of OFAM involved all project contributors, ensuring that terms and definitions are clearly defined and widely accepted within the relevant research fields. The adoption of this standardised ontology, as depicted in Figure 5, supports the generation of precise templates for entering data and metadata, thereby enabling advanced analysis of the data using machine learning models.

4.3.2. Data Documentation

As depicted in Figure 6, data within the AMTwin project are organised and stored in SP lists. These lists, which contain data specific to individual processes, can be accessed directly from the homepage of the AMTwin SP website via the menu bar or SP tiles. Each list displays the processed samples along with their respective processing parameters and measurements in a tabular format. Furthermore, samples can be modified using SP web forms, enabling dynamic data management. This structured approach facilitates the comprehensive and efficient documentation of project data.

4.3.3. Management of Compute Workflows

Workflows facilitate the automation of computational processes. Within the AMTwin project, these workflows were employed for documenting procedures and extracting information from scientific publications related to the additive manufacturing of metals. The user interface of the associated webpage, alongside examples of workflow outcomes, is illustrated in Figure 7. The implementation of such automated workflows significantly reduces the time required by researchers, thereby enhancing efficiency.

4.3.4. Data Export

The export of data from the SP website, aligned with the FAIR data principles to enable open access publishing, is implemented through the data and metadata export concept illustrated in Figure 8. This export process allows users to specify a target audience for the data by selecting from options such as all data, data designated for publication, or data restricted to a specific workgroup. The data are accompanied by metadata organised according to standard metadata schemes like Dublin Core, enhanced with additional keys designed to capture technical metadata relevant to the field of additive manufacturing. These additional keys originate from the custom-developed application ontology OFAM, which is grounded in the European Materials Ontology (EMMO). Once the user makes a selection, the metadata files are converted into the DataCite format, ensuring compatibility for publication on external repositories such as Zenodo. Following this, the selected data and its documentation are compiled and packaged into a downloadable ZIP file. This ZIP file includes the research data for each selected process, formatted as CSV files, along with detailed accompanying data documentation.

5. Discussion

This section provides a comprehensive analysis of the findings from the implementation of SP as an ELN in collaborative research projects. The section is divided into the subsections “Limitations” (Section 5.1) “Benefits” (Section 5.2), and “Lessons Learned” (Section 5.3), each addressing critical aspects of the functionality of SP.

The “Limitations” subsection highlights the challenges and constraints encountered during the deployment of SP, offering insights into areas requiring improvement. In contrast, the “Benefits” subsection explores the key advantages of using SP as an ELN, emphasising its contributions to data management and collaboration. Finally, the “Lessons Learned” subsection summarises practical insights gained from this study, providing recommendations for enhancing the usability and scalability of SP in future implementations.

5.1. Limitations

In the course of deploying SP as an ELN within collaborative research projects, several practical challenges and considerations emerged. These challenges not only highlight the limitations of SP in its current adaptation but also provide valuable insights for improving its functionality and scalability in future implementations.

• Evaluation: The evaluation of SP and its comparison with established ELNs are based exclusively on the authors’ experience, without incorporating feedback from researchers at other institutions or insights from user surveys. Consequently, there is room for further refinement of the evaluation.
• Customisation efforts: The flexibility in appearance and functionality provided by SP comes with associated costs, particularly in the context of official TUD services. Customisations require significant time and expertise, which can strain project resources.
• IT security constraints: The installation of SP applications to implement templates for future projects is not always feasible. This limitation arises due to varying IT security regulations enforced by the organisations hosting SP, potentially hindering the scalability of SP-based ELN solutions.
• Licensing requirements: The use of SP is dependent on all collaborating parties possessing valid SP licenses. This requirement poses a barrier to seamless collaboration, especially in projects involving partners without prior access to SP.
• Adaptation: While small changes can be made via the web-based user interface of SP, larger adaptations are time-intensive and prone to errors. Moreover, replicating these adaptations across multiple SP websites for other research projects introduces additional complexity and inefficiencies.
• Implementation effort: The adaptation of SP using the open source tools RDMAGENT and SPRDMJS necessitates a significant implementation effort and specialised technical expertise. This constitutes a critical factor in the implementation process, as it entails extensive development time, thorough testing, and the allocation of skilled personnel. Institutions must conduct a careful assessment of their internal capabilities prior to undertaking such adaptations, given that the responsibility for ongoing maintenance and troubleshooting predominantly resides with them. Consequently, this may present considerable challenges for organisations with limited technical support resources.
• Storage performance: In the AMTwin project, approximately 1000 test samples were recorded in user-defined SP lists. However, SP lists containing over 5000 items exhibit reduced performances (https://www.sharepointdiary.com/2017/02/list-view-threshold-in-sharepoint-online-faq.html, last accessed 5 April 2025), particularly for operations such as renaming, copying, and pasting datasets. This limitation impacts the usability of SP for projects with large datasets.
• Manual data entry: A significant challenge is the lack of a fully automated process for populating SP templates with data from ELNs or spreadsheet software. Collaborators are required to manually input datasets into SP lists, which increases the likelihood of human error and reduces efficiency.

These challenges highlight the need for ongoing development and refinement of SP-based ELN implementations to ensure their effectiveness and scalability in diverse research settings.

5.2. Benefits

The implementation of SP as an ELN in collaborative research projects has highlighted several key benefits, which are outlined as follows:

• Centralised data management: SP enables the consolidation of research data into a single platform, ensuring easy access, organisation, and retrieval of information by all project collaborators.
• Customisability and flexibility: The adaptable structure of SP allows users to tailor the platform to meet the specific needs of various research projects, including the creation of custom workflows, templates, and data structures.
• Global accessibility: With its web-based interface, SP provides researchers with the ability to access and manage data from any location, facilitating international and interdisciplinary collaboration.
• Integration with existing tools: SP integrates seamlessly with other Microsoft Office tools and external software, enhancing compatibility and streamlining workflows across multiple platforms.
• Security and compliance: SP offers robust security features, such as role-based access control and secure data storage, ensuring compliance with institutional and regulatory standards for research data management.
• Support for collaboration: Features of SP, such as shared access to documents, version control, and communication tools, promote efficient teamwork and coordination among project partners.
• Adaptation of software tools: Using the pre-existing open source software tools SPRDMJS and RDMAGENT can substantially reduce the implementation effort and provide a customised solution that integrates seamlessly with existing workflows and infrastructure. These tools serve as a flexible foundation, allowing adaptation to specific requirements and potentially extending functionality beyond standard configurations.
• Scalability for diverse projects: The platform accommodates a wide range of project sizes and complexities, making it suitable for both small-scale studies and large-scale, multidisciplinary research initiatives.

These benefits underline the potential of SP as a versatile and effective ELN solution for managing data and fostering collaboration in engineering and scientific research projects.

5.3. Lessons Learned

The adaptation of SP as an ELN for engineering joint research projects yielded several valuable lessons that can inform future implementations as follows:

• User-centred design: Engaging researchers early in the adaptation process was crucial. Their feedback helped shape the platform to meet specific needs, enhancing usability and acceptance. Ensuring intuitive navigation and streamlined workflows was pivotal for fostering effective collaboration among diverse teams.
• Flexibility in data management: The ability to integrate various data types—ranging from basic data to simulations and experimental results—proved essential. This versatility allowed the platform to accommodate the diverse requirements of different research projects, making it a robust tool for data management.
• Robust security measures: Implementing strong IT security measures such as two-factor authentication, secure data transmission protocols (HTTPS/TLS, SSH), and fine-grained access control at the item level was vital. These measures addressed the heightened IT protection requirements in research environments, ensuring data integrity and compliance with regulations.
• Adaptability to team size: The effectiveness of SP varied based on the size and nature of the collaborative effort. Smaller teams found the straightforward features beneficial, while larger groups required more advanced functionalities to manage complex workflows effectively. This insight emphasises the need for tailored solutions that can be adapted to varying project scales.
• Ongoing training and support: Providing comprehensive training sessions and resources was essential to facilitate a smooth transition to the target system. Ongoing support helped increase user satisfaction and productivity, highlighting the importance of investing in user education.
• Automation and scalability: Automating repetitive tasks such as data entry and report generation was identified as a significant improvement area. Scalability of the platform to handle large datasets and multiple concurrent users was also highlighted as a critical factor for long-term usability.
• Integration with external tools: The ability to integrate SP with external analytical and visualisation tools enhanced its utility. Seamless data exchange and compatibility with other software systems were crucial for efficient workflows.
• Scalability and adaptability: To ensure SP’s suitability for future projects, it is crucial to align its deployment with organisational IT policies and to develop standardised templates. Additionally, incorporating automated workflows for data management can enhance its scalability, making it more versatile for various project sizes and requirements.
• Cost–benefit analysis: Evaluating the balance between the flexibility of SP and the associated costs, including time investment, licensing fees, and performance limitations, is essential. This ensures that the platform’s benefits justify its implementation for specific research projects.
• Enhancing automation: Introducing automated tools or scripts for data integration would greatly improve SP’s efficiency. This is particularly important for large-scale projects where manual data handling can be time-consuming and prone to errors.
• Facilitating multidisciplinary collaboration: Overcoming challenges such as licensing restrictions and IT security concerns is critical for enabling effective collaboration among diverse organisations. Addressing these issues would promote the broader adoption of SP in multidisciplinary research settings.

The insights gained from this study not only enhance the understanding of SP as an ELN but also contribute to the broader discourse on effective data management in collaborative research settings.

6. Conclusions

6.1. Summary

The adaptation of SP as an ELN in typical engineering joint research projects, exemplified by the AMTwin project, has demonstrated its distinct advantages over existing ELN and research data management tools. The flexibility and adherence of SP to the FAIR data principles position it as a viable solution for facilitating the transition towards open data practices, thereby lowering barriers for researchers to adopt open data methodologies.

The evaluation of SP alongside commonly used ELNs, combined with the scenario analysis, establishes a benchmark framework for assessing ELN tools. This approach provides a structured methodology for comparing functionalities and identifying areas for improvement in ELN implementations. Furthermore, the development of software tools such as SPRDMJS and RDMAGENT, which extend the capabilities of SP, highlights the potential for continual enhancement. These tools, available under an open source licence, encourage community-driven development and broader accessibility.

6.2. Research Questions

The research questions outlined in the introduction have been systematically addressed throughout the paper, providing a comprehensive analysis of SP as an ELN for collaborative engineering research projects.

RQ1: 

The comparison of SP to established ELN tools in terms of functionality and usability was thoroughly examined in Section 4, “Results”, where the adaptability, integration capabilities, and usability of SP were highlighted alongside its limitations, such as scalability issues for large datasets.

RQ2: 

The strengths and limitations of SP in the context of open data and FAIR data principles were discussed in Section 5, “Discussion”, with specific emphasis on the compliance of SP with FAIR principles through its data management features and the challenges associated with manual data entry and licensing requirements.

RQ3: 

The adaptation of SP to meet specific data management requirements in engineering research was detailed in Section 3, “Methodology”, showcasing the steps taken to tailor SP to the unique needs of the AMTwin project.

RQ4: 

The criteria for benchmarking ELN tools across diverse research scenarios were developed and applied in Section 3, “Methodology”, where a structured evaluation framework was presented, enabling a standardised comparison of SP and other ELNs.

RQ5: 

The support of SP for regulatory compliance and enhancement of research reproducibility was addressed in Section 4, “Results”, demonstrating its capabilities in facilitating structured data documentation and secure access control.

6.3. Outlook

The role of SP as an ELN holds promise for advancing open data practices and supporting the principles of open science. Its adaptability and accessibility make it a valuable platform for facilitating transparency, reproducibility, and collaboration in research workflows. The potential to integrate SP with additional software packages and external tools further enhances its utility, positioning it as a cornerstone for research data management in engineering and beyond. The adoption of SP could also encourage standardisation in data management practices, fostering broader acceptance and usage across diverse research disciplines.

Looking ahead, the functionality of SP can be further expanded through additional software packages. The integration of features such as automated design of experiments, aimed at reducing experimental workload, and the automatic acquisition of process machine data, could significantly enhance the utility of SP. Currently, such features are primarily found in specialised software for automated process monitoring that interfaces directly with machine control systems. Introducing these capabilities into SP would address existing market niches and further solidify its role as a comprehensive tool for research data management.

6.4. Future Work Perspectives

To enhance SP’s effectiveness as an ELN, conducting a user survey would be valuable for pinpointing any remaining limitations and facilitating a more precise comparison with established ELNs. Future research should then focus on overcoming the identified limitations of SP, such as scalability issues for handling large datasets and the need for enhanced automation in data integration workflows. Developing features like automated design of experiments and direct integration with process machine data would address existing market gaps and expand the applicability of SP. Additionally, efforts to improve the interoperability of SP with other ELN platforms and the creation of standardised templates for various application scenarios could further enhance its usability. Collaborative initiatives to refine and develop open source extensions like SPRDMJS and RDMAGENT will also play a crucial role in advancing the capabilities of SP.

By addressing these areas, SP can evolve into a more comprehensive and efficient tool, driving innovation in research data management and supporting the broader goals of open science.