Cadmore media player playing video Business Processes for Sustainable Open Access: Recommended Practices for Institutions, Research Funders, and Publishers
Video Player
Accessibility
Using forms mode, you can utilize keyboard shortcuts to make usability more efficient.
Space bar will play and pause the video. Pressing escape will close all displays and pressing it again will jump to the end of the player.
You can press A to open the Keyboard Shortcut Dialog which also provides an audio description of the player and all of its features.
Language
1x
Play Speed
Adjust Volume
Transcript
Search
Result Count
of
Click to jump to result
Search
Re-center
Segments
Result Count
of
Click to jump to result
Search
Name:
Business Processes for Sustainable Open Access: Recommended Practices for Institutions, Research Funders, and Publishers
Description:
Business Processes for Sustainable Open Access: Recommended Practices for Institutions, Research Funders, and Publishers
Thumbnail URL:
https://cadmoremediastorage.blob.core.windows.net/44e35fc3-22a5-4f3a-b670-4f5ff6b53d8f/videoscrubberimages/Scrubber_1.jpg
Duration:
T00H56M35S
Embed URL:
https://stream.cadmore.media/player/44e35fc3-22a5-4f3a-b670-4f5ff6b53d8f
Content URL:
https://cadmoreoriginalmedia.blob.core.windows.net/44e35fc3-22a5-4f3a-b670-4f5ff6b53d8f/SSP2025 5-29 1600 - Session 3E.mp4?sv=2019-02-02&sr=c&sig=dgxCsTO0ZTe592ziHF6CWRiD0ZlLA9av3g1ueyO%2B0Tk%3D&st=2025-12-05T20%3A54%3A43Z&se=2025-12-05T22%3A59%3A43Z&sp=r
Upload Date:
2025-08-15T00:00:00.0000000
Transcript:
Language: EN.
Segment:0 .
Hi, everyone and welcome. We're excited to talk to you today about business processes for sustainable open access. My name is Mary Beth Barilla. I work for the National information standards organization, and I am joined by our three panelists Howard Ratner, executive director of chorus. Ivana conference executive director of O switchboard.
And Chris Shillam, executive director of orchid. And before we get started, I think by now we're on day two of the conference. You're probably familiar with the code of conduct, but it's just a reminder that we're here to have an exchange of ideas and open dialogue. We are not here to arrest anyone. If you have questions about the code of conduct or witness a violation, please visit sbp's website.
So as I mentioned, I'm from DKNY, so I am the director of business development and communications there. And before we talk about business processes for open access, which is what our NISO working group, some of the members of whom you see here are working on. I wanted to just talk a little bit about NISO and our standards process.
Niso, as many of you probably is a nonprofit member organization that identifies, maintains, and publishes standards for the information community. And our standards are very community driven. So community members are part of the process from beginning to end. They're proposed by community members, commented on by community members, and ultimately approved or not approved by members of our community.
And the standards and the hard work that goes into developing standards is done largely by our working group members who are volunteers. We have 300 volunteers from libraries, publishing organizations, technology providers, et cetera, three of whom you see right here. And if anyone is interested in learning more about NISO or working on standards, I encourage you to get in touch with me or another staff member.
So the recommended practice we're talking about today is open access business processes. I said NISO develop standards. What is the difference between a standard and a recommended practice. And they're similar in many ways. The difference is simply that standards go through a more formal approval process.
There tends to be more consensus around the steps required to be compliant with the standard, and indeed, you have to follow everything in the standard to be considered compliant. Some examples of standards. I put some classics up there. Dublin Core metadata, the journal article tag suite, which you might have heard of and more recently, the peer review terminology standard.
Recommended practices are, as the name suggests, recommendations. So you may choose among which recommendations you want to follow. They tend to cover more emerging areas where there's not quite so much a firm consensus about the actual process. Some of our recommended practices, we've got two older ones up there cabart, which is currently under revision.
The transfer code of practice also recently revised and opened for public comment. And then the recently published communication of retractions, removals and expressions of concern. So that's just a little background again, on the standards process. Give you an idea of what we're trying to do here with this particular working group, and I'm now going to turn it over to one of the committee members, Howard.
Thank you. Great well welcome everybody. So my job here is to give a bit of background on this particular working group that we're involved with. First of all, I'm going to take no credit in leading this. Yvonne actually is one of the ones of the co-chair of this group. I was just a mere participant in it, but they've given me the honor of this background bit.
So I'll do it here. So first of all, like, why did we do this. Well, we felt that now was an important time because we all know that publishing has been moving towards a right. It's opening up research to the world. The research funders and institutions are requiring this more and more. The models themselves, we've seen over the last 10, 15 years. What you have become increasingly complex and very diverse.
We've also seen that as this has progressed, we've been moving from a journal level business process to an article level process. And then finally, we see the funders, institutions, and publishers are they've got this ever-growing list of systems and different metadata that they have to interact with. And so we felt that now is a really an important time for us to try to solidify this so we can make it easier.
Well, whenever you talk about these kinds of things talk about pain points. One of the most famous consulting words, right. What's your pain point. So in here we talk about complexity as being a pain point. The fact that there's interaction with many different systems, the lack of interoperability between those systems.
The missing connections that relate to how the research connects to actually the systems themselves, else how the researchers are being asked to enter this information again and again and again. And then they honestly, they resent it. And then specifically, there are lots of things about the author journey, and there's a whole list here that you can read for yourself.
But ultimately, when you look at it, this is all about the processes are inefficient. They're costly for what we do. And ultimately it's hampering the work that we all want to do and make it much more efficient because we want to make it better. So we came up with this problem statement. So gathering all that together, and we basically said we want this to be about transitioning from to pay to read to pay.
We want this to be about the policies and mandates that are shifting from authors, libraries, institutions, publishers, consortia and research funders. All of that needs to be in the problem statement. We need to address all of that, not just one contingent. We want to make sure that it's not just about our current infrastructure standards, but we want to make sure that it fits whatever the new world might be as we approach it.
And then lastly, we want to make sure that this works for the individual solutions for librarians and publishers and understand that many of them are not going to be very sophisticated. And there could be manual work and legacy workflows and systems that this will eventually need to interact with. So ultimately, we felt that there was a development that needed to be done right. We wanted to facilitate and catalyze a variety of established and emerging business models.
We wanted to enable financial transactions in a much more efficient manner. We wanted to track deal and policy compliance and make that much more efficient. And we also ultimately wanted to optimize that related workflow. So that working group has developed. And I can think we can say now that we've actually developed it, we've developed a recommended practice to enable the operationalizing.
That's a very big word of oh, business practice processes for authors, librarians, institutions, publishers, consortia, funding agencies, and other relevant stakeholders. I'm going to stop talking here because I think the meat that you're going to hear from Yvonne is really going to show all the heavy lifting that's been done by this group.
Thanks, Mary Beth and Howard, and I'm really excited to be here at this stage of our work, of our project. As Mary Beth says, this is a community effort. I'll show you even the names of all the people who've worked on this so far. And it's been quite a journey and we're really proud and happy and excited to share with you where we are because we're on the verge of opening the public comment period.
And we're very, very, very keen to hear from you. So please be ready, be prepared to really review the work that we've done, because there's a lot of stakeholders to serve in this initiative. And I'm really glad you're all here in such large numbers to hear about it right now. My name is Ivan Kempf. And day to day I'm working for the Au switchboard. And in that capacity, I actually get asked and I'm in contact with a lot of consortia, universities, publishers, funders, vendors, infrastructure providers.
And throughout this project I get got asked so much about the work that this group is doing and an eagerness and and a question for what we would deliver and if we would please. And I don't want to give away everything, but if we please come up with a glossary and definitions. And if possible, some kind of schema, and I can tell you that's what Chris is going to talk about, because that is the meat and bone of what we've worked on.
Howard was already mentioned it inefficiencies to a large extent have to do with interoperability. And in order to serve that, to support that need to have systems, especially if it's from different companies. And vendors and organizations, to be able to speak to each other. And these deliverables were defined early on. It's kind of funny.
It was quite a bit of a journey to by the way, I'm co-chair together with Amanda Holmes from CRCN. And again, I'll list all the names of all the people who've worked on it so far. It was quite a bit of journey in the order in which we would do this, identifying the problems, as Howard mentioned, the people who came up with the proposal to Nasa to do this work already had an idea. And actually, these deliverables are from a year and a half back.
And I think we've come pretty close in delivering this. So in that list of the original proposal was that this group would come up with a glossary of standard terms, a standardized data dictionary for the use of OE processes, a report on infrastructure gaps and recommended tools and best practices. And here we now. I won't go there yet.
I won't go there as of yet. So that was the brief and what we were working towards. Now quite important. Of course, a project like this with high expectations and high need from the ecosystem, we had to be careful that we would deliver. And I think Amanda and I have really tried to run it like an agile.
Project and we've given ourselves the deadline. Or actually, I think the ambition of. ISO projects is to do it within 18 months. And we said, yeah, that's going to be the determining factor. And if we can't get the work done, then things will have to move to a phase Ii. The industry, the ecosystem is waiting for this. So what is determining is the year and a half and we will deliver.
And again, if we're running out of time or topics are too complicated, they will have to be addressed later. So the scope was Howard mentioned, it provides guidance for standardized business processes across diverse business models. That is quite important. It's not only about read and publish APCs transformative agreements at all.
We are very much aware and we've tried to cover that. Although in all honesty, a lot of the day to day challenges are around these kind of deals. And so we had to recognize that as well. It spends a life cycle. Actually, we've gone a bit further. Again, Chris will probably talk about that. We have also looked at the research cycle awards assignment grant application, because quite some inefficiencies and problems stem from things that could be recommended to do differently at that stage.
And it's filtering through and runs into or brings challenges later on and goes all the way through publication and reporting very clearly. And we had quite some debates. We did decide to be able to deliver something meaningful to I wouldn't even say limit, but to stick to journals and don't go into proceedings and books in this phase. That could be expanded in a later stage. So to manage your expectations.
We have only worked on journals so far, and also quite a bit of discussion was about inequity in the system and especially around APC based models. And we acknowledged it, but we had to decide that it's outside the scope of this process project. Remember this is recommended practices for business processes. And we couldn't take the challenge of saying anything about the inequities.
We did want to acknowledge it. We have it in the text, but we are not making any recommendations there. Now, who's been working on the recommended practice. Take a careful look. This was my first an ISO project and I understand people were invited. Now, I know people were invited to join the working group and it was incredibly oversubscribed.
If that's the word to use. So many people from all different angles in our ecosystem, volunteered to work on this, which was awesome. It was also super difficult. We had to turn people down. So again, the invitation to really now participate in the public review is an open invitation to all of you to join in and contribute at this point. I think we managed to truly have representatives from all the different stakeholder groups, from funders to publishers, institutions, consortia, vendors, infrastructure providers, and it's been an amazing group of people that have worked on this for a year and a half.
So my largest part of know before we go there. Just anecdotal or quite an important point. And Mary Beth already talked about standards and recommended practices. And if you're new to that, we have had quite some debate, as you can imagine, with such a diverse group of people about yeah, this sounds really good. And yeah, this other stakeholder, I'm a librarian and I really think the publisher should be doing this, that and the other and the other way around, publishers thinking that institutions should be doing certain things or submission systems should be doing certain things.
So it was quite interesting. And entertaining to have these lively discussions with each other. And one element I want to pull out the question that came up, would this recommended practice maybe be too aspirational. Or how pragmatic or how realistic are we. Are we going to be. And the question also was raised, are publishers going to be judged on how they're compliant with this.
Well, I'm mentioning it because that's not the point. It's a recommended practice. It's aspirational. It should be common sense and there is no element whatsoever about compliance. It is really up to all the stakeholders to hopefully take what we've done and see that it makes sense and understand how hopefully we together have made it visible, how certain recommendations will contribute.
And how they have a trickle on effect and that you hopefully would want to do it. Whether you're an institution or a publisher or an infrastructure provider. So maybe there will be questions about that later on. But I wanted to share that has been a big point. And actually still coming up while we're finalizing. Isn't that too strong. Should it be must or should it be ought to.
And we're getting guidance from ISO on how you write these sort of things. It is a recommended practice. Yeah And I stress again that again in my day to day work I get asked a lot about this. People are waiting for this, so it's very exciting for us to put it out. Now really, what have we been working on and how long.
It's been over a year and a half. Again, these 18 months have been really driving us. So we started in December 23 when the working group really got together in its first shape and form, getting to know each other, understanding who. We've done some exercises. Amanda had this great exercise with the colored hats. Maybe people remember. Some people have a tendency to always see problems.
Some people have a tendency to only see opportunities. Some people are into the details. Some people are more like philosophical and strategic and having a group of what is it, 24 people. It was really good, actually, to be reminded that people have a different way of looking at things when we're addressing this wide range of topics and challenges. So we split up actually in subgroups and kind of in parallel.
Initially we've worked on three topics. Current business models to set the scene. You can imagine we have to describe what is currently the situation. Remember one of the deliverables gaps in the current infrastructure ecosystem. I'll get to that on the next slide. Then we did start and that was a fun exercise. I was part of that group myself.
We really, really started with a long list and everybody could contribute from their point of view as a librarian, as a publisher, as a infrastructure or submission system provider with terms and terminology. And I think I'm probably exaggerating. I'm looking at the man next to me. But we have 48 definitions of corresponding author. No, not that many. But anyway.
Oh, a responsible I can go on. It was fascinating to see and that was a really, really good exercise. So we've really made a long list of anything anybody could have thought about. And of course, while doing the exercise you would think, oh, but that's the same as this one, just a different label. So maybe in the library community, this is a way to refer to it, or maybe in the US, this is the way you talk about that.
So we did really went all the way and made a huge list of terms and definitions that working group who worked on that for quite a while. And this one I'm going to read to you because this is draft text from the recommended practice, but I think it's important to get it across the status quo of the workflows. We had three subgroups working on the author, the publisher, and the library point of view.
So I'm sorry for reading it, but I think it's better I give you the right context. So in the course of its work, the working group formed groups in which project members visualized high level status quo workflows from the perspective of authors, libraries and publishers. On the basis of these workflows, members identified challenges in workflows as currently practiced, and from this list. The group members then voted on the most acute challenges in open access workflows as they experienced them, and on the basis of these results, the working group clustered these challenges based on similarity, and this work serves as the foundation for the gap analysis.
So actually, all those three subgroups that we started with in parallel have fed into the gaps, the gap analysis, the gaps in current infrastructure. And from that pre work, it's kind of been a sequential process of subgroups and working groups. And coming back together in the plenary group, the gaps in current infrastructure. And I think it's quite relevant to actually list what we found there, because the actual recommendations for tools and practices are, of course, built on this.
So what we voted and found to be the most important, the first one in terms of technical and metadata. A lack of data standards to support efficient transfer between actors in the scholarly communication ecosystems at various stages in the workflow. So I was mentioning it already at the beginning, this interoperability and the way to get data across throughout the process, through different systems, different vendors, you need to have a language and you have to have a way to facilitate the transfer of these metadata.
That's one. Second, difficulty disambiguating and verifying institutional affiliations and research funders and awards grants on the basis of information contained in free text fields and/or under utilization of existing infrastructure and PIDs to support publication workflows. That is the second big one under technical and metadata, and the third one the inability in many systems to model multi-payer transactions authors with multiple and changing affiliations and integrate with other systems.
So these are the biggest gaps and findings and problems relating to metadata and technical. And this is currently hindering the lack or this is currently hindering and the lack of a unified conceptual data schema and common vocabulary, a set of agreed upon practices optimizing usage of persistent identifiers and common vocabulary among all actors in the scholarly ecosystem. Second one is communication. It's of a different nature, because what we mean with that is that many business processes are face challenges, or even fail due to a lack of agreement between the actors in the scholarly publishing space as to who is responsible for communicating what information, in what form, when, and to whom.
It's basics of communication. But it is an issue. I'll give you some examples. First, communicating potential open access publishing charges and opportunities for authors throughout the publication lifecycle. Second, communicating authors eligibility for different institutional publishing agreements in light of different author roles corresponding at different stages in the process.
Third, very important came across communicating open access licensing options and consequences to authors, including for the purpose of meeting research funder mandates. And that was also a big point coming up. And again, I said it. It's not only about transformative agreements or APCs, it's also about funder mandates and requirements that authors need to comply with, that publishers in their business processes need to deal with and be able to deal with.
And the meaning of different dates publication date, submission date, approval dates, payment dates, whatever these sort of things. And then the third one is we have a big debate still, whether that's a gap or something to be aware of and deal with in the current state. Scholarly publishing is a global ecosystem consisting of actors operating in a variant, locally contingent circumstances, and as a result, a wide range of boutique agreements exist that are tailored to the needs of unique institutional and commercial interests between parties who enter into agreements.
Secondly, the relationship between publishers and individual titles like society titles and thirdly, the requirements of specific funders in a specific country and a specific situation. So I understand I need to speed up, but this is the meat and bone of how we got to the recommendations. And I promise you to also say a little bit about business models, but I won't be too much because we were very fortunate that there was previous work done by Tasha Cohen, and the working group has reviewed it and has made some statements about how our working group would deal with business models, as already mentioned in the introduction.
We should be agnostic and independent and be prepared for the future. So what we've done in this subgroup is acknowledged that there's a great many open access business models and that again, for this recommended practice, we've adopted this classification scheme that has been worked on before and has been published. And very importantly, we've used it as a checklist, as a reference.
We're still checking all the recommendations and the data schema against these business models. But they're not prescriptive. They're descriptive and setting the scene for us to make sure that we've not forgotten anything and that hopefully we are catering for all these business models with our recommendations. And with that, I'm handing it over to Chris.
Thanks, Ivana. So I have the nice job of talking a little bit about what we've actually done, and I'm not going to go into a lot of detail here because we want to encourage you to reach to read the draft and comment on it, which will be out in a few weeks. But essentially, our recommendations are structured along the lines of three core business processes that we've identified that typically are used to fulfill or finalize transactions.
First being our agreements. Not every one of those business models that Ivana mentioned uses an agreement. Some of them are more transactional, but many of them do, and many of them are very complex. And it turns out from the work of the committee members, many of whom have been on the painful end, both sides of trying to implement these agreements are currently very, very difficult. So each of our three business process cycles have recommendations for different actors or stakeholder groups.
For OE agreements, those actors are consortia, institutions, and publishers. And here we're not recommending what should be included in an agreement in absolute terms. That's not our job to constrain OE agreements. There has been enormous creativity in the way that these deals are structured. I'm sure that will continue. What we're instead recommending on a meta level is the kinds of things that you should cover in an agreement in order to make it implementable.
And again, I'm not going to go into a lot of detail here, but it turns out a lot of the difficulty is around the rules for eligibility of a publication, which, as we've focused on journals, which articles are covered under an agreement that needs to be defined very precisely in order to avoid a lot of the manual back and forth or uncertainty that folks implementing these agreements have experienced.
Also, there needs to be clear definition of the responsibilities for implementation and operation of the agreement. And I think it's probably true to say a lot of these agreements have been developed by creative business folks rather than systems implementation and operations folks. So it's very important that there's sufficient detail in the agreements about how they should be implemented, who should do what and when.
A couple of other pitfalls that we've heard a lot about are pain points and change mechanisms. What happens when an author changes affiliation between submission and publication. What happens when a journal moves publisher in the middle of a publication of an article. Again, we're not saying what should happen. We're saying that an agreement should specify what should happen.
And then also very important is reporting mechanisms. The second one of those business cycles or process cycles, which turns out to be important is funding applications. And the connection here with OI agreements. Obviously, there are a lot of funders have mandates. They want specific ways in which publications should be handled, licensed, et cetera, in order to allow funding to be used for the publication charges.
And again, eligibility is often dependent on who funded the publication, the research that went into the publication. So here we're providing clear research, clear guidance both for researchers and funders. And it's specifically around capturing dissemination of the key metadata about researchers affiliations and the funding that they receive. And when we say clear, this needs to be unambiguous, which is why we also heavily recommend the consistent use of PIDs persistent identifiers so that you can reference the particular researcher, their particular affiliation and the funder, and the specific funding award.
The last and maybe the most expected of the research cycle is actually the publication process all the way from initial submission, or in fact, all the way from selection of journal. We have some recommendations about that all the way through to reporting about the final publication. Here we have recommendations for consortia, institutions, publishers and also vendors of the systems that publishers and institutions use.
We have proposed that they provide clear guidance to researchers on both institutional and publisher policies. And it turns out that sometimes researchers have to contend with both of those things they're trying to understand what the publisher is requiring of them in order to qualify for or choose an OA model. But often institutions have in some cases more fine grained requirements.
So we've specified some recommendations for best practice workflows, particularly around the problem of getting the authors to unambiguously submit or indicate their affiliation and their funding, and capturing that accurately during the submission process. Again, capture and dissemination of the key metadata, in this case about researchers their affiliations. Again, the metadata of the publication itself and again, consistent use of PIDs.
You can read about that in a lot of detail when the draft comes out for review. The second thing, which we spent a lot of time on in the working group that evonna mentioned, is what we've ended up calling a data dictionary. A lot of debate about what this was. It started out as a glossary. Then it was a schema. Is it an I spec.
For those of you who have data modeling somewhere in your background, it's somewhere in between. It's what's called a data dictionary. And the aim here is to standardize and define all of the data elements, metadata elements that we have learned that are typically needed in order to accurately and precisely process our business transactions. So the use cases for this data dictionary, this is not an API spec or a specific reporting format or a database schema, but it defines the data elements that tech folks might want to take and use in any of those things.
It turns out that there are 132 data elements that we have discovered and needed in our business processes, not all of them in every process, but that's quite a surprising number, and I think that partly explains why currently we're struggling as a community with these processes, because there's a lot of complexity. And there's a lot of metadata required in order to accurately process these transactions.
When we say data dictionary, there's a definition for each of these 132 elements. And then some classical data modeling things like the data type cardinality. Whether you need 0 one more must have optional elements and what's called the grammar. So a lot of this is hierarchical data. So which data element contains other data elements. We've used JSON as the underlying set of data primitives.
That's quite simple, but most technical implementations are using JSON data models these days. And we have tried to reuse work from other projects and definitions from other schemas where possible, including NISO, jats, the tag suite, NISO journal article versions NISO access and licensing indicators and the credit taxonomy. I won't go into a lot of detail on the design of this, but essentially the top level object in this model is what we call an OA transaction.
And then below that, we define data structures for the publication funding decision. The OA agreement. We're not trying to technically model our agreements in machine language. We're just trying to make sure you reference them accurately. The way in which a particular article is matched to an agreement, the charges involved, the invoice, who's paying for it.
And then there's a lot of publication metadata. A couple of key things have turned out to be, again, major pain points. The need to distinguish in the metadata between the roles of authors and publication corresponding author, first author, last author, all that normal stuff and the roles of authors in being eligible for funding. There's a lot of conflation in that. Currently, those two things are related, but that's what the eligibility rules should define.
And then when you're exchanging data, they should be described differently and similarly. And Yvonne has hammered this into me after many, many discussions to be clear about research funding. Funders who issue the grants for the research and publication funding because sometimes they're the same, but often they're not. And it's very easy to conflate those. So again, lots to look at.
This is something we encourage your technical folks to look at, as well as business folks and operations folks when it's reviewed. And with that, I'll hand back to Yvonne. Thanks, Chris. And I think you said something really important at the end that there is probably different people in your organization who want to look at different elements of this recommended practice, and I can't repeat and stress enough what Chris was saying.
Please, please, please ask your data architect, your super techie people. Maybe it's yourself, but ask them to look at those 132 elements and be super critical, because I think as well, I don't even think as I mentioned, this is going to be critical in being able to achieve interoperability and sound exchange and transfer of metadata throughout the workflows and the processes.
So what's next. This is the last slide. And then I think we have 20 minutes for Q&A and discussion. Perfect timing right. So what's happening. The data's been deadly and we're working towards it. We're almost there. We're at the stage where technical editor is helping us to really turn it into the final acceptable mandated NISO format.
So it's really the last bits and pieces. We feel we've done all the work. It's really getting the text ready for the public review, public comment period, which is the end of June. I think we need another four weeks, to be quite honest. But it's June and it is officially 45 days. If you have questions about how technically this review process works and how you can comment and how about it in the Q&A, I'm sure Mary Beth can say more about it.
This is my first time doing it, but it's 45 days and it's a standard process for NISO working groups to go out for public comment. And then we're back onto it. And some of us hope we get a lot of response and interest and feedback. And to be honest, secretly I hope we don't get a lot because we will need to then process everything.
This is not a discouragement to participate, but I hope we've done our work well and actually that we can keep the momentum going. Because as I said, we're getting a lot of questions for it to be published, and it can only be published after we as a working group have again processed all your feedback. So if you're giving feedback, please be specific. Be realistic.
If you want to have a debate or a conversation, pick up the phone. We're happy to talk to you, but in the formal form, please try to absolutely make your point, but in a clear and consistent way. Then my understanding is that after we as a working group have processed all your feedback, it goes back to one of these committees for sign off. And then hopefully.
But it all depends on how much work it is. Q4 is when officially it the recommended practice will be published. But I'm inviting you now for the 10th time, have a look at the recommended practice because then basically what's in unless we got it completely off and completely wrong. I think by participating in the review process, you have a good feel of what we've done.
So you can imagine it's very exciting for us. And yeah, really are invited. And please, please review what we've done so that we can hopefully as an ecosystem, make some steps forward and by maybe some small steps and logical, pragmatic recommendations achieve some more efficiency and smooth experiences for all. Thank you so much.
OK, so we are in the question and answer period. And I shall ask you a question first, or shall we invite the audience. How do you feel. Yes, does. Would anyone like to ask a question. OK, great. Yes thank you. And please tell us who you are.
If you don't mind. Hi Colin Adcock from the APPS. Thank you for this. And I'm looking forward to this, as Yvonne very much knows. I have a question about the data fields and the plans with published articles and Crossref. Is all of this going to be in crossref? Are some of them going to be in crossref? What do you think.
Well so the metadata about the publication is key. And that's the kind of information that's in Crossref. I mean, I think probably Yvonne can talk about this better than I can, but there's a thing called the switchboard, right, which is much more around transactional process, the point to point process of communicating status. So there's a lot of this that's sits around what data needs to go back and forth in the process of getting to the final publication.
I think the data that describes the publication of an article in its final state as an array is already pretty well defined. That's the NISO standard. And I think it's pretty well supported in Crossref. So it turns out that the final status metadata is a lot simpler than all the metadata you need in the communication between the three parties the publisher, the authors, institutions, and the funders.
It makes sense. I was just going to ask specifically about the corresponding author angle, and I think everyone's going to answer this call in, and I know each other. Yeah but also I want to make the point about reverse engineering. And I can't speak for Crossref, but I can speak for the switchboard.
And Chris was very kind indeed, to mention quite a lot of resources and former projects and initiatives having fed into this isec jisc, H2020 switchboard, C. I think we had 12 or whatever. But the exciting or the exciting, the challenge is that when this recommended practice comes out and you've all looked at it, I expect, and I'm speaking for the switchboard, we need to I think you used the word or used the word we will need to reverse engineer.
I mean, I expect absolutely that we are going to have to want to update our schema in switchboard. And again, I can't speak for Crossref, but I would not be surprised with all these new insights and stuff that we've done that there will also be a couple of data fields or things that Crossref might want to amend as nodding. Yeah so just one of the things I'll add is that there are many fields in Crossref that are open, and you can add whatever you want or they're optional.
So one of the things that this recommended practice will do is as you're working through that and deciding what you want to fill out, what you don't want to fill out, it'll give you some standard ways to fill these fields out and to express them in a way that others will expect to see them later on. Just specifically on the corresponding author things. This is a hobby horse of mine, so I think it's often the case that in the definition of agreements, the concept of corresponding author has been used as the basis for eligibility that the corresponding authors affiliation.
And that's created all kinds of their knock on effects like, well, now we have to have multiple corresponding authors, and now we have to have a submitting author. And quite frankly, it's a mess. And we're not saying that your eligibility rules should change. We're saying that they must be written down clearly and unambiguously in the agreement. And there's an eligibility matching process that says, based on the rules in the agreement, this author is what we're calling the responsible author.
And once you've done that matching, that's a semantically separate piece of information that you need to preserve and tag separately. So in the downstream messages you'll and you'll see in the data dictionary, there's a separate way of tagging a corresponding author from an or a responsible author. Often they may be the same. Sometimes they're not.
The important thing is once you figure that out through the evaluation of eligibility rules to tag them separately, you see, we get carried away. We're so excited. But this is such an important topic. What nobody none of US has mentioned, which is in the recommendations, which I thought was such a no brainer, such a brilliant suggestion, and how Chris helped me again.
Deal sheet. Yeah, I never know. Yeah, yeah. Which is a common concept in all kinds of other legal negotiations. But the idea is that there should be a summary sheet, one page, the top cover of an agreement that specifies the key terms. And also that should be shared as much as it can be shared.
So that authors who are trying to navigate all of this understands what has been agreed, and whether they might be eligible. And so that the systems, people or the vendors can actually implement and support these wonderful deals that smart business people have made. Now, I thought that was a brilliant suggestion. And again, like Chris says, that happens in all kind of other industries and contracts.
You just have a semi layman's summary of the deal so that people who need to operationalize it know what you're talking about. Amanda thank you so much. I am a member of the working group. I am also staff at Crossref and I wanted to specifically mention this to everybody, not just to Colin, because Crossref is actually calling for members for its metadata advisory board right now.
And the deadline for that is May 31. So if you go to the Crossref blog, there is a call there with an application for members of the metadata advisory board. So that's one thing. But I will also say that I think you're exactly right that these recommendations are going to come out before that next version of the Crossref schema comes out.
That next version is, I'm almost certain, 5.5 I can't quite don't quote me on the numbers, but I do know that specifically in the next schema of Crossref, we are planning enhanced support for multiple roles specifically credit, but also potentially I think, corresponding author type of thing. So I think the timing of it is perfect because at least the draft of this will come out before that next Crossref schema comes out.
So Colin, you have the ability to say these things on the metadata advisory board and so does everybody else at Crossref. So thanks, Amanda. Good to see that. All sides of the room. Anyone else with questions. What OK.
So I'll ask my question. And maybe this will help everyone visualize the impact of this recommended practice. But I wanted to ask each one of you how you envision this recommended practice being used, how is it going to change people's lives and looks like Howard wants to answer. So I'm going to pass the mic to Howard. Yeah, so I'm a big guy that believes in practical solutions.
I'm actually not a big standard guy for the region of standards. There are many, many standards that just sit on shelves. So as soon as. Yes, sorry, that is true. So as soon as this comes out and you're going to review this, I really recommend that you really think about what you will do with this. So if you're an institution, how are you going to put this into your contracts as an example right at chorus.
What am I going to do with this. Well, I'm going to take some of the data that on those fields, right. And match them up to exactly to what I have already in existence in my existing system. Do I want to map them. Do I want to make a change. Is it an improvement. Is it too much of a normalization.
These are the things I will need to do as a technology provider, but I think each group will need to do it for themselves. Yeah now with my head of the switchboard on what we are for instance, and we're going to do things on the publisher side as well. But on the library consortia side, we're increasingly building integrations, or actually the other parties are building integrations to receive standardized data across many publishers into their systems, just to name two, to make it specific.
Consortium manager. Actually, I'm going to name three consortium manager being used by 60 plus consortia around the world. How rossovich focus traditional subscription agent with a system called focus being used in libraries, where it's combining subscription and invoice and historical data with Article level metadata coming out of switchboard and chronos hub providing also solutions to consortia.
So what we are going to do is indeed, like Howard says, and I think it's not simple, but as basic as this is to map the data fields. So if in switchboard this field we're using for corresponding author or for publication date, we're going to sit down again with these receiving systems that are being used with libraries and consortia and make sure that the data we're spitting out at the moment, on behalf of 37 publishers end up in the right data fields with these systems that are being used by libraries and consortia and what have you.
So to make it really specific and pragmatic, that's what we're going to do tomorrow when this is out. And these are the parties that I mentioned when they amongst others are asking for this to come out to avoid data confusion and yeah, do it right. Yeah and I think I would hope that we can through implementation of this standard in infrastructure and vendor tools, dramatically reduce the amount of manual effort that's being taken to process and handle deals at the moment because if you think about the traditional model of subscription publishing, there's probably hundreds years of established practice of knowing how to do that.
Systems, intermediaries, playing roles that make it all work smoothly. Oh, is not like that today. It's a cottage industry where most of the work is people pushing around and manually dealing with spreadsheets and sending emails to each other. And given all the other challenges that we're facing as an industry, the financial pressure, the integrity, pressure, there are so many better things we could be doing than filling in manual spreadsheets to ensure that only transactions get processed correctly.
So I think in some ways, this is a classic many to many problem which we've tackled and solved as an industry before. We've got librarians who are dealing with information coming at them from many different publishers in many different formats. We've got publishers who were trying to meet the needs of many different customers and many different ways. It's a classic case of inefficiency.
Systems like the switchboard, the other infrastructure providers that Ivana mentioned, they think over time will exist to solve this problem, standardize this process, and we can all move on to more interesting, useful, and value added work. Thank you. Panel so check with the audience again just to see if that's given rise to any questions.
OK, I have another question. What barriers, if any, do you foresee in terms of adoption of the recommended practice. Anyone want to answer that first. I think in some ways, it's the classic collective action problem. So for this to be useful, many individual people and organizations have got to take steps to implement.
And I think that's why the implementation journey. Ivana, you've talked about everybody who has a stake in this, who has a role to play. Looking at what do I need to do to change my systems, my processes, my practices to align this. And that's always a challenge. And again, we as an industry, we do have a track record of solving those challenges in the past. I'm sure we can do it again.
Yeah, maybe. Related to that, maybe not being able to do enough about awareness and making it simple and communicating and getting the word out because it might be scary or big, or people might think it won't make a difference if they don't do everything. But I think the communication, the training. And I was talking to Todd Carpenter from NISO about that yesterday, that might actually be an area where maybe collectively we can get some grants or some maybe an invitation to somebody in the room.
If there's organizations who sit on funds and who have money, who feel that this is indeed a collective action that we should all be working on attending. And again, even though our working group, we try to have representation from everybody. You saw that there's hardly any there's nobody from Asia or Australia. There was, of course difficult with the time as well. But our world is not limited to the US and Europe.
So the getting the word out awareness training will cost money. So I think maybe. What was your question. A risk or a limitation or a barrier is if we're not able to get the word out and to reassure people that every small step helps. I'm going to flip it and not talk about a barrier, but one of the themes that we've been hearing here at SSP is about creating the right personal narrative.
So this is a perfect case. So what are the after somebody has gone through the throes of trying to implement this, create that narrative about that successful story. And by the way, it could be a bumpy story, but as people can relate to success. So I think Chris is right that being that first mover is always going to be that tough barrier. We found that in every initiative, every persistent identifier I've ever dealt with is the first one is always on that bleeding edge.
Who's going to do that. We'll find somebody that will do it. I think people on this panel I'm sure will help do it. But once you've done that, create the narrative and then spread it wide and as deep as possible. And I think for me, that's how you're going to get some success and some traction. Thank you. I think we still have time if anyone wants to chime in or comment.
Just a reminder, we will announce this broadly when it's available in draft. You can always sign up for NISO announcements to get those right in your inbox, but you can follow us on social media. We will issue a press release, and then that will be the time when everyone has 45 days to take a look and add any comments, see if anything is missing or have anything else to raise.
And in the meantime, I do want to thank so much. I mean, again, going back to what I said about our work being community driven and relying on volunteers. Thank you so much to our working group co-chairs, Ivana and also Amanda Holmes, who isn't with us, and group members Chris Howard, Amanda, anyone else. Anyone else in the room who's on an ISO working group. Thank you so much.
Thank you.
Segment:0 .
Hi, everyone and welcome. We're excited to talk to you today about business processes for sustainable open access. My name is Mary Beth Barilla. I work for the National information standards organization, and I am joined by our three panelists Howard Ratner, executive director of chorus. Ivana conference executive director of O switchboard.
And Chris Shillam, executive director of orchid. And before we get started, I think by now we're on day two of the conference. You're probably familiar with the code of conduct, but it's just a reminder that we're here to have an exchange of ideas and open dialogue. We are not here to arrest anyone. If you have questions about the code of conduct or witness a violation, please visit sbp's website.
So as I mentioned, I'm from DKNY, so I am the director of business development and communications there. And before we talk about business processes for open access, which is what our NISO working group, some of the members of whom you see here are working on. I wanted to just talk a little bit about NISO and our standards process.
Niso, as many of you probably is a nonprofit member organization that identifies, maintains, and publishes standards for the information community. And our standards are very community driven. So community members are part of the process from beginning to end. They're proposed by community members, commented on by community members, and ultimately approved or not approved by members of our community.
And the standards and the hard work that goes into developing standards is done largely by our working group members who are volunteers. We have 300 volunteers from libraries, publishing organizations, technology providers, et cetera, three of whom you see right here. And if anyone is interested in learning more about NISO or working on standards, I encourage you to get in touch with me or another staff member.
So the recommended practice we're talking about today is open access business processes. I said NISO develop standards. What is the difference between a standard and a recommended practice. And they're similar in many ways. The difference is simply that standards go through a more formal approval process.
There tends to be more consensus around the steps required to be compliant with the standard, and indeed, you have to follow everything in the standard to be considered compliant. Some examples of standards. I put some classics up there. Dublin Core metadata, the journal article tag suite, which you might have heard of and more recently, the peer review terminology standard.
Recommended practices are, as the name suggests, recommendations. So you may choose among which recommendations you want to follow. They tend to cover more emerging areas where there's not quite so much a firm consensus about the actual process. Some of our recommended practices, we've got two older ones up there cabart, which is currently under revision.
The transfer code of practice also recently revised and opened for public comment. And then the recently published communication of retractions, removals and expressions of concern. So that's just a little background again, on the standards process. Give you an idea of what we're trying to do here with this particular working group, and I'm now going to turn it over to one of the committee members, Howard.
Thank you. Great well welcome everybody. So my job here is to give a bit of background on this particular working group that we're involved with. First of all, I'm going to take no credit in leading this. Yvonne actually is one of the ones of the co-chair of this group. I was just a mere participant in it, but they've given me the honor of this background bit.
So I'll do it here. So first of all, like, why did we do this. Well, we felt that now was an important time because we all know that publishing has been moving towards a right. It's opening up research to the world. The research funders and institutions are requiring this more and more. The models themselves, we've seen over the last 10, 15 years. What you have become increasingly complex and very diverse.
We've also seen that as this has progressed, we've been moving from a journal level business process to an article level process. And then finally, we see the funders, institutions, and publishers are they've got this ever-growing list of systems and different metadata that they have to interact with. And so we felt that now is a really an important time for us to try to solidify this so we can make it easier.
Well, whenever you talk about these kinds of things talk about pain points. One of the most famous consulting words, right. What's your pain point. So in here we talk about complexity as being a pain point. The fact that there's interaction with many different systems, the lack of interoperability between those systems.
The missing connections that relate to how the research connects to actually the systems themselves, else how the researchers are being asked to enter this information again and again and again. And then they honestly, they resent it. And then specifically, there are lots of things about the author journey, and there's a whole list here that you can read for yourself.
But ultimately, when you look at it, this is all about the processes are inefficient. They're costly for what we do. And ultimately it's hampering the work that we all want to do and make it much more efficient because we want to make it better. So we came up with this problem statement. So gathering all that together, and we basically said we want this to be about transitioning from to pay to read to pay.
We want this to be about the policies and mandates that are shifting from authors, libraries, institutions, publishers, consortia and research funders. All of that needs to be in the problem statement. We need to address all of that, not just one contingent. We want to make sure that it's not just about our current infrastructure standards, but we want to make sure that it fits whatever the new world might be as we approach it.
And then lastly, we want to make sure that this works for the individual solutions for librarians and publishers and understand that many of them are not going to be very sophisticated. And there could be manual work and legacy workflows and systems that this will eventually need to interact with. So ultimately, we felt that there was a development that needed to be done right. We wanted to facilitate and catalyze a variety of established and emerging business models.
We wanted to enable financial transactions in a much more efficient manner. We wanted to track deal and policy compliance and make that much more efficient. And we also ultimately wanted to optimize that related workflow. So that working group has developed. And I can think we can say now that we've actually developed it, we've developed a recommended practice to enable the operationalizing.
That's a very big word of oh, business practice processes for authors, librarians, institutions, publishers, consortia, funding agencies, and other relevant stakeholders. I'm going to stop talking here because I think the meat that you're going to hear from Yvonne is really going to show all the heavy lifting that's been done by this group.
Thanks, Mary Beth and Howard, and I'm really excited to be here at this stage of our work, of our project. As Mary Beth says, this is a community effort. I'll show you even the names of all the people who've worked on this so far. And it's been quite a journey and we're really proud and happy and excited to share with you where we are because we're on the verge of opening the public comment period.
And we're very, very, very keen to hear from you. So please be ready, be prepared to really review the work that we've done, because there's a lot of stakeholders to serve in this initiative. And I'm really glad you're all here in such large numbers to hear about it right now. My name is Ivan Kempf. And day to day I'm working for the Au switchboard. And in that capacity, I actually get asked and I'm in contact with a lot of consortia, universities, publishers, funders, vendors, infrastructure providers.
And throughout this project I get got asked so much about the work that this group is doing and an eagerness and and a question for what we would deliver and if we would please. And I don't want to give away everything, but if we please come up with a glossary and definitions. And if possible, some kind of schema, and I can tell you that's what Chris is going to talk about, because that is the meat and bone of what we've worked on.
Howard was already mentioned it inefficiencies to a large extent have to do with interoperability. And in order to serve that, to support that need to have systems, especially if it's from different companies. And vendors and organizations, to be able to speak to each other. And these deliverables were defined early on. It's kind of funny.
It was quite a bit of a journey to by the way, I'm co-chair together with Amanda Holmes from CRCN. And again, I'll list all the names of all the people who've worked on it so far. It was quite a bit of journey in the order in which we would do this, identifying the problems, as Howard mentioned, the people who came up with the proposal to Nasa to do this work already had an idea. And actually, these deliverables are from a year and a half back.
And I think we've come pretty close in delivering this. So in that list of the original proposal was that this group would come up with a glossary of standard terms, a standardized data dictionary for the use of OE processes, a report on infrastructure gaps and recommended tools and best practices. And here we now. I won't go there yet.
I won't go there as of yet. So that was the brief and what we were working towards. Now quite important. Of course, a project like this with high expectations and high need from the ecosystem, we had to be careful that we would deliver. And I think Amanda and I have really tried to run it like an agile.
Project and we've given ourselves the deadline. Or actually, I think the ambition of. ISO projects is to do it within 18 months. And we said, yeah, that's going to be the determining factor. And if we can't get the work done, then things will have to move to a phase Ii. The industry, the ecosystem is waiting for this. So what is determining is the year and a half and we will deliver.
And again, if we're running out of time or topics are too complicated, they will have to be addressed later. So the scope was Howard mentioned, it provides guidance for standardized business processes across diverse business models. That is quite important. It's not only about read and publish APCs transformative agreements at all.
We are very much aware and we've tried to cover that. Although in all honesty, a lot of the day to day challenges are around these kind of deals. And so we had to recognize that as well. It spends a life cycle. Actually, we've gone a bit further. Again, Chris will probably talk about that. We have also looked at the research cycle awards assignment grant application, because quite some inefficiencies and problems stem from things that could be recommended to do differently at that stage.
And it's filtering through and runs into or brings challenges later on and goes all the way through publication and reporting very clearly. And we had quite some debates. We did decide to be able to deliver something meaningful to I wouldn't even say limit, but to stick to journals and don't go into proceedings and books in this phase. That could be expanded in a later stage. So to manage your expectations.
We have only worked on journals so far, and also quite a bit of discussion was about inequity in the system and especially around APC based models. And we acknowledged it, but we had to decide that it's outside the scope of this process project. Remember this is recommended practices for business processes. And we couldn't take the challenge of saying anything about the inequities.
We did want to acknowledge it. We have it in the text, but we are not making any recommendations there. Now, who's been working on the recommended practice. Take a careful look. This was my first an ISO project and I understand people were invited. Now, I know people were invited to join the working group and it was incredibly oversubscribed.
If that's the word to use. So many people from all different angles in our ecosystem, volunteered to work on this, which was awesome. It was also super difficult. We had to turn people down. So again, the invitation to really now participate in the public review is an open invitation to all of you to join in and contribute at this point. I think we managed to truly have representatives from all the different stakeholder groups, from funders to publishers, institutions, consortia, vendors, infrastructure providers, and it's been an amazing group of people that have worked on this for a year and a half.
So my largest part of know before we go there. Just anecdotal or quite an important point. And Mary Beth already talked about standards and recommended practices. And if you're new to that, we have had quite some debate, as you can imagine, with such a diverse group of people about yeah, this sounds really good. And yeah, this other stakeholder, I'm a librarian and I really think the publisher should be doing this, that and the other and the other way around, publishers thinking that institutions should be doing certain things or submission systems should be doing certain things.
So it was quite interesting. And entertaining to have these lively discussions with each other. And one element I want to pull out the question that came up, would this recommended practice maybe be too aspirational. Or how pragmatic or how realistic are we. Are we going to be. And the question also was raised, are publishers going to be judged on how they're compliant with this.
Well, I'm mentioning it because that's not the point. It's a recommended practice. It's aspirational. It should be common sense and there is no element whatsoever about compliance. It is really up to all the stakeholders to hopefully take what we've done and see that it makes sense and understand how hopefully we together have made it visible, how certain recommendations will contribute.
And how they have a trickle on effect and that you hopefully would want to do it. Whether you're an institution or a publisher or an infrastructure provider. So maybe there will be questions about that later on. But I wanted to share that has been a big point. And actually still coming up while we're finalizing. Isn't that too strong. Should it be must or should it be ought to.
And we're getting guidance from ISO on how you write these sort of things. It is a recommended practice. Yeah And I stress again that again in my day to day work I get asked a lot about this. People are waiting for this, so it's very exciting for us to put it out. Now really, what have we been working on and how long.
It's been over a year and a half. Again, these 18 months have been really driving us. So we started in December 23 when the working group really got together in its first shape and form, getting to know each other, understanding who. We've done some exercises. Amanda had this great exercise with the colored hats. Maybe people remember. Some people have a tendency to always see problems.
Some people have a tendency to only see opportunities. Some people are into the details. Some people are more like philosophical and strategic and having a group of what is it, 24 people. It was really good, actually, to be reminded that people have a different way of looking at things when we're addressing this wide range of topics and challenges. So we split up actually in subgroups and kind of in parallel.
Initially we've worked on three topics. Current business models to set the scene. You can imagine we have to describe what is currently the situation. Remember one of the deliverables gaps in the current infrastructure ecosystem. I'll get to that on the next slide. Then we did start and that was a fun exercise. I was part of that group myself.
We really, really started with a long list and everybody could contribute from their point of view as a librarian, as a publisher, as a infrastructure or submission system provider with terms and terminology. And I think I'm probably exaggerating. I'm looking at the man next to me. But we have 48 definitions of corresponding author. No, not that many. But anyway.
Oh, a responsible I can go on. It was fascinating to see and that was a really, really good exercise. So we've really made a long list of anything anybody could have thought about. And of course, while doing the exercise you would think, oh, but that's the same as this one, just a different label. So maybe in the library community, this is a way to refer to it, or maybe in the US, this is the way you talk about that.
So we did really went all the way and made a huge list of terms and definitions that working group who worked on that for quite a while. And this one I'm going to read to you because this is draft text from the recommended practice, but I think it's important to get it across the status quo of the workflows. We had three subgroups working on the author, the publisher, and the library point of view.
So I'm sorry for reading it, but I think it's better I give you the right context. So in the course of its work, the working group formed groups in which project members visualized high level status quo workflows from the perspective of authors, libraries and publishers. On the basis of these workflows, members identified challenges in workflows as currently practiced, and from this list. The group members then voted on the most acute challenges in open access workflows as they experienced them, and on the basis of these results, the working group clustered these challenges based on similarity, and this work serves as the foundation for the gap analysis.
So actually, all those three subgroups that we started with in parallel have fed into the gaps, the gap analysis, the gaps in current infrastructure. And from that pre work, it's kind of been a sequential process of subgroups and working groups. And coming back together in the plenary group, the gaps in current infrastructure. And I think it's quite relevant to actually list what we found there, because the actual recommendations for tools and practices are, of course, built on this.
So what we voted and found to be the most important, the first one in terms of technical and metadata. A lack of data standards to support efficient transfer between actors in the scholarly communication ecosystems at various stages in the workflow. So I was mentioning it already at the beginning, this interoperability and the way to get data across throughout the process, through different systems, different vendors, you need to have a language and you have to have a way to facilitate the transfer of these metadata.
That's one. Second, difficulty disambiguating and verifying institutional affiliations and research funders and awards grants on the basis of information contained in free text fields and/or under utilization of existing infrastructure and PIDs to support publication workflows. That is the second big one under technical and metadata, and the third one the inability in many systems to model multi-payer transactions authors with multiple and changing affiliations and integrate with other systems.
So these are the biggest gaps and findings and problems relating to metadata and technical. And this is currently hindering the lack or this is currently hindering and the lack of a unified conceptual data schema and common vocabulary, a set of agreed upon practices optimizing usage of persistent identifiers and common vocabulary among all actors in the scholarly ecosystem. Second one is communication. It's of a different nature, because what we mean with that is that many business processes are face challenges, or even fail due to a lack of agreement between the actors in the scholarly publishing space as to who is responsible for communicating what information, in what form, when, and to whom.
It's basics of communication. But it is an issue. I'll give you some examples. First, communicating potential open access publishing charges and opportunities for authors throughout the publication lifecycle. Second, communicating authors eligibility for different institutional publishing agreements in light of different author roles corresponding at different stages in the process.
Third, very important came across communicating open access licensing options and consequences to authors, including for the purpose of meeting research funder mandates. And that was also a big point coming up. And again, I said it. It's not only about transformative agreements or APCs, it's also about funder mandates and requirements that authors need to comply with, that publishers in their business processes need to deal with and be able to deal with.
And the meaning of different dates publication date, submission date, approval dates, payment dates, whatever these sort of things. And then the third one is we have a big debate still, whether that's a gap or something to be aware of and deal with in the current state. Scholarly publishing is a global ecosystem consisting of actors operating in a variant, locally contingent circumstances, and as a result, a wide range of boutique agreements exist that are tailored to the needs of unique institutional and commercial interests between parties who enter into agreements.
Secondly, the relationship between publishers and individual titles like society titles and thirdly, the requirements of specific funders in a specific country and a specific situation. So I understand I need to speed up, but this is the meat and bone of how we got to the recommendations. And I promise you to also say a little bit about business models, but I won't be too much because we were very fortunate that there was previous work done by Tasha Cohen, and the working group has reviewed it and has made some statements about how our working group would deal with business models, as already mentioned in the introduction.
We should be agnostic and independent and be prepared for the future. So what we've done in this subgroup is acknowledged that there's a great many open access business models and that again, for this recommended practice, we've adopted this classification scheme that has been worked on before and has been published. And very importantly, we've used it as a checklist, as a reference.
We're still checking all the recommendations and the data schema against these business models. But they're not prescriptive. They're descriptive and setting the scene for us to make sure that we've not forgotten anything and that hopefully we are catering for all these business models with our recommendations. And with that, I'm handing it over to Chris.
Thanks, Ivana. So I have the nice job of talking a little bit about what we've actually done, and I'm not going to go into a lot of detail here because we want to encourage you to reach to read the draft and comment on it, which will be out in a few weeks. But essentially, our recommendations are structured along the lines of three core business processes that we've identified that typically are used to fulfill or finalize transactions.
First being our agreements. Not every one of those business models that Ivana mentioned uses an agreement. Some of them are more transactional, but many of them do, and many of them are very complex. And it turns out from the work of the committee members, many of whom have been on the painful end, both sides of trying to implement these agreements are currently very, very difficult. So each of our three business process cycles have recommendations for different actors or stakeholder groups.
For OE agreements, those actors are consortia, institutions, and publishers. And here we're not recommending what should be included in an agreement in absolute terms. That's not our job to constrain OE agreements. There has been enormous creativity in the way that these deals are structured. I'm sure that will continue. What we're instead recommending on a meta level is the kinds of things that you should cover in an agreement in order to make it implementable.
And again, I'm not going to go into a lot of detail here, but it turns out a lot of the difficulty is around the rules for eligibility of a publication, which, as we've focused on journals, which articles are covered under an agreement that needs to be defined very precisely in order to avoid a lot of the manual back and forth or uncertainty that folks implementing these agreements have experienced.
Also, there needs to be clear definition of the responsibilities for implementation and operation of the agreement. And I think it's probably true to say a lot of these agreements have been developed by creative business folks rather than systems implementation and operations folks. So it's very important that there's sufficient detail in the agreements about how they should be implemented, who should do what and when.
A couple of other pitfalls that we've heard a lot about are pain points and change mechanisms. What happens when an author changes affiliation between submission and publication. What happens when a journal moves publisher in the middle of a publication of an article. Again, we're not saying what should happen. We're saying that an agreement should specify what should happen.
And then also very important is reporting mechanisms. The second one of those business cycles or process cycles, which turns out to be important is funding applications. And the connection here with OI agreements. Obviously, there are a lot of funders have mandates. They want specific ways in which publications should be handled, licensed, et cetera, in order to allow funding to be used for the publication charges.
And again, eligibility is often dependent on who funded the publication, the research that went into the publication. So here we're providing clear research, clear guidance both for researchers and funders. And it's specifically around capturing dissemination of the key metadata about researchers affiliations and the funding that they receive. And when we say clear, this needs to be unambiguous, which is why we also heavily recommend the consistent use of PIDs persistent identifiers so that you can reference the particular researcher, their particular affiliation and the funder, and the specific funding award.
The last and maybe the most expected of the research cycle is actually the publication process all the way from initial submission, or in fact, all the way from selection of journal. We have some recommendations about that all the way through to reporting about the final publication. Here we have recommendations for consortia, institutions, publishers and also vendors of the systems that publishers and institutions use.
We have proposed that they provide clear guidance to researchers on both institutional and publisher policies. And it turns out that sometimes researchers have to contend with both of those things they're trying to understand what the publisher is requiring of them in order to qualify for or choose an OA model. But often institutions have in some cases more fine grained requirements.
So we've specified some recommendations for best practice workflows, particularly around the problem of getting the authors to unambiguously submit or indicate their affiliation and their funding, and capturing that accurately during the submission process. Again, capture and dissemination of the key metadata, in this case about researchers their affiliations. Again, the metadata of the publication itself and again, consistent use of PIDs.
You can read about that in a lot of detail when the draft comes out for review. The second thing, which we spent a lot of time on in the working group that evonna mentioned, is what we've ended up calling a data dictionary. A lot of debate about what this was. It started out as a glossary. Then it was a schema. Is it an I spec.
For those of you who have data modeling somewhere in your background, it's somewhere in between. It's what's called a data dictionary. And the aim here is to standardize and define all of the data elements, metadata elements that we have learned that are typically needed in order to accurately and precisely process our business transactions. So the use cases for this data dictionary, this is not an API spec or a specific reporting format or a database schema, but it defines the data elements that tech folks might want to take and use in any of those things.
It turns out that there are 132 data elements that we have discovered and needed in our business processes, not all of them in every process, but that's quite a surprising number, and I think that partly explains why currently we're struggling as a community with these processes, because there's a lot of complexity. And there's a lot of metadata required in order to accurately process these transactions.
When we say data dictionary, there's a definition for each of these 132 elements. And then some classical data modeling things like the data type cardinality. Whether you need 0 one more must have optional elements and what's called the grammar. So a lot of this is hierarchical data. So which data element contains other data elements. We've used JSON as the underlying set of data primitives.
That's quite simple, but most technical implementations are using JSON data models these days. And we have tried to reuse work from other projects and definitions from other schemas where possible, including NISO, jats, the tag suite, NISO journal article versions NISO access and licensing indicators and the credit taxonomy. I won't go into a lot of detail on the design of this, but essentially the top level object in this model is what we call an OA transaction.
And then below that, we define data structures for the publication funding decision. The OA agreement. We're not trying to technically model our agreements in machine language. We're just trying to make sure you reference them accurately. The way in which a particular article is matched to an agreement, the charges involved, the invoice, who's paying for it.
And then there's a lot of publication metadata. A couple of key things have turned out to be, again, major pain points. The need to distinguish in the metadata between the roles of authors and publication corresponding author, first author, last author, all that normal stuff and the roles of authors in being eligible for funding. There's a lot of conflation in that. Currently, those two things are related, but that's what the eligibility rules should define.
And then when you're exchanging data, they should be described differently and similarly. And Yvonne has hammered this into me after many, many discussions to be clear about research funding. Funders who issue the grants for the research and publication funding because sometimes they're the same, but often they're not. And it's very easy to conflate those. So again, lots to look at.
This is something we encourage your technical folks to look at, as well as business folks and operations folks when it's reviewed. And with that, I'll hand back to Yvonne. Thanks, Chris. And I think you said something really important at the end that there is probably different people in your organization who want to look at different elements of this recommended practice, and I can't repeat and stress enough what Chris was saying.
Please, please, please ask your data architect, your super techie people. Maybe it's yourself, but ask them to look at those 132 elements and be super critical, because I think as well, I don't even think as I mentioned, this is going to be critical in being able to achieve interoperability and sound exchange and transfer of metadata throughout the workflows and the processes.
So what's next. This is the last slide. And then I think we have 20 minutes for Q&A and discussion. Perfect timing right. So what's happening. The data's been deadly and we're working towards it. We're almost there. We're at the stage where technical editor is helping us to really turn it into the final acceptable mandated NISO format.
So it's really the last bits and pieces. We feel we've done all the work. It's really getting the text ready for the public review, public comment period, which is the end of June. I think we need another four weeks, to be quite honest. But it's June and it is officially 45 days. If you have questions about how technically this review process works and how you can comment and how about it in the Q&A, I'm sure Mary Beth can say more about it.
This is my first time doing it, but it's 45 days and it's a standard process for NISO working groups to go out for public comment. And then we're back onto it. And some of us hope we get a lot of response and interest and feedback. And to be honest, secretly I hope we don't get a lot because we will need to then process everything.
This is not a discouragement to participate, but I hope we've done our work well and actually that we can keep the momentum going. Because as I said, we're getting a lot of questions for it to be published, and it can only be published after we as a working group have again processed all your feedback. So if you're giving feedback, please be specific. Be realistic.
If you want to have a debate or a conversation, pick up the phone. We're happy to talk to you, but in the formal form, please try to absolutely make your point, but in a clear and consistent way. Then my understanding is that after we as a working group have processed all your feedback, it goes back to one of these committees for sign off. And then hopefully.
But it all depends on how much work it is. Q4 is when officially it the recommended practice will be published. But I'm inviting you now for the 10th time, have a look at the recommended practice because then basically what's in unless we got it completely off and completely wrong. I think by participating in the review process, you have a good feel of what we've done.
So you can imagine it's very exciting for us. And yeah, really are invited. And please, please review what we've done so that we can hopefully as an ecosystem, make some steps forward and by maybe some small steps and logical, pragmatic recommendations achieve some more efficiency and smooth experiences for all. Thank you so much.
OK, so we are in the question and answer period. And I shall ask you a question first, or shall we invite the audience. How do you feel. Yes, does. Would anyone like to ask a question. OK, great. Yes thank you. And please tell us who you are.
If you don't mind. Hi Colin Adcock from the APPS. Thank you for this. And I'm looking forward to this, as Yvonne very much knows. I have a question about the data fields and the plans with published articles and Crossref. Is all of this going to be in crossref? Are some of them going to be in crossref? What do you think.
Well so the metadata about the publication is key. And that's the kind of information that's in Crossref. I mean, I think probably Yvonne can talk about this better than I can, but there's a thing called the switchboard, right, which is much more around transactional process, the point to point process of communicating status. So there's a lot of this that's sits around what data needs to go back and forth in the process of getting to the final publication.
I think the data that describes the publication of an article in its final state as an array is already pretty well defined. That's the NISO standard. And I think it's pretty well supported in Crossref. So it turns out that the final status metadata is a lot simpler than all the metadata you need in the communication between the three parties the publisher, the authors, institutions, and the funders.
It makes sense. I was just going to ask specifically about the corresponding author angle, and I think everyone's going to answer this call in, and I know each other. Yeah but also I want to make the point about reverse engineering. And I can't speak for Crossref, but I can speak for the switchboard.
And Chris was very kind indeed, to mention quite a lot of resources and former projects and initiatives having fed into this isec jisc, H2020 switchboard, C. I think we had 12 or whatever. But the exciting or the exciting, the challenge is that when this recommended practice comes out and you've all looked at it, I expect, and I'm speaking for the switchboard, we need to I think you used the word or used the word we will need to reverse engineer.
I mean, I expect absolutely that we are going to have to want to update our schema in switchboard. And again, I can't speak for Crossref, but I would not be surprised with all these new insights and stuff that we've done that there will also be a couple of data fields or things that Crossref might want to amend as nodding. Yeah so just one of the things I'll add is that there are many fields in Crossref that are open, and you can add whatever you want or they're optional.
So one of the things that this recommended practice will do is as you're working through that and deciding what you want to fill out, what you don't want to fill out, it'll give you some standard ways to fill these fields out and to express them in a way that others will expect to see them later on. Just specifically on the corresponding author things. This is a hobby horse of mine, so I think it's often the case that in the definition of agreements, the concept of corresponding author has been used as the basis for eligibility that the corresponding authors affiliation.
And that's created all kinds of their knock on effects like, well, now we have to have multiple corresponding authors, and now we have to have a submitting author. And quite frankly, it's a mess. And we're not saying that your eligibility rules should change. We're saying that they must be written down clearly and unambiguously in the agreement. And there's an eligibility matching process that says, based on the rules in the agreement, this author is what we're calling the responsible author.
And once you've done that matching, that's a semantically separate piece of information that you need to preserve and tag separately. So in the downstream messages you'll and you'll see in the data dictionary, there's a separate way of tagging a corresponding author from an or a responsible author. Often they may be the same. Sometimes they're not.
The important thing is once you figure that out through the evaluation of eligibility rules to tag them separately, you see, we get carried away. We're so excited. But this is such an important topic. What nobody none of US has mentioned, which is in the recommendations, which I thought was such a no brainer, such a brilliant suggestion, and how Chris helped me again.
Deal sheet. Yeah, I never know. Yeah, yeah. Which is a common concept in all kinds of other legal negotiations. But the idea is that there should be a summary sheet, one page, the top cover of an agreement that specifies the key terms. And also that should be shared as much as it can be shared.
So that authors who are trying to navigate all of this understands what has been agreed, and whether they might be eligible. And so that the systems, people or the vendors can actually implement and support these wonderful deals that smart business people have made. Now, I thought that was a brilliant suggestion. And again, like Chris says, that happens in all kind of other industries and contracts.
You just have a semi layman's summary of the deal so that people who need to operationalize it know what you're talking about. Amanda thank you so much. I am a member of the working group. I am also staff at Crossref and I wanted to specifically mention this to everybody, not just to Colin, because Crossref is actually calling for members for its metadata advisory board right now.
And the deadline for that is May 31. So if you go to the Crossref blog, there is a call there with an application for members of the metadata advisory board. So that's one thing. But I will also say that I think you're exactly right that these recommendations are going to come out before that next version of the Crossref schema comes out.
That next version is, I'm almost certain, 5.5 I can't quite don't quote me on the numbers, but I do know that specifically in the next schema of Crossref, we are planning enhanced support for multiple roles specifically credit, but also potentially I think, corresponding author type of thing. So I think the timing of it is perfect because at least the draft of this will come out before that next Crossref schema comes out.
So Colin, you have the ability to say these things on the metadata advisory board and so does everybody else at Crossref. So thanks, Amanda. Good to see that. All sides of the room. Anyone else with questions. What OK.
So I'll ask my question. And maybe this will help everyone visualize the impact of this recommended practice. But I wanted to ask each one of you how you envision this recommended practice being used, how is it going to change people's lives and looks like Howard wants to answer. So I'm going to pass the mic to Howard. Yeah, so I'm a big guy that believes in practical solutions.
I'm actually not a big standard guy for the region of standards. There are many, many standards that just sit on shelves. So as soon as. Yes, sorry, that is true. So as soon as this comes out and you're going to review this, I really recommend that you really think about what you will do with this. So if you're an institution, how are you going to put this into your contracts as an example right at chorus.
What am I going to do with this. Well, I'm going to take some of the data that on those fields, right. And match them up to exactly to what I have already in existence in my existing system. Do I want to map them. Do I want to make a change. Is it an improvement. Is it too much of a normalization.
These are the things I will need to do as a technology provider, but I think each group will need to do it for themselves. Yeah now with my head of the switchboard on what we are for instance, and we're going to do things on the publisher side as well. But on the library consortia side, we're increasingly building integrations, or actually the other parties are building integrations to receive standardized data across many publishers into their systems, just to name two, to make it specific.
Consortium manager. Actually, I'm going to name three consortium manager being used by 60 plus consortia around the world. How rossovich focus traditional subscription agent with a system called focus being used in libraries, where it's combining subscription and invoice and historical data with Article level metadata coming out of switchboard and chronos hub providing also solutions to consortia.
So what we are going to do is indeed, like Howard says, and I think it's not simple, but as basic as this is to map the data fields. So if in switchboard this field we're using for corresponding author or for publication date, we're going to sit down again with these receiving systems that are being used with libraries and consortia and make sure that the data we're spitting out at the moment, on behalf of 37 publishers end up in the right data fields with these systems that are being used by libraries and consortia and what have you.
So to make it really specific and pragmatic, that's what we're going to do tomorrow when this is out. And these are the parties that I mentioned when they amongst others are asking for this to come out to avoid data confusion and yeah, do it right. Yeah and I think I would hope that we can through implementation of this standard in infrastructure and vendor tools, dramatically reduce the amount of manual effort that's being taken to process and handle deals at the moment because if you think about the traditional model of subscription publishing, there's probably hundreds years of established practice of knowing how to do that.
Systems, intermediaries, playing roles that make it all work smoothly. Oh, is not like that today. It's a cottage industry where most of the work is people pushing around and manually dealing with spreadsheets and sending emails to each other. And given all the other challenges that we're facing as an industry, the financial pressure, the integrity, pressure, there are so many better things we could be doing than filling in manual spreadsheets to ensure that only transactions get processed correctly.
So I think in some ways, this is a classic many to many problem which we've tackled and solved as an industry before. We've got librarians who are dealing with information coming at them from many different publishers in many different formats. We've got publishers who were trying to meet the needs of many different customers and many different ways. It's a classic case of inefficiency.
Systems like the switchboard, the other infrastructure providers that Ivana mentioned, they think over time will exist to solve this problem, standardize this process, and we can all move on to more interesting, useful, and value added work. Thank you. Panel so check with the audience again just to see if that's given rise to any questions.
OK, I have another question. What barriers, if any, do you foresee in terms of adoption of the recommended practice. Anyone want to answer that first. I think in some ways, it's the classic collective action problem. So for this to be useful, many individual people and organizations have got to take steps to implement.
And I think that's why the implementation journey. Ivana, you've talked about everybody who has a stake in this, who has a role to play. Looking at what do I need to do to change my systems, my processes, my practices to align this. And that's always a challenge. And again, we as an industry, we do have a track record of solving those challenges in the past. I'm sure we can do it again.
Yeah, maybe. Related to that, maybe not being able to do enough about awareness and making it simple and communicating and getting the word out because it might be scary or big, or people might think it won't make a difference if they don't do everything. But I think the communication, the training. And I was talking to Todd Carpenter from NISO about that yesterday, that might actually be an area where maybe collectively we can get some grants or some maybe an invitation to somebody in the room.
If there's organizations who sit on funds and who have money, who feel that this is indeed a collective action that we should all be working on attending. And again, even though our working group, we try to have representation from everybody. You saw that there's hardly any there's nobody from Asia or Australia. There was, of course difficult with the time as well. But our world is not limited to the US and Europe.
So the getting the word out awareness training will cost money. So I think maybe. What was your question. A risk or a limitation or a barrier is if we're not able to get the word out and to reassure people that every small step helps. I'm going to flip it and not talk about a barrier, but one of the themes that we've been hearing here at SSP is about creating the right personal narrative.
So this is a perfect case. So what are the after somebody has gone through the throes of trying to implement this, create that narrative about that successful story. And by the way, it could be a bumpy story, but as people can relate to success. So I think Chris is right that being that first mover is always going to be that tough barrier. We found that in every initiative, every persistent identifier I've ever dealt with is the first one is always on that bleeding edge.
Who's going to do that. We'll find somebody that will do it. I think people on this panel I'm sure will help do it. But once you've done that, create the narrative and then spread it wide and as deep as possible. And I think for me, that's how you're going to get some success and some traction. Thank you. I think we still have time if anyone wants to chime in or comment.
Just a reminder, we will announce this broadly when it's available in draft. You can always sign up for NISO announcements to get those right in your inbox, but you can follow us on social media. We will issue a press release, and then that will be the time when everyone has 45 days to take a look and add any comments, see if anything is missing or have anything else to raise.
And in the meantime, I do want to thank so much. I mean, again, going back to what I said about our work being community driven and relying on volunteers. Thank you so much to our working group co-chairs, Ivana and also Amanda Holmes, who isn't with us, and group members Chris Howard, Amanda, anyone else. Anyone else in the room who's on an ISO working group. Thank you so much.
Thank you.
Form Title Download
Transcript
Form Title Bookmark
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Form Title Share
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Form Title Accessibility and Keyboard Shortcuts
The cadmore media player is a professional video and audio player experience designed to deliver media as well as relevant transcript, segmentation, and metadata. On the screen is a traditional html video player with buttons such as play, pause, forward, captioning, language and play speed selection and more. Adjacent to the video player are generally tabs, one of which shows a scrolling transcript of the video and the other shows any segmentation of the media, sometimes referred to as chapters. At the top of the video is a menu bar containing an Explore button and Tools button. The Explore button allows you to dig deeper into the video by opening up an explore dialog which contains tabs for a visual navigation of the video using thumbnails, an about tab which contains rich metadata about the media, a segments tab which contains further information about the video, and a related tab which contains links to other media related to this media. The tools button opens a menu with options for sharing the media on social media, creating bookmarking links, creating embed codes for your website, generating citations, and more.
Keyboard Shortcuts
Keyboard shortcuts only work while you are in forms mode. By entering forms mode, you will be able to quickly access portions of the media player with single key commands.
Spacebar: Play/Pause Toggle
I: Info Menu,
O: Tools Menu
T: Transcript Tab,
S: Segments Tab
F: Forward 15,
R: Rewind 15
L: Languages,
P: Playspeed
M: Mute Toggle,
V: Volume Bar
N: Video Only Toggle,
B: Full Screen Toggle
C: Captions Toggle
Escape: Closes dialogs and menus / Exits Player
Z: Next Transcript Chapter
X: Previous Transcript Chapter
Q: Next Transcript Paragraph
W: Previous Transcript Paragraph
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Embed Size
-
You Size - Responsive
-
We Size - Responsive
-
Picture Overlay Popup
-
400 x 225
-
512 x 288
-
400 x 700
-
768 x 1024
-
1024 x 512
-
1280 x 608
Form Title Cite
No citation provided.
Info
Segments
Related
Thumbnails
Exit Clip Mode
You have requested to see a portion of the video outside of the clip.
Click OK to switch to the full video or click if you would like to stay inside the clip. You can always go back to the clip with Tools and Clip Mode