 So, welcome everybody, welcome to this first breakout session on the, let's use the acronym SRAA. So, you have the title in front of you, the Strategic Research and Innovation Agenda. I will try to explain, you know, where it fits and hold the movements around the EOSC and also make some links with other sessions that will occur during the day. And since the EOSC Interoperability Framework, as was announced by, mentioned by Catherine in her introduction, has been published yesterday and is now open for comments, there will be, towards the end, a highlight on the EOSC Interoperability Framework as it is so fresh. And Oscar Corsche, who was one of the editors of the document, will join us. I know he's in another meeting, but he will join us during the session and be able to answer questions. All right. With that, let's move into the presentation of the SRAA. So SRAA, if you can go to the next slide, please. All right. So, first of all, I chose this slide as an intro because this is the beginning, today is the beginning of a long journey, which will take us early October with the final version of this document that is just started to be developed as we speak, right? So there is not even a full draft as we speak today. And there will be, hopefully there will be one by the end of the month that the Executive Board will be able to review as well as the Governance Board a few days later. And then the main part of what would lead us to the October will be an open consultation over July, August, and September. So we know that there are vacation periods at that moment in time, but we felt that if we pick a three-month window, it will give an opportunity to everybody to contribute. So bear with us. This is just the beginning, but we wanted to take the opportunity of this Consultation Day to introduce where we are, and of course, more importantly, point to the open consultation that will occur over the summer. So next slide, SRAA, please. All right, so we're not starting from zero, so we put together a table of contents which I will review very briefly. So first of all, of course, yeah, so before I get into the details of the table of contents, first, what is the audience? What's the purpose of this document? So I will connect it to what's going on in general, but at this stage, looking at the table of contents, I just want to share that this document will be for anybody who is interested in YOSC. So that goes from, of course, the European Commission and the state, but to all the infrastructure people in charge of working within infrastructure or funding organization, and of course, any scientist. So it's a challenge in designing this document to have a single document that will be made available as a reference document for such a diverse community. So we have to have that in mind, and there will probably be an how to read section, how to read this document section at the beginning to help people focus on the parts they're more interested in, but we have to have that into our brain, right? This document, at the end of this year, the 1.0 version of the SRAA will be the reference document of what has been done so far and what we intend to do in the future related to YOSC. It's sort of a snapshot of where we stand at the end of 2020. So briefly on the table of contents, introduction of what's happening and the impact of the rise of the digital age to the movement towards open science, part two, connect this overall movement to what's going on in Europe. The third makes a little bit of history and reminds everybody that we're not starting from scratch at the end of 2020, but the whole program has been conceived in 2015. It's been officially launched in 2018. We are ending the transition period, 2018, 2020, and we reach a sustainable organization in 2021. The values and principle is where we are at the moment. What has been decided related to YOSC, so four elements, the fact that it's multi-stakeholder, all the people that I mentioned a few minutes ago will be welcome and engaged and contributing to the evolution of the YOSC, key choices, openness of course, and are there any limits to openness? We know that there are privacy, security, property, but still it's as open as possible as close as necessary. The fair, I won't get into details here. It's clear that it belongs to our values and principles, and the fourth element, which I will focus a little bit more in this presentation, is the fact that YOSC will be a federation of infrastructures, so existing infrastructure, of course, will continue to evolve and develop and provide more and more services to scientists, and the purpose of the YOSC is to federate those infrastructures to provide an extra value add for the scientists. Today we won't get into the details of the next two parts, technical challenges and societal challenges, where work is ongoing at the moment to try to have, again, a status of where we stand, identify the gaps, and then identify priorities. I'm sure that most of the discussion during the summer will focus on identifying those priorities, agreeing because we may have different opinions on what should be the priorities, and merge them, coalesce them into a multi-annual roadmap, which will be part seven and together with Timeline. The document will end with the expected impacts and the role of science in the implementation of Europe's strategy and will end by opening all this effort to the whole world in part nine. So this is the table of contents as it is put together at the moment. Next slide, please. Okay. Very briefly, Catherine showed, this is the link to Catherine's first initial presentation on the Objective 3, and the fact that after trying to not agree well, to share our vision of YOSC, here, this slide summarizes the fact that YOSC is about people, mostly scientists and others that have to play into the game, trying to leverage the ever-growing available data, or scientific results in general, and data in particular that needs special attention, and share them within infrastructure. Today, you know, this vision has its limits that are described in the barriers, and the objective of YOSC is to enhance the situation by making open science the new normal, providing the standards, tools, and services that will allow researchers to find access and reuse available results, and federate the infrastructures so that open science can be developed on the whole available set of information across Europe in the first place, and the world in the second place, with benefits, of course, for science, to do better science industry, develop innovative services and products, and by having federated infrastructure being able to address societal challenge as scientists. So, next slide. So, putting in context, so as you all know, at the end of the year, we will move from the Horizon 2020 program, which we've lived into for seven years, to a new program called Horizon Europe, from 2021 to 2027, and this program will have partnership. We're already partnership is Horizon 2020, but when a program starts like that, new vision or new mechanisms are put in place in order to organize partnerships. This slide presents the current, I think, 47 existing partnerships. The color, they are different types, so the color describes various types of partnership for Horizon Europe. And next slide. And among this, the grand total of 49 partnerships in the works as we speak, and of course should be ready when Horizon Europe starts January 1, 2021. The European Open Science Cloud, EOSC, is the only cross pillar partnership. Pillar refers to the three main roles, main goals of the Horizon Europe, better science, societal challenges, and innovation. And some, depending upon what they are, they are focusing more on one or the other, except for EOSC, which is the only one that goes across since its impact, it's on all scientists and all infrastructure existing by definition. So it's the integrating factor of the rise of the digital age that makes EOSC such a cross pillar partnership. Okay, even if it's a cross pillar one, it's a partnership like any other. So it has to be sort of a partnership proposal described by Catherine, briefly described by Catherine in the initial presentation as to be applied to EOSC. So next slide. Okay, so I'll go fast on this one. So this is, again, a link now forward after this session, there is a session on the sustainability, which will present all the details of the partnership. Just the exercise here is to look at whether there is the SRA acronym on this slide, there is on the left hand side. This would be one of the mission of the EOSC association, the EOSC legal entity, which will be created at the beginning of next year to be the owner of the SRA. So the SRA we are developing now before the association is in is in is working. So this is just the bootstrap the initial one, the 1.0. And then over the seven years of the partnership, the association will be in charge of evolving the SRA as work progresses and deployment progresses and so on. So, so this is the link between this presentation on the SRA and the evolution of the structure around EOSC. Next slide. Next slide, please. Thank you. Let's focus. It's impossible to cover in one hour the whole range. So, since we're at the very beginning. I chose to highlight the part four values and principle, and, and even in particular focus on the federation part. So next slide. Okay, multi stakeholder already mentioned when I addresses the table of contents and the fact that the document is for everybody every actor every stakeholder should find the document as its reference. The two key principles openness and fair will be covered in many other instances, including in during this day. To end this presentation, I will focus on the federation of infrastructures. Next slide. So I will first say a word on the minimum viable us and this will have to be connected to the session. This is shared by Carol tours in breakout three, which is about minimum valuable EOSC. So, alright, so we're playing with the vocabulary here. So let's start next slide with the minimum viable EOSC. So the minimum viable EOSC has been defined in one of the sustainability working group document, the current one called the Timman document. And that sentence says minimum viable EOSC will enable the federation of research that infrastructure for the benefit of publicly funded researchers accessing openly available data. And the document goes on by highlighting the three key components that are necessary for that to happen a mechanism for naming and locating data and services mechanism for discovery of and access to the services and a common framework for managing user identity and access. Next slide. So here we're, we're in the priority line of thought, right, we all have a maximum valuable EOSC in mind, you know, we all have a good, depending upon our role, our job and our expertise or our vision, we have elements, we have elements of the us that we feel are necessary. And one day, that's the vision part. This maximum valuable EOSC will exist. The question of address here with the minimum viable EOSC is where do we start. Right, so it's a priority question. It's not the question of whether one is better than the other. Of course we want to be on the right hand side of the slide. The question is by which action do we start. So that's the question of the minimum viable EOSC and in the session this afternoon. Carol will extend by saying, okay, it's one thing to be viable. It's another to bring value. So this nuance will be this not nuance, but this, this difference will be addressed during the session this afternoon. Next slide. Defining what the minimum viable EOSC should have the same document, the Tinman document highlight a number of property that that the minimum viable EOSC should have. And two of them I have highlighted the architecture will be covered in the two architecture breakout session one on AI right after and as a second breakout and another on PID in the third breakout. Next slide. Okay, and now the focus on the EOSC interoperability framework, which as Catherine said has been published yesterday. So you go to you have the links in Catherine's presentation you go to the years on platform and the first entry in the world the last entry days from yesterday and points you to the EOSC interoperability framework and Catherine also showed you the direct link to go to the to the document if you want to. So next slide. Okay, Oscar. Oscar, are you here. I saw you joining. Okay, so I was trying to unmute myself. I had to be done by setup. I asked Oscar was in charge of was part of the team who developed the EOSC interoperability framework so he was nice enough to reorganize the schedule to be able to present. So I leave the floor to Oscar to present the document that was published yesterday. Okay, thanks. Thanks. So, I mean, as it has been commented already, we made available this this document on Friday. I mean, it was already published during this weekend so that I mean you will have time also to read afterwards. And I mean, we really value comments on it. I mean, what we have been working on is on a first version of the document where we have been discussing which are the main interoperability layers that we have to take into account. Then requirements and recommendations and we will be asking you I mean like for a very first initial feedback on some of them that we will be presenting. We have already made an initial proposal of the model and components that such an interoperability framework should have. Yeah, so these are like the three core sections that the document has. Next slide then. Okay, so first of all, I mean, in terms of the layers, we are following the idea that has been already proposed in other interoperability frameworks like the European interoperability framework, which is mostly focused on a public administrations. Basically, I mean we identify four layers coming from the bottom the technical interoperability part where we are mostly discussing on authentication authorization, PAD, schema, APIs, and so on. Then we have the semantic interoperability layer where all the usual semantic artifacts, yeah, the need for metadata. The need for ontologies, the salary and so on is identified and we discuss which should be the elements that we should have in such a layer. And then we have the two top layers which are those related to agreements between organizations, organizational interoperability and also legal interoperability. In the current document, we have mainly focused on the three layers on the on the bottom technical semantic and organizational and the legal interoperability is currently underway. So it is not filled in in the in the current document. And it will be done by an organization that will be awarded a tender related to this study of legal interoperability. Next slide. Okay, so now I mean like we have like a list of some of the requirements recommendations that we have identified. And I mean, I will only try to highlight the most important elements that you can see over here. I mean, I'm not trying to be exhaustive. So if you go later into the document, you will be able to see all the all the details. But basically, I mean, like the main idea is that we are fostering the use of open specifications to ensure technical interoperability. That's quite common in all interoperability frameworks defining common security and privacy frameworks. There is also the need for AI processes that is common across communities so that the DCC to move from one community to another and I mean like to do this cross domain interoperability that we are always looking for. The need for service level agreements is also relevant and this will be also appearing again on the organizational interoperability layer availability of data sources that could be generic or community base. The need to allow data integration. The need also for having a way to search for data sets. And when we are talking about data sets and data in general in this document, we are also referring to any other research artifact. I mean, it could be software. It could be scientific workflows. It could be open hardware designs. I mean, basically anything that we are using in the context of research. And finally, we are also considering the need for PID policies and I mean, as you can see, I mean, there are connections with all the other streams of work that are being done and that will be discussed today. So this is for the technical layer. If we move now into the semantic layer. Next slide. And over here, I mean, you see that there are a few more recommendations, but they are all focused on the need for having semantic artifacts that are well understood inside communities and also across communities and allow us to perform these interactions in terms of our achieve this interoperability at the level that we can achieve it. Yeah, I mean, like we are and also document is quite clear in this context. We are always discussing that achieving full interoperability is, I mean, something that we would love to have, but there will be different degrees and these are the elements that we also need in this context in the semantic layer. We are talking about the need for clear and precise definitions for concepts. Even the need for having a classification of research disciplines. This is a minor thing, but I mean it has also been identified. They need to have good documentation of the of the semantic artifacts. Sometimes they just come as an implementation, but we don't have sufficient documentation. And the fact that they should be fair as discussed on the on the third principles is not only for data, but also for the semantic artifacts, the metadata and so on, that they should be preferably open. And I mean, over here we point to W3C where all the recommendations are open that we need to have repositories of semantic artifacts some communities already have them. And we have identified them in the in the document. I mean, not trying to be exhaustive, but giving some examples, but we need these repositories and governance models, governance frameworks for those repositories who maintains terms, how they can be maintained, how they can all these semantic artifacts be maintained in general. This is the possibility of doing extensibility. This means that if I belong to a community and my artifacts my data is described according to some ontologies and semantic artifacts. It should be also possible to have other communities coming in and using their own ontologies to describe the objects that we have. Why because this will allow also this cross domain interoperability. This is the discovery of federated research data metadata. And in general, I mean, as we have been discussing, we don't not only refer to data as data sets, but also to any other research artifact that we use during our research. Finally, if we move into the next one, we would have the organizational layer where we have a few less recommendations. Some of the previous recommendations for the technical and semantic layers are applicable over here. For instance, like the need for having a government of all these artifacts or the need to have proper procedures on authentication and authorization and so on. But over here, I mean, we mostly focus on talking about the rules of participation that should be completed with aspects related to interoperability according to our analysis of the current documents that we have. And finally, in terms of the services, we are also recommending over here the importance of having organizations complying with standardized data formats, vocabularies, corresponding metadata, and with some level of quality, which are quite relevant in this context. That said, if we move into the models into the next slide. There is a final part in the document, which is related to the models and components. As we have said, the basic components of the framework are the semantic artifacts. I mean, like ontologies, the salary, shared data models, and so on. We are quite like a wide or big in the way that we describe semantic artifacts in this context. So as to allow any artifact that allows describing agreements between different organizations, different communities and so on. We also say that semantic artifacts should be available in repositories, and these descriptions should be following a read metadata frameworks and elements, which could be at the generic cross disciplinary level. I mean, talking generally about methods, data, software, and so on, or using a specific community based interoperability frameworks. We use the term digital object to refer to all these research artifacts, and all the different levels of metadata will be associated to those objects in order to be more easily transferable from one community to another, or even inside the same community. I think that this is all from the general description of this document. Obviously, I mean, you have the document available to go further in details and we will be really happy to get additional comments on them in the coming weeks. I think that that's all. Next slide. Yeah. I think that Jan-François, your. Yes. Thank you. Thank you Oscar. And so just to finish. So it was just a reminder. This slide I maintained this slide because this shows you that this is work in progress. I mean, we are collecting the contribution on part five and six in order to determine the priorities for part seven and so forth. And all of that will be discussed in the coming month to be ready in October. Okay. And, and also the fact that we even shows you to the point we are in in order to get organized to be able to work together as a community. Next slide. So now we're coming to the discussion session or part of this. Before we get into into the Slido mechanism. Is there any pressing question at the moment by anybody? I know we have covered a lot of a lot of elements, a lot of topic, or maybe we stop. What do you suggest? Should we start with the Slido? Yeah, I think in the meantime I can put on the Slido. Okay, so we have prepared very general questions. Here we go. We have prepared very general question. The first one is related to the minimum viable you ask. So and the definition that was that came from the sustainability working group document. So, so do you have problems? Yeah, I'm just opening the slide. You should see the Slido, right? Yes. Okay, so now it looks like we are. We're on our way. We see the answers coming in. And I've seen that Oscar has addressed a couple of questions in the chat. I don't know Oscar if you want to further comment. Okay, it looks like Oscar, it looks like they are, they are generally questioning the, yeah, you've answered already, but on the on the focus and the, and the openness. I think that we can, we can probably first start with the, the MV part. Yeah, because it is the current, the current question. Yeah. And then we can go, go back into the original questions that I have tried to start addressing in the, in the chat, but I mean, they will come off with Slido. Okay, yeah, let's start with the, you're right. Let's start. So I will repeat that I've been, I've seen that there's been question in the chat. So a minimum viability ask will enable the federation of research data infrastructure. So that's the federation for the benefit of publicly funded researchers accessing openly available data. The, the message here is that if we, in particular, if we start with openly available data, well, it's simpler with this definition to get to, to some sort of low-hanging foods, right? So that is, that's things that we could develop and so forth and reach a level of deployment of the ask that will be very significant and from which we will be able to draw lessons to move forward. Right. So that's the, the idea of the minimum viable years. So, and that's the question which is running in the slider at the moment. So I, here we go. Thank you. And it will allow to develop the three core elements, which are mentioned at the bottom of the slide that you have in front of you, a mechanism for naming and locating data and services, a mechanism for discovery of and access to the services common framework for managing user identity and access. You need those, once you have those three mechanisms, you can deliver the minimum viable ask and start to have success stories. You know, real example of multidisciplinary development. Example within a given community of better communication, exchange and cooperation between scientists based in various places in Europe and so on. So, so the question is, do you see that as a, as a first step in developing the full air switch, of course, will address more complex problem, including addressing the issues of privacy, security and property, which we can work on now simultaneously, but not deploy. The minimum viable is refers to deployment. Right. The slide all gives a majority for the yes, probably some uncertainty or clarification or, you know, when I, I chose to have the maybe so that, you know, people who are not clear enough on the question can express their, their opinion and a few there are a couple of comments in the chat. Okay. Okay, so on. Yeah, implement. So I see question on implementation. So that's all on those three mechanisms. They are issues related to kids issues related to AI and so forth so they will be covered yeah it's intentional that at this moment in this session, we don't get into implementations but please attend the corresponding sessions where you will have answers on those on the initial course tours implementation both on AI and beats for example seems to me that they are necessarily simple services that's sufficient. So in my view they're not sufficient to qualify with this. Do you want to extend your comment. Is it possible to give the floor to Tiziana. Absolutely. Yes. You can speak now. Hello everyone. Thanks for giving the chance to to ask the question. So my remark is about what is the minimum viable years so what I noticed in this definition is that these are necessary support services but they don't provide the end user value as they are. So, in my view the minimum viable years could to be attractive the should provide user facing services in order to address the users and these are actually support services. So yes. I guess we agree. If we move to next slide. The next slide of the of the deck. It's clear we so the three mechanisms are have been put forward in a previous slide because they are necessary right and and they are not there. So if developing services if you don't have the three mechanisms or the common platform. It's necessary. I agree with you Tiziana and in order to be sufficient. So to define completely what the minimum viable yes. The mechanisms and that's why the words mechanism and framework are used because it's clear that with the mechanism you don't have a service right you don't deliver. So, however, we need the mechanisms to be agreed upon so that people can develop the services. So you're going to. Other questions. I'm sorry to sub sample there are too many. The MV seems rather resource provider oriented the minimum product should have at least one service for the customer, the researcher. Well, again, so I think it's the same answer as the one I just made to Tiziana, but yes, the mechanisms. The definition is user oriented since it's a publicly funded researchers access to openly available data. So the definition itself is user directed the three mechanisms at the bottom, the two mechanisms and the frameworks. Yes, they are resource providers so. And I think I have answered answering. I don't think I will be able to cover all of those. I suggest the jumpers to ask people to raise their hands if they want to express any remark. Otherwise, we move to the next question maybe. Yeah, it will be still time in the closing plenary to dress questions. Yes. Maybe we were too greedy by trying to address multiple topics at the same time. Anyway, let's go. Get to the second question about so if you can show the requirements. In the, in the PowerPoint part. So this one is on the technical layer, and then there are three right. This one. So the question is. Do you agree with it? With this state in this document. He asked one interoperability framework. Okay. Okay. I, I'm, I must I cannot. I mean, like, I agree with Rafael that there are. I mean, there is more need to digest all the, all the requirements. But I already saw several reactions here when I was doing the presentation, I have tried to compile them. In order to. I mean, to, to provide an initial piece of feedback over here. And in any case, I think that I mean, we will be happy to receive more feedback on this when you, when you go and go through them. Yeah, where there are more examples as well. There was one comment that was or a couple of comments related to open specifications and what we understood by open specifications. And basically, I mean, like what we are trying to say in the interoperability framework document is mostly that in all aspects, not only in the technical layer, but also when we are dealing with the semantic layer. The need. I mean, like, we would value much more having specifications that are open rather than those that may be closed. Yeah, and they may be more difficult to access or to understand by communities that are not using that specific model or or service or so on. Yeah, so we have examples. Yeah, I mean, we have put an example of W3C. There was also another example on the chat on HL7, which are open specifications. However, we have also ISO and we really have to balance it to have a good balance between the specifications that are open and those ones that are not open. We understand that a nice requirement would be to use as many open specifications as possible. Yeah, that's like a general, a general comment that we make over there. There was also some comment on SLAs on service level agreements where we say specifically that they should be easy to understand by users. And I mean, I had a comment also related to the fact that it may be also nice to have them as machine understandable. And I think that I agree with that comment. We will probably include some references to that. Yeah, that they were not included before. And then I mean, I think that it was Isabel who was commenting that we were not covering services and processing in this list of requirements. I wouldn't say that this is the case, probably we can stress it a little bit more. But I mean, when we are talking about all the typical potential research artifacts, we are not excluding the possibility of having processing services. And we are not excluding the possibility of describing the services that are being offered by, I mean, I don't know, HPC centers or, or anything alike. Probably we are lacking some examples, and they may be, I mean, it may be nice to have some additional examples coming, coming from those areas. But we are not excluding them. I mean, we are not just referring to data objects that need to be shared, but we also consider the service processing services part. But I mean, happy to get any feedback on those ones and any proposal on how to, how to stress that part in the document. There are some comments in the chat. Yeah, yes, yes, yes. I think it's, so we have another 10 to 15 minutes. So I don't know what score. Yeah. So I just, I'm just checking, I mean, like cost was commenting again, I mean, in the topic of open standards, that sometimes I mean, there are also other standards here or there are things available that are easier or better to use, or more available. I mean, I mean, if they are, what, what we are really like commenting over here is that we have a preference for open standards, but we are not really saying that open standards are the only thing that should be considered. I'm not sure. I mean, if there is a lot of controversy on that one, I mean, we may try to get back and see whether whether we have to either rewrite it or, or even even remove it. But that's, I can see that there's controversy over there. Yeah. And I saw I mean, from Nacho Blanqueria that he's commented that I mean processing data transfer storage, they are important to outline. So I will, I mean, I'm happy. I mean, when you, if you have time to go through the, through the document and see whether these aspects are not sufficiently covered in the, in the actual text. There is more text than what we are presenting over here. I would be happy to get some additional feedback from, from that area. Yeah, no problem at all. I have posted the link to the ES platform and, and you're one click away from the, from the actual document for those who wanted to get access to it in real time. I'll take the opportunity and ask a question on the MVP and Bob answered already. It's clear that at the very end, the user is the scientist, right. I mean, yes, only be a success when you know scientists can use data and, and use data from other scientists or so or use or you can even generalize the world scientists so and Bob provided to young and initial answer in the chat on, on the effort in this direction. So back to let's I think it's time to move Oscar what do you think should we move to the to the next. So next slide. Here. Yes. One, one more. The question on model and components. And over here it is also important that them in the document there is much more discussion obviously on the on the actual models that we are proposing initially and I mean this will require some additional reading. I mean, we would like to understand whether these like general, very general points that we are making over here I mean whether you agree with them or not they are mostly focused on semantic into probability power. Yeah, okay, so yeah, if the questions are probably too general at this. Yeah, Oscar. So, any specific. Yeah, any specific feedback coming on these things that we should clearly consider examples could be also relevant. Again, I mean once that you. I mean, I hope that many of you will have time to go through the document. Once that you go to them. I mean, I hope that we can receive further feedback and more fine grained. Thanks. I understand that this is, this is the limit. I mean we've all learning of how to manage a group of 274 people in in such a conference and so at least it was an attempt to do it. You have, you know, basic information links to more detailed information so I, I think we should probably I don't see any more input in the in the chat so maybe we should close here any general comment by anybody. Sarah, the only conclusion. The only conclusion which can be done that disagreement is a very small minority if it is there at all lack of details is choosing. Yeah, exactly. The question, the questions where this one the last was to high level.