[Eril-l] Crossref multiple resolution of DOIs and multiple canonical archives: whither DOI vs openurl?
Electronic Resources in Libraries discussion list
eril-l at lists.eril-l.org
Fri Oct 24 06:55:18 PDT 2025
Melissa,
I think I agree with pretty much all of that.[1] I think we must disagree
mostly on *what should we (librarians) do now?*
What I want to do is to focus on advocating that KBs (including open ones
like Unpaywall) should not use doi.org. Since publishers are often the
source of the linking metadata in KBs, we probably need to be talking to
publishers about that. Publishers can use whatever they want for linking
resolution within their own websites, but KBs (and the library link
resolvers built on them) need to be more picky. A useful link resolver
should be able to produce linking so that if the best way to find an
article on a particular platform is to pass on OpenURL string, it passes an
OpenURL string, and if the best way is to pass a DOI by itself—to the
platform, not to doi.org, which knows nothing about our users—it passes a
DOI. And if the best way is some other syntax—even proprietary, opaque
identifier strings—it should pass that. This is a link resolver's job: to
take the bibliographic and user data which is passed to it and turn it into
a link *to the associated object* at which *the user can access the object*
.
When our institutional link resolver takes users to the wrong place, I
either override the KB linking or complain to the KB vendor (or both). I
haven't tried to systematically identify whether it's a doi.org link which
is the problem; I don't have time for that.
My institution does use LibKey. I treat it as "just another" KB, but I'm
happy we have it, even if I occasionally have to request corrections in it,
too. LibKey's preference to avoid multi-resolution is a helpful approach
for most (of our) library use cases.
Anna
[^1]: "[...]so it's not just a question of publishers and librarians using
it wrong." I would say, "...so it's not *just* a question of publishers and
librarians *failing to use it most effectively in the library context*."
The DOI system isn't a library link resolver. I don't think it should be.
As long as we don't treat it like one (see my longish paragraph above), I
think we're good. Library link resolvers are specialized tools useful in
only some contexts. Other contexts need other tools.
I'm sorry I didn't more clearly articulate "the DOI system is not a library
link resolver" and instead said "the DOI is not itself a location
descriptor". (I don't think it is, but this isn't as to-the-point as I
should have been.)
-----
Anna Shields (she/they)
E-resources Librarian, Interim Systems Librarian
Williams College
on the unceded lands of the People of the Waters that Are Never Still
<https://mohican-nsn.gov/>
as67 at williams.edu
(413) 597-2041
On Fri, Oct 24, 2025 at 9:17 AM Electronic Resources in Libraries
discussion list via Eril-l <eril-l at lists.eril-l.org> wrote:
> I hope everyone else isn't bored with this exchange.
>
> For the authoritative description of the "DOI system", I figure the right
> source is the DOI Handbook,
> https://www.doi.org/doi-handbook/DOI_Handbook_Final.pdf
> It makes very clear in sections 1.2 - 1.3.1 that "resolving" a DOI to a
> web address is very much an appropriate part of what it is for, eg:
> "The DOI name can be resolved to a resource, such as a web or internet
> resource, metadata describing the entity, a landing page with access to
> further resources, etc.
> For example, a DOI name representing an article resolves to the web
> address of the HTML file version of the article."
> That quote is in the subsection labeled "Basic Principles" and is even in
> the first bullet of that section, so it's not just a question of publishers
> and librarians using it wrong.
> Sections 1.5 and 1.6 elaborate on the web site resolution concept. And
> large parts of the rest of the document are focused on the details of
> "resolution", with most examples involving going from the DOI to a document
> on the web.
>
> We might be quibbling about what DOI "System" means. The Handbook clearly
> posits that that system is intended to include, or even be centrally about,
> resolution services and organizations. In that sense, the DOI "system"
> includes Crossref and other organizations (including knowledge base (KB)
> management companies like EBSCO and the individual publishers) that
> implement the vision of DOI as a resolution solution that is clearly
> described in that Handbook.
>
> It even directly addresses the "multiple resolution" issue that started
> this thread, in 5.4.2 (PDF page 67).
>
> I'd like to suggest that the minimal multiple resolution system that
> Crossref has been trying is inadequate, as their own experience with
> feedback has revealed.
>
> And that what we librarians need is some kind of combined service that
> "knows" of the multiple URLs/"resources" for a given DOI, and can then get
> enough affiliation information about the user (assuming the resources
> aren't OA) to filter the list down to the ones the user can actually
> access. I feel like I just described what we already have with KBs, except
> those are starting to themselves rely on the DOI resolution as more and
> more content providers are eschewing supporting OpenURL and using DOIs
> instead.
>
> I just ran an sql query on a recent full download of all content in our
> KB, to see how many of our records use "doi.org" in the URL field.
> I found 33 "packages" (mostly equates to publishers) with a combined total
> of 44,000 titles using doi.org as their primary URL. The vast majority
> are Cambridge UP.
> That's out of about 3.3 million non-deduped records.
>
> That doesn't seem like a crisis. However, in our discovery system, there
> are also "custom" links that don't use the KB links to take the user to the
> full text, but some other way of generating a "persistent" link, including
> OpenURL but also if the citation record has a DOI, using that. I can't
> generate any kind of count on how often the DOI is trying to take our user
> to the full text.
> But I know it fails sometimes because such an incident is what got me
> started on this.
>
> Do any of you see situations where your discovery system uses DOI and
> takes your user to the "wrong" full-text copy? If it never happens, are you
> using some commercial service outside of your discovery system, like LibKey?
>
>
>
> Melissa Belvadi
> mbelvadi at upei.ca
> Make an appointment: https://mbelvadi.youcanbook.me/
> ------------------------------
> *From:* Eril-l <eril-l-bounces at lists.eril-l.org> on behalf of Electronic
> Resources in Libraries discussion list via Eril-l <eril-l at lists.eril-l.org
> >
> *Sent:* Thursday, October 23, 2025 4:03 PM
> *To:* Electronic Resources in Libraries discussion list <
> eril-l at lists.eril-l.org>
> *Subject:* Re: [Eril-l] Crossref multiple resolution of DOIs and multiple
> canonical archives: whither DOI vs openurl?
>
>
> *CAUTION:* This email originated from outside of UPEI. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe. If you are uncertain, please use the Report Message button in Outlook
> and delete this email.
>
>
>
> *WARNING:* The sender of this email could not be verified and may not
> match the person in the 'FROM' field. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
> If you are uncertain, please use the Report Message button in Outlook and
> delete this email.
>
>
> Melissa,
>
> A discussion of 'canonical home(s)' does seem to assume that the location
> of a digital object is an inherent part of its identity. I am reluctant to
> share that assumption. It looks to me likely to elide many of the
> attributes of digital objects which make them different from tangible
> objects.
>
> I don't object to using a DOI as *part* of a locator. This seems very
> reasonable, and one could argue that this is what the doi.org resolver
> and Crossref are doing. (And PLoS definitely described a system doing
> that.) But I also don't object to multiple resolution if you supply such a
> system with a DOI and nothing more. The trouble seems to me to come in when
> you ask a third-party system to act as a link resolver when you pass it *nothing
> but* a DOI. (At a minimum, I'd think for closed access works you'd also
> want to pass user affiliation, for instance.)
>
> I don't think the DOI system is the problem here. Publisher practice
> *might* be a problem. Librarian practice* might* be a problem. Librarian
> and user expectations *might* be a problem. But the DOI system is doing
> one thing—I think its primary goal—rather well, and I think it's able to do
> that so well because the system *doesn't* try to do the locating part.
> Mess with it, and I think you'll get something worse.
>
> Anna
>
> -----
> Anna Shields (she/they)
> E-resources Librarian, Interim Systems Librarian
> Williams College
> on the unceded lands of the People of the Waters that Are Never Still
> <https://www.mohican.com/brief-history/>
>
> as67 at williams.edu
> (413) 597-2041
>
>
> On Thu, Oct 23, 2025 at 12:32 PM Electronic Resources in Libraries
> discussion list via Eril-l <eril-l at lists.eril-l.org> wrote:
>
> Interesting perspective, and can get us into a semantic debate about
> whether the location of the digital object is inherently part of its
> identification.
>
> The What and Whys of DOIs
> https://pmc.ncbi.nlm.nih.gov/articles/PMC261894/
>
> Many major academic publishers are using the DOI URL as their "direct to
> title" URL, eg in our holdings knowledge base (for us that's EBSCO).
>
> I think the train has left on objecting to the use of DOIs as a "locator".
> And I think the server location as resolved by Crossref is carrying a kind
> of metadata that is related to the object, namely who is the canonical
> "owner" (not in the copyright sense, but the maintenance responsibility
> sense) of the object. I'm sure a lot of you are like me in playing around
> with multiple browser plugins like GetFTR, Nomad, Unpaywall, etc. that can
> lead users to non-canonical copies. And with the growth in multiple
> canonical "homes" (the topic of my original post in this thread), that
> "owner" metadata is getting blurry.
>
> I don't have a perfect answer, but I'm thinking that we do need to think
> on a big scale about modifying DOI, or at least DOI as implemented by
> Crossref, to deal with the multiple "owners" problem. A meta question might
> be: where does the responsibility for solving this problem lie? Crossref?
> Our individual knowledge-base vendors? Some kind of third-party (open or
> commercial) service that starts with the 'standard' DOI and can cross-check
> against our knowledge base to find the "right" canonical one for our
> patrons? Other?
>
>
> Melissa Belvadi
> mbelvadi at upei.ca
> Make an appointment: https://mbelvadi.youcanbook.me/
> ------------------------------
> *From:* Eril-l <eril-l-bounces at lists.eril-l.org> on behalf of Electronic
> Resources in Libraries discussion list via Eril-l <eril-l at lists.eril-l.org
> >
> *Sent:* Thursday, October 23, 2025 10:52 AM
> *To:* Electronic Resources in Libraries discussion list <
> eril-l at lists.eril-l.org>
> *Subject:* Re: [Eril-l] Crossref multiple resolution of DOIs and multiple
> canonical archives: whither DOI vs openurl?
>
>
> *CAUTION:* This email originated from outside of UPEI. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe. If you are uncertain, please use the Report Message button in Outlook
> and delete this email.
>
>
>
> *WARNING:* The sender of this email could not be verified and may not
> match the person in the 'FROM' field. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
> If you are uncertain, please use the Report Message button in Outlook and
> delete this email.
>
>
> I am happy to be demonstrated wrong, but it seems to me that the problem
> is one of treating an *identifier* as a *locator*. A DOI is meant to
> uniquely identify a unit of scholarly expression. A link resolver might use
> a DOI to help correctly identify the work it has been asked to locate, but
> the DOI is not itself a location descriptor.
>
> Treating Crossref as a link resolver seems like a bad mistake.
>
> Anna
>
> -----
> Anna Shields (she/they)
> E-resources Librarian, Interim Systems Librarian
> Williams College
> on the unceded lands of the People of the Waters that Are Never Still
> <https://www.mohican.com/brief-history/>
>
> as67 at williams.edu
> (413) 597-2041
>
>
> On Thu, Oct 23, 2025 at 9:38 AM Electronic Resources in Libraries
> discussion list via Eril-l <eril-l at lists.eril-l.org> wrote:
>
> Hi Melissa,
>
> Thank you for bringing this up, this is a concern here too -- the multiple
> resolution screen, while somewhat rare, is confusing for both patrons and
> staff alike. Our most frequent instance of this happening is actually with
> Bloomsbury resources, with multiple resolutions to 2 different Bloomsbury
> collections. A user can't be expected to know which one they can access the
> item through, and honestly, sometimes I don't know either offhand without
> looking it up. Our e-resources team has largely avoided a stance on whether
> or not we recommend using DOIs, but I personally avoid using them,
> primarily for this reason.
>
> Gail
>
> Gail Murray (she/her)
> Electronic Resources & Serials Librarian
> Smith College Libraries
> 413.585.2925
>
>
> On Mon, Oct 20, 2025 at 8:44 AM Electronic Resources in Libraries
> discussion list via Eril-l <eril-l at lists.eril-l.org> wrote:
>
> Hi, all!
>
> This is about DOIs for articles that have more than one
> "canonical"/official publisher home.
> That can happen, and does frequently, when a journal changes publishers
> and BOTH publishers maintain an official archive for PCA libraries.
>
> For instance, the 2006-2011 of the journal, Frontiers of History in China,
> where Brill has 2006-present and Springer-Nature, the previous publisher,
> has 2006-2011. Our only access is on SN because we did not continue the
> subscription in 2012 when Brill got it. But the DOI in our discovery
> service only leads to Brill, not SN.
>
> The NISO Journal Transfer database, https://journaltransfer.issn.org/,
> documents when journals transfer and includes whether the archive up to
> that point will be hosted by the transferring or receiving publisher.
> Sometimes it is actually both.
>
> It was recently brought to my attention that Crossref has a "multiple
> resolution" (MR) system, such that when following some DOI links, the user
> gets a list of links to each of the publisher platforms that are still
> "official" (I think by NISO's concept of that).
>
> I asked Crossref about what I should do to get an "MR" for this journal.
>
> This is part of the reply I got:
> However, just to set expectations, multiple resolution is used quite
> rarely. Most publishers prefer that DOIs resolved directly to the version
> of the content on their particular platform. And, the feedback we get
> from librarians about multiple resolution has honestly been primarily
> negative, because they don't like users to be faced with another decision
> point or extra friction in accessing the content. (we do have a
> workaround to 'bypass' multiple resolution, for that reason, and resolve
> directly to either the primary or one of the secondary URLs)
>
> That said, the more typical solution is for libraries to link to content,
> not directly via the DOI, but using an OpenURL link resolver or discovery
> tool integration that will direct users to the appropriate subscription
> version for which they have full text access. It's possible to integrate
> metadata from Crossref into such a tool, to facilitate linking more
> effectively.
>
>
> As I read and re-read that answer, it occurred to me to question whether
> the entire point of the DOI system is breaking down. When Crossref itself
> tells me not to use DOI links, but instead openurl links, which is where we
> were 20 years ago and whose problems were a big part of the reason for
> supporting the adoption of the DOI ecosystem in the first place, I feel
> like we are moving backwards in a context that I thought we had solved
> already.
>
> I know that DOI still works for "most" situations. But openurl also worked
> for "most situations", and still does. I worked at a library that was one
> of the very earliest adopters of openurl, and even wrote my own openurl
> resolver for my library before the commercial products existed. I have a
> long memory of how we got from there to here.
>
> So I wanted to consult your collective wisdom about this issue, both from
> the immediate "best service to patrons today" perspective and the
> "long-term where should our ecosystem be going next?" perspective.
>
> Your thought would be most welcome!
>
>
>
> Melissa Belvadi
> Collections Librarian
> University of Prince Edward Island
> mbelvadi at upei.ca 902-566-0581
> ORCID iD: 0000-0002-4433-0189
> my public calendar
> <https://outlook.office365.com/owa/calendar/0fbab27c909e4493be65313bd66d66b6@upei.ca/5fa60af92c6d451c9ddf90c0bb11e00f15552192987609852692/calendar.html>
> Make an appointment <https://mbelvadi.youcanbook.me/> via YouCanBookMe
> My pronouns are ಅವರು/ಅವರನ್ನು
> My emails are sent during the hours that I work and I understand that you
> will respond during the hours that you work.
> _______________________________________________
> Eril-l mailing list
> Eril-l at lists.eril-l.org
> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>
> _______________________________________________
> Eril-l mailing list
> Eril-l at lists.eril-l.org
> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>
> _______________________________________________
> Eril-l mailing list
> Eril-l at lists.eril-l.org
> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>
> _______________________________________________
> Eril-l mailing list
> Eril-l at lists.eril-l.org
> http://lists.eril-l.org/listinfo.cgi/eril-l-eril-l.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eril-l.org/pipermail/eril-l-eril-l.org/attachments/20251024/365985d8/attachment.htm>
More information about the Eril-l
mailing list