 Hi there, my name is Kathleen Shear and I'm the Executive Director of CORE, which is the Confederation of Open Access Repositories. It's my pleasure to be here at CNI, well virtually anyway, along with my colleagues Martin Klein and Paul Walk. We're going to provide you today with an overview of our recently launched project called Notify, the Repositories and Services Interoperability Project. CORE is an international association with over 150 members from 50 countries around the world on all five continents. And our aim is to enhance the visibility and application of research outputs through collaboration across the global repository network. Next slide please. So through a whole range of different activities, CORE has been working to increase the value of open access repositories since the organization was launched in 2009. Particularly relevant to this project is some previous work we've done around the future visioning of repositories. So in 2016, CORE launched the Next Generation Repository Initiative, which articulated, I think, a really important foundational vision for repositories that really guides much of the work that CORE does today, including the Notify project. And the vision is to position repositories as the foundation for a distributed globally networked infrastructure for scholarly communication. On top of which layers of value added services will be deployed, thereby transforming the system, making it more research centric, open to and supportive of innovation, while also collectively managed by the scholarly community. This project brought together a group of technical experts from different domains and regions. They developed a number of user stories that really kind of describe the desired functionalities or behaviors for repositories of the future. And then we identified 19 technologies and protocols that would support those user stories. So CORE published a work in 2019 CORE published the PubFair paper, which grew out of a European Commission project proposal. And it kind of brings together a lot of the functionalities described in the Next Gen repository work, but more into a cohesive conceptual model. So PubFair is described as a modular distributed open source publishing framework, which builds upon the content contained in the network of repositories to enable the dissemination and quality control of a range of research outputs, including publications, data and other types of research outputs. Unfortunately, the project wasn't funded. So we decided to go ahead without external funding to really advance one specific aspect of this work, which is connecting repository contents with review services. And critical to all of this is the principle of a distributed environment, which is kind of contrary to what we see today where a few publishers are really controlling a lot of the scholarly communications landscape. The distribution of content and services, we believe will support inclusion in the system, all repositories who wish to will be able to participate. It will allow us to support a diversity of needs across the global and multidisciplinary communities, and also reduce the risk of a single point of failure or commercial buyout. Next slide please. One key aspect to this distributed model is how repositories will connect to other value added services, and that's what the notify project is all about. We launched the project in January of this year 2021 and we're working with a number of implementation partners to develop a standard and interoperable approach that will link reviews and endorsements with research outputs in the distributed preprint servers, archives and repositories. And our implementation partners represent a mix of repositories, preprint servers and review services. Next slide please. So, I think it's important to note that the technologies in this model can really be applied to a huge range of different types of services and use cases. For the sake of this project, we're really focusing on linking repository resources with reviews. And that's because there's been this huge rise of preprints during the COVID-19 pandemic. And there's a really strong interest right now in the community about how we can link preprints with peer reviews in a standardized way. So on that note, I'd like to turn it over to Martin to provide some more details about how all of this will work in practice. Thank you very much Kathleen. So I'd like to take a few minutes here to further introduce the notify project by means of describing an example use case that at this stage of the project is squarely in the scope for for notify. I would also like to highlight the interaction between the parties involved in this use case as visualized here on this slide. On the left hand side we see parties involved such as preprint services and repository platform so basically publishing entities, if you will. And on the right hand side of this slide you see review services such as pre review elive publons that offer their peer review services on the web. So this use case is really about a publication platform let's say a repository that hosts preprints, requesting a peer review on this preprint from a party visual or displayed here on the right hand side of the slide so for example from preview or publons. So let's maybe make this a little bit more concrete. I picked two examples for each box to go through the interactions in this use case, and to also highlighted the benefits that each party can take away from being part of this workflow if you will. So on the left hand side we have our deep space repository platform. On the right hand side, we have a review service preview that are now ready to go and request peer reviews. So the first thing that these two parties need to do is to establish and implement a little bit of software basically to foster notifications being sent back and forth for the sake of communicating between these two entities. Our communication and notify is done by means of sending notifications specifically linked data notifications between participating parties. So being able to send and receive linked data notifications implies that each party has, of course the capability to receive notifications but also has the capability of sending that notification. In order to receive a notification you need to be able to have an inbox that is according to the link data and notification specification discoverable on the web. So let's assume each of those parties have that capability. And let's further assume that the deep space repository on the left hand side hosts a preprint that is identified with the URI URIP in this case. The deep space repository wants to request a review on this preprint from the preview service. So what it does is it sends a notification a linked data notification to the preview service and indicates in the payload of this notification of course the URI of this preprint and saying I would like you to review this preprint identified with the URIP. So by sending this notification on the preview end probably triggers some process where the service considers can it actually accommodate this request cannot do the review or is it maybe at capacity and cannot not do this review. For the sake of argument in our use case here let's assume preview view is willing to do the review, and we then send an acknowledgement notification back to the deep space repository indicating. That's fine. I accept your request. I will be doing this review as requested. So at this stage already. Now, both parties can establish some sort of bidirectional linking and can provide further information about their resources right on the one hand side the deep space repository can indicate that it's really its preprint the preprint that it hosts is currently under review by the preview service on the right hand side of this slide. The review service on the other hand can say I am currently under do conducting a peer review of the preprint hosted at the deep space repository over there on the left hand side. And of course, the peer review is done is conducted, and the preview service publishes a resource on the web that represents the peer review, and it has an URI let's say URI are for the sake of argument. Upon completion of the peer review, the review service will send another notification to the deep space repository informing the repository about the completion of the review. And the corresponding URI URI are in this case. So now the preprint I'm sorry the repository service knows that the peer review exists and it is accessible on the web. And it's identified by your IR. The deep space repository could, let's say update for example the landing page representing the preprint and state that the preprint indeed has been peer reviewed the peer review is complete. And even more so, it could link to the created resource hosted at the pre review service that represents the peer review. So one can connect to the preprint and the peer review. On the other hand, the previous service can do the same thing. It can, as mentioned, publish the peer review identified by your IR and it can indicate that this peer review is based on the preprint identified URIP hosted at the deep space repository platform. So now we can really establish bi-directional linking between both parties playing in this use case for requesting peer review, conducting peer review and notifying each other of corresponding process. All right, so the notify, notify project in this underlying model really fosters interoperability between individual parties on the web. So we have our publishing platforms repositories preprint service and the like, and we have our, let's say value added services, such as peer review and the model utilizes widely adopted standard web protocols such as linked data notification, as I mentioned, and also activity streams to as basically a vocabulary for the payload of those notifications. Given the utilization of the standards, the implementations are really agnostic of platforms or services so it shouldn't matter, matter whether we're talking about a deep space repository or let's say met archive as a preprint service, or a peer review service or three. In addition, we emphasize that we're building on a distributed network of these parties as Kathleen has already indicated, right. So our content providers are publishing platforms and peer review service are really playing in a distributed field here. And that's really important to us. The use of these standards and the emphasis on a distributed infrastructure, we really believe that our model can scale right different parties that you can envision are our in scope can participate in the in the project and adopt the model and the technology. Given that the technology is widely used will be able to lower the barrier of adoption by potentially re utilizing or re using existing infrastructure existing code existing libraries, let's say, right. And Kathleen also indicated, given that we're not relying on existing dependencies between parties between services, we're really increasing the system ability, because we are not banking on the fact that there is a central party in the picture that takes care of our notifications, let's say, I think it's further important to stress that the notify model really supports a wide variety of use cases. One use case I just outlined, but we can think of other use cases where the notify model would be applicable let's say we've heard of use cases where repository platform sense notifications to an archival service to basically trigger the archiving process of just ingested web resources. We can further envision notifications being sent back and forth between pre print services and say commercial publishers to establish bidirectional linking between let's say the pre print your eye and the version of record your eye. Let's say, so a broad variety of different use cases that we can envision for the notify model here. So with that, I'll hand it over to Paul for the next stage of this presentation. Okay, so I'm going to talk briefly about the, the actual development projects and what we're doing in terms of working with our implementation partners and what our intended outcomes are. So, the primary activity is to develop some reference implementation so we have a conceptual model which is quite well defined now we're close to having our first cut of the actual standard that we want to use for describing the payloads in the notifications. And so now we want to really begin to work with our implementation partners to actually develop the necessary software for exchanging notifications between repositories and and services. And the intended outcome is to have one or more reference implementations which we can point people to which will be documented, and which will really show how this, this approach to interoperability between repositories and services can can really happen. Another sort of adjacent activities of that is to actually coordinate or to provide a place where the people involved in those developments can collaborate, compare notes and seek peer support essentially. And at the same time maintain that focus on on interoperability make sure that we're, we're all working to the same conventions and using the standards correctly. Part of that is going to involve actually establishing some practices and conventions. So, the standards which we're committed to using but we believe that we will need to develop at least one vocabulary for describing the types of activities which will be involved in the between the services and repositories. And we may may need to develop other vocabularies in time, and also just establishing good practice in terms of applying those those standards. The particular core standard that we're using is activity streams 2.0 and this is a very broadly interoperable standard it's it's quite forgiving in its structure and in ways in which it can be used so we need to create some conventions that make it easier for people to to implement in a consistent manner. And finally we need to engage with the wider development developer communities involved in building and maintaining some of the platforms which are used typically by our repositories and and some of the services as well. So that we can get the leverage of engaging those those platform development communities if they will adopt notify then that makes notify available to a much larger set of repository and service instances. Next slide please. So in the course of working with our implementation partners we've identified three broad use cases and we're working on developing documentation of scenarios within those use cases. For the point of view of the notify project scenario is is more or less a simple workflow, which can be implemented with an exchange of notifications. So the broad use cases are as as was previously described. Connecting repositories to review services so peer review of repository based resources. Similarly connecting repositories to what we're calling endorsement services so this would include things like overlay journals, particularly when those are represented in our project. Basically, a slightly less clearly defined broad use case but we've had some interest from people who are maintaining services which already consume information about endorsements and about reviews and then make those make that information available to users in in streams and channels and so on. They've reached out to us to work with us so we're certainly looking at how those kinds of downstream services which might be based on for example aggregations of review events which have happened between repositories and review services. How those aggregations can be built through an asynchronous notification approach and made useful to end users. So next slide please. So the the specific outcomes that we're looking for outputs from the project. First of all there's there's validation so this this project will serve as that sort of central hub for validating the implementations which people will be building and have already started to work on. It's possible that we will build a technical validation service. We're not quite sure if that's necessary yet there are available components for validating linked data notifications in general so some combination of technical validation processes and just community validation of what people are doing. We'll be an important part of this work. We're still figuring that out at the moment. The community conventions that I alluded to earlier and we've already started work on the web documentation for for this. I'll be able to show you a picture in a moment and documentation of the vocabularies, which we believe will need to be developed to to support these use cases. Some kind of shared knowledge base relating to the technical implementation. We imagine that implementers will discover common problems and common solutions indeed in terms of actually implementing the software required to make notify work. They're already available open source libraries of code which people can use and we will make sure that people have information about those and the links to those and then we'll be I hope gathering some information from our implementers as they work with those technologies. There's a range of interoperable working platforms so this is essentially the reference implementations now. Our hope is that as as we gain some momentum here then we will not only have our core reference implementations but we'll start to capture information about other people who have implemented the notify technology. That leads us to the last point on the slide which is the expectation that we will build a catalog in fact of services and repositories which have implemented the technology and are therefore able to participate in the notify interoperability approach. And so next slide please. So this is just a couple of screenshots to give you a flavor of how we are documenting this these are already out of date I'm afraid this is a very rapidly moving project but it gives the the right idea. On the left we have the documentation of one of the scenarios I was describing essentially a workflow, and we're using the swim lanes approach from various modeling approaches actually. So in this case the there are three swim lanes that the lane on the left represents in this example represents a repository system, the lane on the far right represents a review service and the lane in the middle contains the notifications between those services. And then we can detail the notifications and explain the actual payload that will be involved mandatory properties and then possibly some optional properties to affect that that workflow. So these scenarios are deliberately quite simple they're linear. They're quite limited. But this is how we we aim to achieve broad interoperability by breaking it up into this kind of size of problem. And then on the right we have just an illustrative screenshot of one of the notifications with the JSON payload on the right. This is already very out of date so please don't assume that this is the correct payload and we've revised it considerably and the website will reflect that. But again it's showing that each notification will have mandatory properties optional properties and then the the actual JSON payload example there for for reference. Okay and next slide please. In fact that's our that's our final slide so if you are interested in following up then the only URL you need to make a note of is the one there the short URL there and that will contain links to to all of the activity. That's under development as well so all of this is quite rapidly moving at the moment, but that link will give you the the starting point to to all of our documentation and so on. Or if you're interested in actually engaging with the project in some way have a question then please drop an email to office at core hyphen repositories.org. And that your message will be rooted to whoever's appropriate to answer it probably one of Kathleen Martin or myself or possibly all three of us. But please feel free to get in touch with quite excited about this and we're open to talking to anybody who's interested. So thank you very much for listening and goodbye.