There is currently only one letter that can be used for ETDs with limited options for customization.

To best serve our student community, it is important to have an ETD deposit notification letter that is generated when an ETD is ingested in Esploro. This communication allows us to not only confirm their deposit has been review and ingested, but to provide the student with the open access permanent URL (handle) that they can use when citing their work. In many cases, this information is required by employers or for other verification purposes.

This information is vital to our student depositors, and we would like to see more functionality and inclusion for student works in the Esploro letters.

We would like some improvements to be made to the OAI_dc output file, for example

dc:identifier:

There are a number of identifiers for each record (ISSN, ISBN, DOI, Asset ID, URLs, Esploro URLS (long-type permalink, Viewer, document within viewer) but there is no qualifier to differentiate the identifier/link type

dc:date:

Both published date and conference/event date range appear as dc:date - they can be different years - how do we differentiate?

dc:publisher:

Shows both publisher and country - how to differentiate between the two?

dc:rights:

Includes licence information, copyright statement and internal rights (e.g. open, closed, metadata restricted) - how to differentiate?

Add internal affiliation to non-affiliated researcher in the creator section of the asset form

Currently it is not possible to add an internal affiliation in the creator section of an asset against a non-affiliated researcher. This poses a problem for adjuncts, visiting academics, as well as staff that may have left the institution or had a researcher record automatically created on import. As the publication cycle often has a lag of a couple of years, assets may come into Esploro after the researcher has left, or the researcher may never have had an internal researcher record to begin with. It is not currently possible to add an internal affiliation against these authors, meaning we have to create a new User record for them, then an Esploro Researcher Record, then merge the unaffiliated researcher to their new affiliated researcher.

It would be good to be able to add an internal affiliation against these non-affiliated researchers so that the metadata in the Esploro asset page matches the article text and to streamline processes.

The CSS/JS load Idea was closed - https://ideas.exlibrisgroup.com/forums/929326-esploro/suggestions/42304072-esploro-portal-and-home-page?tracking_code=c69bab7468ff8e896a94196d9e242aba
and proposed to open the new Idea
If there is specific functionality or customization option that we think we should add to Esploro, We have to open a dedicated idea for this idea and Ex Libris will be happy to evaluate it.

Please Vote:
We would like to receive the options in Esploro’s configuration pages to edit:

Home page and Portal:
Width of the page
Tabs
Headers
Font colors
Background colors

On the Portal
Logo size
Header height, background-color
Font colors - part of them is not readable - following Accessibility rules.
(Like email addresses > yellow on grey).
Persons' information location.
Width of the main page.
Accessibility menu - would like to be added or we can provide our accessibility menu, you can implement it into the Esploro home page and Portal page (it is not something we are going to change every day).

We are an Australian-based Esploro customer and we have asset records containing culturally sensitive information/materials. Repository staff are currently adding the notice below to these records (which at this point, are primarily theses):

"Aboriginal and/or Torres Strait Islander peoples should be aware that this thesis and associated project files, may contain the images/voices/names of people who have since passed away. "

Repository staff customise this message to include what is relevant for the asset record concerned, e.g. images and/or voices and/or names and to the type of publication.

These advice statements would be more effectively highlighted as a pop-up that would appear when the Esploro record was accessed. We are currently adding them to the Comments field which is usually hidden on first accessing the record.

Thank you
Keely

Research outputs typically go through several different iterations or versions over the course of their lifecycle. NISO, for example, defines up to seven versions of scholarly journal articles http://www.niso.org/publications/niso-rp-8-2008-jav. In order to avoid confusion, support proper citation, and ensure compliance with publisher open access policies, it is critically important that institutional repositories clearly distinguish between different versions of the same work by prominently displaying this information in both the asset record and PDF cover sheet.

Esploro currently offers two options for communicating version: asset type and file type.

Asset type refers to the type of resource being deposited. When categorizing asset types, Esploro distinguishes between “Publications” and “Posted Content”. “Publications” refer to published works such as journal articles, book chapters, conference proceedings, etc. “Posted Content” refers to works that have not been formally published, which Esploro defines as working papers, preprints, and accepted manuscripts. Each asset can be assigned only one asset type. Asset type values are predefined and not customizable.

File type is used to describe the individual files or external links associated with an asset. The list of default values consists of a mix of terms used to indicate format (text, image, audio, video) and version (preprint, submitted, accepted, published, correction). Unlike asset type, however, file type values are customizable. Although choosing a file type is not required for deposit, this is the field Esploro uses to display version information on PDF cover sheets.

We believe the overlapping use of asset type and file type to capture version information is a potential source of confusion and data inconsistency. For example, if a researcher wishes to deposit an article that has been accepted for publication, should they deposit it as an "Accepted Manuscript" or as a "Journal Article" with the file type "Accepted"? Either is possible but having two ways to deposit the same work will likely confuse researchers. This inconsistency also creates problems for discovery and analytics. For example, if a user wanted to obtain a list of all preprints, they would only retrieve those defined at the asset level as opposed to the file level. Meanwhile, version information only appears on cover sheets if it specified at the file level. Avoiding this confusion seems to require a single, consistent model for representing versions in Esploro.

Ultimately, we don’t think it makes sense to manage version as an asset type or a file type; it is neither. Instead, we recommend version be managed as a completely separate field. When a researcher deposits an asset, they should be prompted to select the version of the asset being deposited. This information should be prominently displayed in both the asset record and cover sheet and be queryable in Analytics.

We further recommend that Esploro allow researchers to submit new versions of previously deposited works. Different versions of the same work should either be FRBRized or displayed in a way that directs users from superseded version(s) to the current preferred version.

i. When depositing an asset, prompt researchers to indicate if the asset is a new version of a previously deposited work.

ii. If the asset is a new version, allow the researcher to select the previous version from a list of their previously deposited assets.

iii. After the previous version has been selected, a) auto-populate the deposit form with the metadata from the previous version, and b) automatically link the old and new versions via the appropriate relationships (is new version of / is previous version of).

iv. Once the new version has been approved, either a) FRBRize all versions with the latest as the preferred record, or b) exclude the previous version from search indexing (but continue to allow it to be accessible via DOI) and add a prominent note notifying users that this version has been superseded and directing them to the latest version.

To summarize, we believe the following enhancements would significantly improve version control in Esploro.

1) Create a single, dedicated, and prominently displayed field for version

2) Allow researchers to easily deposit new versions of previously deposited works

3) FRBRize different versions of the same work OR provide some mechanism for identifying and directing user to the latest or preferred version of a work