Versioning, Persistent Identifiers and Change Logging Policy

1. General framework

This policy sets out the rules for versioning, assigning persistent identifiers and recording changes for repositories, collections and data objects.

The Digitalia MUNI ARTS infrastructure uses two persistent identifiers: DOI and Handle. A DOI is assigned to entities intended for public citation or external reference. The system identifier for all entities within the infrastructure is Handle. Identified entities include repositories, collections, datasets and data objects. A repository is the basic identified entity. Collections, datasets and data objects are its components, and their management regime is derived from that of the repository. Each identified entity is assigned a persistent identifier. The identifier expresses the identity of the entity in question. The continuity of identity varies across different types of entities and is determined by their versioning rules. Where an entity is assigned both a DOI and a Handle, the DOI must be the primary public identifier; the Handle serves as an internal system identifier and need not be publicly displayed. Changes are expressed through versioning in the format major.minor (e.g. 1.0, 1.1, 2.0). An increase in the minor number indicates a minor change; an increase in the major number indicates a major change.  An increase in the major version number indicates a change in the entity’s identity. The rules for assigning new persistent identifiers when the identity changes are defined for individual entity types. The assignment of a new persistent identifier must follow the rules established for individual entity types. Every change must be recorded as an event, specifying the type of intervention, the date and the person responsible. A record of changes is maintained in accordance with the PREMIS data model, in particular through entities of the object, event and agent types.

2. Repository

A repository is the fundamental identified entity of the Digitalia MUNI ARTS infrastructure. A repository is a specialised data and functional service defined by the type of data it manages, its data profile, and the functional framework for processing and making that data accessible. Each repository must be assigned a persistent DOI identifier as a service. The repository identifier denotes a specific version of the service defined by its institutional, organisational and operational framework, not the current state of its content. Each repository has its own landing page associated with the assigned DOI, which documents the state of the service at the time of publication of that version. The home page must contain a definition of the repository’s mission and scope, a specification of the types of data accepted and the conditions for their acceptance, the conditions for access to and use of the data, the persistent identifiers used, a description of the repository’s functions to the extent defining its identity as a service, and the identification of the operator.

A minor change to the repository is considered to be a change that does not alter the scope, responsibility or operating rules of the repository. This includes, in particular, the addition or removal of data objects, corrections to metadata, technical system updates, changes to the API and export mechanisms, or modifications and optimisations to the interface. A major change to a repository is considered to be a change that alters its identity as a service. This includes, in particular, changes to the scope, types of data accepted, curatorial model, archiving or licensing policy, access regime, or operator. For a repository, a major change is reflected by an increase in the repository’s major version number. A new persistent identifier is assigned only if there is a break in the continuity of the service’s identity (e.g. a change of operator, the splitting or merging of a repository, or the creation of a new, separate service replacing the original repository). Each version of the repository must be recorded as a separate object in the change tracking system.

3. Data collections

Collections within a repository may be defined as independently identified entities with their own configuration of descriptive fields, metadata requirements and rules for their application. Each such collection is assigned a persistent DOI identifier. The collection identifier denotes a specific version of the collection, not the current state of its content.

A minor change to a collection is considered to be a modification that does not alter its conceptual definition or configuration, in particular the addition or removal of data objects within the collection, corrections to metadata, technical modifications to the interface, or changes to the display method. A major change to a collection is considered to be a change to its conceptual definition or configuration, in particular a change to the structure of descriptive fields, metadata requirements, the rules for their application, or the rules governing the collection’s operation. For a collection, a major change is reflected by an increase in the collection’s major version number. A new persistent identifier is assigned to a collection only if there is a break in the continuity of the collection’s identity, in particular when a collection is split or merged, or when a new, separate collection is created to replace the original one. Each version of a collection is recorded as a separate object in the change tracking system.

4. Data object / Dataset

A data object (e.g. text, scan, 3D object or other digital representation) must be identified by a persistent DOI identifier and, at the same time, a Handle identifier. The DOI is the primary public citation identifier; the Handle serves as an internal system identifier.  Unlike repositories and collections, which represent continuous services, data objects are published as separate versions, each of which constitutes a separate identified entity. A dataset is a publication object consisting of one or more data objects. Each published version of a dataset must be a separate identified entity with its own DOI. A change to a data object must be considered a change to the dataset only if it leads to a change in the set of data objects constituting the dataset (their addition, removal or replacement), or to a change in their structural arrangement defining the dataset as a publication unit, or to a change in their content identity. In such a case, the change to the dataset must be assessed according to the versioning rules and may lead to the creation of a new version of the dataset with a new DOI. If the change to a data object does not affect the dataset as a whole, neither the version of the dataset nor its DOI may be changed. A minor change to a data object must be considered to be a change that does not alter its content or structural identity, in particular corrections to metadata, enrichment of metadata (e.g. the addition of subject data, keywords, links to authorities, identifiers or licence information), corrections of formal or typographical errors, the addition of identifiers or licence details, improvements to the technical quality of the representation whilst maintaining the content identity, or a change to the access regime without altering the content. A minor change must be reflected by an increase in the minor version number of the data object. In the case of a minor change to a data object, the DOI must not be changed. A major change to a data object is considered to be a change that alters its content or structural identity, in particular the replacement of the representation with versions having different content, a substantial modification of the text, a change to the document structure, or the removal and replacement of the object. A major change must be reflected by an increase in the major version number of the data object.  In the event of a major change to a data object, a new published version of the object must be created, which must be assigned a new DOI; the original version must be retained and must remain identifiable by its original DOI. Individual versions of the same object must be linked within the change tracking system. Each version of a data object must be recorded as a separate object in the change tracking system, with links to the relevant PREMIS events and agents.