 Today, I'll be talking through a service that we implemented at UNSW Library to support the citation of great literature held in our repositories. Today, this is based on a presentation that I gave late last year for the call Research Repositories Community Days, and that presentation, the slides and video can be found at the link on your screen. I'm going to briefly cover digital object identifiers and say a few words about what they are. I'm going to then take you through the environmental scan that we did to design our service and then some of the details of the UNSW DOI service, including the conditions around DOI assignment, the workflows that we're following, and integration with ORCID identifiers, and a few words in conclusion. A DOI, a digital object identifier, is a type of PID that is optimised for scholarly resources. Importantly, it's the identifier that is digital, and the object can be digital or physical. DOIs are assigned to an object by the publisher or a long-term custodian, and the persistence of that identifier and the resource is managed by the organisation and its policies. There are a few facets to a DOI. We can start with the DOI name itself, which is an alpha-numeric string, and that can be converted to a URL by adding a DOI resolver, like doi.org. When that URL is entered into a browser, it takes you to a landing page with human-readable metadata about the resource, about the object. Basic information about the resource is required to mint a DOI, and that metadata is both human and machine-readable. Why are DOIs important? They've emerged as a relatively simple but powerful piece of technical infrastructure in improving scholarly communication. They make it easier for outputs to be discovered and used by others and to be cited and measured for impact. A useful way to think about DOIs is as a trusted identifier, which is a term introduced a few years ago by a project called Odin, the Orchid and Data Site Interoperability Network. It's the predecessor project to Thor that Natasha mentioned at the beginning. This term captures a set of characteristics that trusted identifiers are unique, so they're unique on a global scale. They resolve as HTTP URIs persistently. They're descriptive, so they come with metadata that describe their most relevant properties. For instance, there's a mandatory set of metadata elements, like Creator's Title Publisher, Publication Year Resource Type, and then you can add recommended or optional elements like alternate identifiers, subjects, dates, rights, information, description, and so on. Lastly, trusted identifiers are governed, so they're issued and managed by an organization that has a sustainable business model and it's managed by that body, which is usually a publisher or custodian. You can read more about trusted identifiers at the link below. When we were looking at designing a service, the impetus for this came from requests from academics. Most commonly they had grey literature, like a series of reports that they wanted to assign DOIs to, and we were also able to implement something based on the ANS Site By Data Service in April last year, 2016, that was extended to account for grey literature, so we were looking at the possibilities of implementing something here at UNSW. In preparation for an options paper, we looked at grey literature and DOI assignment in several repositories, whether institutional, disciplinary, or national. We also looked at options for registration agencies and the resource types that we would cover. A few things that we found that might be useful were a project conducted in the UK called Unlocking Thesis Data. It's a GISC funded project and led by the universities of East London and Southampton as well as ETHOS, the National Thesis Service at the British Library. And they have a number of reports and case studies where they outline options for the workflow to assign DOIs to theses. Another idea that we eventually incorporated into our own service was from the University of Southampton, and they have a role called a Trusted Partner, and that allows certain staff, academics or faculty administrators, to authorise their own DOIs or the DOIs of a research group, and I'll come back to that idea later in the presentation. So in the latter half of last year, we presented an options paper to the library and went ahead with a pilot, which involved a manual workflow for a certain resource type reports to start with, and we had workflows for both library staff and Trusted Partners to mint DOIs. We then moved on to implement a web tool, which I'll show you later, and at the link on your screen you can look at the DOIs minted by that service. I think now we have about 330 DOIs minted for Grey Literature. It was important at the outset to think about the conditions around DOI assignment, and the first one is that the resource is deposited in a UNSW library repository. Our institutional repository called UNSWorx holds a large amount of the Grey Literature created by UNSW staff, and resources in the repository are managed in accordance with the UNSWorx digital preservation policy. So for that repository we have governance, we have preservation procedures in place, and we're then able to sign the DOI, and then potentially if the resources move or the repository moves, then we can make sure those DOIs continue to resolve. The second one is that it's an eligible resource type, and it needs to be within a certain set of Grey Literature that we've defined. There should be no existing DOI for the service, as that defeats the purpose of a unique identifier. There should be no existing DOI request, and it needs to meet the mandatory metadata requirements set by the ANS service, which links to data sites. So in the user interface, as you'll see later, the requester is given these set of conditions, which they need to agree to before they submit. So they need to agree that they're an author or creator of the resource, or have authorization from an author to request a DOI. The resource doesn't already have a DOI. They don't plan to mint a DOI using a different service. The resource is unpublished or published by UNSW. A library repository is the primary publication point for this resource, meaning that when people resolve the DOI, they'll be taken to the repository page, the landing page. The resource is not subject to a permanent embargo, and the resource is not likely to change significantly. That's just flagging that major changes like anything that would be part of a citation shouldn't be changed, and that would require a new DOI. This is the workflows that we're following. So for all users, we allow them to request a DOI. They go into the tool. They select their repository where the resource is, most commonly UNSW works. They search for their record. They select it. The system checks if there's a DOI existing already, or if there's an existing request. It also checks if the mandatory metadata is already held by the system. If not, they need to enter or confirm the metadata and then submit a request. The second part of this is for a DOI service administrator, which is currently library staff. They go back in and review any request that has been submitted. They check that it meets the conditions that we've already outlined. If it does, that's approved. It goes to the AND service, meets the DOI, and comes back and emails the requester with the DOI. The administrator then updates the metadata, and then that information is sent back into the repository and is displayed on the repository page. For the trusted partners, so these are faculty administrators or researchers that we allow to meet DOIs directly, and that needs to be approved by a relevant authority like the head of school or associate dean, and we give those people training and access to the tools that they need. So they follow a very similar process, except that instead of requesting, they're able to mint the DOI directly. So they select their record, they mint, do the administration, and the cycle is complete. Back to the UNS works page, the institutional repository. If you then resolve the DOI, it takes you to that landing page, and the DOI itself is displayed in the record details as part of the metadata about the publication. We are also aiming where possible to include ORCID IDs, so identifiers for researchers and contributors to research outputs to be included in the DOI metadata. The way we do that at UNSW is through our research output system. Users can link their ORCID profile within that system. That ORCID ID is then pushed to the repository, if they deposit full text. Then they can go back into the DOI service, select that record, submit a request, and that DOI gets put back into the research output system. There is then an update. So both the DOI and the ORCID go into the repository, and both of those, the ORCID ID and DOI, can be exposed via external harvesters like Trove and aggregators, as well as through the ORCID profile. Because of the connection between ORCID and data site, that can be easily claimed through data site and added to the user's ORCID profile. So I have a short video here, which I'll take you through. This is showing an early release. So this is the version that was available at the end of last year. There have been some minor modifications since then, but it gives you a sense of what the service looks like and how those workflows actually look in practice. So there's a login screen that uses the usual credentials. So we'll start with the requested DOI workflow. Here the repository can be selected, and there's a search box to pull in the information from the repository. So the user selects the record, and they're given a preview of the metadata. So what we show here is the mandatory metadata for assigning a DOI. And if any of that is missing, they're given the opportunity to add it. They see those conditions for requesting, and they submit the request. There's a confirmation message. And they also have a list of their requests, and they can see the status, whether that's pending or whether the DOI has been minted or declined. The next step is for the DOI service administrator to log into the system. They have access to a tab called review, where they can see the pending requests. They can then review each request and the metadata. Based on that information, they can either decline or mint. If they choose to decline, there's an option to send a personalized message and to follow up with the requester. If they mint, then that request goes to the AND service and comes back with the DOI. And then this is emailed back to the requester. So they're given the DOI immediately. The administrator then updates the metadata in the system. You can see that the DOI is active immediately. And that's the end of that process. And the last part to show you is the mint function for the trusted partners. And this just means that for people that have high volumes of publications, great literature that they need to assign DOIs or an ongoing series, that they're given the option of actually doing that directly and having responsibility for the whole process. The procedure is much the same. They can search for the record. They select the record, review the metadata, and then they complete the minting process immediately. Okay, that's a repetition of before, so I'll just skip through the rest of this. Okay, so in conclusion, the UNSW DOI service was designed to meet existing and future use cases. So it's flexible and scalable with future cases in mind. A priority for us was ease of use. So we're reusing metadata where possible. So anything that we hold in the repository that we need for the DOI metadata, we reuse that metadata, which is reviewed. It integrates with existing workflows, for instance, with the research output system, with the repository itself. And it connects with other PIDs and platforms like Orchids. There are conditions set around it, so we ensure that the identifier is governed correctly, that the resources remain persistent, and that the link can continue to be resolved and be a citable enduring part of the scholarly record. So that's handled by preservation policies, by the reviewing process, and the ability to track our DOI requests. Okay, thank you very much. There are a couple of links at the end of the slide there, to both the slides and video. If you're interested in the software itself, we've made the code available, and both of those, of course, have DOIs to access.