In our previous blog post in this series, we explained why no metadata matching strategy can return perfect results. Thankfully, however, this does not mean that it’s impossible to know anything about the quality of matching. Indeed, we can (and should!) measure how close (or far) we are from achieving perfection with our matching. Read on to learn how this can be done!
How about we start with a quiz? Imagine a database of scholarly metadata that needs to be enriched with identifiers, such as ORCIDs or ROR IDs.
We’re in year two of the Resourcing Crossref for Future Sustainability (RCFS) research. This report provides an update on progress to date, specifically on research we’ve conducted to better understand the impact of our fees and possible changes.
Crossref is in a good financial position with our current fees, which haven’t increased in 20 years. This project is seeking to future-proof our fees by:
Making fees more equitable Simplifying our complex fee schedule Rebalancing revenue sources In order to review all aspects of our fees, we’ve planned five projects to look into specific aspects of our current fees that may need to change to achieve the goals above.
On behalf of the Nominating Committee, I’m pleased to share the slate of candidates for the 2024 board election.
Each year we do an open call for board interest. This year, the Nominating Committee received 53 submissions from members worldwide to fill four open board seats.
We maintain a balanced board of 8 large member seats and 8 small member seats. Size is determined based on the organization’s membership tier (small members fall in the $0-$1,650 tiers and large members in the $3,900 - $50,000 tiers).
In our previous instalments of the blog series about matching (see part 1 and part 2), we explained what metadata matching is, why it is important and described its basic terminology. In this entry, we will discuss a few common beliefs about metadata matching that are often encountered when interacting with users, developers, integrators, and other stakeholders. Spoiler alert: we are calling them myths because these beliefs are not true! Read on to learn why.
Ideally, a DOI is registered for each new content item by its owner prior to or at the time it is published. This single DOI would then remain associated with the content item forever. However, because content can travel from place to place online, and it can live in multiple locations, a content item may exist at more than one URL. With multiple resolution, you can assign multiple URLs to a single metadata record. Members often use multiple resolution for co-hosted content or content in transition from one platform to another. Instead of resolving directly to a single page, a multiple resolution-enabled link will instead land on an interim page. The interim page presents a list of link choices to the end-user.
A single member may register multiple URLs for their content, but multiple resolution usually involves coordination between several members. One member needs to deposit the DOIs and metadata as the primary depositor. The primary depositor is typically the DOI prefix owner of the content being registered, and will commit to maintaining the metadata record. If second (or third) parties are involved, they will only be able to add and update secondary URLs for existing records.
Multiple resolution interim pages can be set up for an entire DOI prefix, or for individual titles.
There are no fees associated with multiple resolution. To get started, please let us know who and what content is involved in your multiple resolution project, and send us your additional URLs. Learn more about how to set up multiple resolution.
If the content you are working with does not already have DOIs and is not published by you, please contact us.
Multiple resolution typically involves two (or more) members involved in a co-hosting agreement. For the purposes of multiple resolution, the primary depositor is the member responsible for the prefix of the multiple resolution content being registered. The secondary depositor has been authorized by the content owner to also host content and assign additional URLs (called secondary URLs) to DOIs. We’ll always defer to the primary depositor’s instructions regarding changes to a metadata record including all assigned URLs.
Follow these steps to coordinate and implement multiple resolution:
Establish permissions - contact us to let us know what organizations and content will be involved in your multiple resolution project and we’ll adjust permissions as needed.
You can skip this step if you are implementing multiple resolution without a secondary depositor or intend to supply the secondary URLs yourself (as you are by default enabled to register multiple resolution URLs for your own content).
The primary depositor must notify us of the intention to implement multiple resolution for their metadata records, as well as all titles and/or prefixes involved. The secondary depositor may coordinate multiple resolution activity with permission from the primary depositor - this can be an email stating, for example: XYZ Publishing has permission to coordinate multiple resolution activity on our behalf for titles (…).
Primary depositors can create metadata records and deposit primary and secondary URLs. Secondary depositors may only register secondary URLs for existing records. The secondary depositor will be assigned a new system account to be used for multiple resolution deposits only.
Unlock your DOIs - you must enable each metadata record for multiple resolution by sending us an ‘unlock’ flag for each DOI. This can be included in your files or sent separately as a resource-only deposit, like this example file.
Register your secondary URLs. Secondary URLs are usually added to an existing metadata record using a resource-only deposit. The secondary URL registration file contains the DOI(s) being updated, the secondary URL, and a label. The label value is case-sensitive and must be a minimum of 6 characters (no spaces).
Create an interim page template
We provide a standard interim page when a reader clicks on a DOI that is in a multiple resolution relationship. This means that users can be confident that they’ll see consistent behaviour across all Crossref DOIs that are in multiple resolution. Depositors don’t need to do anything to create this interim page, it will generate automatically for a DOI when the multiple resolution relationship is created.
Clicking on these DOIs will take you to examples of the interim pages:
Note that the logos are pulled from a service called Clearbit who curate company logo and other information. These are not hosted and curated by Crossref. If your logo isn’t appearing and you would like it to, or you’d like to update your logo, you can contact support@clearbit.com so that they can assess your request.
Unlock DOIs for multiple resolution
The primary depositor must enable (or unlock) each multiple resolution DOI before secondary URLs can be deposited. You can do this using either a metadata deposit or a resource-only deposit (details below). It is expected that once a content owner gives permission for multiple resolution to be attached to DOIs of a given title, or to all their content, that the content owner will routinely enable multiple resolution when creating or updating their DOIs.
Unlocking a DOI does not change the linking behavior of a DOI - an unlocked DOI will continue to resolve to the URL supplied during registration until a secondary URL has been registered.
Unlock DOIs using the main deposit schema
This mode should be used for all new DOIs created after the content owner has recognized that secondary deposits will be taking place. It allows the primary content owner to enable the DOI multiple resolution permission at the same time as the DOI is initially created.
The XML used by the content owner to create (or update) the DOI must include an a element with the multi-resolution attribute set to unlock.
This approach can be used for all existing records or can be used for new records if the content owner does not wish to include this metadata in their main metadata deposit. Resource-only deposits should be uploaded as ‘DOI Resources’ when using the admin tool or operation=doDOICitUpload when doing a programmed HTTPS transaction.
When more than one URL is registered for a DOI, the DOI becomes a multiple resolution DOI. The primary URL is registered through a primary metadata deposit, but secondary URLs are typically submitted as a resource-only deposit by a secondary depositor. The secondary URL deposit consists of the DOI being updated, the secondary URL(s), and a label. No item-level metadata is required:
A secondary URL resource-only deposit must be uploaded with type doDOICitUpload for HTTPS POST (or DOI Resources when using the admin tool. The secondary depositor must have permission to add URLs to the primary depositor’s DOIs.
How to update multiple resolution URLs
If you are the primary depositor, the primary URL may be updated in the standard way. If you need to update a secondary URL you’ll need to re-send the secondary XML file to us with the updated URLs included. When updating, please note that the item label value and the depositor role must be consistent with those used in the previous update - this is how we know what URL to update.
Reverse multiple resolution
Multiple resolution can be reversed if the service is no longer needed for a DOI. When multiple resolution is reversed, the content owner should also lock the multiple resolution DOIs, preventing any future multiple resolution deposits.
To remove secondary URLs and lock DOIs, submit a resource-only deposit with a closed collection element, for example:
Crossref’s implementation of multiple resolution supports a form of appropriate copy based on the country of origin of the user requesting the resolution service. This service allows a content owner to deposit multiple URLs for a single DOI, each of which is intended to service users from a particular country. The DOI resolver will determine the resolution request’s country of origin and select the appropriate URL target based on country codes (see list.
The country code and URL information are supplied within <collection> (learn more about the collection element), and can be deposited as part of a primary metadata deposit or as a resource-only deposit. If a country code is not supplied, the DOI will resolve to the URL supplied in the top level resource element.
Metadata deposit example for multiple resolution
<doi_data>
<doi>10.5555/ilovedois</doi>
<resource>https://0-www-crossref-org.library.alliant.edu/hello</resource> default URL
<collection property="country-based">
<item country="US">
<resource>https://0-www-crossref-org.library.alliant.edu/howdy</resource> USA URL
</item>
<item country="SE">
<resource>https://0-www-crossref-org.library.alliant.edu/hej</resource> Sweden URL
</item>
<item country="KE">
<resource>https://0-www-crossref-org.library.alliant.edu/hujambo</resource> Kenya URL
</item>
</collection>
</doi_data>
Resource-only deposit example for multiple resolution
<doi_resources>
<doi>10.5555/ilovedois</doi>
<collection property="country-based">
<item country="US">
<resource>https://0-www-crossref-org.library.alliant.edu/howdy</resource> USA URL
</item>
<item country="SE">
<resource>https://0-www-crossref-org.library.alliant.edu/hej</resource> Sweden URL
</item>
<item country="KE">
<resource>https://0-www-crossref-org.library.alliant.edu/hujambo</resource> Kenya URL
</item>
</collection>
</doi_resources>
Role of the DOI proxy in multiple resolution
The DOI proxy is maintained by CNRI on behalf of the IDF. Multiple resolution required the introduction of an additional Handle property for DOIs, called 10320/loc, which is itself a Handle.
Example Handle record
In the sample handle record the default URL is set to represent the content’s primary location. This is typically the platform of the content owner, or its primary publisher. The presence of property 10320/loc, containing an XML snippet, indicates to the proxy that multiple resolution is enabled for this DOI. The XML is interpreted as follows:
<locations> element, chooseby: specifies the order of rules to be applied by the proxy when selecting from the <location> elements.
locatt: used if the DOI request specifies a specific location item
country: used if any location item specifies a specific country which must match the country of the requester
weight: a weighted random selection from those <location> elements having weight values
<location> element identifies a specific location
id: a unique ID given to each location element
cr_type: a Crossref property that specifies the type of multiple resolution to support
cr_src: a Crossref property that identifies which user deposited the location value
label: used by us to identify the co-host
href: the URL of the location
weight: the weighted value to use when applying the weighted-random selection process
The presence or absence of a rule in the chooseby property will enable or disable that type of selection process by the proxy.
What if I want to do multiple resolution but sometimes want to send people directly to my site?
DOI resolution requests may be structured to bypass our interim page using features built into the proxy’s multiple resolution capabilities.
You can bypass the interim page by appending a label parameter to your DOI link. To force the DOI to resolve to the primary (original) host location, add the locatt=mode:legacy parameter to the end of the URL, for example:
To force the DOI to resolve to a secondary URL, add locatt=label:HOST-XYZ to the end of the URL, where HOST-XYZ is the label supplied in the secondary URL deposit, for example:
How does multiple resolution affect my resolution statistics?
A click on a multiple resolution DOI is still a single click, it’s just that the clicks will be coming from an interim page instead of the DOI resolver, and your resolution reports will reflect that.
Page owner: Isaac Farley | Last updated 2024-April-03