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. dfdfd
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.
To work out which version you’re on, take a look at the website address that you use to access iThenticate. If you go to ithenticate.com then you are using v1. If you use a bespoke URL, https://crossref-[your member ID].turnitin.com/ then you are using v2.
When your organization signs up for Similarity Check, a central contact at your organization will become your Similarity Check account administrator. They will set up all the users on your account.
When your administrator adds you as a user, you’ll receive an email from noreply@ithenticate.com with the subject line “Account Created” containing a username and a single-use password. You may only log in once with the single-use password, and you must change it the first time you log in.
Log in to your user account (v1)
Start from the link in the invitation email from noreply@ithenticate.com with the subject line “Account Created” and click Login
Enter your username and single-use password
Click to agree to the terms of the end-user license agreement. These terms govern your personal use of the service. They’re separate from the central Similarity Check service agreement that your organization has agreed to.
To change your email address, remove your current address from the Email field, enter your new email in the same field, and click Update Profile to save.
To change your password, enter a new password in the Change Password field, repeat it in the Confirm Password field, and click Update Profile to save.
Find your way around for users (v1)
In the main navigation bar at the top of the screen, you will see several tabs:
Folders: this is the main area of iThenticate, where you upload, manage, and view documents for checking