 bit. I think we have three of the four speakers. We're just missing Yann LeFran from Ios Pilla, but he's not speaking into a little later on, so we have a little bit of time. My name is Owen Appleton. I work for EGI and I'm part of the Ios Cup project. I'm not quite sure how I was selected for this particular session, but it's definitely a pleasure to be involved in it. The idea of this session, before we get going with it, is that the regional projects, the 5B projects, or the ones that are regional at least, this of course expands, which is not regional, are an important part of IOSC because they extended or take it to a deeper level in geographical areas, but they're also intended to bring new elements to IOSC. IosC Cup, we've been really trying to beta test the day to day, perhaps sometimes less exciting core of what IOSC is meant to be, but this is definitely not the limit of the vision for IOSC. IosC needs to go much farther. It needs to bring new abilities, it needs to bring new services, new concepts to the research community in Europe, and we definitely see that the regional IOSC projects are a place where we would hope to see a significant amount of that happening. Let's see if we have our last co-host here as well. Yann has arrived. So this session is meant to highlight that. We're not here to introduce the projects, hopefully you all know them. What we're here to do is to talk a little bit about what they each do, which is different, which others can learn from and benefit from, perhaps replicate or take up and exploit elsewhere. So we have the regular housekeeping. The event's being recorded, there'll be a link available afterwards. Fantastic, I'm sure you're used to this by now. Don't activate your microphone unless the host gives you permission. That'll be me, mostly it'll just be the speakers who are talking, I think, at least at first. For questions, please use the Zoom chat. Since I'm sharing the content from others, I'll definitely be able to keep an eye on this quite easily. Hopefully we'll have a reasonable amount of time for questions at the end. Please note questions in the chat or keep them until we get to the end and then we can try and answer a few. I imagine there will be, perhaps, time in fact after each session for maybe one or two questions if there are clarifications on that particular talk. I don't want to make sure everyone gets a chance to speak. So before I go into introducing who the speakers are, briefly, one plug I wanted to make, which I was requested to do by some of the 5P projects, in advance or timed to come out with this conference. There is a book Insights from Regional Projects and Infrastructures. It talks about the innovative activities or plans from these projects. There is a link here to it and my slides are already available on the website for the event. So please do go and have a look at this as well. I will just quickly say who's going to be talking before I pass over to our speakers. So we have first Ilya Levinson from the University of Tartu from Yosemnordek, who's going to talk about service PIDs. I have to say this is a subject close to my heart because it's something I definitely see the need for. Then we will have Mario Davide from LIP for Yosemnordek talking about, pardon me, about basically quality assessment for software and services. This is an interesting topic. Yann LeFran will talk about social and technical innovations from Yosemnordek and Judith Eva Fazekas-Pará apologies for the pronunciation. We'll talk about open innovation from Southeast Europe. We'll have some discussion. Okay, I think with that we're at the end of my introduction and I will hand over to Ilya. I'll give him control of the screens because I think he has some things that are easier to show us live. So Ilya, please, if you want to project your screen, take it away. Thank you very much. I will actually show slides instead of live just in case, but generally speaking if there are questions I can show live as well. So first of all, thank you very much for the opportunity to present the work that we have been doing in Yosemnordek. This is not a talk about the whole scope of the project. So generally speaking, Yosemnordek is a regional project, which means that we are aiming at implementing whatever Yosemnordek is in the specific geographical region. With respect to the motivation for PIDs and why we want to do them, this basically comes from the service package or package where we are concentrating on integrating services from the Nordics into the Yosk, as well as making them more interoperable on the site. Now the PIDs are primarily important for the integration of services. So we have identified several main goals of why we in general want to have PIDs. So basically the very first one is that we want it uniquely. So whenever we are publishing, republishing, updating a service and so on, we want to have a way to say whether the service is in or a way to refer to that. So this is the very basic need and I think everybody agrees that this is important. Now when we already have it, it kind of makes sense to think what else can we get with that. And what we want and what service providers, at least in the Nordics, but I think it's a common problem, generally have an issue with is to how to get attribution for the work that is done. So how do we easily create reports and how do we easily figure out who has been actually using the services? So basically, if we're already using PIDs, this can be something that could help to solve this problem as well. And finally, because this is a original YOSC project, we want to make sure that we will be able to address the upcoming requirements from YOSC, from different working groups, from potential funding mechanisms, and make the life easier for the service providers from the project. So actually, now I want to just show you some screenshots of what we have been doing. In order to make it easier, we have decided that we will publish all the services that will be onboarded from the Nordics on a separate website under NAICNO services. So NAICC is a Nordic funding body, which is essentially a funding agency funded by different Nordic countries, and it sponsors different projects. So inside the Nordic, Nike is playing the role of the coordinator of the project. The Nordic services are basically YOSC services with some additional, probably more strict requirements. So we require them to be accessible cross-border, we require them that the service providers actually agrees to have them listed, and we also aim for automation of delivery services. So the first step was actually to register the PID for the service list itself. So we have a collection PID that could be used in order to figure out what services belong there. Now for each of the services, we basically have a way to register them in the onboarding platform in a way that would also generate a data site PID with required data, metadata, and make it available for the search. It's also made available for referencing, and it's also made available for discovery by the users at large. And that means that basically we are one step closer to getting automatically reports about why a specific service is useful. Because I mean at the end of the day, I think everybody agrees that the infrastructure services are generally as useful as the science that they support to do. Now if we go further and go for a particular PID, so I'm hoping that you're generally familiar with the PID system, so in this case we're using data site PID, and we have a separate production handle that allows to register services. So this is an example of a service entry that has been generated. Now I must say that the data site selection was done to an extent because University of Tartu is part of the data site, so it was quite quick to set it up, and it also had at least the basic support for the services schema. So this was the first step to go for that. So as you can see, we have basically a way to require or suggest users how to refer to the services in a somewhat standard way. We also did the next step, and that is to provide a common landing view for the sites so that all of the URLs that you can get when you resolve the PID, they look generally speaking the same. And the important aspect is that we try to make it so that this URL would have all the components required for the service to pass the validation, at least the current validation, for the EOS portal. So it means that we are generally able to generate the lightweight landing sites, which includes all the required information for the offerings that makes the life of the service provider easier. And we also started doing a bit of background analysis, so at the moment we just collected the referrals, but the plan is to do more and to either integrate some external service or do some basic analysis ourselves to understand as to what is the use of more generic services in well, publishable results. So this is a kind of screenshot from the live system that we have. So in a different work package, in the work package four in particular, which deals with the fare and data, we have a activity which is working on the automated assessment of data repositories using a tool developed by Mark Wilkinson. And the way how it works is basically that you provide a reference to a digital object, so PID basically, and it runs through a series of tests of different types and tells you basically how fair a particular data object is. So out of fun, we tried to do the same with the services and figured out that we actually are, as is relatively high on this fare certification metrics. Now, of course, this is a toy example and a number of tests there do not make a lot of sense for the services. However, as an approach, it actually feels that this would be quite valuable. So if we could indeed do the assessment of services based on automated tests, so this would allow us to improve the maturity of the service offerings. Well, I believe quite a lot. We will be working on that more as the time goes by for now, we're kind of just starting there. And finally, what's next? I mean, this was a bit last minute presentation in a sense that we just started with the using of the PID. So this is in the very early stages of that. However, what we want to figure out is we want to understand if we can integrate also data management plans for the services and hence get a somewhat live dashboard of expectations of the scientists on services without any additional infrastructure. We also want to figure out if we can push the accounting data as usage to the PIDs because some of the PID systems do support that. However, the metadata schemas for that is, we're making a stretch to fit it into the service model. We would also like to push information about how to order services into the PID metadata. Now this, of course, assumes that there would be a certain standard, but for now, we'll probably start with something quite ad hoc, just to see if we can reach the point where all you need in order to get any ESC services is PID. And of course, we want to achieve the dream of the service providers in a sense to remove the requirement to chase the users and get the citations by making those reports automatic. So I think that was it. Thank you very much. If you have any questions or comments, I would be very glad to hear. There are a couple of questions in the chat which we can address. One, I think I can help with them and there's one I definitely want to pass over to you. So Sean said, are you looking up PIDs for services as well as data sets? How do you extend this? How do you deal with the data is replicated across sites or if the service is federated as each instance can its own PID? I just want to say as a potential customer of this service in a way, this is something that we've been talking about needing for having this connection of different catalogues within ESC to allow or prevent services being onboarded multiply to different, basically not having the same service onboarded in multiple places. So if something has already been onboarded by ESC synergy, we don't want to also onboard it again in exactly the same way for ESC pillar. We prefer to just pull the data across. And I would say if there's a service, I would define the service as not just the tech, but the actual instance of it as well. So potentially I guess different instances could have different PIDs. But I would see that the live service would have a single identifier across different places. And as Ilya says, this will be really useful for both funders and providers to understand the use of their services. And certainly from the catalog and portfolio managers, this would be incredibly useful. One question I see from Isabel is Isabel Kampos. She says, what is the point of using the concept of PIDs when we already have digital certificates to ensure the uniqueness of the services we publish? Yeah, maybe you can answer this. I must admit that I'm not quite sure what you mean by the digital certificates. I mean, maybe Isabel, you could elaborate a bit a bit. I see Kostas mentioning PIDs are persistent and can be updated to point to different locations if needed through time. So maybe this is a difference. Isabel, come on mute. Let me see if I can. Yeah, I was referring to your first slide when you were kind of motivating the user, this unique publishing and updating services in the old catalogs. We have been using digital certificates and all the service providers identified themselves with that. Sorry, I'm not quite familiar with the concept of digital certificates. Can you elaborate a bit? Maybe this is the problem of the misunderstanding. So whenever you publish a service in order to authenticate yourself to the user in a proper way, you have to prove who you are, right? And this applies to people and it applies to services as well, right? So every service has a unique digital identifier already in terms of its certificate. So what you are proposing is using this concept instead of... So do you mean like a TLS certificate or X59 certificate? Yes, this kind of certificate. Ah, okay. Yeah, I mean for sure every federation has its own concept of unique identity whether it's reference to the organizational units using some BID system or the ontology in a particular X59 federation. I mean the point there was that the digital certificates which are X59s are somewhat more technical ones and the federation that are typically established there, I mean the trust there is not so much aimed at the distribution of the metadata which is required in order to generate a nice looking website. So we basically took the BID from the data side because it's essentially connected with the publications. So we get essentially... I mean you can get, you can satisfy the uniqueness with quite a number of ways however in order to satisfy also other requirements you need to be a bit picky about those things. So if you get the X59 certificate you probably will not be able to generate automatically a website that has well lots of useful data nor would you be able to automatically get the citations if somebody refers to you. Okay, can I just... Sorry, Isabel wants to reply but Isabel, I want to give other people a chance to talk as well. Is it something brief or is this a lengthy discussion? Okay, let Isabel answer them and we'll let Poster say something and then probably we'll have to move on to the next presentation. Yes, but I wanted to add the no, as Ilya said also the certificates are not persistent and they might change and they affect a number of different things. While persistent identifiers which is what is PA distant for are there to cover exactly that persistence and unique identifiers that the universe throughout the world and it's easy to transport and to copy paste in every form. That's one part of the question. The other part is that we are talking about the service description itself. We're not talking about the service instance which has a specific certificate X59 certificate. It's completely different. A service, the service description will not have one unique certificate for that. You may have a VAB if you want but the website will have one certificate for the whole website which may include zealons of services. Assigning to an entry in a website that this is the certificate for that entry is a bit time-consuming, expensive and an expression to maintain. While a PAD is a lot simpler by using an API you can issue a PAD assigned to the service and maintain that throughout time easily without updates if there will be a location of the service or the service description changes because you won't update the web server or you will decide that you need to add one more category in the path. That can be updated easily and this is why the persistent identifiers make sense. Okay, I'm going to let Isabelle have a very brief comment then I'll wrap up and I want to go on to the next presentation of it. There's some interesting stuff in the chat as well. Isabelle, did you want to say something briefly? I wanted to ask if this is then only made for the purpose of acknowledging the usage or cross referencing. Not just also identifying having an identifier that spans across different portals or different registries so that like I said you don't end up duplicating the onboarding and updating of services. This is another real usage and just to answer I'm not going to go into everything but on to one other point that was coming out of the out of the chat about who owns this. For me if we have a service PID, we don't have to call it a PID if we call the Sean, but if we have some unique identifier that's persistent for services I think this is a schema that whoever fulfills it should in the end be owned or mandated by the US legal entity because the point is that you shouldn't just be down to one particular place you should span all of the arms of the Oscar. It's just my view anyway. For now I think we should move on because that was an interesting presentation and prompted some interesting discussion. If I could just a couple of last words, I see that the comment from Sean is that he's not happy with the approach. Sean I would be very happy if you could just write me some points in chat not to take more time just to figure out why. Thank you. Yeah me too. I'm interested in perspectives because this is something I see the need for from the onboarding side. Okay I'd like to move on now because I think that was a really good presentation, but I want to give all of the regional projects a chance to talk. I know these stretch on otherwise. So the next speaker is Mario David from Lip. Mario do you want to just take control of the screen? I'll try if not I'll give it to you. I'll try to share the screen. You really go. If not I have your presentation I believe. Okay you can see. Yeah that's fantastic. Okay good. So this is the contribution of EOSC synergy for this session. We'll concentrate on the quality assurance of things and we'll get to that later on. So this is the outline which I will pass briefly and go to the content itself. This is the project mission which is to add capabilities by leveraging national digital infrastructures. This is the consortium of more than 20 partners from eight countries and we'll get now to the actual quality for software and service. So we start on the top right which is a software quality assurance and I'll go through this circle as we go on this hold to have a higher quality of service to be integrated in EOSC. The next is quality service quality assurance. Then these the first two are the first two are let's say kind of abstract criteria that we do not sorry that we do not make any say on the implementation because the implementation that we are working have been working is through CI CD pipelines through DevOps approach and Jenkins and we'll go to that also later. We plan to have and then we are working on an SQA as a service. This is a pipeline composer on demand. If either the software or the service has passed the criteria then we will issue badges and this we hope that it will lead to higher quality of services to be integrated in EOSC. This is the same slide but with actual links so the software quality assurance we have a link to digital cc qualities published as open access. We'll have that as well for the service quality assurance. Again the Jenkins libraries and pipelines they are already being applied to quite a lot of software components even from the indigo times and in EOSC synergy we are developing this SQA as a service. There is a white paper which is linked here for the badges where we assess several technologies. So in particular these are links for example for the Jenkins library and example of Jenkins file as well as the service that we are hosting for the badges in the EOSC synergy framework. The software quality assurance has been published quite a long time. We are supporting and evolving the criteria. It is currently at version 3.2 so we have the links. It's open and we accept contributions. You have the guidelines and the document itself and the documents themselves are treated as code. So the issues are the doc is managed in GTIP repository. Public GTIP repository it's treated as code. This discussion goes through issues. I mean if you want to contribute or if you want to make comments you go through issues. You can also make changes to the document or that things and this will go through pull requests and discussion of these changes. The document when it is approved the pull request is approved is auto built. That means that the PDF HTML are auto built for a given document. The criteria is designed toward automation and the DevOps approach. And you have here as well all the projects that have been contributing and using this document baseline. And now EOSC synergy is doing this. Here I go briefly through the plans for the 4.0 version. I'll go quickly through this. Basically we want to add topics about software release, maintenance and support as well as appendices that have the actual implementation and actual technology and services that we use for several software components. Before we go to a service we have to contextualize what the service is. A service as conceived synergy represents the following three items. A web service and this is described here. A web application and a platform or service composition, which is an aggregation of multiple small services into a larger service. It can be an integrated set of web service applications and software components. Examples of these are web portal scientific, portals, gateways, data services and repositories and the thematic service for example. So when we talk now about services we are talking about these three in conjunction or in separate. This is to end. So the service quality assurance, we are working on the document as we speak for this. It follows a DevOps pragmatic approach, builds on the outcomes of the end experience from the software quality assurance baseline. In fact there are points or criteria that are common to both or are similar let's say. Service put in place processes and tools to define and automatically validate software and service quality and maturity. And we will be applying this to the thematic and eventually generic services of AOSC synergy. Also data we are working on automation, automated verification of fair data principles and for this we have been having collaboration and meetings with fair sphere and CESDA for example the results and outcomes from these projects. After again the documents we try to have this document the criteria description as abstract as possible so that the developers or the operations or whatever can implement let's say the criteria with whatever service they want in particular. We use several things. I mean we use gtab for the code for the issues for example pull requests we use unit tests for the software and we use Jenkins and Jenkins pipelines to automate several types of tests that map into the criteria. So the service quality extends the Jenkins pipeline goes a step beyond the software quality and we also work on automated deployment so this is also part both of the criteria and then the pipeline in the end if everything is well then we issue badges. So these are the steps. The SQA as a service is a way to make on-demand composition as Jenkins pipelines and this is actual development that we are doing right now in AOSC synergy and you have two moments where badges can be issued on the quality and the software quality criteria validation and on the service instance validation. So these are the two points let's say in the pipeline that you can let's say have badges to issue for the quality that has been verified. So this is working in progress. I don't know if I have much time but so this will have let's say a service where people can intercompose their pipelines. It makes use of a Jenkins library developed by us. This is working process. The badges contain metadata inside and the metadata states the passing of the criteria through the Jenkins pipelines that means the verification of the criteria that either the software or the service has passed. So we have published we have published a white paper on the state of the art of badges technology and we have chosen Badger platform to operate and to issue the badges and this is in operation in this in this link under the AOSC synergy framework. So this is just let's say snapshots of the badges service and now probably the ultimate what we want to do and test with are the thematic search. So we have 10 thematic services which are here. So this will go through dealing with different types of codes and repositories testing unit testing code style and security checks and in instantiation we have things like authentication and authorization with authentication and authorization. We have things about testing the service itself monitoring and yes we have one criteria which chase the service to have a PID although this is just one of many things that we require for the quality of the service. The pioneer we chosen one let's say pioneer use case which is Varsika. Let's say to test all these machinery and the Jenkins pipelines pipeline. So this is being work done for Varsika. We are one of the use cases or thematic service which is for coastline waterland simulation of coastline waterland interface. It's based on Copernicus data. So it has been chosen as software and service quality assurance implementation. It is composed of several services. So this is a platform. We have a web portal, a processing engine, several microservices and has to be integrated both computing and data repository. So one does not go without the other for sure and most of the use the services are like that. This is a status of the work being done with Varsika which I will pass and I would like to final remarks. So the final remarks are held what the previous windmill. The software QA has been published. You can contribute as I said. It is in an open data repository in digital cc. The service quit QA quality assurance baseline is working progress. Although it already lives in GTAB but it is in a draft, very draft mode. The SQA implementation with CD pipelines, the software quality assurance implementation, this type of criteria has been implemented since the time it was originated in the Indigo data cloud. Project and it continues. Several components and software over several projects follow these these rules. Let's say this criteria. The SQA as a service composer for pipelines is under development. The batches white paper has been published and the services is operational. Of course all of these will go to the thematic services and in particular now we have the Varsika, let's say we are concentrated on the Varsika thematic service. Although all the other thematic services are in different stage of work regarding the SQA criteria and implementation. So I mean it's not we are concentrating on Varsika but all the other thematic services are already of course implementing parts of this criteria at their own cost. Thank you. Thanks Mario. That was interesting. You were pretty much at a time and that was great. So we have time for a couple of questions or comments. I'm just pulling some things out to the chat. Tony Wildish says not every service is web-oriented, e.g. databases. Gavin Fox points out SQA docs should also be machine readable. I'm going to open this to comments for people in a second but one point I wanted to make from my point of view is I'm very interested in service quality and I think what you've done with service quality is interesting but I do think we have to be slightly careful that we don't see this as the whole picture of service quality. But what you're talking about building on the software quality which is a very valid approach for me feels like service technical quality. This isn't quite the same as the full range of quality measures if we think about the management availability things like this. So I think we need to see this in the context of perhaps some other measures as well rather than the only measure but I think the measures you're making are really really interesting. I wanted to make a comment on this. The first of all is that the criteria is very oriented to a pragmatic DevOps and it can be verified in an automated way. So this is one thing. Of course this will be a first application that we want to introduce and this will be applied in the OSC synergy for sure for the thematic services and others. And of course I mean we are this is why it needs an open these are open documents is that you can go you can check and you can contribute and we can discuss. But again this is a let's say a first way let's say on pragmatic automated as possible way towards quality. Yeah I agree and I think this is an interesting way forward as well. If we look at validation of services within the OSC one of the things we know is that mechanisms are which require everything to be checked by hand when work. So we need to automate and make machine readable everything we can and then probably leave the things we can't for human testing. I think this is very analogous to fair certification as well. I know this is something I've discussed with Hilker cause for instance from surf who's very involved in this automated testing which in fact Ilya presented earlier on briefly tangentially on the fairness of data sets or data sources is really good but doesn't always tell the whole story but it reduces the workload enough that you can do the extra bit. So I think that's an interesting. Just a small comment on Tony. For example if you have a public API you can test that public API for example of the service and you can I mean and we have seen from cost of the monitoring that you can do functional testing which isn't just not pinging the service and port you can really do functional tests. So sorry if you have a public API exposing the service we can indeed do this type of thing. Okay I think I'd probably like to move on although I do notice there was quite a lot of support including from me of the idea of using the open badges. I like that it's something I've seen elsewhere and I think it's quite effective and it's quite a smart choice for the area. If we have time at the end we can return to some other questions. However for now I would like to move on to the next talk if that's okay which is from Yan Lefran from EOS Pillar. Is it a Chinese in France? Yan are you happy to take over projecting your screen? Sure. Excellent. Go ahead Yan. Hi so hello everyone so I'm Yan Lefran I'm working with CNES as the technical manager for the project EOS Pillar. There's my email so if you have any questions you can also drop me a line and I'll get back to you as soon as possible. So today I will try to present an overview of the innovations we do in Pillar and we chose to actually look into two different aspects of EOS that we consider important social and technical. So a short slide for summarizing Pillar I won't go through it you suddenly have seen it already but I will make the slide available so in any case if you don't know Pillar that's a good way to find information. So within the project our vision is that if we want to build a European open science cloud and we know that it's shared by everyone we need to consider the two aspects of the cloud which is which are the social aspect considering governance policies and and how you and the different national initiatives in many of the states interact so legal aspect and so on and the technical aspects which is which are more related to how to connect services and resources together so you can work with them and these two different aspects are strongly grounded on practical cases based on the various needs from the scientific communities but also the national initiatives and member states. Okay great so in the both we're working on the both case social and technical so this presentation is going to be focused on several aspects that we're working on that we think are innovative on the the two different sides of social innovation and technical innovation so one was the national initiative survey that was performed at the beginning of the project and I will talk a little bit about that and design the lean framework for for national initiatives to easily integrate EOSC and the second part would be on technical innovation and we have several so I will mostly focus on one that I think is quite interesting and important and we hope that you will gain also your interest and you will we will be happy to to have your contribution as well and your input is to build what we call the federated fair data space to actually support scientific communities involved in the project which is actually nine different communities to actually create a unique space where you can access data from from from these different communities. There are several others that I might not have the time to talk about but I'll be happy to to to talk about it if you have any questions. We're also building detailed catalogs of national and infrastructure services using EOSC service description templates. We're also building links to between the infrastructure services and this federated data space and we have some use case driven innovation and I have two slides on that and if I cannot go through you can go through the slide and contact us if needed. So in terms of social innovation the first things that that we think was quite an innovation is that we started to look at what is the current status at the regional level at least the countries involved in the project for the different research infrastructure on organization, technical aspects and legal aspects for data management. So for that we actually used a standardized method for building survey and doing the analysis and we came up with a representative online survey and we gathered inputs from multiple also stakeholders and this actually this questionnaire and the code source was actually a media open source and it's been reused partly by the other regional projects. What was innovative is that we started to really look into an extensive list of all the organization that could be addressed in the regional countries and we actually classified them into four groups, e-infrastructure, research infrastructure, universities and funding studies and this work allowed us to actually look of course at stakeholder groups that are big and already involved in EOS but also to include now in the analysis the small and regional initiatives and we actually asked them questions about four different topics, business model, SLA and user support, access policies, AI and licensing, data management and fairness and user community and service. All of this data has been mined and the data set is made available together with the analysis on the Australian social data science data archive and you have the DOI in the slides if you're interested. The other innovation we are working on and this is work in progress actually my colleague Federica talked about it during the previous session on national initiatives. The idea is to build a lean framework for national initiatives to look at the constraints and opportunities for them to hook up with EOS and actually to work together and things on cost analysis and business models legal and licensing aspect and also one thing that's interesting is to actually look at indicators to evaluate the EOS readiness for these national initiatives I won't go further. So now to the technical innovation so the second part of the project is actually for use on technical part and the initial idea of the EOS PLAR project is to actually have an infrastructure architecture where we have on one side a federated data space a federated data space and a federated infrastructure of services that would be accessible and registered in national service registries and directly available for on-demand processing and cloud computing services. This architecture is enriched by the fact that we have nine different use cases covering a broad range of domains which allow us to actually build up and identify needs from these communities and add to these different building blocks the needs of the community such as data provenance vocabulary and ontology management services catalogs and metadata standards on the federated data space there was the need expressed by a community to actually link data with open access publication and on the infrastructure service there are several needs like virtual analysis platform, VREs, archiving and of course compute services. Our approach is to actually harvest these requirements from the communities and then look also at the existing EOS service that could be available through the EOS hub portal on storage and preservation, data management sharing, discovery, compute and processing analysis. So this is to give you a broader overview of the context. Now I'm going to focus mostly on the federating and federated fair data space. The idea here is to say okay we have many different communities and some of them have actually collaboration and might need to actually access data from one and the other. So the idea is to create, to federate and this data repository and in the process to try to verify them so make them as fair as possible. So our approach is to actually consider this federated data space as a layered approach where we have the data repositories and that would be interconnected through an interoperability layer that will include connectors for each of the APIs that will allow us to harvest the metadata from these different repositories and then to start looking at how to convert and enrich these metadata so that they would be fair compiled and then published in either a fair data point or and or a fair digital object repositories. This federated data space has two sides then. One is for repository owner and we're building a process and an interface for actually the repositories from the different communities to register their repositories and start doing the the conversion of the metadata and the enrichment and then the publication fair data point and there is the side of the user where we want to connect infrastructure services such as D4Science for data analytics as a DRE, Galaxy services for analysis workflow or any community specific service and even provide a federated data space search interface so that if you want to go and look at what kind of data can be available there you can already do that on a single front end. To build this federated data space our idea was to say okay we need to go fair so let's align these repositories to the fair principles through the integration of the specification the current specification on the fair digital object and the fair data point and we are working now on the first implementation so this is work in progress so please be gentle on the comments and do not hesitate to give us feedback but the idea is to actually rely on existing tools and not reinvent the wheel so we are currently deploying an instance of a Cordra that was developed for as a fair digital object repository we are also deploying a fair data point service developed within the context of GoFair a fairifier service that we are going to certainly extend at some point but that's there it's developed by LUMC and for the metadata harvester we are going to investigate the smart harvester proof of concept that was developed in UDAT and the VRE for science for some of these components to actually work with the data. Now I don't know if I have time I've been very quick so this is one of the innovation that's coming out from one of the use case that I actually showed in the general context picture this is work we're doing with the social science community basically the request was to try to build a bridge between Nakala which is a French social science repository with HAL which is a French open access publication repository which actually proposed a dedicated view for social science publication only and the objective there is to link the data set stored in Nakala together with the corresponding publications stored in HAL and to allow users to go from one to another and vice versa so that they can actually directly see what are the metadata sets associated with the publication and if they go through Nakala for searching the data set they can automatically retrieve the associated publication. So we're doing a current proof of concept implementation where we use one of the EOSCUB service a V2 note as a service to build a link data compliant links between the data sets and the publication and the second one that we are working on is also a secure galaxy environment for sensitive data the global idea is to actually have this sort of computer service available to work with personal S data and to work basically on a secured environment and avoid having to upload the data and extract data and to connect that service to the federated data states. So it's built on existing services that we have already in our catalog of infrastructure services and and basically the idea is to do close to the data computing. So I know it's slightly different from the previous presentation where each which were hyper focused but we are trying to build this federated data states and all these pieces all together are going to contribute to the usefulness of this federated data state and now if you have any questions please shoot. Thanks Jan that was interesting and I appreciate what you said about it's slightly different to the other the last two talks but at the same time I think you're still really focused on the results which is really what I think we wanted to do with this session so I appreciate it. Yeah and I wanted to be exhaustive to be fair with my colleagues we're doing a lot of stuff and I think there might be a lot of interest from different projects and different perspectives so it was a hard to choose one. Well I still think it's good and hopefully I don't know what others think we can mention this at the end I think this validates the idea for this session that we don't do you know project descriptions we do showcases of the things which others are going to find interesting I think this one of the values of conferences like this and maybe brings us more close to a scientific conference than sometimes these what are essentially massively oversized project meetings can become. There were a couple of questions that I want to pull out from the chat and go for a couple of minutes. The first was from Isabel who Isabel you're always very reliable on asking questions and I appreciate it. What are the federation tools you want to use for the federated data space given two repositories how do you federate them which middle where they are? So the middle well layer is actually this that we are testing is this you that proof of concept or we call the smart avicer. This is based on the idea to use the open API specifications so to create an open API description of each of the APIs of this repository and to have a centralized service for storing them access in them and to use them for querying automatically the the APIs of this. So I can see that so this is this is what we're trying now so this is the first proof of concept implementation so if you have any suggestions for any other technologies please. Great. We also had a question from Chris Atherton, a giant have you thought about using a rule-based system such as IRODS as a way of creating a federation tool? Yes IRODS would be a good candidate to create such a federated federation tool. However our aim here is to actually ease the burden on the repository owner right so we don't want the repository owner to have to change too many things because they don't necessarily have the resources to do that and to make it really practical to actually integrate things so that's why we would like to create this I would say common descriptions of the API so it makes things easier that's the only thing that they have to do and just make sure that they maintain this API description so that we can get the latest version of the API so we can make the proper queries. Yeah thanks and there's one last one that just came in for you Jan from Farath Kareef that is it a federation of the metadata or federation of the underlying data? So yes that's a very good question in the end it's a federation of the metadata but as this as the technology we're using is the fair data point which relies on dcat to standard basically through that you can get direct access to the data within the repository right so the URL to get access to the data within the repository itself so actually firing up the recording of that asset is already there so the federation is more at the metadata level I agree with you. So that's I think all the questions we had in the chat I see some thanks from the last two people you've answered as well so clearly your answers were appreciated. Is there any last comments before we move on to our last speaker? I want to give everyone a chance to talk. Okay in that case thank you very much and we'll move on to the last talk. So the last talk is from Judith Eva Fazek as Para from Nefos Europe and I have to apologize I had missed off the Europe when I meant when I was listing Nefos in the past I had to say I knew about Nefos but I hadn't clocked there the full name so my apologies for that. Judith are you happy to present from your screen? Yes I do that. Fantastic it's my straightforward. Great so the floor is yours. Okay so can you see my screen? We see your presenter view so you might want to switch. Oh cool yeah just a sec. Okay now it should be okay. So I'm the representative of Nefos Europe project and I would like to talk about how Nefos Europe promotes and supports the Oskine Open Science Innovation in Southeast Europe. Our project main goal is to build a local national and regional capacities by supporting the development and inclusion of open science initiatives in the 15 partner countries by facilitating the adoption of fair principles through trainings by providing technical and policy support in onboarding the existing and future service providers into EOSC. Within the landscaping survey the question was held on how familiar are you with EOSC. It has been found out that 60% of our stakeholders in the partner countries are either not very familiar or unfamiliar with EOSC so we have a lot ahead of us to train the different stakeholder groups on EOSC and open science innovations. Out of the 534 respondents 90% said that training is either needed or much needed our goal is aligning with their intention. Out of the survey results an online stakeholder map has been created which shows the existing open science stakeholders in Southeast Europe they have been identified by by their roles of open science functions. We have identified funding, creating, supporting, consuming and facilitating open science functions. This map is the result of our landscaping activity. It offers insights on the local capacities and needs to provide input for the whole range of NIFA's Europe activities and we contribute together with the EOSC 5B project to the final mapping of the whole European landscape. As you can see this map supports filtering. You can filter to country and stakeholder group. There is a zoom in functionality. It enables users to find the precise location of a stakeholder. Each stakeholder is marked with a pin and a tool tip showing the organization's name and link to its website. The datasets which includes information about 110 stakeholders deposited in Zanoda under a free license. Aligning with the results of the survey we designed our training platform to serve the needs of our trainees and trainers. We are using an integrated Moodle and Big Boo button environment with AI login. This represents a single location where all training materials is going to be gathered and provided to the trainees. Anyone interested in a particular topic should be able to find easily with the available resources. Each training event organized will use the platform as a repository for all training materials. The training platform will provide access to online sub-paced courses including training materials shared by other related projects. The platform supports various roles. It's GDPR compliant. You can choose out of the different course categories and create on the fly users if needed. It's a user-friendly environment with simplified course discovery based on tags. As I mentioned Big Blue button is the integrated webinar system. It gives us the opportunity to have interactive virtual trainings with its slide sharing option, live vibe board possibility, built-in polling system and the session recordings. The training plan is aligning with the results of our survey. We are trying to train the different stakeholders in the partner countries on their needs. We have already finished three out of the five train-the-trainer events. We planned 15 capacity building training events which will be built upon the train the trainer events and expand the training with additional topics which are relevant for the national service providers. For the national end users we planned 17 training events. Here the goals are two-fold. One hand these training needs to increase the familiarity with Fair and EOSC building upon the train-the-trainer events and combining the specific topics identified in the landscaping survey analysis. On the other hand these trainings will also focus on the use of the onboarding services, adopted the set of services that are of interest on the national level. We have EOSC promoters in all the partner countries. They will be science communicators and bring EOSC closer to the scientific and all different stakeholder communities. They need to know the infrastructures and services of EOSC and the open science initiatives within their region. It is expected that all the EOSC promoters are people who have visibility at national level and are able to engage the community acting like ambassadors for EOSC and Fair. Further training of the promoters might be needed. For this purpose all the EOSC promoters would be participating in the train-the-trainer events of EOSC Europe. The EOSC promoters would receive additional trainings in topics such as Fair, national EOSC promotion, ORDM and onboarding of services. Relevant services onboarding is one of our major role and supports the long tail of science. Our onboarding experts created a methodology, what I will now show it to you. Within the EOSC Europe project for the proposal stage we have organized regional services in a hierarchical structure based on their functions and relationship. At the first level of this hierarchy we have grouped service from the pre-production environment such as monitoring help desk AAI, accounting, so on. At the second level we group common services that provide general capabilities and address technical needs that are common to various research areas such that they can be used by multiple thematic services. The services from this level of the hierarchy supports different aspects of the data lifecycle from creation to processing, analyzing, preserving, accessing and reusing. Thematic services at the third level are research community specific services that provide value to the researchers. In this category we have grouped highly cross-disciplinary services that typically provide access to the community specific data resources through the software layer that unifies tools for various analysis, comparison, visualization, study and all other numerous aspects of post-processing. At the highest level of the hierarchy we have grouped various literature and data repositories that hold and preserve scientific information. At the lowest level we have a resource catalog or portfolio system that implements a resource description template and contains information about all project resources. In general resources onboarding includes five main steps. First, request is sent by the service provider via email or submitted via a dedicated form that officially initiates the onboarding process. Second, relevant information is gathered using a service description template or a corresponding online form which could be incorporated in the service catalog or portfolio system. Third, resources integrated with the existing EOSC tools and federated core such that it is compliant with the defined rules of participation. Four, a service is validated by tools from the federated core and five, a service is published in the EOSC catalog. During the first six months of the project we have developed a methodology based on which a plan for resource providers onboarding to the EOSC was created. The figure summarizes different aspects of resource description that will be gathered by the NIFOS Europe service portfolio system. Some of them are non-EOSC related aspects of the resource description such as general resource descriptions and technical specifications of the resources. While more interesting for us were EOSC related aspects that drove the NIFOS Europe onboarding timeline production. In particular technology readiness level that TRL, EOSC integration level EIL and management integration level MIL, aspects of the resource which will be equally considered during the onboarding process. We use the technology readiness level TRL to assess a research development stage and the figure illustrates nine different stages that TRL oversees in the process of development. From the onboarding perspective only high TRLs are of interest. However in our portfolio system we will also collect and describe resources that are currently under development. We strongly believe that EOSC could influence the course of the development and therefore we would like to be able to track the progress of a particular resource and inform the developers about EOSC features and functionalities that could be integrated and reused in the early resource development stage. Inspired by the TRLs to be able to measure the EOSC integration levels we have put on the same equal footing various levels of integration that could be achieved. We have tried to organize gradually these levels based mainly on integration complexity and the necessity of particular integrations. The figure illustrates NIFOS Europe EOSC integration level EILs to be accomplished by a resource. The level of integration presented here might not be interest of particular resources in the case when direct benefits from integration is not apparent. In such cases we consider that the resource accomplished a particular level of integration and it will be able to proceed with higher level integration. The resource management integration level MIL procedures and policies will ensure the practical implementation of various roles and participations. Technically although resource management reflects the achieved level of integration with the EOSC it imposes some concrete obligations on the resource providers related to the resource maintenance and operations and therefore it is considered independently. Using the same approach as for the TRL and EIL categorization we have introduced nine different levels that the resource could reach in the in the integration with the project's resource management procedures and policies. We have tried to align the management integration levels with the EOSC integration levels by identification of tools relevant for the performance measurement. Also we have identified cumulative levels of integration with EOSC. That resource can reach during the integration with the EOSC low, medium and high. Here we lay out the previously introduced TRL, EIL and MIL categorizations onto this more descriptive classification. The primary purpose of this is to identify a minimal integration level that the resource has to reach to be exposed through the Nefos Europe catalog as well as minimal integration level that the resource has to reach to be distinguished as an EOSC resource. These conditions illustrate and the figure should not be considered as a static set of rules. They reflect the current EOSC development stage and will evolve through time following this EOSC expansion. We believe that EOSC core resources that provides the means to discover, share, access and reuse data and resource have to evolve dynamically with the EOSC exchange layer which holds on all onboarded resources. To evangelize national open science initiatives, trainings, onboarding and EOSC, we planned 30 national country-level dissemination events and one great regional event. During these events we will have the opportunity to talk to Volria stakeholders and serve their needs in the changing scholarly communication ecosystem. Thank you for your attention. Thank you Judith, that was interesting. Interesting in the also had quite a different focus to the other talks. You definitely still weren't doing the project introduction which I'm incredibly grateful for but quite a different focus on where the innovation is which I think is really good to show that the innovation doesn't always have to be a tool or a technical system. I think the integration in terms of should we say a greater focus on training in the communities that you're serving is a really a different way forward. There's a few comments in the chat which maybe I can get you to answer. Sean DeWitt asked and I'm pretty sure he was talking about the training because that's when he asked the question are these only available to your communities are they advertised in the portal? So these are your training options. Can you repeat the question sorry? He asked if your training is only available to your communities within Nifos. I guess he's asking actually at the moment yes yes at the moment our trainings are for just the community but we are considering some trainings to be freely available. I think that could be interesting especially if they're open if they're on mode. Yes that's good. Then Ignacio Blanquer asked are EOSC promoters focused on EOSC evangelization or interfacing with the scientific communities to guide their adoption of EOSC services and principles? I believe the latter could boost more uptake of EOSC in the in the in the user communities. So he's asking are your promoters focusing on just saying EOSC is great or going specifically to some communities? No they are not just focusing saying that EOSC is great but they are trying to like EOSC promoters are mostly high-level people so they have like the access for the ministry people and the funding bodies so they can go there and like tell the vision of EOSC for the high-level decision makers I would say. Okay interesting so that's the idea in that case. Okay and then there's a question from Mario saying I think this is when you were talking about the TRLs does this mean that a service at TRL one belongs to minimal integration in the EOSC? So he's asking I guess is TRL one still being part of EOSC or not? Costas raised hand can we unmute? Can I unmute him? I can unmute him it's fine thank you there you go Costas? Well yes and no they are two different three different categories how we classify both providers and resources or services it doesn't mean that they are on par they have the maturity integration level and the or the marginal integration level and the EOSC integration levels they are based as a say as a pattern towards the TRL but doesn't mean that the TRL one equals TRL EOSC integration level one there's no let's say direct connection between them it it sometimes happens but other times you know you may have EOSC integration level of one but TRL nine for example an HPC system we never have achieved high level of integration with EOSC it will only be part but on its own would be a TRL nine or ten so you shouldn't be comparing those they are different criteria just to evaluate what are the resources available. And so Maria was asking can you show the slide he said it was the penultimate slide because I think that's what people are referring to might help the discussion I might have just been a misunderstanding based on that. Anastas also wanted to say something. Yes I wanted to add actually to Kostas fully agree with what he said I mean we there was there has been a lot of discussion on the quality and the necessity of the services and on the data sets in all previous events people say that you might have even very low quality data that is very useful for example the same should go with the services sometimes there is some services might not be on a very high TRL although we do like to have them in a in a higher TRL but sometimes some communities find something that is maybe not that high on the TRL scale but find it very useful so that's why we will not use exclusively TRL that the idea that was shown on the slides and on the NIFOS onboarding processes that that we use this composite like metrics for for the services and would like to see from different aspects yes high TRL is important means that something is right and tested etc but NETs should not be the only and the only eliminatory and the only inclusion factor all things should be considered that's why we go to these complex metrics provide different aspects and then combine these different aspects both the integration level the technical readiness the EOSC readiness etc so when this combined we will have the the better better view of a specific service to be onboarding I think that's an interesting way of putting it that no one measure is sufficient to show usefulness to EOSC yeah there's also a question here saying from from Chris Atherton I may have missed it but who asserts the different levels for the providers I will let people from NIFOS answer that but I do also want to mention here something which is actually I wanted to bring out some other sessions as well TRL while an interesting measure is problematic in that what we've been given from the commission is essentially a single line definition for each TRL level and it doesn't offer up something which has a large list of criteria that show that you have met each TRL and I have had a very large set of discussions about for instance which TRL level is beta because beta is also understood to be different by different people I think one thing that we may have to do as a community and maybe we can do this through some of the interest groups or you know the collaboration platforms we have is among the projects that are on boarding services and other resources come to some agreement mutually on what criteria we can add to each TRL not just descriptive criteria but validational criteria because this is actually quite a problem we can say something is tested but what does that mean are we going to go to the provider site and see their testing plans often we're never going to have the time for this there's also a comment from Isabel did we agree at some point that TRL seven or above is what we go for and just a comment on that right now for EOSC hub we only accept services to be listed in the EOSC portal if they are TRL seven or above although we only offer them to be orderable if their TRL eight are above so we accommodate some slightly lower TRL services to be listed but we don't go to the same level of integration there's nothing against TRL one services but perhaps they are not ones that we're exposing quite so widely I do want to give a chance to the people from Nifos to answer the question though about who asserts the level of all these different scales of the service of course this is that without what you wanted to to mention I can unmute you again I can answer that both and also the what about the TRL question so let's go first with Isabel the idea was that we we proposed this management integration level in EOSC integration levels even though TRL may not be that high so that we can entice and cultivate the services or curate the services to to achieve the minimum levels required i.e. TRL seven or integration levels higher that's one part of the equation now when it comes to who qualifies the easiest that Nifos has already created a strong team that it does exactly that a validate the services against this those criteria we have b curate and enhance and support the service providers in order to achieve higher levels our aim is exactly that to make sure so that the services are else great you're mature enough or strong enough to be on board and be provided to to EOSC and this is very interesting because maybe it's a difference between EOSC hub and the regional projects that there is a greater emphasis for the regional and the cluster projects to incubate new services as they come up through the TRL to TRL levels before they hit the level where we're perhaps going to expose them so widely outside but again I do find it interesting having these multiple measures so multi-dimensionality is important here if you operate in a regional or a smaller scale than EOSC or EOSC hub then it's easier for you to focus nationally and provide these as Judith mentioned in her presentations our the main goals of Nifos Europe is to build exactly that the national EOSC initiative or national EOSC let's say our organizations or providers you can do that by a building consensus in a political level so that there is one EOSC initiative per country b by cultivating curating services to become EOSC ready or EOSC valuable this may be a for example you may have a high TRL service but they have no access policy they have no help that can operate independently of the rest of the organization you need to be able to be able to allow this flexibility in order to open for for example to to EOSC customers I think that's a good point and so we only have a couple of minutes left but we'll need on the other hand I think hopefully we're drawing to the end of the discussion about about this topic before we we stop because I don't do want to stop on time so everyone can get a lunch break and also some of us have long sessions doing training in the afternoon I wanted to ask if there are any other last general questions about the session or any other burning questions people want to to raise about one of the talks which we probably can't discuss now but at least to start the conversation from that perhaps in the offline discussion is there anything else anyone would like to say please I've raised your hand if there's anyone and I think anyone wants to raise okay so there was something from Anastas but that's directed to Mario so I'll let that probably help and offline okay in that case I'll try and wrap up I don't have any slides for this because this this session is also a little bit of an experiment but for me I think a successful one I hope this is a kind of session that we can run again because I think it is nice to have an opportunity to show each other the new and unusual stuff that we're doing and yeah like I say avoid describing our projects focus on showing our innovations and our successes and the things that could be taken up by other people and I did see in this session quite a few people mentioning that they were interested in the work of other projects and they might investigate or try and maybe take up their solutions if that happens that would be for me a big success and also part of showing what is the case for EOSC which is that we can learn from each other that we can share each other's work we don't have to replicate everything in every area you can let things be built in different areas and still all benefit from so hopefully I will see you all in a session on this topic again the next time we have an event perhaps in person perhaps virtually depending on how things go but in the meantime I think we can stop here and I'd like to thank all of the speakers and everyone that asked and answered questions as well this was certainly one of the one more interesting sessions for me so far so far this week okay thanks everyone goodbye have a good lunch see you in the afternoon bye oh and thanks