When each line of code is written it is surrounded by a sea of context: who in the community this is for, what problem we’re trying to solve, what technical assumptions we’re making, what we already tried but didn’t work, how much coffee we’ve had today. All of these have an effect on the software we write.
By the time the next person looks at that code, some of that context will have evaporated.
It turns out that one of the things that is really difficult at Crossref is checking whether a set of Crossref credentials has permission to act on a specific DOI prefix. This is the result of many legacy systems storing various mappings in various different software components, from our Content System through to our CRM. To this end, I wrote a basic application, credcheck, that will allow you to test a Crossref credential against an API.
Subject classifications have been available via the REST API for many years but have not been complete or reliable from the start and will soon be deprecated.
The subject metadata element was born out of a Labs experiment intended to enrich the metadata returned via Crossref Metadata Search with All Subject Journal Classification codes from Scopus. This feature was developed when the REST API was still fairly new, and we now recognize that the initial implementation worked its way into the service prematurely.
Crossref and DOAJ share the aim to encourage the dissemination and use of scholarly research using online technologies and to work with and through regional and international networks, partners, and user communities for the achievement of their aims to build local institutional capacity and sustainability. Both organisations agreed to work together in 2021 in a variety of ways, but primarily to ‘encourage the dissemination and use of scholarly research using online technologies, and regional and international networks, partners and communities, helping to build local institutional capacity and sustainability around the world.
Setting up your iThenticate v2 account for use directly in the browser (admins only)
Documentation Menu
Setting up your iThenticate v2 account for use directly in the browser (admins only)
This section is for Similarity Check account administrators only. It explains how administrators need to set up the iThenticate v2 account for their organizations if they are planning to use iThenticate in the browser. You need to follow the steps in this section before you start to set up your users and share the account with your colleagues.
If you are using iThenticate v1 rather than iThenticate v2, take a look at the section for v1 account administrators.
If you intend to use iThenticate v2 through an integration with your Manuscript Submission System (MTS) instead, go to setting up your MTS integration.
Your personal administrator account in iThenticate v2
Once Turnitin has enabled iThenticate v2 for your organization, the main editorial contact provided on your application form will become the iThenticate account administrator.
You will receive an email from Turnitin with a link to set your credentials. The email will look like this:
Click on the blue ‘Set up my account’ button at the bottom of the email. This will bring you to a page which looks something like this:
Fill out your username and password, and don’t forget to tick to agree to the terms and conditions. You will then arrive at your new iThenticate v2 account.
How do you know if you’re an account administrator?
When you are logged in to iThenticate, what tabs can you see?
If you’re using iThenticate v2, you will only be able to see Users on the menu if you’re an account administrator.
So if you can’t see Manage Users or Users, you’re not an account administrator, and you can just read the user instructions for iThenticate v2 on the Turnitin website.
Updating your email address, username or password in the future
If you need to change your personal email address, username or password in the future, you can find instructions on the Turnitin website.