TCDL 2026

Piloting a New PID: Exploring Implementation of Research Activity IDs (RAiDs) at UT Austin
By: Bryan Gee & Michael Shensky

A wide range of persistent identifiers (PIDs) exist for scholarly research, from DOIs for diverse research outputs, to ORCIDs for individuals, to RORs for institutions. Each of these different PID types helps to ensure that research outputs are Findable, Accessible, Interoperable, and Reusable (FAIR). However, there has long been an absence of an established and internationally accepted standard PID for research projects that can interoperate with other PIDs to help facilitate linking and centralization of information about related research project elements. To address this gap, the Australian Research Data Commons (ARDC) has recently developed RAiD (Research Activity Identifier), a PID designed to identify, track, and share information about research projects and their associated outputs. RAiD is already established in Australia and is now being piloted in the U.S., with the University of Texas at Austin participating as a pilot organization. This presentation will provide an overview of RAiD and the current pilot implementation being explored by UT Austin with respect to publication of research data in the Texas Data Repository (TDR). We will also discuss potential challenges to growing the use of RAiDs, and describe prospects for future expansion of the implementation of this PID.

Integrating Handle.net into Digital Asset Management for Persistent Identifiers
By: J.J. Bennett

In mature digital repository ecosystems, persistent identifiers (PIDs) are the connective tissue between storage, metadata, and public access. This talk describes our custom deployment of a Handle.net server paired with a Django REST Framework wrapper API, and how we’re integrating that PID service into our DAMS platform to make identifier assignment reliable, automatable, and operationally scalable.

We run a containerized Handle.Net v9.3.1 server in Kubernetes, alongside a separate Django API pod that provides a stable programmatic interface for the rest of our ecosystem. The Django layer encapsulates Handle administration and handle CRUD operations (create, update, delete, resolve) using a purpose-built Java entrypoint (HandleWrapper) and securely managed server configuration and keys. This approach gives us a clean boundary: Handle remains the authoritative PID store, while Django provides authentication, request validation, auditability, and a developer-friendly API surface.

A central theme is “batch semantics without batch servers.” Handle itself is optimized for single-handle operations; large-scale workflows are orchestrated in Django using Celery: ingest pipelines enqueue jobs, tasks fan out into individual handle operations, results are tracked per handle, and retries/throttling protect the service from overload. We’ll show how this design integrates with DAMS components (Fedora6 object storage, IIIF manifest generation, Elasticsearch indexing, and downstream portals), enabling consistent PID minting and updates as assets move through ingest, publication, and long-term preservation.

The outcome is a PID service that behaves like first-class infrastructure: observable, testable, and aligned with modern repository automation patterns—while remaining standards-based and interoperable through Handle.

Some familiarity with the role of persistent identifiers is assumed; otherwise no preliminary knowledge is necessary. UTL plans to open-source our implementation; some technical knowledge is necessary to adopt our example but that is not within the scope of this presentation.