Introduction
Open Science is a set of practices that go beyond open data, ensuring the full scientific process is open and accessible to everyone. (UNESCO, 2021)
The rise of Open Science, demanding Open Access to research data and the tools used to transform the data, has opened the possibility for data reuse at an unprecedented scale, leading to new questions about reproducibility, provenance, and attribution. This makes data versioning an integral part of Open Science and the FAIR Guiding Principles for scientific data management (Wilkinson et al., 2016), which require us to unambiguously be able to uniquely identify a specific version of a dataset.
Versions are related to the idea that information objects can have different representations over time. In Library and Information Science (LIS) and Knowledge Organisation, this phenomenon is also discussed as ‘instantiation’. In general, an instantiation is the realisation of a work in time as a result of an action (Smiraglia, 2005). Often, networks of multiple instantiations, for example derivations or mutations, form around information objects. Instantiation networks can be particularly complex in the context of research data as a result of the ‘complex lifecycles of data deposit, use, and reuse’ (Smiraglia, 2017). From a Knowledge Organisation perspective, these complex instantiation networks of research data raise many questions that are not yet sufficiently explored through theory, for example, under which circumstances instantiations inherit properties from each other, and the implications for metadata (Greenberg, 2009).
As data move through their lifecycle, from initial collection through processing, analysis, interpretation, and eventual publication, they undergo numerous transformations that create related but distinct datasets. Each processing step, format conversion, quality enhancement, or analytical derivation produces what could be considered a new ‘version’ of the original data. However, we often speak about ‘B’ being a version of ‘A’ without using systematic terminology to describe these relationships. This lack of clarity leads to confusion when relating digital data artefacts to each other, undermining the very reproducibility and traceability that Open Science seeks to achieve. A precise definition of terminology to identify each data artefact and its relation to other data artefacts would help in data management, tracing data provenance, supporting reproducibility, and clarifying attribution and citation.
Versioning practices are well-established in software development, as well as in library and information science. Technical systems to support versioning have been available in software development since the early 1970s to enable asynchronous concurrent work by a team of developers on software code (Fitzpatrick et al., 2009; Grune, 1986; Rochkind, 1975). Over the past twenty years, the Git protocol has established itself as the most widely used version control system (Perez-Riverol et al., 2016). These technical implementations of versioning focus on changes in the bitstream. But, as we will show in this paper, there are many other ways in which individual data artefacts can both relate to each other and differ from each other.
In this paper, we will use the Satellite ASTER Geoscience Map of Australia Project (Caccetta et al., 2013; Cudahy, 2012) developed at the Commonwealth Scientific and Industrial Research Organisation (CSIRO) as an example to explore how the artefacts in this work are related (Figure 1). The work of the CSIRO team is based on the Level 1B1 and Level 2 products of the Advanced Spaceborne Thermal Emission and Reflection Radiometer (ASTER) mission (Tsu et al., 1996). The complexity and variety of research outputs from the CSIRO project were the starting point for us to ask how we can describe the relationships and evolution of the many outputs from this project.
Figure 1
Overview of the data products and data items of the Satellite ASTER Geoscience Map of Australia (Caccetta et al., 2013).
In search of a conceptual framework to describe the relationships between the outputs of the Satellite ASTER Geoscience Map of Australia Project, the Research Data Alliance (RDA) Data Versioning Working Group (WG) adopted the Functional Requirements for Bibliographic Records (FRBR) to understand how data artefacts relate to each other and applied it to data versioning. While FRBR was not designed as a comprehensive model of instantiation as described by (Smiraglia, 2005), it is widely used in library and information science for representing networks of related information objects in information systems.
FRBR is now part of the IFLA Library Reference Model (LRM) (CEG et al., 2024). It describes how creative and intellectual works relate to the items made available through libraries and other information infrastructures (e.g., data centres), and how they are described in the respective catalogues.
The IFLA Library Reference Model defines a hierarchy of entities that are used to describe information resources:
Work represents the abstract concept or intention behind a ‘distinct intellectual or artistic creation’. In data terms, this could be the overarching research objective or the initial data collection activity, regardless of how data is stored, formatted, or analysed. Here, we interpret the work ‘Satellite ASTER Geoscience Map of Australia’ (Caccetta et al., 2013) as a work derived from ‘Advanced Spaceborne Thermal Emission and Reflection Radiometer’ (ASTER) (Tsu et al., 1996).
Expression represents a specific intellectual form that the work takes. In data terms, this may relate to how data is structured, organised, processed, or derived. For instance, the ‘Satellite ASTER Geoscience Map of Australia’ is expressed as a set of data products that capture and store data derived from observations made by the ASTER sensor aboard the Terra satellite, with each product having its own underlying structure, variables, and relations within a data product.
Manifestation refers to the physical or digital embodiment of an Expression. In data terms, this is the file format or structure of a digital object that embodies a particular expression. For instance, in the case of the Satellite ASTER Geoscience Map of Australia, the data products are provided (‘manifested’) as GeoTIFF, netCDF, or BSQ formats.
Item represents a single instance or a copy of a Manifestation. This could be a specific file on a server from which a data file can be downloaded. In the ASTER project, Items are the individual files hosted on platforms operated by CSIRO (Cudahy et al., 2020), Geoscience Australia (Cudahy et al., 2012), and the National Computational Infrastructure Australia (Cudahy et al., 2023).
For clarity, we will capitalise the terms Work, Expression, Manifestation, and Item throughout this paper when we refer to the concepts defined above.
Methods
The recommendations were developed using three main approaches: 1) a bottom-up analysis of current practices, 2) the application of an established conceptual framework, i.e., the IFLA Library Reference Model (LRM), and 3) discussion with the community of data curation practitioners to develop the data versioning principles and then refine them into recommendations.
Collecting and analysing data on versioning practices. We have collected 56 examples of data versioning use cases or current practices (Klump et al., 2025). These use cases came from contributions by individuals, primarily members of the RDA Data Versioning Working Group, and literature reviews. The use cases represent the practices of approximately 42 organisations worldwide, spanning various research domains such as social and economic science, earth science, and molecular bioscience, and involving various data types.
The purpose of collecting these use cases was to document current practices reported by data providers and to identify differences in their approaches to data versioning. By analysing these use cases, we compiled a list of key issues and inconsistencies. Notably, we observed inconsistencies in terminology, with different terms used for the same concept or the same term having different meanings and practical applications. For instance, the term ‘version’ was used very broadly, beyond its primary meaning of revisions and replacements.
Applying the Library Reference Model (LRM). In a second step, we applied the LRM, especially the FRBR model, as described earlier in this paper. We used the FRBR model as a framework for developing the data versioning principles and for developing the actionable recommendations for data versioning guidelines, as detailed in this paper.
Community feedback. Drawing from an analysis of the collected use cases and the application of the FRBR model to the data lifecycle, we initially developed six data versioning principles (Klump et al., 2021). These principles provide a general framework for consistent data versioning practices and establish a common language, with specific definitions for terms such as revision, release, granularity, manifestation, provenance, and citation.
Subsequently, we organised a data versioning workshop through the Berlin University Alliance (BUA) in June 2024 in Berlin, Germany, to discuss the actionable recommendations derived from the data versioning principles. Around 40 experts from information infrastructure institutions and diverse scientific backgrounds attended this workshop. The contributions of experiences from their own work by these experts significantly contributed to the discussion, helping to clarify the recommendations for data versioning for practitioners. Key topics were the differences between revision and release of data, dynamic data, provenance and citation. Participants discussed these topics in small groups, led by a moderator who collected the results and issues raised. A documentation of the workshop and results was published (Klump et al., 2024). The recommendations in this paper were drafted after the workshop and further refined through discussions with RDA members at three RDA plenary meetings in 2025 and 2026.
Results
From the discussion and the analysis of versioning use cases (Klump et al., 2025), the RDA Data Versioning Working Group developed six data versioning principles (Klump et al., 2021):
Version control and revisions (Revision)
Identifying releases of a data product (Release)
Identification of data collections and aggregates (Granularity)
Identification of different data formats (Manifestation)
Requirements for provenance of data sets (Provenance)
Requirements for data citation (Citation)
Publication of the data versioning principles helped the discussion by providing terminology that could differentiate the different patterns and uses of data versioning, but it did not provide actionable guidelines for applications in data management and curation. Through a series of public events involving the community (as documented in the Working Group final report (Klump et al., 2020), we discussed our proposed actionable recommendations on the versioning of data and sought feedback from practitioners in this field.
In this paper, we summarise the outcomes of this community-driven development. Key contributions were made within the framework of the Research Data Alliance (RDA) and its plenary meetings since 2016, and in particular during the Working Group phase of this group between 2018 and 2020. Building on these global discussions among experts in research data management, further community-driven activities were supported in 2024 through funding from the Berlin University Alliance (BUA). The results of these efforts were subsequently discussed with the RDA community and consolidated by the authors of this paper (Klump et al., 2020, 2021, 2024).
General Recommendations
Data versioning practices must be embedded in a consistent management strategy for research data. These should include standardised guidelines for version tracking, using Persistent Identifiers (PIDs) for unique identification, and maintaining clear documentation of changes to the data and metadata. Their technical implementation requires user-friendly version control systems and effective communication of versioning practices to stakeholders while encouraging regular reviews and updates to align with technological advancements and community standards.
Revisions
Recommendations
File-based data (file system): Use systematic file and folder names (Martinez, 2017). Include the modification date of the file in the format described in ISO 8601 (ISO, 2019). This approach is suitable for the private and collaboration domains.
File-based data (Git): Use Git for small files (Martinez, 2017) or Data Version Control (DVC, Kuprieiev et al., 2026, for larger files. This approach is suitable for the collaboration domain as the distributed nature of tools based on the Git protocol supports data sharing, documentation, and recording of provenance.
Dynamic data (relational databases): follow the recommendations of the RDA Dynamic Data Working Group (Rauber et al., 2025).
Motivation
The most basic case of versioning digital objects is noting a change in the bitstream of an object without determining the significance of the change. Every change in the bitstream constitutes a Revision, and several technical and non-technical solutions exist to manage the associated files (see, e.g., Grune, 1986; Martinez, 2017; Perez-Riverol et al., 2016; Rochkind, 1975). Version information, like internal system identifiers with annotations, like commit notes in Git or other systems, makes a Revision of a dataset uniquely identifiable, allowing data users to determine whether data has changed over time and to determine specifically which Revision of a dataset they are working with.
The most straightforward approach is to give files systematic names. Data Carpentries (Martinez, 2017) recommends this approach as the technically simplest. This method is suitable for individual researchers or small working groups. An alternative to managing files in a file system is to use a versioning system based on Git (Martinez, 2017). Data Carpentries recommends this method because it supports versioning, backup, file sharing, and, to a certain extent, provenance tracking.
The RDA Working Group on Data Citation (WGDC) developed and published recommendations on the citation of dynamic data (Rauber et al., 2025). The aim is to provide a tool for describing which subset of a large dynamic dataset was used at a particular time. This approach is particularly well-suited for systems like relational databases and versioning of file-based data via Git, XML databases, and NoSQL databases, but it does not extend beyond the management and identification of Revisions.
Releases
Recommendations
Releases: Establish workflows for creating and identifying data releases.
Release notes: Use release notes to communicate the significance of the change and record the provenance of data (Lacan, 2023).
Motivation/Problem statement
Datasets may undergo several changes before they are made available to other users (Treloar and Klump, 2019). Making a dataset available to other users is an editorial process, and in software versioning, it is called a Release. While tracking Revisions can be done as a technical process, comparing the checksum of a dataset to detect whether it has changed, the editorial process of producing a release takes the significance of the change into account.
To make sense of the differences between multiple versions, you should explicitly mark official ‘Releases’ for your data using well-adopted and widely understood conventions, even if versions between the releases are tagged using a custom scheme (Buttigieg et al., 2022). There are many reasons for making new Releases available. Examples are:
Fixing errors that data users have reported.
Changes to the entire data set in which a new approach (a new algorithm, for example) has been applied to the processing of the original data.
Data were removed because certain properties were identified as holding sensitive or confidential data (after release).
Existential angst resulted in the author’s decision to change the vision of their work significantly.
A Release relates to the editorial process of publishing a new Expression. This requires establishing workflows for creating and identifying data Releases and using release notes to communicate the significance of the change using well-adopted and widely understood conventions (Lacan, 2023). The significance of the change will depend on the requirements of the designated user community (Bettivia, 2016; Parsons and Duerr, 2005).
Figure 2 illustrates a case in which an original data set (time = T0) was appended and partially overwritten with changes. The proposed procedure is to publish a new data release after the first set of changes (time = T1) and the second set of changes (time = T2). Each release should be separately identified. In addition, to enhance findability, all releases can be identified by an umbrella object that encompasses all releases.
Figure 2
Identification and retention of data releases (Klump et al., 2016). The identifiers in this figure are only for illustration purposes.
Granularity
Recommendations
Collections: Identify the collection as a collection item. In the case of very large collections, i.e. thousands to millions of objects, persistent identifiers for individual items in the collection can be minted on demand.
Time series: Time series in which data are only appended and not inserted can be identified by one persistent identifier. Subsets can be identified either by defining a canonical path or by using template PIDs.
Motivation
A data product (Expression) can be a set of data items, and the number of files (Items) associated with this data product can be very large. A data product might also change over time as a time series. Also, the data might come in different formats (Manifestations) and can be made available at multiple locations (Items). While it is important to make those differentiations, standards, or best practices for references between Items, and between Items and Manifestations, do not exist. The section below discusses different forms of data granularity, i.e. collections and time series, and recommends how to refer to the respective instances.
The granularity, the smallest identifiable unit by a persistent identifier, is not always easy to define. In some cases, where time or space are dimensions of the data, a subset may be defined by a range or by bounding parameters, or data may have an internal structure that allows the formulation of a canonical path to the defined granule. In other cases, the data product may be composed into a collection of discrete objects (Items).
Collections
A collection is a curated aggregation of resources (Items) that share a common context, purpose, provenance, theme, project, ownership, or management arrangement, and which can itself be identified, described, cited, and published as a discrete research object (Expression). In the context of data versioning, a collection is a set of discrete objects that together form a data product (Diepenbroek et al., 2014; Jenkyns et al., 2025). The ASTER data products distributed through NCI are an example of a collection (Cudahy et al., 2023).
Access to research data plays a key role in reproducibility. To enable reuse, a dataset’s granularity must be comprehensible for its designated user community in the context of other outputs like the research publication, code, and protocol (Jenkyns et al., 2025). In particular, where studies draw on parts of existing datasets, the ability to reproduce the data depends on consistent granularity.
Since a collection is a set of discrete objects, each item could be identified individually. Some data centres do not apply individual PIDs to all items but mint PIDs on demand. Some data centres use DOI as PIDs at the collection level (Klump et al., 2016) and alternate PIDs, e.g. EPIC IDs (Kálmán et al., 2012), at the individual item level. The use of alternate PIDs as part of data releases bears the risk of creating confusion about the identity of an object, especially if there is no way for machines to disambiguate the objects. In some cases, the structure of the collection can be used to define canonical paths to identify its constituent objects.
A special case of collections might be Complex Citation Objects (CCO) (Agarwal et al., 2025) and RO-Crates (Soiland-Reyes et al., 2022). The purpose of a CCO is to bundle many references to highly granular objects, e.g., data sets or physical specimens, into one digital object that is identified by a PID, which in turn links to all its constituent components by using related identifier elements as pointers. CCOs could be seen as a special case of a collection because of the one-to-many relations between CCOs and their constituent objects. While CCOs are designed for inclusion in scholarly publications and have a simple internal structure, an RO-Crate is a structured archive of all the items that contributed to a research outcome.
The relationship between a collection object and its constituent elements can be expressed through their metadata (relationType hasPart or isPartOf in DataCite metadata) or listed in a manifest (RO-Crate or CCO).
Figure 3 illustrates how a collection of objects can be identified, with each object having its own identifier.
Figure 3
Collection of objects, where each object contained in the collection has its own identifier (Klump et al., 2016). The identifiers in this figure are only for illustration purposes.
Time series
Time series are a special case of a changing data set in which changes occur only by appending new data (Figure 4). Identifying a time series as a whole may be sufficient, but there may also be use cases where snapshots of the time series could be considered as new Expressions derived from continuous updates to the time series, and would be identified as new data releases, e.g., monthly data releases.
Figure 4
(top row) Identification of a time series as a whole with identified data snapshots at times T0, T1 and T2 as individually identified data releases and (bottom row) identification of subsets through a canonical path (Klump et al., 2024). The identifiers in this figure are only for illustration purposes.
Mirroring and re-publication
Recommendation
Mirroring and re-publication: The mirrored or re-published data should always refer to the original source (authoritative version) using the ‘IsIdenticalTo’ attribute in the DataCite metadata (DataCite Metadata Working Group, 2026). This explicit relationship helps to manage multiple items that embody the same Manifestation.
Motivation
Mirroring and re-publication refer to making data available on another platform. This directly pertains to the Item entity, which represents a single instance or a copy of a Manifestation. A new item is created when data is mirrored or republished by a different service provider. For example, the hyperspectral scans of geological drill cores published by the Australian State and Territory Geological Surveys are available through the respective Geological Survey data portals and as a federated search through the National Virtual Core Library (NVCL) (CSIRO et al., 2023). To enhance performance and make large-scale data analysis of NVCL data easier, all hyperspectral data were mirrored to the high-performance computing platform at the National Computational Infrastructure.
The availability of data from two platforms affects metrics like download statistics. In the example described above, this would have led to a significant underestimate of the impact of the original data publications due to the larger number of downloads of the mirrored data from a platform with better bandwidth availability for data transmission. This can be relevant in cases where data centres have been asked to demonstrate their relevance and impact on their funding organisations.
Deleted items and retractions
Recommendations
Data unavailable: A persistent identifier should always resolve to a landing page displaying the metadata, even when a dataset has become unavailable.
Metadata unavailable: If both the data and the metadata have become unavailable, their persistent identifier should resolve to a tombstone page.
Retractions: Display the metadata with an appropriate release note describing that the data have been retracted.
Motivation
There are many reasons why Items can become unavailable, but the associated Expressions with their metadata and persistent identifier should persist. If the object was identified by a persistent identifier, the identifier will persist and should resolve to the metadata of the deleted object. If the metadata no longer exists, the identifier should resolve to a tombstone page providing further information. The DataCite support pages comprehensively summarise best practices for this case (DataCite, 2024).
Data publications that have been retracted still need to be identified and described. Whether the retracted data are still accessible will depend on the circumstances and the policy of the data repository. Retracted data can be kept accessible if this is necessary to support the reproducibility of results, even if they are wrong. There might also be cases where retracted data are inaccessible to prevent misuse. In both cases, the retraction should be explained in the accompanying release notes.
Provenance
Recommendations
Release notes: The provenance of a data item should be recorded in its accompanying release notes.
Git revision management: Using Git for revision management automatically records provenance. Most Git platforms also support release management with accompanying release notes.
Motivation
Provenance refers to the origin and history of the data. The LMR model’s hierarchy supports provenance by distinguishing between different levels of change (Work, Expression, Manifestation, Item) and different degrees of change. Tracking changes from one Expression to another is a core aspect of Provenance. The explicit relationships outlined in the LMR model, such as ‘prov:wasDerivedFrom’ linking a processed Expression to a raw Expression, are crucial for tracing data lineage.
Systematic versioning supports the recording of data provenance, as the version history and the release notes already record part of the provenance (Paine and Ramakrishnan, 2019). In principle, the chain of data products derived from one another should be traceable. In the case of mirrored data, a reference could be made to the source object (the authoritative version).
Several authors (Bellini, 2019; Lemieux, 2021; Sicilia et al., 2019; Specht et al., 2025) have pointed out that registering data on a blockchain would natively record provenance. While blockchain is a mature technology, how it would be used and what would be stored on the blockchain remains unclear.
Format variants
Recommendation
The metadata of the data product (Expression) should record the availability of different format variants (Manifestations) of the data. When manifestations are added or removed, the metadata of the Expression should be edited to record these changes. There are no known examples of Manifestations of data being separately identified with PIDs.
Motivation
In the versioning of software source code, the problem of format variants does not exist, as all items have the same format (text). In the case of software source code, changes in the bitstream are always indicative of changes in content. This is not necessarily the case with data. Sometimes, the same data product is produced in different formats but with the same content. For example, a dataset might be available as character-separated values and in JSON format. In this example, the content is identical, but the encoding is different, resulting in bitstreams with different checksums. In another example, a geophysical map might be offered in netCDF format and as a GeoTIFF. In both cases, the content is the same on the level of the data product (Expression), but its values are scaled differently on the data format level (Manifestation). Also, Manifestations may change over time, as new formats are added or content is migrated to new formats due to preservation actions, while the content of the data (Expression) does not change.
There are no known examples where Manifestations of data have been separately identified with PIDs, but DataCite recommends using the attribute ‘IsVariantFormOf’ in the relatedIdentifier element of the DataCite metadata schema (DataCite Metadata Working Group, 2026) in the metadata describing an Item.
Citation
Recommendations
Citation still follows the established practices for citation in scholarly communications, even though not all journals might yet accept it.
Credit is given to the creator of a data product by citing the Expression.
Citing the Item will credit the infrastructure providing access to the data product, but in the case of mirrored data, it might lead to skewed metrics.
Motivation
Data citation has been one of the primary motivations for developing formal data publication pathways (Altman and King, 2007; Costello, 2009; Klump et al., 2006; Parsons et al., 2010). Identification and versioning can help support citation, but the purpose of the citation has to be clear. Credit is given to the creator of this data product by citing the Expression. Reference to the Item supports reproducibility and gives credit to the infrastructure providing access to this resource.
The distinction between referencing the Expression or the Item leads to a problem of conflicting aims in the current system of citation metrics. Citing the data product (Expression) will give credit to the authors and their research output but will not differentiate who provided the service of making the data accessible. Citing the Item might lead to skewed metrics in the cases of mirrored data (see section on mirrored data). Credit can be given to the authors and the data provider (publisher) through the use of the appropriate metadata elements.
Versioning of metadata
Recommendation
While this use case may exist with metadata aggregators, there is no consensus on implementing metadata versioning in them. Communicate clearly to users which identifier refers to the object described by the metadata and which identifier refers to the metadata record itself.
Motivation
While metadata itself is not one of the four core FRBR entities, it is the means by which the four FRBR entities are described and linked. The question of whether metadata should be identified and versioned is currently under debate. Metadata records can change over time (Strecker, 2026), and some self-service repositories trigger a version change of the data upon changes to the metadata. Versioning of metadata records has not been part of the DataCite metadata schema since version 2.0. Versioning was no longer included in the DataCite metadata schema to avoid confusion with the versioning information relating to the data object, and because no compelling use case existed.
The rise of machine-readable metadata records ingested by metadata aggregators (Chodacki et al., 2025), and the use of generative AI for metadata generation and augmentation, create new use cases for metadata identification and versioning. As aggregators republish metadata, both human users and automated systems must be able to distinguish between different versions of a metadata record and identify the origin of the metadata.
Discussion
Versioning and the data life cycle
Traditionally, research data management has been described through a linear ‘data lifecycle’ model (DCC, 2010). In this view, the phases – from collection to processing, archiving, and reuse – follow a fixed sequence. While this model helped to establish basic structures, it oversimplifies the complexity of research practices and neglects the many interactions between the different stages (Cox and Tam, 2018). Instead of seeing the data life cycle as a rigid, one-directional process, data can be understood as part of a dynamic system in which feedback loops and iterative changes play a central role. For instance, published datasets can be re-annotated, enhanced, or reinterpreted in new contexts, and these changes can occur at different levels.
As data progress through their life cycle, a selection process occurs (Treloar and Klump, 2019), and only a fraction of the initial data artefacts will be shared, released as data publications or submitted to an archive. Furthermore, data can change their format throughout their life cycle. Derived data products, in particular, can be disseminated in multiple formats and through multiple platforms. The need for versioning became apparent early on in the management and identification of dynamic datasets. The work that led to the development of data versioning principles, which are the basis of this paper, was prompted by prior work of the RDA Working Group on Data Citation (Rauber et al., 2016).
The recommendations developed by the RDA Working Group on Data Citation noted that data versioning is essential for research to be reproducible, but they did not elaborate further on what versioning means. The need for further clarification prompted the formation of an RDA Interest Group on data versioning and, later, a Working Group. The RDA groups on data versioning began by collecting and analysing data versioning practices. The group noted that there was no systematic terminology for describing data versioning patterns and practices. To clarify the relationships between objects, the Library Reference Model (LRM) (CEG et al., 2024) proved to be a useful framework for the development of a systematic terminology.
We recognise that there is a broader scholarly discussion about the LRM model and whether it is an accurate representation of versioning (see e.g. Smiraglia, 2017, and others). Our intention in this paper is not to claim that the LRM provides a complete theory of versioning, but rather that it provides a well-established conceptual framework and terminology with which versioning relationships can be described.
In further work with the community, the data versioning principles, which were published as an output of the RDA Data Versioning Working Group (Klump et al., 2021), were seen as too abstract. The recommendations presented as our results in this paper were developed to give guidance to data versioning practitioners. The recommendations are illustrated with a short discussion of the motivation and a problem statement, and with best practice examples.
The concept of a work in the context of data versioning
In scholarly communication, data have for a long time been regarded as supplementary to the publication of an idea in a scholarly publication, often referred to as ‘the paper’. In academic research, the ‘storefront’ metaphor highlights how a research paper presents the synthesised findings and conclusions derived from data, while the data itself serves as the supporting evidence. Essentially, the paper is the public-facing display of the research, showcasing the interpretations and insights, whereas the data is the underlying raw material that justifies those interpretations. The paper acts as the bridge between the data and the broader understanding it supports. It is the structured narrative that makes the data’s meaning accessible and understandable. The quality of the paper depends on the rigour of the data collection and analysis, as well as the clarity and accuracy of its presentation.
Building on prior work, we see the distinction of a Revision from a curatorial Release process, and the application of the IFLA LRM to link the physical embodiments of data to abstract conceptual entities as part of the scholarly knowledge graph as the key innovations of this paper. The application of a systematic terminology will help scholars and practitioners refer to specific versioning practices and patterns for the development of best practices and policies.
In the IFLA Library Reference Model (CEG et al., 2024), a Work is a conceptual object that bundles the constellation of concepts and ideas that form the shared content of what the reference model defines to be the Expressions of the same Work. We value the intellectual effort described in the paper most, and the intellectual effort that went into producing and structuring the data is pushed into the background. In the past, data supporting a hypothesis were included in the paper. As datasets became larger and more diverse, data disappeared from the papers, leading to a structural divide between data and their interpretation in the literature (Klöcking et al., 2025; Klump et al., 2006). In the model presented here, we interpret the publication(s) and the data as Expressions of a Work.
In the example discussed in this paper, we interpret the ASTER Mineral Map of Australia as a Work derived from the original concept of the ASTER Mission through some of its data products. The ASTER Mineral Map of Australia team developed several data products (Expressions) that are available in different formats (Manifestations). The individual files (Items) are provided for download by different organisations. The resulting pattern is illustrated in Figure 5. The model proposed in this paper allows us to uniquely identify each object and actor in the process, from developing an idea to publishing the physical embodiments of the research process.
Figure 5
Derivation of the Satellite ASTER Geoscience Map of Australia (Work) (see also Figure 1) from the Spaceborne Thermal Emission and Reflection Radiometer (ASTER) (Work) by further processing of ASTER Level 1B and Level 2 data. Both Works are expressed through journal publications and data products.
The RDA group discussed whether the framework could be simplified following the structure described in the BIBFRAME model (Library of Congress, 2016). This model defines a Work and an Item, like the IFLA Library Reference Model, but defines an instance as one or more individual, material embodiments of a Work. An instance reflects information such as its publisher, place and date of publication, and format. This simplification does not allow us to describe a paper as the ‘storefront’ and data as the ‘supporting evidence’ in the same semantic richness as the IFLA Library Reference Model and therefore was not adopted.
In the research space, a concept that may be considered adjacent to a work is a research project, or, more generally, a research activity. Organisations supporting research are looking for ways to make research activities more visible beyond the published paper. The emerging Research Activity Identifier (RAiD) (ISO, 2022) is an identifier for research projects. Its metadata record holds key metadata relating to the identified project. It indicates relationships to other entities associated with the research activity and their persistent identifiers and metadata, and might serve as a proxy to the concept of a Work. It could offer a technical solution to close the gap between the paper as the ‘storefront’ and the data as the ‘supporting evidence’.
Outlook and future work
Over the lifetime of the RDA Data Versioning IG, the world of research data has continued to evolve, and new structures with distinct requirements have emerged. Data citation has become an established practice, data volumes have grown exponentially, and the rise of AI has emphasised the already growing need for machine access to data.
Data citation has underscored the need for a systematic terminology for elements of the data life cycle and their relationships. The introduction of systematic terms like Expression (e.g., the data product developed by a team of researchers) and Item (e.g., the data file that can be downloaded from a research data repository) has highlighted the different requirements for citation, attribution and credit of different stakeholder groups. In our example, researchers are seeking credit for the development of the data product, while the research data repository is seeking credit for hosting the data and enabling the download. The download statistics become fragmented when homologous items can be downloaded from more than one repository.
The increasing data volumes ask for better machine actionability, as expressed in the FAIR Guidance Principles. FAIR data are also an important contribution towards AI-readiness (ESIP Data Readiness Cluster, 2023). This has led to the development of package formats that allow the bundling of many digital objects. Examples are RO-Crates (Soiland-Reyes et al., 2022) for the purpose of data management and processing, and Complex Citation Objects (Agarwal et al., 2025) to allow the inclusion of large numbers of research data and other artefacts into reference lists for the purpose of citation and attribution. Both formats can contribute to the construction of knowledge graphs on a particular field of research.
Systematic data versioning practices contribute not only to the implementation of the FAIR Data Guiding Principles but, through their support for recording data provenance, also support the development and operation of explainable AI (Kale et al., 2022). Furthermore, data provenance is also essential to the CARE Principles of Indigenous Data Governance (Carroll et al., 2020). All three are essential components that contribute to enabling Open Science.
Even though the work of the RDA Data Versioning IG has continued for over a decade, new topics continue to arise. Future work on data versioning, and versioning more generally, might investigate whether the framework presented in this paper can be applied to artefacts other than data, other organising frameworks such as blockchain (Bellini, 2019), or whether patterns exist that do not fit into the LRM framework.
Data Accessibility Statement
The collection of use cases that formed the base of the analysis of versioning practices is available as: Klump, J., Wyborn, L., Wu, M. and Elger, K. (2025). Data Versioning Interest Group Compilation of Data Versioning Use Cases (1.3). Melbourne, VIC, Australia: Research Data Alliance. Retrieved from https://doi.org/10.15497/RDA00041.
A documentation of the workshop in Berlin in 2024 is available as: Klump, J., Pampel, H., Rothfritz, L. and Strecker, D. (2024). Dokumentation des Workshops ‘Forschungsdaten-Publikationen zwischen Dynamik und Persistenz’ #PIDsBUA (Workshop Report). Berlin, Germany: Berlin University Alliance. Retrieved from https://doi.org/10.5281/zenodo.12917465.
Acknowledgements
Jens Klump, Mingfang Wu, and Lesley Wyborn would like to acknowledge the ongoing support of the Australian Research Data Commons, in particular, the facilitation support during the Working Group phase of the RDA Data Versioning group.
Jens Klump would like to thank the CSIRO Research Office and AuScope for their support, which allowed participation in the RDA plenaries, and the Berlin University Alliance for their support through the Fellowship Program Advancing Research Quality and Value. This work was also supported by AuScope Virtual Research Environments under the Collaborate initiative, with funding provided by AuScope and the Australian Government via the National Collaborative Research Infrastructure Strategy (NCRIS): auscope.org.au.
Lesley Wyborn would like to thank the Data Management Team of the National Computational Infrastructure, Australia, for advice on how to manage data versioning at scale.
The authors would like to express their sincere gratitude to all participants of the workshop ‘Research Data Publications between Dynamism and Persistence’ (#PIDsBUA), which took place on 28 June 2024 in Berlin. The constructive discussions and valuable contributions provided important impulses for the further development of the topics addressed. This workshop was generously supported by the Berlin University Alliance (BUA) within the framework of the Fellowship Program Advancing Research Quality and Value. We gratefully acknowledge this support.
Heinz Pampel was partly funded by the Einstein Center Digital Future (ECDF).
This work was developed as part of the Research Data Alliance (RDA) Interest Group entitled ‘Data Versioning’, and we acknowledge the support provided by the RDA community and structures. We would like to thank members of the group for their support and their thoughtful discussions during working sessions at RDA Plenaries.
The authors would like to thank the reviewers solicited by the Data Science Journal that helped us improve the manuscript.
Author Contributions
All authors contributed to the analysis and writing of this paper. The initial use case collection and analysis was led by Jens Klump, Lesley Wyborn and Mingfang Wu.