Common Stacks Episode 023: John Seguin on Open Access and Third Iron

Learn more about Third Iron here:
https://thirdiron.com/

Third Iron enables the vital role libraries play in the research process with innovative technologies that meet the expectations of today’s user.

When the point of discovery is within the library, in services like databases and discovery layers, our services simplify and expedite how users get to full text.

When research starts outside the library, at sites like Google and ResearchGate, Third Iron technology identifies and seamlessly connects users to library full text.

Together, Third Iron services deliver libraries a modern digital access strategy that saves researchers countless hours of time, reduces the load on the help desk and unnecessary ILL requests, and meets the expectations of students, faculty and researchers.

Rough Transcript: Episode 023 - John Seguin of Third Iron

John  (00:04:44):

And so that's, that's always been the objection. And it becomes, you know, very, very expensive cuz you're doing this for thousands of titles, right? Pain and subscribing. When you look at a gold OA journal, that is literally like the reverse business model. And so in the reverse business model, you've got publishers who are making all of that material on, in their journals available for free, but to get your title or I'm sorry, get your article published your pain for that Privilege. So those are usually referred to as article processing charges. And those can range you know, quite wildly from a few hundred dollars to several thousand dollars, depending, depending on the title. The reputation of the, you know, publisher and the journal and all that kind of thing. And so the author needs to budget for that, right?

John  (00:05:36):

So if they're writing a grant and they want it to be open access, maybe that's part of the grant. Maybe it's coming from other research funds from the, you know, grants from the, you know, university or sponsoring body, all that kind of thing. But it's, but it's the reverse, right? So that material is much more widely available for, for folks to to access. There, there's a couple other variations on that. So Diamond is sort of a gold variation in that with Diamond, they're referring to this idea that there is no real quote unquote business model. It's much more pure. It's this idea of saying the information should be available to everyone and there shouldn't be some barriers for researchers to, to publish. So obviously nothing's free, right? Somebody has to pay for this.

John  (00:06:27):

So they're typically government entities who are sponsoring these things, or conglomerate conglomerations of government entities. Silo is probably the most famous one out of Brazil. It's huge thousands of titles mostly in Spanish and Portuguese. And you know, there's other ones as well that are, that are smaller. But it's, but it's kind of the Bulletproof model, right? Where they're, they're not dependent on the researchers having the funds. And they're not dependent on subscriptions either. There's, there's maybe, you know, two more variations including the one that of course we're gonna spend a lot of time on. But one other one is bronze which is an interesting one I think coined by the folks that impact story the folks behind on paywall where it's, it's very similar to a subscription model or a gold model.

John  (00:07:24):

It's kind of a combination thereof. So it, it's sort of, or not a gold model, I'm sorry of a hybrid model. And this is usually where things are open access after a period of time. So they sort of bronze over time, if you will. So, you know, you would see things where materials are, or sorry, the journalist, a subscribe journal except maybe after 12 months embargo, then it becomes open access or 24 months. And there were a number of high wire titles in particular who, who did that quite a bit. But you see some publishers also sort of retrospectively doing that, where they say, oh, okay, every, all material before 2002 is now open. And we, we would consider that a bronze model as well. Hybrid is, is a is a combination of gold and subscription.

John  (00:08:17):

And so a hybrid journal is is this idea of it being a subscribe title to access all of the content, but some of the content is available for for everybody to access in an open access model. And so, you know, I I, you know, this, this is often a criticized model, as you might guess, cause it kind of sounds like a heavier cake and eat it too, if you're a publisher, right? You know, you're, you're, oh, we're supporting open access, but also, by the way, please renew. Kind of thing. Which is not untrue, right? You know, so, you know, the basically they're giving researchers the ability to pay to have their content accessed if they would like. And you know, that's becoming a popular model because you have a number of funding bodies who are saying the material must be available to folks after a certain period of time or immediately. And so, you know, they're, they're helping to, to fund some of those article processing charges and so forth as part of the part of the mandate. So consequently, a lot of publishers are are, are embracing that.

Rob (00:09:25):

Yeah, there, there's no surprise in our industry that the business models are opaque as the progression of a shift in our industry is kind of upon us. And librarians do a really good job of focusing on that and determining the opportunity. Yet within open access, I feel like there's a struggle because there are so many moving parts, and traditionally there's standards to deal with moving parts. Are there any standards as these journals release hybrid regards to one month, they have to have a composition of 60 40 from paid to open? Or is this just make it until you make it in this?

John  (00:10:11):

Yeah. it, it's very much improvised. And you can imagine that depending as a publisher, depending on you know, who you are as a publisher and, and, and what titles you have, the age of those titles, you know, if they're emerging titles or if they're big legacy ones that have been around for a hundred years, you're probably gonna approach this differently, right? Depending on the revenue base you've got from subscription and so on it's a lot easier to have an entrant into this space as a you know, gold oa journal because you're immediately saying, well we don't need subscribers right away. We need, we need people to submit, and the submissions alone are going to fund our operations. So it's, you know, it's, it's no wonder that it's very easy to kind of maybe start a bunch of journals that way.

John  (00:11:04):

But, you know, on on the flip side, you know, and we can perhaps get into this as well, is, is that, you know, that sort of practice is, is is the one that's most commonly associated with predatory publishing. Not, not trying to lump, you know, open access and go away into predatory a hundred percent. But you can see where that's where the abuse could happen, right? When you're trying to launch that. But it's a similar sort of, you know you know, critique when you think about, you know, hybrid as well where you're saying that, you know, these are some of the most popular journals in the world, but the highest revenue models you know, why also do a very, very steep article processing charge, you know, to be part of this because people are gonna subscribe anyway, <laugh>, right?

John  (00:11:50):

So so, so it's a, so it's a, it's, it's an odd thing, but there is definitely no standard in terms of, you know, 60 40, like you're kind of suggesting I've not seen that. But I, but you know, I have seen these, these various efforts to say we are going to launch the journal as maybe full gold oa or we're gonna have a journal that is subscribed and we're going to add hybrid with the intention of, of kind of pushing that model. You know more you know, there was a, a statement by the head of publishing from Springer a few years back noting that they've just been trying to do more and more hybrid oa, that there's a great demand for that. And then it makes sense to, you know make as many titles as possible you know, hybrid oa capable so that researchers can have that choice.

Rob (00:12:43):

So, so why all the complexity we're, we're really in a market where traditionally it was a subscription, and then we went to a purchase model, and then some other disruptive options came on the market. Why are publishers making so many layer labels, but also from the utilization perspective, so confusing?

John  (00:13:07):

Yeah. yeah, I, I, I think it's all opportunity, right? You know, they, they, they know that if, if they can do a hybrid oa they can attract certain authors who have that mandate to do so. It's not super clear if all the authors are, you know, doing the hybrid oa you know, APC purchases, purchases because they firmly believe that this should be open access. I don't know if there's great evidence for that. I'm sure some of them do. But others are, are just responding to, you know, this general you know, injustice that a lot of folks see of, of, you know, large federal funds going into a project that then, you know spurs a lot of great science, and then it's locked up for the public, you know, and that's not so, not so great.

John  (00:13:58):

So trying to figure out different ways to, to make that available from a publisher standpoint and to keep traffic coming to your site, rather than being spun off to a green OA repository, which is kind of the, you know, the second option there makes sense as a publisher. So if you can, if you can do that, you can realize some additional revenue, you don't think it's going to hurt your subscriptions, Hey, let's do it. So it's, you know, but, you know, to, to like an earlier point, it from a end user an end researcher whatever the label is, shouldn't really matter to you, you know, it's, this is content that you can make of you know, make it available to, to utilize in your research and, you know, the challenges for libraries to say, how do we make sure that we can get as much of that content in front of users as possible in the workflows that we have?

Rob (00:14:52):

So, it's fair to say that publishers are now shifting their focus away from the journal to the article as they are now shifting their focus to the author that the players now are moved down in the workflow and publishers wanna both diversify the journals they represent. But now with APCs, the interest could be to find authors to pay into that revenue stream. But is anybody watching the APC costs? I mean, is there some watch group out there that's saying publisher A, why are you lowering or raising your price? Or are we still on the wild, wild ones?

John  (00:15:38):

Yeah, I, I, I'm not aware of, of that. There could, there certainly could be. I, I know it varies wildly. I mean, I've seen, you know, different prices for different things, and it's, and it's all over the map. But I, but I would, I would also, you know, guess when they come up with, with those pricing models, they're experimenting as well, right? How much can we get? It's not different than a subscription model. It's just, you know, saying, well, let's add up the revenue per article for one issue and go, alright, this is what it's gonna cost for, for this publication you know, for this, you know, quote unquote issue to move it forward and so on. So does that all make sense on our end? You know and, you know, of course it's, it's a lot easier for, you know new upstart publishers to operate this way than it is the legacy ones because they're, they're defending revenue, right?

John  (00:16:30):

They're saying, we have all these subscriptions, <laugh> how, you know, can we convert, you know, to a, a fully gold away model? Probably not in a lot of cases without taking significant, you know, financial losses. So you know, it's unlikely that, that they do that. And, you know you know, I can't imagine what an APC would have to cost for, you know for nature, for example, to move it to, you know, a gold away model. It would be, you know, astronomic, right? So, so, so, so for some journals that's just not ever going to happen. But it's, it's providing, I think a revenue model or journals that maybe would be, you know, two niche perhaps for the traditional model. And that's more of the opportunities in all this, right? It's like, you know, there are some subjects and so on that just not everybody's looking at, right? But it's very important to a small group of, of researchers globally. And, you know, the journal's always been the the means of scholarly communication. And so having a forum for those users to, or those researchers to interact that way you know, that provides a new revenue I'm sorry, a new, a new model for, for those types of researchers.

Rob (00:17:48):

And we have spoken about containers and, and how the targets and the containers are shifting. But you said something very interesting and I, I just wanted to circle back about opportunity. Do you see that the larger publishers that, that have to defend their legacy business having a disadvantage in the market versus a a, a fresh start or a new publisher, is we're all about names in our space, right? It's either this or that. Where is the opportunity in that fresh startup, that new publisher that has a niche and a value, do you see them standing up quicker in this space or going through different sets of art?

John  (00:18:34):

Yeah, I mean, I, they're different sets because I think what the, what the larger players are doing is, is they just come up with new titles. And so their, their portfolio of gold oh eight titles is increasing. And because of all the rest of their operational scale and, you know, publishing automation and all the rest of the things in their toolbox, they can stand up new titles, you know, fairly quickly and inexpensively. So they don't need to make the revenue of their big flagship titles with these smaller things. But they can offer to to researchers all the benefits that comes along with those things. And probably more importantly, like societies, right? Societies often drive, you know, new titles and that sort of thing. And if a society says, you know, yeah, we, you know, we wanna support the open access, you know, architecture, right? Like, you know, we believe in that. You do see a, a, you know, I mean we, we've seen over the last few years a number of titles that we're formally subscription flip over to full gold away probably, cuz they're more, you know, they're more nichey titles and they're smaller and so on, and so they can afford to kind of run the numbers and, and make that calculated switch.

Rob (00:19:40):

So let's talk about that for a second. As lib key and as a solution, helping libraries find content, how do you deal with this re-engineering of an article, right? All of a sudden this journal comes to you through an api or you're trying to resolve it through your technology, but you're in, you're reading something differently. And how is that a challenge that, that not only live key handles, but overall anybody in this space of the message in the bottle's different now? What's kind of the big view of that?

John  (00:20:18):

Well, well, I mean that's very, I think it's very operationally different depend on, depending on who is trying to keep track of that, you know, so the way that we do it is probably very different than the way that other you know, linking solutions do, do that sort of thing. You know, what everybody has to do though is you know, to do this well is they have to have article level intelligence about, you know, what's happening with this one article. It's also good to have container level intelligence, which I think a lot of folks try to do right now. And you know, saying this whole journal is now oa for example, you know, it, it flipped to OA in 2014 or whatever it is. So, you know, having that container level is good. But in order to track the hybrid, you really have to have the article level intelligence.

John  (00:21:08):

And that's, that's the, the tricky bit. Cuz there's various different you know, solutions who are trying to tackle this you know, to varying degrees of, of success. You know, we've always been very operationally nimble you know, and we've always tried to be very responsive to customer you know, issues that come up. So making sure that we have the right, you know, switches on our end where if anything is discovered, not only can we adjust, you know, something very granular but we can also, you know, kind of sniff out patterns of, you know, sort of like, you know, the canary and the coal mine sort of situations where you go, oh, that okay, that, that, you know, someone reported this little thing. Okay what else might have been affected by that? And how can we kind of swiftly react to that? And then, you know, using some more you know, bobs in the water, if you will, that we're kind of sensing things ahead of time. So we're not, we're not being just reactive of course. We have a lot of things where we can figure things out before anybody else notices.

Rob (00:22:14):

The, the complication and sorting and routing of the requests and content seems to be the challenge that both companies, like Third Iron half, but also the challenge that libraries have in trying to figure out, well, are my solutions working well? Yeah, and maybe you could spend a little time helping us understand of, you know, what really worked well for libraries kind of pre OA or really early on in the open URL methodology and, and discovery layer. What, what made sense in, in that stack?

John  (00:22:53):

So I think, I think it's important to understand kind of the history of that, you know you know and going back to when Open your was developed and why it was developed and, and what was missing at the time, right? Because in the mid nineties you had a bunch of indexes and you had full tech sources, and those were you know, separated. You had, you know, some experimentation I guess with like ProQuest and epsco with full tech sources, but by and large, you had the publishers being very isolated from there and, and you had no easy way to go from one to the other because right before that the indexes, you know, they would indicate volumes and issues and that was great because then you'd go to the physical, you know volume on the shelf and it was, it was, that was the process.

John  (00:23:41):

But since it was available electronically that's great, but how do we link somebody from point A to point B? And the publishers designed their websites however they wanted to, right? So they all had their different architectures and so on. There was no like standard of this is where we're gonna put things on the, on the publisher websites. So the idea was, well, if we can invent this common protocol where we can take metadata from an index source and then hand it over to a, hand it over to a destination source, then the destination source can reinterpret that open URL data and, you know, do whatever local thing it needs to do to get you to the right the right full text item. And in between that then there needed to be a knowledge-based mechanism where libraries could keep track of what do we have access to here so that you could be presented with these options of where it should link out to.

John  (00:24:43):

Cuz the protocol itself, of course, doesn't know what an individual library has access to. And so from that you know, open URL was born with, with that turning into the commercially available sfx, then from the nascent ex Libra. And all of that was very much based on this volume issue page sort of concept and matching that up to your knowledge base and, and so on. And you know, there, there was a lot of you know, and so like the thing that, that, you know, it's, it's major claim to fame, I think was we literally went from zero to 60 by doing that, right? We had no idea if we had access to something to now we have a reasonably good idea, we have access to something, right? And that was huge. And so that was, that was, you know, working, if you wanna put it that way, right?

John  (00:25:35):

That was, that was very, very useful and very helpful. When it came down to do we actually have this journal at least some of this journal, you know, I open URL was, was most reliable when it came to the numerics. So when you're looking at issn volumes issues, things that are hard to mess up, right? Like it was very reliable in that sense. You started to get into situations though where you know, if open URL was maybe incorrect in certain places from like the index side, you know, they, you know, they made a mistake in the indexing, for example, and that goes into your open URL resolver, it starts using false, you know, bad data essentially, that links out to publishers where that's not actually even matching. And then you get these like, you know, bizarre errors, right? And things don't line up and, and that sort of thing. And so that was quickly seen as, oh no you, you know, you know, there's, there's, there's noted imperfections in this, you know, there's, there's because of just the nature of metadata not necessarily being accurate or clean, you're going to have some, some issues there. But you know, before, you know, we got involved with this and some others to improve that open URL brought you from zero to 60, and that was a huge, huge improvement.

Rob (00:26:57):

And, and most of these open URL resolvers are still operating in libraries today that this technology has been bundled or packaged into other suites of services. So it's really hard for libraries to pinpoint a point of weakness or a technology that's aging as we move into kind of an article and resolving to kind of that article container, another journal.

John  (00:27:28):

Yeah. And, and, and, and and a lot of the different, you know, vendors out there, they have improved upon that initial design in different ways. And so, you know, I won't go through the, a whole laundry list, but a general way that, that a lot of them have, you know, tried to improve upon this is by trying to understand you know, trying to equate that open URL to articles in an article level index on their end. And when they can do that, that can you know, give them better specificity, you know in terms of linking to the right container that's usually, you know, based on some legacy sort of publisher you know, feeds of that data which has kinda its own, you know, kind of quirks and, and issues sometimes. But, you know, I think one of the things that, that lib key is doing in particular that's, that, that is improved upon that even further, is we're completely identifier based.

John  (00:28:23):

So we're very much looking at a precision you know, identifier for the article, the ui, p m IDs, that sort of thing. And that way we're trying to kind of sidestep the issue of hey, let's figure out what this article is and the article's already figured out, and instead we can put all the energy into, well, let's focus instead on get you to the right container as it were, right, with the right database source and so on. Let's do the authentication correctly, and let's add additional intelligences to this, this article level linking we're doing. So understanding the open access status, for example. What about retraction status? You know, those different other bits of element bits of data that we can layer on top of that to just really, really improve reliability. Because that's the other thing to keep in mind is that when Open URL was first conceived in the mid nineties DOIs were just not prevalent the way that they are today.

John  (00:29:19):

That, that whole, that whole thing came about in the mid two thousands. And, and today, now it's extremely common for an academic article to have a dui. It's, it's either much, much more the rare duck if you don't at this point. So because of the success of that whole initiative the actual identification of articles in terms of is this the right article I'm thinking about and talking about and want to get access to that problem's been largely minimized. But the problem of, okay, now you have it, but you've got it from 10 different databases according to your knowledge base, which one do we link to? How do we link to those, you know, how do we authenticate it? Should we authenticate it? Is there an open access for like, all those questions? Those are still there. And that's, and that's what Li Key is focusing on

Rob (00:30:07):

There. There's a lot of things that Li Key does. There's a lot of magic that that happens when Live Key gets implemented into a library. Can you just explain, and I know this is, it's gonna be a difficult question that we look back at things like a knowledge base that required older, slower not dynamic protocols and technology, li Key's doing things differently. You're using some ai you're using APIs clearly leading in this space. So how does that magic happen?

John  (00:30:43):

Yeah. So I appreciate you saying it that way, <laugh>. Yeah, like the way that we do the magic is, is essentially that we are, we are taking advantage of, of, of certain, you know technologies that exist. You know, the ability to do massive web scale fast, you know, dynamic stuff you know you know, with cloud hosted technology and so on. So we can do, we can make a lot of decisions very, very fast. And the AI that, that we employ is, is an expert system type. And so this is sort of an opinionated service, I like to say, where if you had a knowledgeable e-resources librarian who's been in the industry for a long time watching over your shoulder while you navigate a link resolver that's what Lib Key would do.

John  (00:31:34):

It just wouldn't have to show you all the steps and troubleshoot the things for you. It would just kind of do it. And you know, the kind of the, the, the history of Lip Key is, is a history of browsing, which is our first product that we developed about 11 years ago. And when we built browsing, it was designed as a mobile app from the get go. And, and because of that it kind of threw some sort of constraints on what we were, what we were trying to do. Because if you can kind of rewind the clock you know we, we developed this literally months after iPad one came out. So like, you know, things were quite kind of primitive in terms of the technology cuz you were kind of taking a step back 5, 6, 7, 8 years in terms of computing power versus your desktop when you talk about like iPads and tablet computers.

John  (00:32:25):

So things were slower. The <laugh> the, you know, kind of the wireless protocols were not as good as your wire protocols, right? For speed processing power wasn't, wasn't really there. Also you were dealing with you know a, a a a format where you didn't have a lot of screen real estate. And so at the time not many, not many especially academic publishers were doing a lot with mobile responsive design on their sites. Not to mention link resolver vendors and all this kind of thing, right? There's just, there wasn't a great demand for it at the time. And our first thought was, oh, okay, well, we'll build this service browsing, which was really focused on the user experience of browsing journals electronically and trying to re-envision that in a much more graphically intensive, user-friendly mode.

John  (00:33:19):

At the time, we, you know, we had observed a lot of libraries doing away with their print journals, browsing rooms, right? They were like, oh, put a coffee shop in here, or more student space, or whatever they needed it for, which of course made sense because a lot of academic publishers were like, we're gonna stop publishing and print anyway, you know, so we're, we're gonna send you any paper. And, and we thought, well we understand this is happening, but that modality of serendipitous discovery and, you know, navigating the, the, the print shelves for you know, the, the the brows ability of the material is still really, really important to a lot of researchers who are not necessarily just sitting in a search box all day. You know, they just, they want to have that communication of what's going on in my society, what's new in this general, you know, area here.

John  (00:34:09):

And so that's where we thought the opportunity was for, for browsing. And we thought, okay, well we'll just attach this to a library's link resolver, and, you know, great, we're done. And we did that when we, when we kind of built some prototypes of it, and the user experience like was just terrible because you essentially had a very slick front un that our, that our team had built really cool bouncing around table of contents great. And then you're like, go to full text and everything was like, glacial, glacial, glacial, and then I have to choose some stuff. And sometimes it was formatted nicely, and most of the time it wasn't. And the buttons really tiny, like everything was just, you know, it kind of ruined the magic that we were trying to create with browsing you know, where our mantra was, we're trying to delight users and we're like, eh, it's not gonna delight them.

John  (00:34:56):

So so we kind of backed up a little bit and, you know, kind of unpacked the way that Link Resolvers have to do their job. How do they know where this stuff is? How do we get, you know, from A to B, how do we do this smartly and all this? So there, you know, there's been a good like 10, 11 years of us kind of rebuilding, link resolving and that concept to, to say, okay, well, you know, you should have that, you know, librarian looking over your shoulder, doing all of this kind of smart stuff. Understanding sources you know, we've analyzed hundreds of sources, understanding which ones are most reliable the best speed there. Most librarians will tell you, like, we prefer to go to direct to publisher sources because the accuracy is there, the timeliness is there, et cetera.

John  (00:35:43):

Or aggregation. If open access is available, we, we prefer to use that over anything else. We prefer not to put impediments of sign in for users if we don't have to, you know, all these kind of like very common things that I think most librarians when we talk to them, they say, yeah, like, of course, yes, that's what I would do, that's what I would do. But we've just automated that. So, you know, one of the, you know, bits of magic, if you will, about lib key, I think is that we've done all this hard working hard work of all that source selection, AI stuff for the library. So there have been other methodologies that have come out over the years where you know the library can go in and, and twist a bunch of knobs to configure kind of source selection, but it's a huge burden for the library to like, think through all the ramifications of that.

John  (00:36:30):

When, you know, on our end, we're thinking very much from a user side where they say, I just want, I want to click and get the thing that I'm looking at. Like, here's the abstract, you know, here's the abstract, give the full text. Like, just do it <laugh>, right? Don't, don't ask me a hundred questions about this. Don't make me choose between things I don't understand. Don't feed me a bunch of library jargon about embargoes and Ill options. Just build the link, just do the thing. And so, you know, a, a large part about what we, what we do then is try and build that opinionated service that says, you know, we think we've thought through all these different possibilities for you. Let's do all those calculations in a 10th of a second. You don't know that anything's happening, <laugh> and, and, you know, just kind of deliver it. And, and, you know, we've worked that up over a long time to the point where we actually have a patent on that process of like how to do all that very, very fast. I, and take all that into consideration to build the link that, that you're asking for based on that identifier.

Rob (00:37:27):

There's a lot to unpack there. And

John  (00:37:30):

Yeah,

Rob (00:37:30):

<Laugh>, the good news is, I remember so <laugh>, little, little, I'm gonna take small wins today. I, I remember those early days browsing and, and that traveling with the sales team and having to say, who's got an iPad? Who's got an iPad? I dunno, they're too, they're too expensive, or I'm still waiting to,

John  (00:37:48):

Right, right,

Rob (00:37:48):

Right. Deliver there, there's no Apple store in my town. And it's, I think what you captured there, which was, which was really insightful, is we don't realize how many years we've been in this digital space. Yeah. Especially as it relates to the value of a knowledge base over something like an api. And maybe you could just spend a minute there explaining the libraries that maybe the a a knowledge base is like Web 2.0, but an API is like, like 3.0. It's like they, they seem to be so dependent upon this knowledge base, yet I've never met one that's accurate for more than two weeks. But in api, calling directly to the publisher just seems like a more, more intelligent design and better delighting users.

John  (00:38:40):

Yeah, well, there's, there's, there's a couple of things there. Like that was one of the other decisions we made is that we, is that we could have said, okay, we're gonna be a Link Resolver product, you know, and we're gonna say, you know, oh, you have a link Resolver, tear that out, you know, use, use, you know, third iron technology for this. But we realize that, you know, a lot of, you know, folks are set up with a link resolver and knowledge base which is doing a lot of work. That is beyond the scope of what we were looking at attacking. You know, we're very much focused on articles and, you know, academic articles and that, and that's principally because we see that's the lion share of linking that occurs, and it's a lion share of the problems <laugh> in linking that occur.

John  (00:39:29):

And, and you know, so we, we, we wanna make sure that you know, do we really want to take a, you know, take on full responsibility for a knowledge base and link resolver? And we ultimately decided, no, we don't wanna do that. And the other aspect too is that you know populating your knowledge base, that's a huge effort. Like to get going with that and say, oh, here's all the things we have access to, click, click, click, click, click, you know, and, and it's a necessary step in building a link revolver system. So many libraries have already invested in that years and years, if not decades of time, you know, really trying to tell this thing, this is what we have access to, and all these different systems, even though if there's, you know, a bunch of fragility there as you're kind of pointing out and, you know, maybe there's, you know, things that aren't as updated as they should be and, and so on they're doing, it's already there.

John  (00:40:19):

It's already built. And so instead what we did was partner with all of the link resolver companies so that when we work with a library we actually work with their library vendor to say okay, your knowledge base is being managed already by the system. We're not going to change that. You'll continue to have that system, but they provide us with a copy of that knowledge based data. And that becomes one bit of the in information for us to build our linking mechanism. It's not the only one, but it's one of them. And depending on the sourcing they're looking at you know, it's a very, it's a very important one. And instead what, what, what we talk about with Lipkey is that we are going to be kind of a layer on top of that ingesting injecting a lot more intelligence into that linking process that might actually sort of paper over some of the fr that you have in your Link Resolver system.

John  (00:41:17):

You know, one little example of that, right? If you have a journal and maybe it says you've got it at six different sources, right? That's what your link resolver, you know, tells you based on the information that you put into it. And this isn't the link revolver's fault, this is also kind of user error, right? You know, people have to maintain these things, things they have to keep 'em accurate. Oops, we canceled this last year. Did you update the link resolver? You know, all that kind of stuff, right? So there's a maintenance issue there. When that, when that happens and you've got six sources there you know, I, I joke sometimes that any time there's more than like six or seven, like one of them definitely is gonna fail. Like for sure, it, like, for whatever reason, it's gonna hit a brick wall.

John  (00:41:55):

But really you just need one to work, right? It's not important that all six work. If five of the six work, that's fine. But lip key, very likely because of the algorithms we've put over things is probably gonna be using one of the more reliable and stable ones. So you're not gonna notice these cracks in your link resolver knowledge base which is important, right? And that's, that's huge. You know, for example, if that article, if we know that it's it's a hybrid OA article and you've got it from three aggregators and two publishers and one OA source that is linked to DOJ not doing it, you know, like journal level linking, it's all messed up. Whatever the situation is, none of that matters because we're gonna link you right to the, to the article and the user's not gonna know the difference.

John  (00:42:45):

So that was the other sort of like, part of the evolution of browsing into lip key is that we built an integration into Discovery systems really to promote browsing to, to, to, to make this idea of let's add serendipitous discovery into your discovery system. And so we, you know, we had this integration where you could go in and when you're looking at an article record in all the major vendors, you could click on a link that would then bring you into browsing, and it would show you that article in its published context. So a very cool kinda modality that didn't exist anywhere else. People discovered other articles within that table of contents. We actually tracked the data on that, about eight more clicks was on average after they came into browsing from that modality. So very successful, and that was great.

John  (00:43:34):

But we started getting some feedback from some of our longstanding customers of browsing who said, you know, we've noticed something strange. Sometimes the link doesn't work in our discovery system, but when we link back into browsing and then we click on it, it works. Why is that? And we didn't think what we were trying to do something like, you know, better than other folks or, or more clever or whatever. But we started realizing like, oh, why are they doing that? That's, that, that's, that's silly. Why? Why? You know? And so we started noticing what more of these cracks in, in, in different methodologies. And so we thought, well, why don't we externalize what we're doing in browsing as a linking technology so that you could use it directly, right? You don't have to like, like, you know, whip back into browsing and then, and then do it. And let's just make that a kind of a separate skew for us. And that's what, that's where Lib key came from. But I, I think that, that, you know, that sort of appreciation for hey, here's, here's some other things that we could do to make things better. That's what turned it into a, let's make it its own linking technology.

Rob (00:44:43):

And, and Lipkey is a part of a suite of services, right? It's not just one product or one application that you, that third Iron offers. Maybe you could explain real quick about what other tools that you have available for.

John  (00:45:00):

Yeah, sure. So if I mentioned browsing before and like I say, browsing takes journals that you have subscribed to, creates a curated collection so that it feels like a virtual reading room. That's the kind of gist of it. The other element that you can go a little further with it is that individual researchers and students and so on can make a browsing account, which allows them to take journals that they care about and put them on what we call my bookshelf. They can rearrange that. It's all very graphically intensive. And then we track when new articles come out for those journals. So it's a great way to stay up, stay in touch with your favorite journals and so on. You know, and there's a couple other features there for exporting to lots of different, you know, systems, videographic management and so on.

John  (00:45:45):

But that's what browsing is focused on. Lib Key does have a number of different flavors. It's all sort of the same technology, but there are different integrations, and so we give them different names to make it easier to talk about. You've got the integration into the Discovery vendors, which we call the Key Discovery. And that's in every major system out there, your Primo, your Summon, your eds o clc, TD net, et cetera. And that, that's the one where we take just the raw linking t an entitlement technology, and we make it dynamically appear within those interfaces. So you'll immediately see, oh, this is available and here's a, you know, one click link to the pdf, for example. You know, and PDF linking is a component of Lip key. But it's kinda a minor one, I guess.

John  (00:46:31):

It's, it's it's something that a lot of users told us they really want. So we kind of tried to go the extra mile to say we'll sort out the source selection complexity, but we can also do one click to PDF for most vendors as well, which is very popular. And so that appears dynamically whenever it's available. So it's not like a link resolver where you say, let's click and then see, instead with an api, what we're able to do is dynamically query our, our knowledge base and return it back to the interface before you even notice it. You know, it loads at the same time, the page loads, you don't realize it's an external service. And so libraries can really turbocharge their discovery systems with this very, very quick and easily by integrating Li Key. But that's not the only place, of course, that libraries are linking to their content.

John  (00:47:20):

There's also all of their a and i databases and as well as big third party things like Google Scholar or PubMed, right? Web is science, ebsco, host databases, et cetera. And because of the technology restrictions of those systems, they don't have an a a place where we can insert an API that requires cooperation with vendors and so on. Google isn't famous for lots of cooperation for third party integrations of anything. So instead we're, we developed a variation on the Lip key api, which we call Lip Key Link. And Link looks like a link Resolver. We don't bill it as such. We call it a Link Resolver accelerator. But essentially it sits, right where your link resolver sits in whatever setup system you're, you're dealing with. So Google Scholar for example, so that when you click on on your, the same link you've always been using there, it will first query lip key to see if any of the li Key acceleration stuff can happen.

John  (00:48:18):

So we can produce that one click experience for you, if you'd like that. We have something we called a format chooser, where we've sort of turned the link resolver intermediate screen on its head whereas the intermediate screen usually is saying, here's a bunch of sources, what do you wanna do? And giving that to the user. And, you know, our, our sort of ethos is to say user doesn't care about that, but what they do care about is do we have it? And what source do you want or what, what format do you want it in? So instead of saying it's available at these eight places, we say you've got it, do you want it in PDF or do you wanna see the publisher's page? You know, and which one is important to you? And, you know, for different use cases, PDF is not always the answer for sure, right?

John  (00:48:59):

If you're on a mobile phone, PDF is kinda lousy actually, right? You actually want that nicely formatted html that exists in 2022 that didn't exist in, you know, 2011, right? So you have that, that opportunity. Or maybe you want the ancillary data sets, right? That go with that thing. Well, you're not gonna get that if we send you to the pdf. So we do that with lipkey link. The other two is Li Key Nomad and Nomad is a browser extension, so it's an integration into your web browser. And what this extension does is works with those users who may not be using your library services per se, but have a need for the subscriptions you have access to, right? And that's why we call it the nomad cuz you're not going right to your discovery vendor or your even your library website, but you may be going right to Wiley or you're doing just Google searches.

John  (00:49:51):

Google Scholar never heard of it, right? But I find it, I, I wind up at, at at Wiley, right? That kind of thing. Or I'm at ResearchGate or Wikipedia or I go right to PubMed. There's all these different use cases for that. And so what we're doing is we're analyzing the contents of pages, looking for those identifiers, signaling that there's an article there, and then we're instantly signpost on the screen that yes, you have access at your library, click here, and then we do all the li key magic to get you right to the content immediately. So it's a really, really cool way to do that. Another you know great bit about that is that also that technology allows us to do group policy deployments at your library where your IT team can say, we can push this to every browser on campus.

John  (00:50:37):

We see that very popular in hospitals as well, right? So nobody has to install anything or know what's going on. All of a sudden though, when they're just, you know, go, you know, going around looking at things, being frustrated at paywalls or whatever and they see that article there, they see a little button that says, get it now at, at your institution. And off you go. And, you know, we take you through whatever authentication steps need to happen and get you to that content. The final pieces, lib key io and lib key lib key.io is a destination platform. So you can go right to that web address and it's, some people have kind of built that as like a legal cy hub, cuz it follows a very similar methodology of, here I am, give me a DOI or P M I D and we'll ask you what institution you belong to.

John  (00:51:22):

And you, you tell us, oh, I'm at, you know, Southern California, and then we tell you, yes, you have access to it right here. And then all the li key magic ticks off from there. And so the nice part about that is it's a resolution syntax. So you can do lib key.io/a DOI or a pm i d and all the same stuff will happen. The browser will remember who you were previously. So you're not always like saying, oh, I'm at usc. I'm at usc. So it's very smart about this. And and so we've seen a lot of third party integration with that. So lens.org, semantics scholar, citation Z host of others, all use that technology to greatly increase the amount of content that users can get to in a very simple free way. It's, it's free for them to use.

John  (00:52:07):

We don't license that to them. And so the, the other kind of aspect of that is evolution of the doi.org resolution scheme as well, right? Because one of the things that always frustrated me as an E-Resources person was that people would say, well, I got the DOI for this, so I clicked on it, but, but I don't have access to it. And we're like, well, well, yes you do, but you have to come back to your library website and go through our link resolver and then look up the journal, and then you can go to the journal and you can click on it, it'll go through our proxy server, you see, and then you're gonna have to look up the article again by ne it's like, oh my gosh, no, no, no, no. So there's like way too many things that have to happen.

John  (00:52:44):

So with Live key.io you can resolve that DOI and it's gonna understand your entitlements and it's gonna understand your, you know, open access capabilities, all that as well as your authentication mechanism specific to your institution. And it's gonna build all the links accordingly without having to understand all the library jargon essentially. So, so those are like kind of the four sort of, you know, different integrations or modalities of lip keep. But you can see it all kind of keeps coming back to, we're trying to make this simple, we're trying to hide all the messy bits that libraries deal with all the time and be very user focused to try to say you care about the content, we get it. That's what we're gonna do, do on our end is just, you know, take care of all the technology to get you there.

Rob (00:53:30):

You have always been a library company and from your past occupation as a librarian, you're still a librarian. I've been told you're never not alone.

Rob (00:53:42):

<Laugh>. And it really shows, really shows through in all of your solutions that you, you understand the workflow of the library, you understand that, that mindset of the user and you've created this, this suite of access solutions, which is, which is incredible given how fast technology is moving. And one of those things that, that I noticed that I think you're one of maybe the first to the market with addressing retracted articles. Why, why was that really important to, to Two Third Iron? Was this the inner librarian in you going, this is a terrible No-no, we have to address this. Was it in the, was it in the development? She, for a long time? Why was this something that surfaced? Very,

John  (00:54:26):

Yeah. I mean, especially with, with with Covid you know, some, some really high profile things got retracted, right? That were, everybody was rushing, obviously to try and figure out, you know, what can we do about this, you know, terrible thing. And you know, when, when things move really, really fast, you know, sometimes mistakes happen, right? And and not all retractions are are nefarious, right? You know, I mean, things, mistakes happen and, you know, but, but whether it's nefarious or not when bad science gets out there and bad science is then cited in other science, which would otherwise be good science, you get this proliferation of retraction, of retracted material unbeknownst to those users. And the further it gets away from that and things get built on it, the more like mur it becomes, you know, it becomes much more opaque about, you know, was this re retract was, you know, is this related to things at all?

John  (00:55:30):

And so, you know, I, you know, we had been aware of, of the work that the Retraction watch group has done you know, they've been doing this about 10 years. They're, you know, they're they've, they've been kind of researching the phenomena and and, and not only kind of tracking retractions, but they've also been looking at you know, writing news stories about them. You know, they would say they're journalists, right? They're writing journalistic on, you know you know, investigations about what's go, what's behind different retractions and so on. Because sometimes it would be a onesie, twosie sort of thing, but other times it was, oh, this is a pattern of behavior for this researcher, you know, and the dozens of their papers get pulled, or, you know, I mean, some really kind of scandalous things happen too.

John  (00:56:17):

So they've been putting that together in a database. And and I, and we had had seen that that had been integrated into Terro. So Ter as a, as a citation service had actually integrated with that first, and we thought, oh, that is a cool idea. Because if you're, you know, if you've got your citations in, in Terro or, or other services a lot of times retractions don't happen immediately, right? They happen months if not years later. And so you could find an article and think, wow, this is great. I let stash it away. Maybe I'll cite it, you know, later when it's appropriate. And so this, you know, Zara was able to, as you kind revisit your bibliographies, go, oh, this one that you flagged, you know, a year ago was actually retracted now. And we thought, well, that, that, that's a great use case, right?

John  (00:57:08):

That's a good place to do it. But us as a linking provider seemed like another good responsible way to help with this problem, right, of, of retraction because we observed a number of different scenarios where you can come from a place an index, which has no knowledge that the article that they indexed two years ago is now has a retracted status. And so there's nothing on the screen indicating to you that this is retracted. And then when you click on it depending on where they're linking to their full text content, that full text provider may have no information about retraction in some cases. And I would say in the majority of cases, if you're linking directly to a publisher, the publisher probably has a nice watermark, hopefully on the paper and so on. But there's a lot of other circumstances where you're linking to repositories or you're going to aggregation or to other things where there is no indicator of this.

John  (00:58:12):

And so we thought, well, not only, you know, could we save people time by flagging this right at the moment of discovery, you know, sign posting it in their discovery systems or as soon as they click on that link so they don't have to go all the way down the rabbit hole, get all excited about something, only to find out, oops, it's very retracted, but in other cases, we've completely prevented them from knowing about it, where they would not have at all. So it really came from you know, an interest in, in trying to make science better and and to, you know, kind of help with this, with this issue. I was, I was part of a, a really cool working group that the University of Illinois did talking about the proliferation of retractions and kind of brainstorming different solutions that both kind of the publishing, you know, sector as well as technology sector could do to try and improve this type of thing. And it, so it made a lot of sense for, for our products to be able to, you know, take advantage of this unique position we've got in the in the ecosystem and create some speed bumps for researchers to, to, to to put that in their workflow.

Rob (00:59:19):

Well, we, we expect the best from third iron going forward to so continue all this great development continue really being on the front wave of understanding the trends and publishing and really continuing to delight users. And one last question for you, and it's question coming from conversations with libraries and their struggles, sourcing usage data about open articles and open access. Any thoughts on where the industry's going and more specifically, what and how live key is helping in that particular area?

John  (00:59:59):

Yeah it, it, it's, it's a hard problem to track because it does require that you, that you know about that article level intelligence which is, you know, something that we're uniquely spearheading right now. And so we, we on our end just introduced a tool last month where the, the usage reports that we provide libraries now have a breakdown in the article download section where we're indicating at the time of clicking through to an article, was the article considered open access or not? And it's a, we consider it a temporal measurement because of course status is thing, those things can change over time. But at that time, what was the status? And, and then we're kind of doing the calculations on that. So you could see it for this journal 33% of the downloads were open access or a hundred percent because it was a gold OA title.

John  (01:00:55):

So all of them were and doing a full roll up of that for all of your articles downloaded in a given time period. And we think that this is really gonna be helpful because a lot of libraries will use usage data linking data, et cetera to help inform collection choices, right? You know, how do we build our collections? What do we subscribe to? At what point do journals you know, lack of usage maybe turn into, well, should we still subscribe to this? Or instead, should we move this over to an ill kind of, or an on-demand or a pay per view or some other methodology, right? And up to this point that was totally based on just downloads without any consideration for you know, what is the open access or subscription status of that particular article.

John  (01:01:47):

So this is giving libraries a real world view into their user's behavior at a journal level where they can see, well, maybe 30% of the articles from this are, you know, open access. How does that change my formula for how I do collections? Right? and an important aspect of that, I should, I should add as well, is that when we're doing those calculations and we're working that through the other aspect of open access that's really important to understand is versioning. And at Third Iron, we've taken the stance that if you're gonna be comparing it to subscription material in a hybrid sense, right, in a hybrid journal, it has to be the version of record that it's not a substitute to say, oh, here is a non version of record that you could get instead of the version of record.

John  (01:02:36):

Therefore you should make collections decisions based on this because you're essentially getting something that is you know, potentially inferior. You know, you have your version of record, which of course is the gold standard, it's what was published, et cetera. You've got your accepted version which is usually very, very, very close to the version of record content should be the same. The formatting won't look the same, it won't have that nice, you know, publisher kind of chin on it, but the content and the material should all be there. But there's also submitted manuscript as well which is, is for most folks inferior to either one of those. And most of the kind of open access integrations we've seen to other systems have taken none of that into account, everything is just treated as equal. So, you know, your, your question you know, a time ago where you were saying, is this all the same for an end user in terms of things like hybrid gold, bronze like diamond?

John  (01:03:36):

Yes. But in terms of version, no <laugh>, and that's where things get murky really quickly. But you know, at Third Iron, we're kind of sanitizing all of that to say we're presenting versions of record. And so that way you can have confidence that yes, this is the real deal. I'm not looking at something that hasn't gone through peer review, which is typically the case when you're looking at a submitted versus accepted manuscript and, and that sort of thing. So when you actually look at your you know, analytics from us, keeping in mind that, that we're not talking about things that are in a green repository, that is a submitted manuscript that is not the same, we're talking about apples to apples here in terms of the content,

Rob (01:04:18):

That that was a, a tremendous dive into what seems very similar when libraries are using the live key technology to resolve a very complicated, lots of different lanes, lots of different data, lots of different versions, and thank you for sharing all of that information with us and continue to do great things in this space, continue to develop. And thanks thanks for coming to the Common Sachs podcast.

Heather (01:04:52):

Hey, that was amazing, wasn't it? Thanks for listening everybody, and thanks to John Segui for really digging into everything with us so thoroughly. I told you it was like a masterclass, didn't I? Hop into our community and discuss your takeaways@community.library.com. We have some exciting events going on in the next few weeks. We've got trainings, we've got all kinds of stuff happening, so community dot library lover.com, and also it's free to join. You don't have to be a member of the Library Lover Consortium to join. So just go on over and hop in, and we'd love to see you over there. We'll be back again on this show in a couple of weeks. In the meantime, we'll see you all over the internet. Thanks for listening.