1 of 19

Charting a collective course towards Entities:

Reflections from exploring and implementing Configurable Entities as a community�

2026 DSpace North American User Group Meeting��Julia Gilmore, Digital Projects Librarian, Scholars Portal

2 of 19

🌱 Scholaris is a new(ish) opt-in Canadian shared institutional repository service.

🛫 We started a pilot project in 2023 with 2 institutions to migrate their IRs to Scholaris infrastructure (DSpace 7.5).

🙌 From 2024-2026, we ran an Early Adopter Program. Our partners at the Canadian Association of Research Libraries (CARL) convened 3 Scholaris Network of Expert Groups.

🪴 Today, we have 30 participating institutions from across the country and are in the progress of upgrading to D9.

Setting the scene

In terms of our service model, we provide technical as well as community infrastructure.�

In addition to the technical pieces of hosting and configuring DSpace instances, the community component is really important and our close relationships with the Scholaris community and the broader repository community, through the Early Adopter Program and expert groups, have played a significant role in shaping what we build and deliver on the technical side. �
This community-informed model is essential in making sure the service is scalable, sustainable, and able to dynamically respond to and reflect the needs and interests of participating institutions.

Technical:

The Scholaris service model consists of hosting and managing parallel DSpace instances using a Software as a Service model.�
Each participating institution has their own DSpace instance (consisting of a development and a production instance), hosted on dedicated virtual machines on Scholars Portal servers. We keep the code in GitLab and we use an open-source version of Chef to automate the management of the code and roll out updates and upgrades. Institutions have front-end access access to their instances, with back-end access (server and command line access) restricted to the Scholaris technical team. Local requests are applied to a centralized codebase and deployed to the instances using a configuration management system. �
Of course, Scholaris is more than just technology — building strong community infrastructure is just as important and continues to be a significant focus so we can build a collaborative and dynamic service that is attuned to the needs of our repository community and aligned with repository best practices and developments on an international scale.

3 of 19

Technical Infrastructure

Community Infrastructure

Centrally hosted and managed by Scholaris (Scholars Portal)
Parallel instances of DSpace

Dev and prod sites for each institution on dedicated VMs

Data storage at UofT

Early Adopter Program
Scholaris Network of Expert Groups
Scholaris subscriber community
Participation in Canadian, international, DSpace communities and groups

Scholaris service model

In terms of our service model, we provide technical as well as community infrastructure.�

In addition to the technical pieces of hosting and configuring DSpace instances, the community component is really important and our close relationships with the Scholaris community and the broader repository community, through the Early Adopter Program and expert groups, have played a significant role in shaping what we build and deliver on the technical side. �
This community-informed model is essential in making sure the service is scalable, sustainable, and able to dynamically respond to and reflect the needs and interests of participating institutions.

Technical:

The Scholaris service model consists of hosting and managing parallel DSpace instances using a Software as a Service model.�
Each participating institution has their own DSpace instance (consisting of a development and a production instance), hosted on dedicated virtual machines on Scholars Portal servers. We keep the code in GitLab and we use an open-source version of Chef to automate the management of the code and roll out updates and upgrades. Institutions have front-end access access to their instances, with back-end access (server and command line access) restricted to the Scholaris technical team. Local requests are applied to a centralized codebase and deployed to the instances using a configuration management system. �
Of course, Scholaris is more than just technology — building strong community infrastructure is just as important and continues to be a significant focus so we can build a collaborative and dynamic service that is attuned to the needs of our repository community and aligned with repository best practices and developments on an international scale.

4 of 19

From the beginning, there was interest from our community in Configurable Entities.

5 of 19

…and a LOT of questions about them.

6 of 19

We took this an opportunity to learn about them together ⛵

7 of 19

APPROACH 1

Dedicated investigation by the Scholaris Metadata & Discovery Expert Group (S-MDEG)

In terms of our service model, we provide technical as well as community infrastructure.�

In addition to the technical pieces of hosting and configuring DSpace instances, the community component is really important and our close relationships with the Scholaris community and the broader repository community, through the Early Adopter Program and expert groups, have played a significant role in shaping what we build and deliver on the technical side. �
This community-informed model is essential in making sure the service is scalable, sustainable, and able to dynamically respond to and reflect the needs and interests of participating institutions.

Technical:

The Scholaris service model consists of hosting and managing parallel DSpace instances using a Software as a Service model.�
Each participating institution has their own DSpace instance (consisting of a development and a production instance), hosted on dedicated virtual machines on Scholars Portal servers. We keep the code in GitLab and we use an open-source version of Chef to automate the management of the code and roll out updates and upgrades. Institutions have front-end access access to their instances, with back-end access (server and command line access) restricted to the Scholaris technical team. Local requests are applied to a centralized codebase and deployed to the instances using a configuration management system. �
Of course, Scholaris is more than just technology — building strong community infrastructure is just as important and continues to be a significant focus so we can build a collaborative and dynamic service that is attuned to the needs of our repository community and aligned with repository best practices and developments on an international scale.

8 of 19

Membership: 8-10 members of Canadian repository community with specialized expertise�
Purpose: provide guidance and recommendations on metadata and discovery to inform the development of Scholaris �
Scope: provide guidance and recommendations on metadata, enhanced discoverability of repository content, and innovations in metadata and discovery practices�
Four subgroups, including one for Configurable Entities�

Scholaris Metadata & Discovery Expert Group (S-MDEG): Overview

9 of 19

Information gathering

Conversations with Entities adopters

Iowa State University, Université Laval, University New South Wales �

Testing

Testing sessions with Scholaris team on shared demo site�

Drafting and feedback period

Draft guidance shared with community for feedback period�

Publication

Published Entities Guidance and Advice 1.0 in April 2025
Updated Entities Guidance and Advice 2.0 coming in Fall 2026
Available in English and French�

S-MDEG: Entities Subgroup

Footage from our Entities testing session

10 of 19

APPROACH 2

Configurable Entities Working Hours

In terms of our service model, we provide technical as well as community infrastructure.�

In addition to the technical pieces of hosting and configuring DSpace instances, the community component is really important and our close relationships with the Scholaris community and the broader repository community, through the Early Adopter Program and expert groups, have played a significant role in shaping what we build and deliver on the technical side. �
This community-informed model is essential in making sure the service is scalable, sustainable, and able to dynamically respond to and reflect the needs and interests of participating institutions.

Technical:

The Scholaris service model consists of hosting and managing parallel DSpace instances using a Software as a Service model.�
Each participating institution has their own DSpace instance (consisting of a development and a production instance), hosted on dedicated virtual machines on Scholars Portal servers. We keep the code in GitLab and we use an open-source version of Chef to automate the management of the code and roll out updates and upgrades. Institutions have front-end access access to their instances, with back-end access (server and command line access) restricted to the Scholaris technical team. Local requests are applied to a centralized codebase and deployed to the instances using a configuration management system. �
Of course, Scholaris is more than just technology — building strong community infrastructure is just as important and continues to be a significant focus so we can build a collaborative and dynamic service that is attuned to the needs of our repository community and aligned with repository best practices and developments on an international scale.

11 of 19

Monthly working hours hosted by Scholaris team on Zoom�
Informal drop-in sessions to bring Entities questions, provide updates, share workflows and approaches�
Open to Scholaris repository teams, S-MDEG members, and invited guests �
Guest presentations

Pierre Lasou, Université Laval
Gabriela Mircea, University of Calgary
Caitlin Bakker, University of Regina
John Aspler and Nikolas Lamarre, ORCID CA

Configurable Entities Working Hours

12 of 19

TAKEAWAYS 🛍

What we’ve learned from our collective adventures with Entities

In terms of our service model, we provide technical as well as community infrastructure.�

In addition to the technical pieces of hosting and configuring DSpace instances, the community component is really important and our close relationships with the Scholaris community and the broader repository community, through the Early Adopter Program and expert groups, have played a significant role in shaping what we build and deliver on the technical side. �
This community-informed model is essential in making sure the service is scalable, sustainable, and able to dynamically respond to and reflect the needs and interests of participating institutions.

Technical:

The Scholaris service model consists of hosting and managing parallel DSpace instances using a Software as a Service model.�
Each participating institution has their own DSpace instance (consisting of a development and a production instance), hosted on dedicated virtual machines on Scholars Portal servers. We keep the code in GitLab and we use an open-source version of Chef to automate the management of the code and roll out updates and upgrades. Institutions have front-end access access to their instances, with back-end access (server and command line access) restricted to the Scholaris technical team. Local requests are applied to a centralized codebase and deployed to the instances using a configuration management system. �
Of course, Scholaris is more than just technology — building strong community infrastructure is just as important and continues to be a significant focus so we can build a collaborative and dynamic service that is attuned to the needs of our repository community and aligned with repository best practices and developments on an international scale.

13 of 19

Interest and implementation varies widely depending on local contexts �
Institutional reasons for adopting Entities:

Adding RIMS functionality to the repository (or using the IR as a RIMS system)
Better discovery and disambiguation
More support for PIDs
Using IR for journals management
Meeting open access mandates, easier reporting
ORCID integration was the carrot 🥕 but is increasingly the cherry too 🍒

Takeaways

14 of 19

Institutional considerations:�

Deciding where to start

Determining scope and structure
i.e., which Entities and who gets them?

Getting buy-in to allocate resources to this work
Adapting existing workflows
‘Entifying’ existing content

Common starting points: Persons and Publications, followed closely by OrgUnits

Takeaways: Part 2

15 of 19

Resources/support that would make it easier to adopt Entities�

Practical examples, use cases, and workflows
Hierarchical metadata models, more default relationships
More guidance for projects and funder relationships
Tools for migrating to Entities
Tools for batch creation of Entities and relationships
Admin interface for Entities management
Information on impact of DSpace-CRIS merger for Entities

Takeaways: Part 3

16 of 19

CURRENT SNAPSHOT 📸

Where we are with Entities today

In terms of our service model, we provide technical as well as community infrastructure.�

In addition to the technical pieces of hosting and configuring DSpace instances, the community component is really important and our close relationships with the Scholaris community and the broader repository community, through the Early Adopter Program and expert groups, have played a significant role in shaping what we build and deliver on the technical side. �
This community-informed model is essential in making sure the service is scalable, sustainable, and able to dynamically respond to and reflect the needs and interests of participating institutions.

Technical:

The Scholaris service model consists of hosting and managing parallel DSpace instances using a Software as a Service model.�
Each participating institution has their own DSpace instance (consisting of a development and a production instance), hosted on dedicated virtual machines on Scholars Portal servers. We keep the code in GitLab and we use an open-source version of Chef to automate the management of the code and roll out updates and upgrades. Institutions have front-end access access to their instances, with back-end access (server and command line access) restricted to the Scholaris technical team. Local requests are applied to a centralized codebase and deployed to the instances using a configuration management system. �
Of course, Scholaris is more than just technology — building strong community infrastructure is just as important and continues to be a significant focus so we can build a collaborative and dynamic service that is attuned to the needs of our repository community and aligned with repository best practices and developments on an international scale.

17 of 19

Uptake: Nearly one-third of Scholaris institutions are testing Entities on their dev sites

Two are using Entities in production with more approaching rollout
More adoption on new IRs and larger IRs with staffing complement�

Community-developed API-based workflows�
Service support for Entities

Configuration and technical support
Training and resources
Customizations

Submission forms
Simple item pages
Relationships

ORCID integration setup and testing

Scholaris community + Entities: Raising our sails ⛵

Example: CREATE Project record, NOSM University

18 of 19

Breaking the waves: Entity use cases from the Scholaris community

	Institution 1	Institution 2	Institution 3	Institution 4
Scenario	New repository	New repository	Existing repository 45,000+ items	Existing repository 70,000+ items
Implementation scope	Persons (uni-affiliated), Publications, OrgUnits (institutions/organizations), Projects	Persons (faculty), Publications, OrgUnits (departments) Journal Entities	Persons (faculty), Publications, OrgUnits (departments)	Persons (grad students, advisors), Publications (ETDs)
Deposit workflow	Mediated deposit	Mediated deposit	Mediated deposit Self-deposit	Mediated deposit
Entities workflow	Batch upload via API, external spreadsheets, Python script	Submission forms, bulk import via UI	Submission forms, bulk import via UI, evaluating API routes	Batch creation via API
Common themes and considerations	Scoping creation of Person records OrgUnits for Departments Name disambiguation, author reconciliation		Strong interest in API workflows Phased ORCID implementation

🏄🏄🏄

NOSM workflow

Create spreadsheet for publications and authors, including publication UUIDs, author names, institutional IDs, and Person UUIDs.
Use Python script and DSpace API to match Publication authors to Person Entities.
Use person.namevariant to assist with author matching and account for variations in author names.
Publications are created through API calls
Author order is preserved

Name disambiguation, author reconciliation

name variants;
initials;
duplicate names;
missing Person records;
historical names;
determining whether two records represent the same person;
maintaining relationships when a Person Entity doesn't exist.

Applications of OrgUnits for representing institutional contexts

NOSM currently records Division/Discipline information on Person records.
UdeM is actively creating Department OrgUnits mapped to their repository structure and testing Person-to-Department relationships.
URegina temporarily preserved departmental affiliation in dc.contributor, with the intention of eventually creating OrgUnits for these records

ORCID is increasingly important, but isn't a complete solution

UdeM: considering ORCID as a source for Person data.
Bishop’s: ORCID integration in place, no ORCID login
URegina: ORCID authentication creates Person Entities upon login, encouraging researchers to connect ORCID.
McGill: Researcher Profiles are enabled, testing ORCID integration with sandbox credentials on dev
NOSM: relies more heavily on institutional identifiers and name variants.

API workflows

batch creation of Entity records and relationships
checking for presence of existing Person records
ordering of authors on Publication records
potential to develop an admin/tracking tool, like an Entities dashboard particularly for the institution using the repository as their RIMS
importing open access articles using external APIs (ORCID, Crossref, OpenAlex which tends to be listed as the primary source)

19 of 19

Thank you! �

Questions about Scholaris? �info@scholaris.ca

Scholaris Service Team (Scholars Portal)�

Julia Gilmore (Scholaris Service Lead)
Mohana Sarmiento (Scholaris Technical Lead)
Rachel Wang
Thierry Letendre

�Scholaris Metadata & Discovery Expert Group�

Caitlin Bakker (University of Regina)
Teresa Bascik (Université de Montréal)
Cindy Beauchesne-Jolin (Université de Sherbrooke)
Carl Brouillard (Université de Sherbrooke)
Pascal Calarco (University of Windsor)
Robin Desmeules (McGill University) - former co-chair
Sharon Farnel (University of Alberta)
Gabriela Mircea (University of Calgary) - ex-officio, Scholaris VPO
Mike Nason (University of New Brunswick) - former co-chair
Jordan Pedersen (University of Guelph) - former co-chair
Laura Smart (Western University)
Carolyn Sullivan (University of Ottawa)