Twitter was abuzz this past week with the announcement of Get Full Text Research (GetFTR) at the STM association meeting in London. GetFTR attempts to reduce friction between discovery and access through a new kind of linking data service, and Roger Schonfeld’s same day analysis here in The Scholarly Kitchen provided some information from a publisher perspective.
Developed by a group of five of the largest publishers, and built on top of RA21’s Seamless Access service, GetFTR was very effectively kept under wraps until the formal announcement — so much so that the staff of NISO, a lead partner in Seamless Access, was completely unaware of the project.
GetFTR offers clear benefits for publishers and researchers. A direct link to a copy with known access entitlements is very useful. But, it seems some were taken aback by the less than warm welcome the announcement received from the library community.
Today, I wish to articulate why many librarians are concerned about GetFTR.
In doing so, I do not claim to represent all librarians. Instead, I offer these ideas in the hopes they can enable movement from surprise to understanding, and perhaps even appreciation, of the library perspective. I am one who believes that libraries and publishers share the common mission of serving researchers, though I observe that we do not always agree about the best approaches to doing so. Nonetheless, we can strive for mutual understanding and respect.
Concern: The Connection to Seamless Access
GetFTR builds on the foundation of Seamless Access, an initiative that troubles the library community. The predecessor project, RA21, raised many concerns related to control over and privacy of user data and the future of publisher support for proxy and IP based authentication, access pathways that are valued and broadly implemented in academic libraries. The follow-on organization to the RA21 project, Seamless Access, seems to be unable to find a library organization partner to join the leadership team in spite of making a number of overtures, and the group has chosen to move forward with implementation without that engagement. By connecting itself to Seamless Access, GetFTR is “inheriting” a number of the library critiques of Seamless Access. That these two initiatives share a number of organizations and individuals in leadership roles makes this joining up of critique all the more understandable. As long as GetFTR stays tightly coupled with Seamless Access, so too will the concerns.
Concern: The Limited User Base Enabled
Seamless Access currently serves a very small percentage of the library user community. Seamless Access uses SAML and relies on libraries having alerted publishers that a SAML service is available from their campus for the publisher to connect to. Making these technical connections live requires, at a minimum, communication between the library and the publisher, but likely also the campus’ SAML service manager, and may involve a data agreement as well. A quick review reveals that only a limited number of libraries have enabled federated identity access on the publisher platforms. For example, there are only 16 schools in the InCommon Federation in the United States that have enabled access on the Wiley platform. Elsevier’s showing is a little better but still tops out at 250 InCommon institutions enabled.
And, of course, an institution must have implemented SAML before the library can enable it with publishers. Many institutions, however, do not have a SAML service. For example, the InCommon Federation, the main federation in the United States, has only 764 members, not all of which are colleges or universities, out of a total of approximately 3,000 higher education institutions in the country. Libraries and institutions face many challenges in implementing new methods of authentication and so we cannot anticipate rapid deployment of SAML across the remaining institutions.
To the extent that GetFTR represents improved access to publisher platform content, librarians are rightly concerned that it is only being offered to such a small part of the population that could benefit from it. In addition, the small percentage of users who will have Seamless Access, and thus GetFTR, will have radically divergent experiences across devices and even across browsers on the same device because Seamless Access is specific to a given browser and not the device or user.
Unfortunately, GetFTR is currently unable to use IP recognition to enable GetFTR linking due to GDPR limitations on passing IP addresses (considered personally identifying information) to third-party services. Future work to investigate proxy-based access would be welcome to supplement the Seamless Access-based approach.
Concern: The Insertion of New Stumbling Blocks
GetFTR’s utility is limited by how Seamless Access is activated for the user. To activate Seamless Access, a user must have set their institutional affiliation in the course of logging on to a publisher platform via Seamless Access or have been provided with a direct link to the Seamless Access service in order to declare their institutional affiliation directly to the service. In the latter case, the user would be aware that the activation has occurred but in the former it will likely be very obscured.
But, in either case, Seamless Access is not activated for the user per se. And, Seamless Access is not activated for the user’s device. No, instead, Seamless Access is activated for the specific browser on the specific device. Thus, for GetFTR to be active, the user will have to be using the specific browser on the specific device that has been activated with Seamless Access.
Personally, for me to activate Seamless Access across the six devices that I use on a regular basis and all of the browsers on each, I would need to activate Seamless Access 13 times. It is hard to imagine the typical library user pursuing this intensive activation process proactively in order to ensure a consistent user experience for themselves. Instead, their GetFTR experience will be confusingly varied.
What reliance on Seamless Access also means is that most on-campus users are going to have the non-GetFTR experience on their on-campus devices because those devices use IP recognition for resource access. To overcome this, the user will have to proactively visit the Seamless Access service directly to register their affiliation.
All of which is to point out a concern that GetFTR is introducing new stumbling blocks and further Balkanization of the user experience. When a discovery layer provides a differential user experience of GetFTR based on whether the specific browser on a specific device is Seamless Access enabled, there is no question that user confusion will ensue.
There is clear value in a direct link to a publisher platform PDF. My own library has had this functionality in our locally developed EasySearch interface for quite some time. We have the advantage of serving a specific user community with known entitlements and so, while not without its challenges, this is more straightforward for Easy Search. (For an example, see “ScienceDirect Link” in this search result.)
However, the value of having a link to the content when it is available does not mean it is useful for GetFTR to display a “red” signal that would indicate “no access.” The actual reality of what the GetFTR service knows is “there is no entitled access that is known to exist for all users at this institution on the publisher platform.” And this — this is hugely problematic if it is used to display a “red” no access signal. Access may be available from another library licensed resource (e.g., an aggregator) or in an open access repository. Indeed, the user may have access on the very publisher platform but via a departmental or individual subscription rather than an institutional one!
Any implementation of the “red” signal will result in users being inappropriately thwarted and libraries will find themselves resorting to explaining that the red signal must be ignored. Of course, most users probably won’t ever ask a librarian about this because why would they question a clear signal from the platform?
Removal of the “red” signal from the GetFTR approach would remove the concern that users could be misled by that signal into thinking that they do not have access when in reality they do.
Concern: Exclusion from Advisory Committee
GetFTR is the project of five publishers (American Chemical Society, Elsevier, Springer Nature, Taylor & Francis, and Wiley) advised by others in the industry including the American Society of Civil Engineers, Atypon, Digital Science, IEEE, Mendeley, PLOS, Silverchair, and Third Iron.
Missing from this list? Libraries.
Publishers often take great pains to talk about how libraries are their partners, collaborators, and stakeholders. As recently as last month, for example, Elsevier’s CEO Kumsal Bayazit stated in her Charleston Conference keynote that “we see Librarians as key partners in moving to an ever-more frictionless research information system” and expressed a hope that “we can move beyond the past, work together pragmatically in the present so that we can partner and work together on the future.” In developing GetFTR, it appears that not only did publishers exclude libraries externally from the partnership but it appears some may also have excluded their internal library relations leaders from this new project as well as their library advisory boards.
At a minimum, GetFTR should offer opportunities for the library community to learn about the project through webinars and the like that are developed specifically for a library audience. Given the reliance on Seamless Access at this point, a joint webinar may be particularly useful. What should libraries be doing regarding registrations, configurations, user outreach, staff training, etc., if they want to maximize the benefits of these initiatives in reducing friction for their users?
And, perhaps obviously, adding library representation to the Advisory Board and the various GetFTR project groups would address the concerns of libraries as partners and stakeholders and ensure they are considered in the development process. Given the structure of GetFTR governance, I do not anticipate seeing library representation on the governance group, given how tightly scoped it is; though of course that would be welcomed by many. As a side note, university presses also appear to have been unrepresented in the discussions and this may be worth addressing as well.
Concern: GetFTR Replacing the Library Link Resolver
The GetFTR website makes it seem like GetFTR is a user-facing service with a distinct interface of its own and this is particularly messaged in the image showing a GetFTR icon on a user screen. This makes it appear that GetFTR replaces the library link resolver rather than working alongside or, potentially, within in. Since the link resolver is a mechanism through which libraries can route users to an appropriate copy for a variety of purposes, it is not surprising that libraries are concerned about this.
This concern is a result of confusing communications rather than a fundamental design flaw with GetFTR. Rather than user-facing as depicted on the GetFTR website, GetFTR would be better described and visualized as a data feed via an API that scholarly platforms and discovery tools can integrate along with the many other data feeds that they use to construct their interfaces.
The integrated approach to GetFTR can already be seen in Dimensions in instances where “View PDF” has a rollover text in some cases that says “Open Access PDF available from Publisher”). When Dimensions is fully enabled with Seamless Access (as of this writing it is waiting to be whitelisted by Seamless Access), for subscription articles the “View PDF” rollover will say “Access via <college/university name>”. Smartly, Dimensions will not send a “red” signal to users to indicate no access if Seamless Access+GetFTR does not indicate an entitlement as Dimensions recognizes and enables other user pathways, e.g., to aggregators and open access repositories.
Revising the visualization and adding language to the FAQ about how GetFTR does not replace the link resolver would address this miscommunication. Better would be to have a demonstration of how GetFTR and link resolvers will work together (perhaps drawing upon the Dimensions implementation) rather than only a statement that they can. Libraries work closely with their discovery providers and would welcome the opportunity to understand how GetFTR can be integrated in those settings for improved user experience.
Whether GetFTR will act to remediate these concerns remains to be seen. In some cases, I would expect that they will. In others, they may not. Publishers’ interests are not always aligned with library interests and they may accept a fraying relationship with the library community as the price to pay to pursue their strategic goals.
Acknowledgements: My reflections here are informed by deep engagement with the Twitter and Facebook dialogue about the GetFTR announcement, detailed review of the GetFTR website, and my own testing with SeamlessAccess and GetFTR in Dimensions. I have also had the benefit of conversations with Ralph Youngen (GetFTR/ACS), Jason Griffey (NISO), Andromeda Yelton (Harvard), Robert McGrath (ReadCube), and Roger Schonfeld (Ithaka S+R) and I am grateful for their time and expertise.