 So, for those who are staying for the research infrastructure and and for the discussions, we can proceed as follows. One I think important action that we can take since I think Raúl and Gerbelia are still here, right? Yes, I'm here. That's very good, is to better explore the possible scenarios of collaboration and see how we can do that since we are presenting the open air and access services by integrating the services that we are offering with the research infrastructures and the infrastructure offer, okay? So that could be one possibility to go. So if I start from the themes that we have highlighted, we have some use cases here already suggested which we can discuss and for that of course we need your support and the support of the people around to better understand the scenario. So one thing and I just roll it out so for the sake of sharing commercial terminology, we are doing is to take action to embed what we call publishing workflows within the infra and AI service experience. The idea, the concept is simple, the concept is we cannot rely on scientists to manually publish all their results anymore. So this is not possible. The results span both beyond publications. We all know that in several cases are produced by machine and in quantities and in relationships that are too hard to cope with at the manual level. So we need machinery to do that to keep track of the science we perform of the elements that we produce, the elements that we use, the services that we adopt to transform an input into an output to the configuration. So all the aspects that are necessary to track science, reward scientists, reproduce and keep track of impact. So these are the things that machinery are supposed to do. And for that we need to establish common interoperability framework, common understandings and push at the right abstract, at the right abstraction level, all these concepts. Because we know that in some cases there is a strong community flavor and in other cases is that we can work across. So the ideas, the simple, the first very simple ideas that I came up with listening at your presentation are the ones that you see here where your projects are mentioned. Two actions, which are the one related with the GI and DICE, are more at the infrastructure level. This means that, and again this is very conceptual, if we make sure that any action taken at the infrastructure level is properly published, this means that all research infrastructures, all community using these infrastructure services are provided without the box tooling to publish. So let's say the lower in the fabric we embed our publishing principles, the more others will benefit out of it, out of the box. And they will need less efforts at their thematic level to build publishing workflows. In some cases, this is, as I mentioned before, this is not possible because we want to, for example, capture the essence of specific communities. And so if you look at C-Scales and Reliance, which is very interesting, they do the other way around. So it's general purpose-ness at the community level, I really like that. In this case, instead, we can embed the workflows directly into the thinking of the scientists. So in the way they will be provided thematic services. An example is Reliance. So a scientist will create explicitly or indirectly research objects. And we want these research objects to be automatically published, automatically provided with the right metadata, enriched when future versions will come or will be linked by other objects or they will be added with the further objects of the aggregation they represent and therefore need to be updated. And this has to be made available, and made available not only to the guys using the service, but also to others who are not even aware of the services. They will find it in Scolar, in Scopus, in OpenAir, in whatever. So the whole infrastructure needs to be nicely shaped, bottom up and top down. So what's your thinking on this general conceptualization? Do you think it would be worth investing in this direction? I am interested, from my side. Shall we, I'm not sure what was the path to follow. If you have other ideas which may, let's say, respond to what I said, which are more concrete, I'd be happy to pick up on those and start the discussion. Otherwise, I can, of course, propose specific actions, but you know that Gergely had something in mind as well, for example. What do you think? What's the, for example, the position with respect to the experiments you're going to perform in EGIAs? When I use a notebook, fantastic thing, by the way. So if this is something we need to discuss that goes in other bullets here, possible corporations, but if I am a user and I'm using your notebook, what are you thinking to offer me in order for me to publish the results of what I'm doing? To do it in the proper place, to do it in a fair way, to do it in a reproducible way, because that's the nice part of it, because you are offering a notebook so the notebook can keep track of all the actions of all the parameters of everything that is needed to make my outcome not only published, but also when accessed reproducible, if it will be referred to and you publish together with it the representation of the experiment. So this could be one way to go. One thing that I, for example, one could think of is to align and the way experiments are published. And since reliance is proposing a methodology together with a standard, we could propose that and build specific workflows that go into the direction. For example, the adoption of arrow crates as a way to express and to represent experiments in general, which is cross-platform in a way. And protocols that allow any service to publish arrow crates into Zenodo and to be to share or into other repositories as long as these repositories are compliant to these APIs and standards. So these are the kind of approaches that I had in mind. Yeah. I mean, from my perspective, what I was thinking was going into this direction, I mean, of course, I needed to get your view on that because the research topic, like you know, it's just like the logical unit that can have connections to different resources. This can be like the notebooks that can be used via the EGI computing resource infrastructure. But also these kind of resources from the DICE, right, that can be data sets or can be any other research artifacts that were generated or that are available. And connected, of course, as part of one research work, one of whatever kind of scientific investigation is going. And the idea then is how this can also be moving to the part of the publication process into the open air environment in general. So of course, we were thinking of making some kind of pushing this every time there is some kind of milestone that we call it snapshots, right? So every milestone, we can just push this into the publication platform. And this would allow us, of course, to increase the visibility of these results. Into the wider community, and of course, to also identify some other connections with existing other resources that are available there. So I mean, it's a good step in this direction. But of course, we need to identify what will be like the best way of pushing. This is part of the same pushing or depositing into this platform. What would be the best format? What would be the best way of putting these results into or the research of into the platforms? And that kind of thing, that's the kind of discussion that I think we should have. OK, so yes, I think this is a way to go. And probably we can discuss it further when we are going to meet in person. So really start a concrete discussion on what to do. The same will happen with the other projects with which we have planned individual meetings. So we're meeting with all of you, trying to come up with all possible collaboration actions. And I'm trying to keep track of things. So if we look at this picture. There are several things that we can do for the communities. And I wonder if you as reliance in C-scale would be interested. We are working already with ePOS in that direction. So with the research infrastructure. But there are other things that we can do. For example, monitoring and discovery. So for monitoring, we can provide monitoring for the research infrastructures you are serving and building. So to track the number of outcomes that are due to the services that you provide. So this will measure basically the overall impact of your infrastructure. As well as all the results that scientists are publishing because of your collaboration actions or whatever you have. So that would be one possibility. The other one is to flank your community in a broader way with respect to the research infrastructure and not necessarily one, but could be more than one infrastructure. We discover services, specific services for that. As you've heard in the presentation, we can customize that. And we can customize it and try to find the largest number of objects, research objects, which in the future will contain research objects as well that are relevant for your community. So these are two things. The third one is of course, apart from the integration with Zanodo, which could be beneficial of course, as we discussed, it's also Argos. So Argos offer user interfaces to manage and build your data management plans. So maybe you could consider to use Argos as part of your internal management as projects really to build your research data management plans. So in this case, the DMP will be fully integrated with the scholarly communication. So published as a publication linked with persistent identifiers to the whole to all the entities that we know about is color communications ranging from authors. So researchers' IDs to DOIs of the data that you're going to produce or the persistent identifiers of the repositories you are referring to and so on. So that could be another way of action. So out of the three, we can offer really monitoring for research impact, discovery also, and the DMP. Yeah, also from my side, I would say that it's interesting few things. One is all of these graphs, these research data graphs that you have in Opener. This could be also a very good source for us in the enrichment phases that we have for the research object that is happening now automatically. And that we were, of course, always trying to connect to some where we had in the, you know, previously we had like a service that was getting or trying to get some information from scholarly communication like it was Google scholar, but it was not. We didn't go further with that. So I think in this direction we can actually reuse those kind of services that you have there, trying to leverage and increase or improve the kind of enrichment that we can do. That's one thing. And the other thing is regarding the Argos and DMPs. Yeah, I think it's an interesting thing. We have, for example, planned some kind of fair assessments, wizards or, you know, tools that can also check or take into account that there is such kind of data management plan or that, you know, verify that the data management plan is actually, you know, being applied, you know, that kind of things we need to check exactly what we can do in a machine. Understandable way, but it's something that for sure can be a piece that we can connect to the assessments that we want to do as well. Yes, that's something that we can certainly support you with. With all the information Ellie gave a nice presentation, but I mean the time was really short so we can go more into the detail of that. That's true for all research projects in general. So we can support that for all projects out there. As to the R.O. research object support, that's exactly what I had in mind when I heard you. So knowing what Carol is presenting, one of the issues is the fact that creating the research objects required interaction with several sources where objects are originally stored. And the graph would certainly function as one single entry point to all these sources. So given that a community has a nicely sustainable and integrated sources with a scholarly communication, for example, Workflow Hub will be or Banguea and again all the services out there are part of OpenAir. So if your scientists are putting their objects in there, then you can build services for the creation of research objects that interact with our APIs because we have all the objects there. So that will simplify a lot and your software development in general. And that's really one way to go that I'd like to propose to Carol as well. I think this is a very nice thing. I mean, we should follow up on this in particular. It's an important point. Okay. Deborah, are you still there? Yes, I'm here. What do you think about these possible solutions? Because I remember I collaborated with Mark and we had the discussions in the past and we were close to put them in the proposal. So do you have explicit plans in that direction or thinking of standards for publishing data or integrating with other services, et cetera? Okay, so we don't have anything explicit in the proposal. But I think it is something that it would be nice to explore if we can add this on top of what we have already planned. Yeah, I know there has been already some discussion on this, not involving myself, but more the technical team. So yeah, I would be supportive to explore a little bit more of this scenario and see what we can achieve. As you know, all our projects have a lot of money to be spent to the provision of services and very little for development of services or further integration. But I think it is something that we have to explore, at least see what is required and how we can make this possible with the effort we have, with the resources we have. But as part of the service provision, are you working on a specific interoperability framework towards the, let's say, the exposition of your services through standards and via the use? So is there any specific action or, let's say, your packaging and integrating the services in a closed environment for the moment and exposing them only via UIs? Yeah, okay, so sorry, now I got your point. So no, at the moment we are working as, we are looking at the interoperability guidelines and what is available, but we haven't yet worked with that in general. So it's something that it is in our plan to explore and work on. So yeah, it's something that we can look at in the, as a possible collaboration between our projects. Absolutely, yeah. Okay, thank you. Is anybody in the audience working for a research infrastructure and willing to know more about Nexus and of course also the other O7? Aulo, can I? Yes, Alessia. Alessia speaking, yes, I have a question. So we discussed about this interoperability frameworks and also the fact that generic infrastructure like open air, but I see also EGI is not a domain-dependent infrastructure. So it's horizontal, let's say. So how can we, let's say, merge an interoperability framework which is generic with the specificities of the communities that we're going to serve? So should we be better to collaborate on specific use case and then adapt that to a generic audience or vice versa? Think about a generic interoperability framework and then try it on specific use cases. That's a good question. I think that's my personal opinion, of course, but I think these are two different problems, basically. So we are not looking for one interoperability framework. There can be many. And each interoperability framework has a different aim. Okay, so if I think of EGI and DICE, where their way of thinking is very high level. So it's providing virtual machines or providing storage space. Or when you think of that, you are completely agnostic over the kind of content or the kind of software you're going to run, right? You're not imposing anything. And these interoperability frameworks will have to count on that. So when we want to publish at that level, we know that we're publishing an object whose description has to be injected from the top. So your interoperability framework is an interoperability framework that is generic with respect to the application domain. And the application domain has to inject the necessary data. So this means that thematic services using the underground services, when using them, we love to introduce the necessary context for publishing to take place. Okay, so that's roughly the thinking, I guess. Instead, if you go at the higher level and you want to publish, then in this case you have everything it takes, of course. And you do it specifically at that level. So yes, it's context injection in a way. The lower you go, the more you need it. So that's, I think, should be the approach, but it's one of the many solutions. So one other thing that I wanted to mention is the, this idea that I mentioned by mail to all of you to organize the workshop with the commission. So we take maybe a month or two to draft a plan on what we want to do across the 07 bilaterally or all together. And then we organize a workshop where we present to the commission all these ideas in a nicely organized and structured way and present the plans. I think it would be great, maybe not today, but to set up a date for that workshop that we all agree where we invite the commission so that we are kind of forced to converge soon enough to deliver something. I also think that it would be nice so that we can get feedback from the commission on our ideas instead of waiting, let's say, our general first review meeting where we present what we have done and maybe they will say that this was not what they expected from us. So I think that providing them already our vision on how the collaboration, the integration and collaboration among us should work and get early feedback would allow us to already shape both what we do. I mean, to make them either to say them that what they ask is not visible or doesn't make sense or to adapt a little bit towards their opinion on what we should do. So I think it's a nice idea. And also, as you said, give us a deadline where we absolutely have to deliver something because otherwise I know we are all very busy and this kind of activity tends to slip a bit. We don't have a lot of funds in the list, so we should better plan them in advance. Yeah, absolutely. Maybe also to have some, apart from these bilateral meetings that kindly you started to organize, maybe we can also already think to have a more meeting among all or seven, maybe involving more specific people or also maybe on the technical side or expert on specific services that we can discuss a bit more in detail possible technical integration and interoperability solution. Yes, because I love to join this discussion, but I'm not a technical person. So I mean, we don't dabble at that in the next meetings that face to face meetings we're going to have now with Nexus and the rest will take place. Of course, also, we really involve technical people when we're going to meet, we're going to discuss actual plans and concrete ideas and priorities and decide what to go for first and so on, because I don't think we'll be able to arrange for them for their meetings. I mean, it's five projects, right? Yeah, yeah, absolutely, yeah. So we need to do that first, right? OK, that's fine. So it's nice to see we all agree. And one question for you, Deborah. So as DICE, are you considering to use our goals or to explore possibilities of going for monitor and discovery services? Yeah, yeah, absolutely. I haven't we haven't got yet into the point to really look in details to that. But yeah, absolutely. It's nice to start looking in what you already have and save. That would be good. Well, Argos is also the result of a collaboration in the past. So I think it's worth using it. But you will get also full support, of course, because we are here to serve. So we have support from Argos and we will help you. OK, good. So I think for the time we had, we had a lot of ideas on the table. We put a lot of ideas on the table for the group. So thank you again. Is there any other question from the audience or I'm just also supporting all of these ideas of the, you know, bilateral and zero seven meetings and workshop with the Commission. So we are all for that. Great. Well, thank you all again. That was extremely interesting to get important. So we got to know each other better, unfortunately, not in person yet, but we are hopeful, right? That's the injection that we'd like to have more than the context injection. And I wish you all the best injections you can have. And talk soon again. Thank you very much. Yeah, very much. Thanks to you.