 Thank you all for joining us. As they said, I'm currently the chair of the RRUK open access publishing processes group. We've been in existence for a few years now before transformative agreements and they like came along. We've been trying to work with publishers not just on behalf of our UK members, but anyone really who's engaging with a publisher, particularly in the payment of an APC to kind of help talk with publishers about what it is that institutions need when they pay an APC, so the metadata and funding information and so on that we find quite hard to get sometimes from publishers and also engaging with them about the types of messages that they're giving to authors in the APC workflow. We've been doing that, like I say, for a number of years and there's more information about the group on the RRUK website. The OA Switchboard is a project that some of you may have read about. I think it's been around as a concept for a couple of years I think and I'm started really in earlier this year and Yvonne is here to tell us about it, but it is addressing very much part of the OA publishing processes as Yvonne and I were just talking about. So the project is hoping to come up with a proof of concept, minimal viable product over this year and we wanted therefore to ask people to talk to people in the UK about what the switchboard is and what it's hoping to do and I think to invite people's engagement as well. So with that I'll hand over to Yvonne to take over the main part of the webinar. Great, well thank you Ruth and David and Melanie again for the opportunity to talk about the OA Switchboard which is indeed a neutral information exchange hub streamlining the communication between funders, institutions and publishers regarding OA publications and as already mentioned it's a very practical tool. It's a tool I'll also show some demos and you'll see it's quite detailed administration back office yet with the potential to achieve a breakthrough in the transformation of the market such that Open Access is supported as the predominant model of publication because the complexity and the administrative burden on institutions, funders and publishers has hindered progress in developing new business models to support a broader move to OA and from a researcher perspective the landscape is at best confusing and at worst impenetrable. My name is Yvonne Campfans. As said I'm the project manager for the OA Switchboard and very happy with the opportunity to present to you today and maybe as a brief introduction I'm an independent consultant and I'm doing this project for this year. I have 25 years of experience in academic publishing and related industries and in that time I've been involved in a number of collaborative large industry wide initiatives and I'd like to mention the transfer code of practice that more than 20 years ago I think or some 20 years ago we started together with Edpins and others to enable the move of society journals from from one publisher to the other and the debates around what is competitive and what is not and what can be shared and what you can do together was heated so it's kind of a threat throughout my years in the industry and I'm very pleased to be involved. Now for today I have a brief agenda. I would like to just at a glance look at what the switchboard is then zoom into what the underlying problem is how we see the solution and the value the OA switchboard will bring them we get more practical how does it work also a little bit about technology but there's also an appendix in this PowerPoint deck and if you really would like to talk technical details. I'm happy to organize a separate meeting also involving our technology partner for that. Then I'll have a demo I have a couple of videos to show you hopefully to to bring it to life so you see what it's all about and there should be time for for discussion and Q&A. I won't show it but I want to mention it at this stage I have I have information about other industries because some other industries have tackled similar problems long time ago and I'd like to mention the banking world to you maybe you know about Swift and that has been around for over 40 years and it's a secure financial messaging surface and it started with just four banks working together and right now 40 years later the whole world is connected. And I'd like to mention that as an example to to show that it is possible to collaborate especially in the back office space in infrastructure with different players and achieve wonderful things that may not be visible at the surface but can benefit everybody. So, in short, David already mentioned it, but the OA switchboard initiative is a not for profit collaboration between funders institutions and publishers. The switchboard itself is a tool. It's a central information exchange hub connecting parties and systems and streamlining the neutral exchange of OA related publication level information and ensuring a financial settlement can be done without getting involved in the actual financial transaction. Quite important to to mention. The initiative is currently overseen by OSPA, but the ambition is already for 2021 if nothing impacted by Corona hopefully. But the planning is that for next year we move to a sustainable governance structure and funding model moving forward. And in a nutshell the timeline indeed for a couple of years probably even before December 2018 I was not involved at that time but in December 2018 there was an initial stakeholder meeting with various people involved and on our website you can see who were there right from the start but it was publishers funders institutions but also Crossref and others. Then throughout 2019 talks some blocks meetings conferences panel discussions and the support for the concept was growing. In December last year I was appointed after an RFP process because they were looking for a consultant to get it off the ground dealing with the chicken and egg situation of and I'm moving forward a little bit jumping ahead. The ambition of having something in place where funders institutions and publishers are equally represented and at the same time wanting to get started. That's why we're in a project for 2020 and we're working hard towards this operational stage for for 2021 and beyond. This year a lot has happened a steering committee has been announced in January amazing people on there and we were starting to get project funding sponsorship to get through this first year. An advisory group was put in place first meeting in February in March product specs and as we moved as of May with our technology partner after an RFI process selected. We have started to build the minimum viable product and it will be ready one more iteration to go. We're in the last iteration it will be ready beginning of August and it's very exciting and I will show you today what it looks like because now the story comes to life and we can also much more specifically talk about further improvement cycles. Interest of the institutions or of the funders but also other types of publications than journals we're talking with just started working groups on proceedings and books. We're looking at the diamond model we're looking at China because the ambition is for this to be global and irrespective of publication type and business model. That was just at a glance now in a bit more detail the underlying a problem and I'm sure you know all this but all these developments are actually bringing this challenge of complexity and administrative challenges because open access output is growing year on year. Increasingly funders and institutions are paying for always centrally business models become more complex some with others without individual publication fees. Some through agreements with publishers some through sponsorship models and also the requirements about how various research outputs should be published are expanding. And the bottom line of the practical problem is what we're addressing with the switchboard and that is that for a specific publication there's very likely to be multiple authors involved. Each with multiple institutional affiliations and their own funder arrangements and we we've come to call that multilateral publication level arrangements and that is what the switchboard is all about because it's complex for all funders institutions and publishers alike to implement that and to honour those multilateral publication level arrangements. As mentioned this is because multiple authors involved and the institutional affiliations and the funder arrangements but also the myriad of systems and processes with all these players involved. It is enormous to deal with the different systems and processes. So the people who got together and I should not take any credit for that I was not involved but I think the people who originally got together and thought about this and looked also at other industries and also into the past of our own environment. They thought the answer to this specific problem to this many to many problem is an intermediary in the middle a central hub connecting parties and systems and streamlining in a neutral way the exchange of publication level o a related information. And what we're then talking about is data and information but also very much standards and that is nothing has nothing to do with technology so when we were starting to build the MVP this year. Actually the first weeks months we talked a lot about standards and types of information and orchid and roar and wringled and what kind of fields would be mandatory and what you would want to know and what is nice to know. So standards is a big big part and we're still in the middle of it obviously then the infrastructure is the actual message hub and being able to send one message from one party to the other and routing it to the right place in an efficient way. Relieving the participants obviously of knowing all the details about how a specific funder or institution would want to receive. Whether by email or in a web hook through an API that is all the stuff that the always switchboard takes care of when setting up the accounts and the back office services. Think about reporting I'll show you what that is all about but if this functions if these groups communicate with each other in a standard way through the switchboard. These messages can obviously be exported into reports and I'll get to that in a minute also fed directly into your own system so there is no manual processing at least for this part of the information needed. So what is it all about what is the value that the always switchboard aims to bring. It's the smooth out processes I can't say this enough this is back office we are not planning an interface for researchers or authors ourselves we're serving funders institutions and publishers or their strategic partners their system partners who will on their behalf very likely be the ones who are interacting. With the switchboard but it's all about doing things that we can do in an anti competitive way to bring efficiency bring down transactional cost and and reduce overhead and smooth out processes making it more efficient and that will bring clear data and greater accountability and indirectly it will relieve the researchers and authors from financial and administrative hassle. That is what it's all about. Now how does it work practically. I already mentioned standardized communication so the switchboard is all about predefined set of messages between funders institutions and publishers and the switchboard enables them to send them. Automated integrated scalable in the demo I will I will show you a user interface but I'm almost joking in all of these presentations and meetings that I hope nobody will use the user interface because it's so much detail. And not all fields are mandatory but still it is a hassle to fill out that form manually but it is possible because maybe some people some parties are not yet ready to work with an API and do it in an automated way. Also to be quite honest to give you a demo it's impossible to show an API it's easier to show you a user interface so we have it. But we always say we hope people don't use it and are able to integrate it into their existing system so that this whole switchboard is truly behind the scenes facilitating the communication already mentioned if these messages flow through. It enables real time monitoring and tracking as well as standardized reports on predicted committed always spent and publication numbers and details and that can feed into local solutions and systems. So for instance we're talking to the people from JISC but also other players consortium manager knowledge and latched CCC editorial manager OJS basically all the systems providers that are acting on behalf of a publisher and institution of funder or multiple parties. We're talking about talking directly to the switchboard or feeding in the output of the switchboard directly into their system so that that doesn't have to be done manually and indirectly I have a visual on this. Integrate with your systems the funders institutions and publishers so that behind the scenes the always switchboard can enhance the services again in a neutral way and not having any interface for researchers ourselves. Now even a little bit more detail three slides on how it works so the communication and the MVP means minimum viable product and it truly is minimum because of budget limitations but also because we wanted to get it out as quickly as possible and to be able to show it and get feedback. The MVP is minimum and it basically means we only cover two messages so called eligibility inquiry and a publication payment settlement notification message and both these messages in the MVP initiate from the publisher. There's an important food note here that ultimately moving forward we want to see if there's the desire once we have this hub in place for for instance specific message messages to be initiated from the funder or the institution and go the other way around. What is also important that no prior agreement so it is not necessary we can deal with it but it is not necessary to have a read and publish or transformative agreement in place to communicate between the publisher and say the institution. And then the concept is pretty straight forward the publisher sends a standardized message and eligibility inquiry or a publication notification to switchboard make sure that it gets delivered to the right place and answer can be sent and will make sure that it gets delivered. And as I already said API is a recommended means to do the communication but we have a user interface and there is also a notification and alert by email if that is desired. Then to the inside and overview the reporting the monitoring if these messages get exchanged you enable or standardized reporting is possible again various ways in the user interface it is possible real time monitoring and tracking. Downloads I'll show that in one of the demos Excel sheets but also Jason format can be exported from the switchboard or ultimately feeding it directly into local systems and solutions and not even touching it by hand. And third this is where the switchboard behind the scenes can enhance author researcher facing tools so on the publisher side. Imagine a submission portal or the services portal or the content platform behind the scenes those tools researcher facing tools author facing tools can talk with the switchboards to provide additional information or to answer any questions. There may be and likewise on the institutional funder side. For instance the journal checker tool we're exploring how that can be how we can talk to each other and enhance the journal checker tool who obviously has an interface will have an interface for the researcher but also universities having their own researcher support portal or funders having grant application tools. You can just imagine through API that certain questions can be exchanged information being exchanged and better service being provided. The last slide before the demo and then David I thought I pause for a minute see if there's any questions I think there's a lot of questions. The last slide before the demo the MVP technical and bear with me because normally our tech provider does this bit of the of the presentation. The MVP basically consists of this core message app and then a message data store it's operated via API also available via UI you see that on the left hand side so it's a choice but underneath even or also the UI is actually operating on the API. So that is the heart of of the switchboard. It's almost all it's all open open source. Also the documentation all the code the message structure including validation schemes and examples and the API are available via an open bit bucket repository and if you go there now you can see everything that is listed here. Latest edition is configurable notifications actually configurable validation the notifications were always there. So depending on what is used email alerts and web hooks will be sent to notify that there are messages to to act on. I think I should pause here for a minute David see if there's any questions you want me to address at this point. Oh you're muted. Most of the questions have actually been some technical ones with some problems with people being out here. But Manwala Palota has asked about the main difference between the API and the API platform such as dimensions. I'm not familiar myself with dimensions. I don't know if that's something. Yeah, I can say something about that this. What is unique about the OA switchboard is that it all happens super early in the publication process. So these messages. The eligibility inquiry and the publication notification is definitely the eligibility inquiry happens way before publication. Because the eligibility inquiry is a message from the publisher to the institution or the funder about an article which is not yet published and the question there is does this. Intended publication have the potential to meet your requirements and would you have central funding available to pay for any applicable publication charges. And the second one the notification and we're finding out in the pilot at what point in time it sent but it's either at acceptance or otherwise at publications are really the minute before or after publication. It is a notification message from the publisher to the relevant institution or funder with all metadata. The DOI now included an information about how the bill will be settled or which deal it will be charged against. So I am talking to people from digital science but also from any other parties who have services later in the process flow that possibly possibly. And here comes this one into play again information from the switchboard could feed into these services. But I should say at this point that the OA switchboard is not a database or a tool that fantastic analytics tools or additional services can be built on top for a standalone commercial purpose. Let me clarify that right away. This is a back office communication tool between publishers funders institutions. There's any commercially or privacy sensitive information. We will deal with that in a secure way and it could very well be that that is it. It's behind the scenes it between those parties and it never never goes out. And the reporting that I was talking about go into the systems of the funders and institutions but don't make it into third party systems at all that clarifies. Yeah. And then there was a follow up on the API is as to is it an enriched model or modeled as a graph. So that's a technical question about the API. I can't answer that I need to take that to my tech guy. Yeah. So we'll follow up on that. All right. But that was that was it. Check how we're doing on time. I think we're good. Then I suggest I just move on to the demo to the demos. This is an overview. And let me say at this point again this what we're building is a minimum viable product on a on a. How do you say it limited budget and also we are an iteration five at the moment so the demonstration videos that I will be showing are from intermediate deliveries and by every step with every demo with every iteration. We've been collecting feedback talking to pilot users and improving as we move along. So you'll see in the demo some some glitches. So bear with us but after the beginning of August when the MVP is delivered for all these key features we will make nice and clean demo videos because these are the key features of the always switchboard MVP. It's compose an eligibility inquiry both in case there is a prior agreement in place and in case there's no prior agreement in place. Compose this publication payment settlement notification message same for the same two scenarios then recent because maybe you didn't get a response and you want to recent the same message or following an eligibility inquiry. You now want to compose a publication notification message. You don't want to enter all the same information manually again so you can work from a pre populated sheet. Then obviously the ones who get the messages have the opportunity to read them and respond. Then the monitoring and the reporting real time export API and this is on predicted and committed always spent publication numbers and details. Then the routing and I should say at this point in MVP were using the roar identifier the registry to make sure that the message gets delivered to the right recipient and I'll show that to you and there's auto suggest. I'll also have a demo on that and last delivered last week in iteration five is custom validation and auto reject based on master data of central often terms like for instance. Journal has to be in the DOAJ or the APC cannot be above 1500 euro just making it up. But if these terms are pretty firm and fixed we can include those as master data for an institution in their configuration and based on that actually auto answer the eligibility inquiries. Now the demonstration videos I have them here embedded in the PowerPoint but they're also available from our website. As I said moving forward with each and every intermediate delivery we're making improvements we're adding functionality all the videos are on our website. But today I will show you number 4.2 4.5 and 5.3. So the first one is quite straightforward compose an eligibility inquiry message without a prior agreement in place. And in the test environment the sandbox environment that you're looking at it will be hindawi who are sending a message to the University of Amsterdam and this is obviously all fake. This is just the test accounts that were that we're using. So what you'll see in a minute is the dashboard for hindawi and in the next video I'll show you the dashboard for the University of Amsterdam but it looks very similar. So look in the top right corner you see whose role we're watching so hindawi and they can compose a message. An eligibility inquiry or publication notification message in this case an eligibility inquiry. So obviously if you use the API this doesn't need to have to be done manually. At institutions this is where in the user interface there is the integration with the Roar registry so you'll get suggestions to pick the affiliation. Obviously article title is a mandatory field whether the article will be published in an open access journal or a hybrid journal under which license is mandatory. The journal title needs to be filled in journal ID is ISSN and then the switch prior agreement yes no in this case no and that means all the details on the APCs and other charges and discounts is to be filled out. At this stage with an eligibility inquiry it can be that the APC is not yet firm that it's an estimate. The type of APCs is indicated also the amount then based on feedback from our pilot users we've identified 16 different 1616 different charges and discount. So for instance membership society membership discount or extra charges for speed of publication. All these amounts can be filled out and in the answer to this eligibility inquiry the University of Amsterdam can indicate line by line if they accept it or in full or partial. Now here I want to stop quickly because the send to in this case in DAWI this message the eligibility inquiry can only be sent to a party and affiliation a university or a funder that bears a relationship to this manuscript. So if only the University of Amsterdam is here in this form then this message can only be sent to Amsterdam. If and you'll see that in a later demo if also the Gates Foundation has provided funding or there's also another university involved here the publisher needs to choose who to send it to. Obviously the same message can be sent in parallel or sequentially to multiple recipients but it can never be sent to a party that bears no relation to the manuscript to the submission. And here somewhere in this dashboard now this message I think it's the second one appears an E1 is this eligibility inquiry from the publisher to the University of Amsterdam and at the moment it is awaiting the response from the University of Amsterdam. Here you see arrows and that means that there is a follow up messages this E1 that you see here has a green tick and it doesn't say awaiting response it basically means that it has been responded to. If you would click on these messages you zoom into the actual message and get all the detail. So this is pull down arrows if you would click on that I can't do that here it's a screenshot you can see all the underlying messages that are related to the one that we sent. Okay the filtering and the reporting I'm going to show to you from the point of view of the University of Amsterdam and I will show in one video the reporting which is exporting files and the filtering which is on screen. So top right corner you see University of Amsterdam they will not compose a message they will go to reporting. Here is a number of criteria that can be picked whether only eligibility inquiries with related messages or only publication notification. You can indicate as a university for which publishers you want to get the report also the time period also various other things again we get continuous feedback on what to do here. And then the export nowadays is both possible in Excel and in Jason. After this video I'll show you simply how the Excel file looks like but left bottom corner that is where your export the Excel will appear. It's as simple as that basically all the data fields in the messages can be exported. Now the filtering top right corner that is on the screen real time. If you just want to have a quick glance this one has improved in the meantime as well you pick from Hindawi to the University of Amsterdam for a certain time period. The results will be displayed on the screen. By now and this is a version from the beginning of this month but by now here you see 7,312 the sum of the money per currency we will now also show the separate currency. So if hypothetically Hindawi has sent eligibility inquiries or publication notification messages for say euros as well as Canadian dollars. And also the amounts separated for the P messages and the E messages you get a number of lines where you currently see here some of money that will be shown and it just gives you a quick glance. Obviously you can get the same if you do an export, get the Excel and play around yourself. This is just a quick way in a certain time period maybe for a certain publisher that you want to see how much did I commit to how many of these eligibility inquiry messages. Did I approve? I think that's the end of this video and then the export, the Excel, it is just a huge, huge file. There's more details now already in a new version. Basically what we've done also with input from Ruth and from other pilot users is check all these data fields against lessons learned and recommendations and templates from other projects. And from other purposes to be sure that we export everything, but obviously also that we have all the data fields in the messages because that's what it all comes back to the standards of the messages and the message structures. But whatever we have in, you can report on. Now the last demo, let me check yet. I think we're doing fine on time. The auto suggest or auto reject with the iteration five, we have enabled the functionality to keep master data on central away funds in the switchboard. And what does that mean? I mean, say if the University of Amsterdam has a central away fund, but it's only available to gold journals, gold OA journals and the journal has to be in the DOAJ and the APC amount should not be more than 1500 euro and Amsterdam never picks up additional charges like color charges or whatever. Again, any of these fields, if we can identify them discreetly in the in the form and in the funding, sorry, in the central funds policy, it can be configured. And we've done that so that the eligibility inquiry can get an automatic answer. And in this next video, I'll show a basic, basic functionality of that. So here we are, hindawi again, the publisher creates an eligibility inquiry, enters author name. And in this case, we're going to add multiple institutions for that one author. And we've configured different master data on the central away funds of the University of Amsterdam, the University of Exeter. And this is all just testing. And this is not real. Leiden University are all in there. So the mandatory fields. And as part of the pilot, which is ongoing as we speak, we're working with the funders and the institutions to find out what are exactly the mandatory fields that they really need as a minimum to be able to answer the question of whether the publication has the potential to meet the requirements and whether central funding is available. We have to go through the motions again, put in the APC type of APC for more estimate and an amount. And now we get to, and I'm going to pause here because now and we're working on the indicator. So apologies for the visually impaired or the colorblind, but there's three different colors here. The University of Amsterdam has a green dot, Exeter has an orange one and Leiden has a red one. And this is an author suggests because we know that the University of Amsterdam is a participant in the switchboard. And they've also indicated when we set up their account, they have a central away fund. So it's a good idea to send this message to Amsterdam. Exeter, for the purpose of this demo, are orange and they have an account in the OA switchboard. So you can send the message. Actually, it will be delivered if you choose to do so. But Exeter has indicated they do not have a central away fund, which I know any reality isn't true. But again, just for the purpose of this demo, then it's maybe not a good idea to send it because they have informed us that there is no central away fund. Now Leiden, we don't know because they don't have an account in the switchboard. So we have no idea. It's a red dot. It will be coming back to you if you're Hindawe and you're still trying to send this message as an undeliverable message. So you get it in your dashboard, but it will never be delivered. I already mentioned the issue of privacy and maybe commercially sensitive information, especially if there are read and publish agreements and transformative agreements. One needs to have a contract in which we deal with this privacy issue and confidentiality when we set up an account. So there is no way that people can just go in the switchboard and play around to get information. You have to set up an account and comply with the relevant levels of security. Good. And this is the auto suggest functionality. I can't show you now, but it is live in the meantime, the auto reject. So if we had put in here, I don't know what either, well 1500. Actually, we have configured Amsterdam that the journal has to be in the DOAJ. If you don't and you push send, it will come back and you will get the message auto reject because it doesn't meet the requirements of the recipient. Okay. I think we're doing fine on time, David. I've tried to speed up. This was what I could show you. I think I should just open up and see if there's any questions or discussion. There certainly are. Thank you. That seemed to be really clear. So just a couple starting from me and then I'll go through the questions. So every each institution would have a single contact person or who would set up an account with the switchboard and then would enter these details that you've just been describing. Yes. Okay. So that will be done centrally. Okay. Question about how that works for publishing read deals where there's no individual APC transactions under by the institution. So I guess for the UK has an agreement with Springer. How would that work? Right. I didn't show you a demo but it is on the website. We do not keep details on the content of the read and publish agreement. So the most basic eligibility inquiry. So number two, sorry number one, compose an eligibility inquiry in case there is a prior agreement is the simple question. Here we have this author. These are the journal details and this is the name of the deal. Say, I don't know, RL UK and Springer in this example. And do you agree that this article is covered under your agreement without any financial details? That is the most basic form. It's what people now I think already do either by email or in other formats. It's a validation. We're going to charge this article under our existing deal. Do you agree? Now what we have added on the request of some very engaged pilot users is that it is possible because apparently that is sometimes relevant that even if there is a prior agreement in place, there is still something to be confirmed around the finances. So exactly all the data fields around APC and everything I've shown you around APC and also additional charges and discount. We have that as a second step in the prior agreement functionality and then there is the choice. We do need to specify financial details, yes or no. But what we don't do maybe just to really clarify anything that's in your contract. We don't maintain or host that in the in the switchboard. It's just to check against what you have in place and getting a yes or a no. It was Anna who asked that question. It's an indication chat if that's answered or if you have a follow up to that. What we can do while we will do that is in the chat actually there's a question about. Anna is responding yes but interesting if there's a cap with Wiley. Is that a cap in the total number? Can we put Anna on? Can we make Anna not mute? Maybe she could ask the questions directly rather than have me try to interpret it. Can you hear me? Yes we can Anna thank you. We've got a deal there as well but there's obviously a cap on the amount of articles we can publish across the UK. And also interestingly there's some discussion on which type of publications are eligible or not. But presumably these things can be worked through in terms of the criteria and what's recorded in the dashboard. I would think so definitely the type of article I didn't show you but there is a field next to article title. There is also article type. So we've taken the what is it? I forgot there is an industry standard of I think 31 article types. So we try to work in general as much as possible with existing standards and lists and pulldowns. So yes there is a field for article type and that is one. And then the cap yeah I think I'm thinking out loud now. Yeah I think if that could be in a master data right? Well the cap is UK wide so it's interesting how that works. That is interesting. This is why we don't want caps at all you see but that's another discussion. Okay let's take that off fine because I indeed don't immediately see how we would do that for you. Okay thank you that's fine. Stay in chat just for a moment. Jane was asking about any plans to integrate the switchboard with JISC monitor. Yes talking to them. Like I mentioned we talked to many people. We are talking with Frank Meniste and his team to do exactly that. So the reporting that I was showing the E1, the P1 messages would be feeding or it would be possible to feed those straight into if you have a JISC monitor local. I think it is. Sorry for not knowing the details but yes definitely. Okay thank you and I noticed that Liam Ernie is on your steering committee. Definitely. So there's obviously a very strong connection there with JISC and some of those. Then back to the Q&A so Mamwana is asking about interlinking publications to research data at some stage possibly post publication. Yeah at the moment because we know it's a requirement from some of the funders. We have a field that with the publication the research data will be deposited somewhere or at the PMC or somewhere because we know that that is a condition for picking up the APC bill. No further details yet. We haven't explored it but yeah it could be. Okay and then there was a second part to this which was considering including the switchboard API making also actionable and interoperable DMPs and we may need to get Manuela on because I'm not entirely sure if Manuela is there. Do you want to expand on the question a bit? I don't know what DMPs, maybe I do know but I don't immediately recognise DMPs. Can we get Manuela to data management plans? Okay so integrating with data management plans. Could you elaborate a bit on what that would mean? She's not able to unmute herself, let me see if I can do it or maybe we might have to ask Mel. Mel can do it for us. Okay. I haven't muted so Manuela if you turn on your mic you should be able to speak. Yes hello, hi, thank you. I did not notice the message that was allowing me to unmute myself and I was just wondering in case as I was asking also research data was going to be integrated in the APIs which seems to be, that could be a possibility eventually, whether especially from the funder's point of view also DMPs which are documents written by the researchers at bidding stage to compare the requirements of the funders, whether these documents which at the moment are being given some pits, some DOIs in general as a standard that is becoming a bit more implemented, whether those two will be integrated in the APIs as documents supporting in a way the research data as well. I hope it makes sense. I think it makes sense, or sorry, I think I understand what you mean. What we have, and maybe let me just quickly start that video again, you might see on the screen that there is a funder name, a grant ID and grant name. We haven't done much with those fields yet, but like we have with the Roar integration with the institutions, I can imagine and we still need to talk to Crossref that there is something I think I should pause here for you to see it. Hold on. Anyway, what we haven't done yet, we have a field for funder for grant name and grant ID and I'm aware of what you're saying that more and more of these grant documents get a DOI and I also know that Crossref is doing something in that space and I'll be talking with Edpence later this week and also Jeffrey Builder is one of our technical advisors and Brian Vickery is on our advisory group, so we should look into that if that can somehow be integrated. If that is what you mean? Yes it is. Thank you very much. Can I just ask you something as well? I was going to write it, but maybe I can just ask you since I am talking to you. Can I ask you whether you will add in the metadata fields also the 14 credit rolls which are just in the credit list for the various authors rolls? Thank you. It's in already actually. It's not a mandatory file. You should probably just have this video keep on running running because you see credit in the third row and again the 14 ones standard are in there as a pick list. So credit is there. Now at the bottom you see funders grant name, grant ID and this is perfect questions and feedback. This is exactly what's happening with our pilot users all the time. We show the demos, we talk about it and we get these kind of questions and we look at what is reasonable and some things are easy to fix in the next iteration and some things we just need to park for continuous improvement cycles. So thank you. And Anna has asked a follow up question about there around the grants and the grant IDs and can you can you actually allow multiple grants to be linked to a single publication? Yeah, definitely what we've chosen now because it already got so full and complex as a form but technically there is no issue whatsoever. We currently have done the funder, the grant name and the grant ID at manuscript level, but it's ever so easy to pull that up to the author level and also to like we have with you see here at other for fees and other charges and discounts. The same we could do for grant. We just simply haven't done it yet. Okay. I think we've exhausted the questions both in the Q&A and in the chat. I should have checked with you before, but I don't know if you're going to say a few words about what's next in terms of the MVP will be launched in August, I think you said. What can this group, what can the participants who are on this webinar today, what would you like them to do? Can they get involved? What's the next stage there? Well, that's a really good question, David. Thank you. We at the moment have three universities from the UK as part of our pilot users, but we can absolutely manage more. So basically that means you get in touch with me. There is a very simple contract basically to agree that there's no money exchange and that we observe GDPR and that kind of stuff. Then you, in a day, our tech partner will set up an account for you and you can start playing around. That is one thing and you can give us feedback. And as you see in the top continues improvement cycles, depending on our funding, we are still incorporating feedback and improving as we go along. Another thing might be that there is a very specific topic, maybe with a specific publisher. We have those pairs account names, but there are some publishers and institutions who have indeed contracts and who have a glitch in their current workflow. And they are now, as we speak, using this sandbox environment to iron it out or to see if we can, with the switchboard, make it easier for them compared to what they're doing today. So that could be a second thing. If you have something very specific that you want to test yourself, we can provide it. There is maybe a matching publisher that might be the requirement. We can do that. And then as we move on a completely different topic, but we are starting to think about a pricing model for 2021. And I already mentioned this is not for profit. This will work best if everybody participates. The beauty there is that if all publishers, institutions, funders participate, the service will work best and we can lower the price. Basically we can do it as advantageous as possible, but we're cracking our heads on how to do the pricing. So if there would be anybody in this group who wants to think along and we have some ideas, of course we have ideas, but think along and give us feedback on how we can do this because also here we want to do it in a fair and transparent way. We are going to be, we are actually completely transparent on the finances of this project, how much it costs and how we're funding it, but also moving forward. We will be completely transparent on cost and pricing. So, yeah, anybody who wants to think along on fair and transparent pricing to make this available as cost effective for everybody, that would be great. The question about knowing who's involved in terms of publishers and funders. So, I'm looking on the website at the moment. You've got some, you've got a list of contributors and sponsors, but if you were thinking, oh, we have a problem with publisher X, how would we know, or would we just write to you? You write to me, because to be entirely frank, this is indeed so far one of the things and OSPA doesn't like it. It's clear about that, that we have not yet disclosed the pilot users, but some, to be honest, were keen to test it out, but it was way too early for them to openly support the OA switch board. So that is honestly the only reason why the pilot users are not listed. One final question just come in about modelling the, how things might be affected by how plan S changes, how transformative agreements and such like change. I mean, is a switch board almost independent of those models? Yeah, because we aim to be global and neutral and everywhere. But of course, if there is the same with what was mentioned about the grant IDs, if Crossref is the one who is keeping a registry of DOIs and what have you, it makes sense to enable that or facilitate that. But we are independent of coalition S and we are, and that is one of our challenges to be quite frank, we are serving publishers and funders and institutions. That's why I keep on saying where back office and then it kind of boxes what we could do, but we could not do something that makes institutions unhappy because then none of you would participate right and we don't have a service and the same with the funders. So, yeah, this is our balancing act. This is what you deal with if you're an intermediary, right? Yeah, you have to keep everybody happy. Definitely, yeah, which in a way keeps it, we can't get carried away with fancy dashboards and services because that possibly is likely to not serve all three equally. OK, well, thank you. Those are the questions. Can I hand over again to Ruth, who I think is going to take us to the close? Thank you. I'll be very, very quick because we're nearly half of the hour, so thank you to everyone for joining us. I wanted to say thank you to Yvonne for the webinar for answering all the questions. I am, as those people that know me, ever an optimist in these areas, so I'm hopeful that we can get this working. But as Yvonne said, if you want to take part and we'll have any questions, I think she is the best person to contact. You're welcome to go in contact with me if you want something passed on. And just quickly also to note, I did put it in the chat, but I did have a conversation with Frank just a couple of weeks ago and just not really interested. So they are talking as well. If there's anybody else you think that needs to be involved, then do let Yvonne know. Yvonne that, thank you very much everyone for joining us.