 session, which I don't know if it's good for you or not, is mostly me talking and then trying to answer some questions as well. Hopefully you can see the presentation. If anyone wants to mention in the Zoom chat that they can see the presentation rather than my presentation, rather than the present for you, that would be great. We'll start in a moment and I just want to give you some idea of how this is going to run. This is training on how to onboard a service, since that's what we're mostly onboarding right now to EOSC, through the EOSC hub route, because there are a couple of routes running. It's going to be basically me running you all through what that process is going to look like, what you will have to do, some of what you can expect. I will try and take some questions through Slido, but I will probably look at Slido and should we say at the end of each bit that I'm talking about, rather than all the time, because I'll have to get through the material as well. I would like to let you all know that I don't expect that this session will necessarily take the full hour and a half. We can extend as long as we need in order to cover the content, but at the same time, I'm not going to keep you here for no reason. So I have a number of slides and we can then have some discussion. Hopefully that can be profitable for all of you. OK, does everyone hear me OK? Can someone just say something in the chat so I know that I'm not speaking to silence? Great, fantastic. I see some familiar names and some less familiar names and that's good news. I don't want to just talk to the people I've already met. So let's start off with the regular housekeeping slide. I'm sure you're incredibly familiar with this and you probably write it out from memory now. The event's being recorded. That means that any mistakes I make will be kept in perpetuity. Hopefully no one will remember them. Please then activate your microphone and video unless they give you permission. I will, if there is a, when we get to the kind of asking questions part, I will give you the opportunity to do that. We have a slido for this session. Like I said, I will look at it every now and then. So I won't be answering live quite, but I will be trying to look at it. I don't just want to use it for getting questions in the session though, but also for perhaps collecting questions or concerns, which you have with what I'm presenting and how onboarding works right now. And then we can use them to inform our future work and improving it since we certainly have an opportunity to. I've also put the slido link in the footer of the slide, so you should be able to see it all the time. There shouldn't be any time when you don't have some idea what's going on. OK, so. It's what I want to talk about today. There is, I have to admit, a little repetition in some of the slides between this and the onboarding current status talks that I gave yesterday. However, I do want to say slightly different things about some of them. So hopefully this is interesting to you, even if you were in that session as well. Here we have an hour and a half, then I have 15 minutes. So we have the opportunity to go into quite a lot more detail. And that's that's useful, I think. One thing I would ask since I don't have a co-host for this particular session, if the organizers see a particular question in the slido, they can pop them within the Zoom chat because I can see it straight away. OK, so I think we can go ahead. First, what is onboarding? And I mentioned this yesterday as well. I've also I've had one opinion in the last week, which I found interesting, but maybe onboarding is actually the wrong word in that this really suggests that we're bringing people into EOS from the outside. Whereas a lot of what we're doing is connecting people who are already within the EOS community with some internal structure and internal frameworks. Nonetheless, for now, this is the term which is in use. Maybe this is something we want to change to be more inclusive in the future. So this is a sort of map of the space in which we work right now that's useful for this particular discussion right at the top. You see the research community, which is what they should be. They're the ones we're trying to serve. That's why all of this is being done. They will interact with EOS resources, so services and other kinds of resource through portals and APIs. We see this as the main way that they're going to be touching on EOS. And through this, they get to a domain where there are researcher facing resources. This is what the Tin Man will call the EOS exchange. This is supported by the core services of EOS. These are internal services, things that keep the trains running. They're less exciting, but they're very much needed. This is the EOS core or federating core in the Tin Man terminology, and then there are some core resource providers below that. So in this world, what do we have? We have users. Obviously, we have as many users as we can get in the research community. We hope we get more all the time when they want to connect with EOS. They will have to be hopefully doing some sort of provider. Providers sit in this researcher facing resource area, and they bring with them resources, services, data, software, scientific publications, other kinds of research, product and resource. Then in the core, we see some core services and some core providers who provide them. If users want to access a resource, they will talk to some portal or API that will connect them somehow to some sort of resource, let's say a service offered by a provider. This relies on for some of the back end core services within the EOS core to come from the EOS providers. And onboarding or whatever we think it should actually be called is basically adding things to this pool. So that's what we're talking about today. Taking providers and then the resources they bring with them. And we're talking about services today and bringing them into this researcher facing resource pool, into the exchange. The definition I have is connecting providers and their resources to EOS such that they can be accessed by researchers and can build over core services. And I think if we think about the terminology issue here, perhaps we can swap out onboarding for something like connecting to EOS without actually damaging the definition. This is a larger discussion. Right, this is again a bit of a repetition from yesterday, but this is even more relevant today. Onboarding is not one thing and does not occur in one way. And will not occur in one way as it will occur in a few different ways or a few different paths. And unfortunately, I have to give you a very short history lesson in order to make that happen. The two groups who started off trying to collect lists of initially basically just services for EOS were the e-infra-central project, which was essentially trying to do a sort of meta-catalog of what was coming out of all the different projects in the infrastructure domain and sort of predated EOS to some extent as well, or certainly was going along with the EOS pilot rather than the EOS Cup and the EOS Cup, which was trying to collect services that were from within its consortium and then later from outside as well. These both intended to populate their own marketplaces or catalogs, which was fine, but on the request of the EC, reasonably, although in quite a complicated way, they were asked to merge these two efforts into one stream. And this one stream then populates EOS Portal, which is a website, and on it the catalog or marketplace of currently services which sit on EOS Portal. I would like to point out, and I said this yesterday as well, that EOS is not the portal, nor is it the marketplace. There is a layer behind this, which is where all of the core services sit and also where all of the providers of the researcher facing services are. This is a window into EOS Portal and the catalog rather than EOS itself. And I think that's something we should keep in mind. So apart from this path, which is a little bit complicated but has worked for the last number of months, there is a new path coming up, which is through the EOS Ginhance project. EOS Ginhance is taking on a lot of the responsibility for the portal. EOS Ginhance actually includes pretty much everyone who was involved in EOS Portal anyway, but it also includes representatives from the various cluster projects. So it brings in a wider group. It also brings in OpenAir, which is interesting, because up to now, and while I'm presenting today, pretty much all onboarding is of services. In fact, all onboarding that we do is of services. That's not to say we don't think data is important. Obviously, we think it's incredibly important. But the setup we have, the structures we have are there to basically collect data about services, not data sets. There is a gray area, which I'll talk about a little bit later around data repositories, but still, this is something that's not yet sorted out. However, through Enhance, we are going to start onboarding things around data and other research products later on this year, I believe. And this will be with the assistance of OpenAir and bringing onboard some of their structures as well. Then we also see, in the future, at least, although there have been some experiments on this, onboarding from the different clusters, so both the thematic cluster projects and the regional projects, the 5B projects. I haven't ignored Expans, but I've kind of thought of Expans and Pan Oscars, somewhat clustered in this, that's where their logo is in there. These probably wouldn't be onboarding individual services because they would be onboarding services to their own marketplaces or for catalogs. They would be shifting data about services and other resources from their catalog into the central catalog. So one thing to mention here is that, although we have three different kind of paths, ideally, we should all use the same set of steps and they should all be collecting the same data. They just might use slightly different tooling and be validated or checked by different people. So in that way, I think it's important to say that there is, for moving into EOS Portal, one set of data we're collecting, ideally, just a few different front-ends that you get to it with. This is something I put up yesterday and I think is particularly relevant now. This blue bar, it works, but it's a bit messy. And unfortunately, what I'm presenting you today is the current status of this because that's all I can really show you right now. And it is a bit. And that is just what we're stuck with. We are in the process of improving these processes and they will improve based on the feedback from you and others. The path through EOS can enhance is currently being launched and will replace or update some of the things I'm teaching you about today. However, I'd like to stress that while the precise form in which things come may change, the basic content will not. So I still think this training is useful, but please don't get too stuck on the specific tooling or the odd typo as much as the kind of data we're collecting and what. And then I hope that the path planned from the clusters from the other community organizations will basically be in some way mimicking or using as a basis what we're doing for EOSCUB and for EOSCINHARMS with their own extensions if they wish, not going to force them to do exactly the same task, but hopefully we have the same basic descriptions of resources. So I don't want you to think that it's totally different. Right, so what we're looking at today is showing you how the blue line works, which will also enhance the content which will also inform you to some extent about how the yellow line will work and will have some impact on how the other one works. Right, so the current method process for providers, this is how it will seem to you. And I would like to point out there's a link here to the service provider documentation, which is quite brief to be honest, it could be a little longer, which is offered on the EOSCUB wiki. This is a public part of the EOSCUB wiki so you don't need to have a login in order to be able to see it. And here is where we keep some useful documentation for service providers. It's not, and I think this is a valid criticism and should probably be something we solve, it's not currently on the EOSCUB portal website. That's because EOSCUB portal for a time had different paths that can be used to onboard services, we haven't combined them yet. So it was a little bit difficult to get a single set of data. Now with the launch of EOSCUB enhance, I think you go in the next month or so, see much more documentation about this on the portal itself. And I think you should be able to, pardon me, expect that. However, in the meantime, if you want to go to this link, please feel free and might be useful to you. So we have four stages that we see in the onboarding and I'm just going to pop up a summary I put off them. The first is where you submit a request from boredom. In theory, this should all come in the same way. It doesn't. This is the reality now. We're in the process of implementing processes over a fairly initially informal world. And in doing that, we have to accept that those processes won't be all followed the same way out first. But we hope to really push this into a single entry point for at least the EOSCUB, the EOSCUB enhance answer. There is a form on EOSCUB portal. Again, one of those truths that I think is worth telling you, the form asks for quite a lot of data, but really all we're looking for mostly from the onboarding teams is who are you? How do we contact you and what is your service? The extra information about what do you want to do with the EOSCUB is useful, but frankly, we get this in other ways as well. As a result, we also have other people onboarding not using the form on the EOSCUB portal, which is on the providers page, or I think it may have been now renamed, but also just sent by email to the email address on the screen here, join at mailman.eoscub.eu. This is just a mailing list which reaches the EOSCUB onboarding team. So all of us, there is a team behind this who work on shifts to make sure there's always someone available. Or honestly, some requests I get via email to me or one of the senior members of one of the partners in the EOSCUB who then forwards it to me and the team. There's a few paths, but in the end it all comes to the same thing, which is you will be sent a form to fill in with information about your service. And this is the information gathering phase. Right now we are filling in forms in what is in fact a Google Sheet, because this is easily editable by both you and us. The work by the former EMPHRA central project does also have a web portal where you can fill in data in their form, that's slightly different to ours, shorter in some places, longer in others. But the two are basically moving together right now. So for now you'll still get a Google Sheet, but soon within the next month or a few months at the outside, this will be via a dedicated website which is the provider portal part of the EOSCUB portal. You can submit data directly through the file we send you or through the web portal, but you will also be able to submit data through an API. They're already APIs for the older EMPHRA central way of cataloging data. They're not yet updated to the latest version of what we're now calling the resource and provider profiles, which is how we're gonna collect this data, but they will be soon and that will be something that's provided heavily wanted to be available. So there's a whole bunch of different ways we'll ask you for this data. And honestly, it's not just a case of we send you something. The way this works in practice is we send you a form and then there's quite often a back and forth because people don't find the meeting to fill in straight away. Often they need some explanation or help to understand what certain fields are. This is we're gonna go through the form today so you'll be able to see what's going on. So yeah, this is a combination of data entry and some consultancy from our side to try and help you understand what it is we're looking for. And if you're in EOSCUB, this is the WP4 team and let's do this. Once this form is complete and you filled in at least all the required fields because there are a whole bunch of optional fields, we move to a next step, which is validation. So here we're checking the appropriateness of a resource, whether it's compliant with our criteria for inclusion in EOSCUB and also increasingly the rules of participation coming from the rules of participation working group. I would counsel here that the rules of participation are currently very high level and frankly don't provide very detailed, clear checklist style rules which we can use to apply. So we have actually had to create our own criteria for inclusion based on those rules or inspired by those rules and updated as they change. Validation is a different team of people to the people who help collect the data. So the two sets of eyes are pretty much on every entry. I think this is a good safety measure. Validation is quite similar to the data collection except the validators really do look at all the data you've provided. So they check where the links point, they check that when we've asked for an acceptable use policy that's what you gave us and they often enter into some discussions with the provider to clarify a few issues. Once this is finished, we have a validated set of data about your service. We go into a publication stage. Publication is basically pushing that data into somewhere in public. Right now, this is pretty messy and manual and essentially involves us transcribing data into the back end of your marketplace. Once we switch to using this provider portal, part of your portal, this will not be nearly so complicated, it will be a much more automated step. But right now, and I'll touch on this later, there was actually some back and forth in order to get a draft entry up and let you check it before it goes live. I'd also like to give a plug here for the work of one of my colleagues, Kostas Kuwendaros from Gionet who has developed the Agora Service Portfolio Management Tool which in some way mimics some of the tooling of the provider portal, but is intended for you to be able to manage your data about your services locally for you as a provider and be able to at the end output directly an entry into the system which is already complete and much more likely to get validated quicker. So this is a solution which has been around for some time, it's currently being updated to use the latest versions of the resource and provider profiles from the Oskine Hans, but this is a way to perhaps streamline the process since we'll be able to deposit by API rather than going more manually. Right, so that's the mess process in a little bit more detail. I'm just going to switch and see if there's anything mentioned in the slide. Doesn't look like there is yet. So I've seen a question in the chat from Ellen Lynette. I would appreciate if it's possible to use the Slido for the questions if you can because it's easier for me to keep them for later. So Ellen, I will get your question in a second. All right, let me just check that and have to go back. Two, if there's any one question for now, I'm not going to answer that later. Right, so Ellen, the reason I said I'll get back to you is because the next slide is in fact, what you're asking. Once, well, when we're going through this process at the validation step, we are going to check or we do check whether not only you filled in the form correctly, but are you the kind of service which we think should be in the Oskine we should be supporting? And that is this rather long page of text. I appreciate it's probably quite small for you. I believe this file is already up on the agenda so you should be able to download it. I'm going to go through these one by one which I didn't do in the last session where I mentioned them. I'd also like to point out this isn't the one you'll find online because this is an update which was basically from last week which we will push out in the next couple of days based on some discussions we've had based on some edge cases for onboarding. So this is what we call our inclusion criteria and these are the ones inspired by the rules of participation and I guess you can say that in order for us to accept a service, right now that's what we're dealing with, you have to meet these criteria and you have to fill in all of the required sections in the templates that we provide in these resource and provider profiles or service description templates whatever you want to call them. How this exactly tracks the ROP is not something that we've been should we say super transparent about. It's only just starting to update since we've only had one version of the ROP out so far and they were for consultation and I think the response to them was not negative but certainly there were a lot of questions. So there's some things we haven't pushed too hard right now for instance around being free of the point of access. This is a very contentious and complicated to understand point needs to be clarified before we start strictly implementing it because it could have an impact on really every large number of providers including a lot of academics. So what do we go through when we're trying to decide if a service is suitable for inclusion and I'd like to point out ideally providers will have looked at this before they start filling in the form because we have no desire to waste their time by filling in a very long form before they understand whether we're gonna read it at all although we have to read it in order to understand the answers to these questions. First, we consider what resources maybe connected to EOSC. There are two subsections here, one for services and one for research products. The one for research products which is actually second in the list just says for now rules TBD. That's because we don't yet have rules about research products. We will have them once we have the pipeline for bringing research products such as datasets into EOSC portal later on in the year. So for now we're only doing the services. So first we check it as a service and we say it must be an actual service and what does this mean? It has to be a specific service offered live to customers. It may be an IT service, a human or a human service for instance, training and consultancy for now we're certainly accepting all of those but it has to be something that's actually available not a plan or an offer to develop a service for you. Also when we say a specific service what we will not accept is for instance an organization trying to onboard their list of services to EOSC. We're not interested in basically pointing to just their website. We would prefer that they onboard the specific services that they offer even if it's quite a few such that they can be correctly cataloged, searched, accessed, retrieved, benefited from by the community. So this is something that's actually come up a few times recently. We also say it should not be a research product for instance a document or data set or a piece of software. There is a note here I think which is either note one or two. There is an interestingly special case of a data repository because a data repository has been considered by quite a few people to be data. Actually I don't consider a data repository as we see them onboarded to be data. I consider this to be a service. A data repository as I've seen them is often some sort of portal or gateway which allows me to access some set of data with some tools over the top of it. So some search, some annotation, some connection to other services. There is really something which is service-like about it rather than just the data set itself. So I think right now we do onboard data repositories and also repositories of repositories but just not the data sets themselves. And there's been a few good examples. I think the Finnish social science archive was one of the first ones I noticed where this was clearly a repository or a set of repositories are very nicely wrapped with all the things I would expect to see on a service and they have no problem filling in the templates because they were asking them questions that they represent. So right now, that's it being a natural service. Next, the service must be discrete. It must be available and offer value on its own. It may not only be only a feature of a larger service available when already using that service. Again, this has come up. There are organizations which have tried to onboard what is essentially a function within a service they offer. So perhaps in order to use some visualization, you have to already have signed up to the platform on which that visualization sits. We wouldn't then let you sign up that visualization as a service because we can't get to it unless you're already part of the platform. We'd ask that you onboard the platform or separate that function out so that it can be used separately. This makes it much easier for us to categorize things and manage things on our own. Okay, and now we come to probably the most contentious I see a question from Sean DeWitt which I'll get to in a moment. Whether a service is somehow suitable for EOSC. Now, we've gone through a few iterations of these criteria and for this, we had more criteria in the past. If you look at the version of this which is on the website currently on the EOSCUB Bookie, you will see we have four different criteria for is something appropriate for EOSC. We've got it down to two but they probably require a little bit more explanation. Certainly they're a bit complicated from our side. We say present services must meet at least one of the service must be targeted to EOSC and EOSC communities or the service must build on or leverage EOSC capabilities to serve some other community. So let me explain the thinking here. We have had, well, again, I think I made people laugh the last time I said this, we have had requests quite frequently to onboard webshops selling fake Louis Vuitton or Pandora products. We normally get about three to four of these a week. These we don't even bother to reply to. Hopefully no one will shout at us for not replying to them. However, there are other services which are suggested to be onboarded where it's a little bit less clear. So we've had a request quite recently from an internet service provider who is saying that they want to offer their ISP services to customers of the EOSC. But what they're suggesting to bring on board is just their webpage offering their services from their website. And this for me fails what I was calling the Dutch post office test because that was an example that came to my head. I was trying to work out by trying to think, what do we onboard? What shouldn't we onboard? And I was thinking, what would happen if the Dutch post office wanted to onboard their services? Obviously, they're potentially of use by researchers. So we can't say researchers don't like using the mail. But at the same time, they seem to have very little specificity to our community. And what we've come down to is that if a service attempts to target EOSC and its communities, it's probably acceptable. So to take the ISP example, the answer they I think have received now is no, we won't take your generic services. However, if you were offering a specific service for the research community in the EOSC community, you have a webpage for it. It has some differentiation from your other services. Maybe you choose to offer a better rate. Then in that case, we may accept it. And this is a bit of a moving target. And this is something we're trying to sensitively deal with in order to not, should we say, stifle interest in EOSC without putting things into EOSC which are inappropriate and clog it up and make it look not really very valuable. So that's one possible measure. The other one, sorry, I also wanted to mention this. A lot of these services that are targeting EOSC are quite specific. They're a service for the life sciences or say the fusion community. Others might be quite generic, but they're still targeting EOSC. For instance, I don't know if you're all aware of the Okra project, which is a cloud procurement project which includes some major cloud providers but who are supplying resources through a procurement framework for EOSC. The services they're providing are incredibly generic. It's just cloud VMs, but they're providing them in a way that's clearly targeted to EOSC. Therefore, it's one that we're going to accept. The other possibility is the service must build on or leverage EOSC capabilities to serve some other community. Now, this is me or us trying to accommodate some edge cases we had, particularly from the EOSC Digital Innovation Hub. So the Digital Innovation Hub is a platform for interaction with SMEs primarily and EOSC. The DIH network is also a massive thing. It has a budget roughly like EOSC and is much larger than just the EOSC-DIH, but there is a DIH for us in Digital Innovation Hub. There, there have been some business experiments where companies used EOSC resources, knowledge, technology to build new services which they had then offered to their customers. Now, these obviously are services which target their customers, not ours. There was an example from a company called DataFern, which was looking at trends in furniture design that they could tell their furniture producing customers. Clearly, this is not of any interest to EOSC researchers, but because it was built off the back of EOSC and using some of our resources, some of our expertise, it still should somehow be included in the picture. So we have this as a way to accommodate those sorts of activities as well, since we don't want to keep them. So these are really the criterias about appropriateness and I will look at a couple of the questions now. So from the Zoom chat, although I prefer to use the Slido, does EOSC hub offer support on possible adaptions of actual services to get it onboarded? If so, at what level, e.g. technical? We provide consultancy in filling in the forms which often becomes a bit of organizational consultancy on what you have to do. We point you in the direction of resources that are helpful. We do offer technical help if you're trying to integrate with EOSC core services. So if you want to use the EOSC AI, if you want to use the Federated Help Desk, if you want to connect to monitoring and accounting, there is effort, not money, but effort available and I suspect that in the next stage of funding under EOSCO 3, you'll see similar sort of opportunities. And then there was a question from Sean, would a container which encapsulates some code be classed as data or a service? It certainly brings no resources. Difficult one, Sean. I think we kind of have to go through them a bit case by case and this is a problem. We try and be as objective as possible but there is some level of subjectivity. I think if it looks like someone is just trying to do something to fulfill the requirements but it doesn't really meet the spirit of the rule, probably we'd say no. On the other hand, if your container with your code actually is operational and useful to someone, maybe we'd be more open minded unless Matthew gave an answer there as well. Luciano Gaido also says the ROP working group has suggested to treat free at the point of use and other similar criteria which are difficult or impossible to enforce as general principles instead of rules which have to be assessed and enforced. Not sure this will be accepted though. Yes, Luciano and frankly we've ignored the rule on free at the point of use or free at the point of access which is actually what it says because right now it's too difficult to enforce. And I've also been told for instance by my colleagues from South Sarah in the Netherlands who are part of the EOSCUP, a leading player in the EU DAT that if you took that in the wrong way you'll actually exclude them. And I think if we're excluding an organization like that probably the rules are a bit difficult. So there's really a lot of clarification on that. Right, I'll move on. So the next set of these criteria are basically about what you fill in. So I've updated the terminology to use the new version of this terminology rather than a service description template or a resource description template. We're now talking about a provider profile and a resource profile, but it's really the same thing. So you have to fill in a description of you as a provider and provide a profile and you have to fill in a description of each resource resource profile. All required fields must be filled in and you'll see this as we go through the form. There are a few other specific rules. URLs should be fully qualified domain names just because it's a little bit easier for us to trace than just IP addresses. There are also some rules here which are actually related to EOSC hub rather than what we see as a future vision for EOSC about things being in English. Now, this is very easy for me to, should we say, I think is okay because I'm English and I speak English. I don't believe that EOSC should be monolingual but at the same time for simple resource reasons we don't have the ability to check and validate services and service information in other languages today. This is something which EOSC may want to consider in the longer term when it moves to the EOSC legal entity how multilingual does it want to be? What is it prepared to keep a pool of people in who speak lots of different languages in order to be able to check data over? But for now, practically a lot of stuff has to be in English. So the provider and resource profiles must be filled in English. We've said the basic information in the UI must be available in English. This is really because otherwise we can't check what we're looking at reliably. We've said that some key documents, not everything but privacy statements, terms of use and any service level agreement or service level specification you offer should be in English. Everything else can be in a native language. That's okay, but there are some things that we really need to check and they're able to see in English. And we think it's appropriate if you're entering into a multilingual environment with the help desk you have, whatever form it takes you must be able to answer queries in English with them, even if that's not the first language. The last two criteria here, resources must be available in Europe and in a European language. So if it's solely in Chinese and we have had some services which were solely in Chinese, that's difficult for us to deal with and probably not something we can accommodate right now although maybe if it grows, this is something that we do accept. Currently also you must be able to access these resources in Europe. So there's no point in American organization onboarding a service only available in America to EOSC. EOSC is currently E for European. If this becomes GE for global or W for worldwide that would be slightly different. But for now it has to be European. Right, so that's the end of that slide. I know we went through this in a lot of detail and I know that this version isn't currently public but it will be very soon. I think probably we'll make it public next week if everyone agrees. I think this is something we will need to highlight much more clearly going forward because we really need providers to check this before they fill in the wrong form, particularly about whether the service is EOSC competent. Hopefully for most people sort of related to research this is not going to be a barrier but certainly if for some people more peripherally related there are going to be times when we say no. Right, okay, let's go forward. Well actually going back briefly the section here, the section about a provider profile and resource profile being filled in. We're actually going to look now at that profile or the service description template as it is today in order to talk about the different sections. I'm not going to go through literally every field because there are really quite a number but I'm going to at least talk about every section because I think that's useful. The current version of this is 1.3.0 that's the current EOSC hub version. There are other versions from the central people and also from the Catriss project. These will all be merged and there is a merger about to happen. Part of the merger is a mapping from the current set of fields to the new set so don't panic too much filling in this one be wasting your time but we will be moving to a new version of this in the next couple of months I think. I hope at least maybe the new version will be approved first in June and if it is we'll start using the new EOSC hub as quickly as we can. I have also made a copy of the current version of this file. It's already in the service provider documentation I linked earlier but if you want to go to this bit.ly link bit.ly slash EOSC dash STT dash demo you can have a look at the file so that you can zoom in a little bit more. I've also replicated this bit.ly link on all of the following slides so even if I move forward and you haven't copied it down yet hopefully you'll have an opportunity to. I think this is probably the best way I can show this to you. I just want you to also check the question from the Zoom from Ignacio Blanca because he had problems finding the Slido. He says, went through the process of onboarding with free services and I think it's highly useful and manageable with experience. However, I think you should implement a continuous evaluation and a long time to ensure the services work properly. I know this is time consuming though. I could not agree more and I'm actually going to come to this at the end and highlight this is actually a key weakness of everyone in how they deal with services right now. I will get to this later but really I totally agree with you and it's a priority for me to make this a little bit more advanced. Right, so now the maybe not most fun bit of this talk where we look at a whole load of what it would look like basically spreadsheet slides but I encourage you to look at the file itself rather than necessarily look at Zoom if you so desire. I will just double check if people are able to get into this document. Looks like there's a few people connected so that's something. Not all 83 of you but at least a few. Okay, so here is the first screen you see. Well, actually first you see these instructions on the right side of this slide which do give you hopefully some indication of how to fill this file in of what's the process of what's the license for it is Creative Commons license. But once you go through that, this is the first screen. And again, you see the link at the top the bitly link for the demo if you want to have a look at that. This page is the service provider description. So in the new schema, one of the benefits we will have is that we will have a service provider profile which is basically this and then a resource profile which is all of the other parts. So you won't have to fill in the service provider part for every service right now for historical and administrative reasons you do although you can just copy paste it from one to the next. Still, it's a bit of a pain and I think this is definitely a place that we can screen one. So I see someone asking for a link to the file. If you look at the top right of the slide it says view the SDT and there's a bitly link bit.ly slash yosc dash SDT dash demo. Hopefully you can access that. It looks like people are able to access it. So the service provider section is not very long. It's fairly straightforward. I'd also like to point out a little bit about the format of this sheet. So you see there is a code for each field. This allows us to check things a little bit more easily and be specific about what we're referring to when we talk to you. There is a name for the entry. There's the entry type. So what do we expect to see here? Do we expect a single line of text, the URL, free text and email? There is whether it's required and whether it's public. There is data that we collect which is definitely needed but we're never gonna make public and there's data that we may will make a public. Right now, not everything is made public that we collect and say might be but that's going to change as the portal front-end develops. I don't know if we have anyone in the call today from the team who are dealing with the portal front-end mostly from CypherNet but I think they plan to show more of this data at the time. There is then some guidance for you to fill it out and there are also some validation criteria. These are normally hidden when you see the file but you can unhide them if you choose. This is to give some guidance to us and our validation team of how we should validate this. This validation criteria, they're not always perfect. Some judgment is required but it shows how we try and take care of things. So for a lot of questions it is things like looking for obvious typos in names or in URLs. We can't tell you what your organization is called but we can at least highlight if we think you've got it wrong. Other places is being able to check a URL. Check the URL actually does point to the real organization not some dodgy version of the organization who's trying to claim they are in the real organization and check that you've used the coding correctly. So we ask for the provider name, the country, the URL. We also ask for a description of the service provider and some idea of your affiliation. This is optional. You can see the things in red are required, the things in yellow are optional. I would also like to highlight some of the improvements which are coming to this system. Things like affiliations. Right now you just have to say I'm part of this network. I'm part of this federation. I'm a member of J-ONS. I'm a member of EGI or a UDAT. I'm a member of Indigo. In future, using either the API or the provider portal, you will be able to select from a list of affiliations or connect yourself to another organization that's entered its own data. So this will become more automated over time. Now description is you want to describe your organization. We give you the opportunity. We don't insist on it. We do ask for logos. This is because otherwise it's very hard for us to nicely display material to users. We're going to ask for logos again. In fact, a tagline you'll see for services and other resources. So this is required, but I think this is not exactly a big ask. We also ask for contacts. And these are not things that we make public, but we definitely need a way to talk to each provider. It might be that we have an issue with several of their services at the same time. It might be that there is some legal or security issue in which we can't get through our security contacts, which we ask for later. We think it's reasonable to have some contact. One change I think we might make is for some of these contacts, we will accept more generic email addresses, but I think from this one we ask for a question. And again, then this is the kind of balance we have to have. We give you the opportunity to list certifications your service provider has. There are many certifications, particularly, for instance, ISO standards. In my own organization, we have ISO 9,000 and 20,000 certifications. These obviously impact our services, but we can't claim that the services are certified. It's the organization which is certified. So it's nice for us to be able to show these, but not everyone will want to. And we definitely have to strike a balance. And I think we can go to far and other directions at times about what we actually ask people for or give them the opportunity to expose. But I think certification, particularly in the era of concerns about security or professionalism of the way we deliver our services is a good thing to ask about. Clearly there have been quite a lot of security incidents in the last week around the HPC community. So being able to show that you take security seriously and have some sort of certification is probably a positive. So this is the service provider screen. So this is what will become the provider profile. It'll be perhaps a bit longer than this because it will also, in the new version, have a whole bunch of other optional data to support physical research infrastructures and physical research centers. But most of this is optional. There are also a couple of extra questions we'll ask like, are you a legal entity? Which is a very useful thing to ask. And this will be a yes, no question. And then any other data you provide will be optional. I will just quickly move to the slide out to see what else we have here. So I see two questions from Mark Allen for services that already have complex online portals. What does EOSCUB bring? In the case, is EOSCUB really just pointing to that service portal webpage, making it more findable? And to take the risk of onboarding a service we would also want to know how to remove a service. We should be optimistic, we would need to know this. So can services specifically be off-boarded? I'll answer both of them quickly. Off-boarding, as I'll mention later, honestly, we have less developed processes for everything except for the onboarding, but we can suspend a service very quickly if you request it. And indeed I've done so when people requested. I haven't actually yet fully deleted services from our records because no one has asked for it. But getting them off the public listing can be done very quickly by anyone from the publishing team right now. And we have a mailing list which covers all the people in the whole onboarding team, including the publishers. So this is definitely doable. As to people who have their own complex online portals, I don't know if a more community mark comes. I did mention earlier on onboarding from other portals to EOSC and yesterday I gave a talk which I encourage you to look at the slides from or look at the recording of about a future vision for onboarding which really tried to stress what is the benefit to communities that have their own portals to onboard their services. And they would not onboard them by filling in this form. They would onboard them by using a compatible format for their data and basically using an API to submit directly to EOSC portal. There are benefits which I tried to stress yesterday so I won't go into too much detail on them today. But Mark, if you want, ah, from the astronomy field, if you want to follow up with me afterwards or you want to look at the recording from the service onboarding session yesterday, I'm happy to do that with you but it's a slightly longer story with some slides attached. So I don't want to go into too much detail now. Hopefully I can get back to you. My email address is on the last slide but it's my name, owin.appleton.egi.e Okay, let's move forward. The next, with the next tab in fact, service description. So this is a very long tab. There are a few screens of it. I've grouped them by the large scale sections. And again, I'll try not to go through everything but I'll try and give enough of idea of what we're doing. Hopefully some of this is fairly obvious and self-explanatory. If you're going to onboard a service and in future this will cover other resources but for now it's just services. We would like to know what's its name, what's a description of it, where is it? We give the option for you to say the endpoint as well as the webpage for it. And we also need to know in what language is it and where is it geographically available? In all cases when we ask for things around language and location, we are using ISO codes, so two-letter ISO codes. You'll see at the end or if you're in the file itself that these are also in the tab at the end. I mean, you can always look them up but there is also a tab which lists all of them to try and support you in doing this. We see this is the most machine readable, programmatically sensible way of gathering location and language data. But this is the basic service description. Hopefully there would be really no objections to what we're asking for here. The next two sections are service marketing and service customers and users. I mentioned earlier on that we require a logo. We also require a service tagline. I know in later versions of this, we actually will be changing the description to say a single line description. In case you don't have a tagline, we don't expect you to make up and authorize one with your senior administration. We need to have a very short description of the service to go alongside its name when presenting it in your support and in any other way that it's exposed. So this is a requirement. On the other hand, things like multimedia, videos about your service, use cases, we allow you to link them and we will expose that data but it's by no means required. We want to give you the option to enrich the listing you have to encourage you to use your service. First, service customers and users. So this will come up in a minute on another screen as well. There is a problem of categorization. So what is the best categorization to use for actors and stakeholders but also to use for scientific disciplines? This is on our later screen that is useful but not so detailed. We spend nine years talking about it. Every field will have its own categorizations, vocabularies, ontologies. So what we are suggesting and what we recommend is that in areas like this where we're trying to understand what kind of user do you target that we use very coarse-grained categories probably only a handful of them. So here we have, I think, five researchers, research communities, business, projects, providers. And again, these may be tweaked over time because there are some criticisms of them, valid ones but we don't go into anything more complicated than that but then we allow you to provide tags to describe your target customers in whatever way it fits for your field. So I know that different terms are used for different kinds of user in different fields. We can't cover all of that. We don't want to get into that sort of global super catalog of every possible mental concept in the EOS space. We prefer to go for coarse-grained categories than you can tag whatever you like and you can use the terms that your community will use to find those things. Moving on, this is the next slide of the service description. Here we have two sections, one on classification and maturity and one on standards and technologies. I'd like to raise exactly the same point I just made about service categories and service tags that I did about target customers. So here we have more categories of service. So what do we have? Eight when the look of it, which again won't be a perfect description but gives you some coarse-grained way to describe what kind of service you have and then you can have whatever tag you like. So we have, should we say compute as a category but we don't say exactly what kind of compute. You can tag that as cloud, you can tag it as IS, you can tag it as VMs or really meaning the same thing most of the time or you can tag it as GPU or quantum computing but we're not going to create a new category for quantum computing because then we just have two new categories. For research fields, this is a little bit more complicated. I'll show this at the end. We've tried to use wherever possible standardized descriptions of things. So in the same way we used ISO language codes, we've chosen to use the Frascati Fields of Science as the basis of our description of the research fields services are related to. And I think under Rioskin Hans that will continue to do so. There will be basically some slight addition of a non-specific or generic category for for instance a compute service which doesn't address a specific research domain. But again, you'll also be able to list multiple research fields which you are related to. So here we asked for basically the codes from the Frascati level two but these are included in the tab at the end of the file. Also I need to highlight TRL. So this came up in the last session. I don't know how many of you were with us from the last session. We discussed TRLs. TRLs are interesting because they are imposed on us by the commission or suggested to us by the commission. And it's very useful because it means that we have, should we say a consensus way to say something about maturity of our services. Although it's not everything to be honest. It's technology-readiness and what service maturity is. It's more about the tech and how it's delivered. However, the descriptions we have for them are really single lines. And this is something that's been problematic in the past. In earlier versions we actually had alpha, beta production, other terms like this. But people have different meaning and understandings of those terms and they map them to TRLs in different ways. So for now we are sticking, I think, and in enhanced we will do the same with TRL. But I'm really hoping to launch an initiative with the other projects that are providing marketplaces and catalogs and registries to come up with some consensus for practical criteria to check TRL. Because there has to be something that our validation teams can check. Otherwise it's very hard to use this. And I have had people suggesting a TRL eight or nine service for which there was no help desk of any sort. And this for me suggests that people are at times filling in things rather optimistically. And other times I've seen people being very pessimistic when in fact clearly it was an incredibly high quality service but they were just missing a few small parts. So that's this service classification and maturity. This is a complicated area. And there were some really interesting things in the previous session about innovations from the 5B projects. The Nephos Europe project has been looking into service maturity level of integration in a way that's much more developed than I'd realized. This is something I'm definitely going to check out. So if you want to look at the recording of the last session, the talk from Judith and then the questions after the thought is really positive. For now, this is what we have. There's then a section on standards and technologies and you'll see as we get further down this service description, it becomes more optional. This is all optional. This is allowing you to specify standards that your service obeys. This is something that might be useful in specific areas especially if you're talking about a private or secure data. We allow you to talk about certifications you have from the service. Some may sit on the service level, what's on the organization level. And we have the option to talk about open source technologies. This is not things like we use Apache. This is more like if your service is really dependent on a specific open source project, it's useful for the provider to understand that because there is some risk or positive side to that. There's a well-known community around R for instance or this is some tiny little open source project which we don't think is going to stay alive. I'll give you some information about it in two sets. So I'll move on and then I'll check the questions after this. Last section of the service description is dependencies. So service dependencies here, this whole section will disappear, I believe in the next version of the resource profiles because rather than just listing dependencies in terms of other services, related services, related platforms, you will actually be able to select from a list of the other onboarded platform services to show the connections you have between them. So this is somewhere where we can really use having a technical platform for this to improve the experience for people doing the onboarding. For now, because it's all been done through these sort of forms, you've had to list what your affiliations are for services, what your dependencies are for services. But for instance, the related platforms has been quite useful. For instance, I think we have a whole bunch of services from the WNMR community, but they have different names. This allows them to all be also grouped together. So you can look at that platform, the WNMR platform, you can see all their services, even if they have different providers contributed. Right, I'll have a quick look at the slide though to see if there's anything else that's come up. For now, it doesn't look like it. So I will probably go on. I see some discussions between Matthew and Sean. I'll check on them later. Okay, next slide. Now we have two sections on service management. So service management is about how is your service delivered? And this is an interesting and contentious set of sections because here I really feel we're not only asking providers to describe themselves, we're also at times trying to improve the maturity or the professionalism of providers and prompting them to provide information, which they probably have to hand, but they may or may not have exposed to their users and customers or thought about. So this section often requires discussion between the people doing the onboarding or the validation with the service providers. And there are also arguments about which sections of this should be required. I will try and sketch out some of them briefly. The very first question is, do you have an SLA, a service level agreement or a service level specification? A service level specification is a term we use to basically talk about a service level agreement where you haven't signed or you're not necessarily promising some penalty. I mean, honestly, penalties are not always part of SLAs, although I know this is a commonly held belief. It's something I don't agree with. SLAs can be penalty free and very slim, but still this can be a term that concerns some communities. So we've also talked about specifying your service level rather than necessarily agreeing it. The reason this is the first question is that if you have an SLA, you can probably answer every other section of this straight away from the top of your head because really the contents of this mimic the contents that I would expect to see in an SLA. And I think that surprises some people and they expect to see a lot more, but in fact, this is most of the most important stuff that we see. So we asked for a few things. We asked for a number of contacts and here right now, we don't ask for a name. Well, if you have a name, we'll take it, but really it's the contact and email that we're really looking for. We want to know who's the service owner. So who do we contact to discuss that service specifically? Who is the service support contact? So this is not to talk about the service as a whole, but maybe some technical issue with it, some problem reported to a help desk that we want to try and push to the individual provider, some problem in how it integrates with the portal. And again, taking the recent topic of the HPC centers and the security challenges they've had, a security contact. This is something that we feel is absolutely required. For every service onboarded to EOSC, there needs to be a way that EOSC, as much as it has a central hub, can contact someone regarding the security of a service. Maybe we feel that the security of that service has been breached and we have some indication or maybe the portal has been breached and we want to tell them that communications they get from the portal may not be genuine. So this is something that's absolutely required. And it's surprising how often this hasn't been thought about by providers or at least how often it's just the same person's name. And here, yeah, you can have people's names, that's fine. In a way I'm more confident if I see security alerts at an organization, because then I feel like there's a number of people behind it, there's a team, there's a process. This is a way that we try and drag up the level of maturity. Then the next couple are about the help desk. So I believe that for any service in EOSC, there must be a way that its users can contact the providers of that service to ask for help, raise a ticket for a bug, ask where training material is, if it's not clear, make contact in general. You actually only have to fill in one of these two sections, either a URL or a help desk email address. We're pretty open. I would say that if it's an email address, we prefer if it is the kind of service name dash support at rather than Owen Appleton at, because we believe that for a mature service, certainly something in TRLA to online, your support shouldn't be governed by whether a single person is checking their email that day. It should be going to a more generic address. A ticketing system is even better, but not everyone has one. So we think of this as absolutely required. We also think there has to be some sort of information about usage for users, although we have some questions about this next field about a service user manual, because some very simple open access services have no user manual because the interface is the manual. So this is something we're actually talking about whether it should be required. For now we are some indication of telling people that there's an opportunity to this premium as well. And then the last few sections on service management, and again, this is really in the service of being able to try and drag up people's maturity and also increase the integration of the OSC. If you want to provide a monitoring URL with monitoring information about your service, great, you can. The same for a maintenance URL, where, which tells you when a service may be unavailable. These are not required, but I think as we move towards a more integrated OSC, this is the sort of thing we expect people to see. Hopefully, in the end, it won't be filling in a URL, we will all be adopting perhaps shared frameworks for service monitoring, service accounting. But in the absence of that, we at least can give you the opportunity. And lastly, to require sections and probably the ones that most often trip up providers in validation, we would like to see a terms of use or acceptable use policy or terms and conditions. I appreciate these can sometimes be different things. Often the line between them is pretty blurry. In short, we would like to see that a provider tells users how they can use the service and how they should not use the service. And they should be as clear about that as possible. We provide some examples and we explicitly suggest for organizations that do not have one adopting the WISE baseline AEP from the ARC project. This is really a fantastic piece of work that I feel very, very positive about. And I think it gives you an opportunity to have a basic AEP in place very quickly if you don't really have one. So I think this is one of those areas where we're just trying to point to the resources. Perhaps more complicated, we also asked for a privacy policy. In the era of GDPR and many other concerns about security, I think this is a fair baseline for maturity of providers. We're not gonna go and check how good their privacy policy is, but we really are asking them to think about the privacy or privacy guarantees or promises they make to their users and explain them somewhere on their websites. Again, I personally feel this is incredibly reasonable, but I also know that this is often been challenging for the providers. So that is the end of the service management section. I'll have a quick look at the slide out to see if we have anything new. No, seems I've either managed to keep your attention or you're all checking your emails. Can't be sure which, but I'll try and stay optimistic. Right, not too many more sections. No, I think we'll be not far off time. A last few taps, access and order. Here we're really doing two things and they're all required on the grid. One is we're trying to understand what is the access model of your service. So we want to know, is your service an open or wide access service? If it is, then everything else basically goes green automatically because there's no need for any other information. If your service is either free for anyone without any registration or login at all, or what we call wide access. So it requires an account, but there's no validation of who can have an account. You just have to have signed up with the username and password. Then really that's all the data we need. We can just point people to your service. If not, we would like you to describe your service access policy in a reasonable way that users can understand. We looked at very different ways to capture this data in the past, but what we've come down to is, in a few lines explain what your service access policy is. To give you an example from colleagues in Italy, their access policy was, it's paid if you're European, it's free if you're Italian because it was underwritten by the Italian government. This is then a mixture between a market access model and what we would call a policy-based access model, you can use the service if you're in this area, but you can explain this in just a couple of lines of text. We then will ask you to list as a checklist which of these models you're actually using, and this is more for information for us and also for the commission in how these services are delivered. This is useful stuff for us. We then offer the opportunity to set up service ordering through the portal. Now I would like to stress that the setup of service ordering is not part of the onboarding process but it is triggered by the onboarding process. So over this stage, you want to not only have your service listed and people click through to it, but you want them to be able to directly order the service. That is an option, but we can't gather the data in a form like this because the way that that will happen can really vary. A lot of service ordering happens by essentially collecting data for a formatted email sent to a provider who then follows up with the person requesting it. In other cases, it's an API call to use Ansible to deploy something on a cloud infrastructure and it's straight away available. There are a lot of different options. So really here we're just asking, do you want to set up service ordering and who do you want to actually do that setup? So we ask for some service administrators. Then that process is handled by a slightly different part of the OSCUB run by my colleague, Debra Testi, who deal with the service ordering. Service ordering is happening through OSC not huge volumes and it's largely ordering of services which are pretty highly integrated with the OSCUB because they come out of the project or are very close to your OSCUB, but there are others as well. So getting to the end here and I think this is my last slide with a picture of the spreadsheet, you'll offer the option to look at attribution of your service. So basically who paid for it? This is really mostly of use to funders, but it's also of use to you as providers because it allows you to tell the funders that you have acknowledged them and it allows that information to be available through your support. I think we all recognize that while this may not increase the scientific value of your work, being able to show funding agencies how widely their funding has had an impact in the research community is a necessity of the world to be working. I would call this sort of reflexive communication or dissemination to the funders and it's reasonable for them to ask those sorts of questions. So we want to make that easier. In the long run, I hope that if we have PIDs for services or some sort of identifier some of this can be automated. For now we give the opportunity basically to say do you want to give some attribution? And then basically listing funding bodies, programs and grant names, it's this option. And then I will throw I think there's nothing else on the slide I still so I will go to one more slide and then hopefully we get to the more discursive bits. The last few tabs on the form are basically supporting information. So I've just screen-shotted bits with here so these are country and language codes, TRL levels, loads, just the single-learn description and a view of the Frascati Fields of Science description that we use. So this is just so the information you need is in the file. How this happens in future with the work that we asked in Hans will be seen. Even for central formally had a companion document with all of this information in. It was good because it kept the documents shorter but it was bad because it had to be two documents. So there are positives and negatives. I think a lot of this, if we're using tooling to fill these in can be through tooltips or contextual menus. There are other ways to provide this information. This is just supporting material really. And lastly, after this, hopefully not mammoth effort of doing this, but after you filled in all of this what happens next? So next there is a publication step and this is thankfully the end of the story. We take your filled in description template or resource profile and we have to translate that to what appears on your screen. Right now, this is not a great process. It's basically quite manual for various reasons about integrating the different sources of this data. In future, this will be a fully automated process where we just press a button and it appears. But for now, we're essentially transcribing data manually basically, which is not ideal. Because of this, it's a bit of a multi-step process. So after the data is validated, a member of our publishing team will translate the data into a draft entry in the Oscar marketplace. They will then send that to the owners of the service and ask them to log into the back end of the marketplace and have a look at it to make sure that we've got it right. And then after that, and it's been approved by the provider, it goes live. This often leads to a bit of pinging back and forth with emails, which is quite annoying. And sometimes this delays the process quite a lot. But for now, it's a necessity, but one we're trying to tool out as quickly as we can. So I'd like to show, this workflow at the bottom is in fact our whole workflow for managing tickets. I'm not gonna go through it in detail, but the publishing is this whole section on the right. So there's as many steps there as there are in quite a lot of the rest of the diagram. We hope to really streamline this process. There is a question though that we do have to think about about do we still want some checking by providers of a draft before things go live? This is something we probably need to discuss. Right, so after that, what I've essentially talked about is adding a record to the registry. Of course, adding a record to the registry is not the only activity. And I think this comes from also one of the questions in the chat. For me, in a way, we have not covered the full range of the tasks we need to in dealing with these registries because my specialism is in service portfolio management which this is definitely part of. But if you look at the typical activities involved in service portfolio management from some IT service management standard, we'll see three things. We'll see add a service, modify, maintain a service and retire or remove a service. And really we've done all of the work in the first step. This is partly historical because the request to launch EOS portal was not one that was planned by the people who launched it. It was something the commission asked of us and we had to scramble to do and I think we've done quite effectively but still had to scramble to do it. A lot of the effort went into the onboarding rather than maintenance. And now for me is really a time when we have to massively improve the maturity of the rest of the process. So we don't currently have a separate workflow for updating records to creating new records. So for now, what essentially happens is you create a new ticket but refer to the same service description template and tell us what you want us to change but we have to run it through the same workflow. This is not good. This is not ideal and this needs to be fixed. And trust me, we're paying attention to this. Because we are moving towards a new version of the onboarding process together with EOS enhance, we haven't made some of the changes to the old process up to now because there was no point changing a process we were soon to replace. The core data remains the same but the steps in the process are changing a bit. So expect to see a better process rather than essentially reusing the onboarding workflow with skipping some steps because that's what we can do. We also need to consider just updates in general not just in terms of how we deal with updates but how do we get you as providers to deal with updates? We need to make sure that part of the rules of participation, part of the agreements that providers have is that they must update their service data periodically. Maybe it's twice a year, maybe it's once a quarter, you have to decide on something reasonable and then we need some way to monitor that. And this is something that's been considered for the tooling for the provider portal, I know. Right now that's not explicit. So there are greater risks of outdated services persisting in the registry. What we plan to do because we are now moving towards this next version of the resource and provider profiles, we are going to have to shift everyone's data who is already onboarded to the new profiles. In doing that, we're going to find a whole bunch of gaps and a whole bunch of issues. We are then going to request that the providers log in and look at the new version of their entry and basically correct it. We're not gonna ask you to do the transfer, that will be just simply not fair and it'll be too under us on all of you. We're going to automate it as much as possible and then basically get providers to do one, probably fairly big bang revision of the data about their service, which hopefully they then won't have to do again for some period of time, because this is the big integration step from the different data sources. After this we're talking about maintenance updates which are far less impactful on what data you fill in. And I think then it's probably fair to ask after what a year and a half of the OSP portal existing for one big update. And then after that relatively small updates. And finally on removing services, we already retire on request, but this is not best effort, it's just not a particularly well-defined process, but it works nonetheless. For suspension, this is somewhere where we have an informal process, but we do have some escalation path really, because certainly when we suspend the service we have to have somewhere that people can complain about that or ask about that or try and appeal it. So we have some structures in place for this. So then next steps, we're almost at the end. Version 1.3 of the SDT is moving to the enhance provider and resource profiles version three. The combined onboarding process for this will be have the tooling and the platform for enhance. The OSCARP will still be providing a lot of the effort for this, so it's a joint activity. We will start using this new version of the form as soon as we can, and then we'll try and migrate everyone's data over to it. We also see the option for future expansion into other resource types, particularly through the workload. The process is we need to update the, sorry, we need the update and removal process to be clarified. I absolutely accept this as a really valid criticism. And we need to move to joint onboarding with enhance. And then for the criteria and rules, so RIP version 0.2, the first version out for comment came out of comment a couple of months ago. They're currently collating the feedback. Luckily I'm involved with that process, so I get to see what's going on and try and keep us ahead of it. RIP 0.3 should be out soon for further consultation. We really need to see what that looks like. However, I expect it's going to be still at a very high level. And one of the things that I see, we really need to do as a community is work out what is the steps between the rules of participation and the practical implementation of those rules. And the inclusion criteria you saw on the top of this presentation were really our attempt to do that. And that's something I hope we can do in concert more than we have in the past. And then my last slide, and this is an advert I made yesterday, after the Budapest symposium, some interest groups were set up. And one of them was on service and research product catalogs. This group has never really gone off the ground, but I really would like it to because I think this is a topic where we really need to collaborate between the providers, between EOSCUB and the projects that come after it, and between the thematic and regional and other marketplaces, community organizations. Because a lot of the value that we can add relies on us having shared processes, shared data models, profiles as you've seen today. So I'm going to hope to use this platform and encourage others to use this platform to discuss these issues going forward. I will get the EOSCUB and Hans project to put as much content as possible into it for review. I would also encourage the rules of participation group to make sure that their consultations are listed there as well. And I would also ask you guys all to join it. I think it would be really useful if they had greater participation than not many. So I'll leave the link there. That's the end of this talk, which was just me talking for an hour and 20 minutes. I hope I didn't bore you too much. We have some time for questions. I'm going to leave this slide up, and not my thanks for your attention last slide, so you can see the link to the interest group. But I will just grab a couple of questions that I see. One from Anastas Mishaev asking, how does this relate to Jorge's presentation about enhanced profiles in the version three? And then I think Anastas realized that I did actually cover that. We are moving to use exactly that version three that he presented as soon as it's available. I think it will be available probably first of June. If the tooling is not available for it, we will keep our current process, but swap out the spreadsheet for the one from version three. And as soon as we can ditch using spreadsheets, we will start redirecting people to the provider portal, which I think is provider.iosportal.eu, which is where you'll be able to do the same thing. This would make life much easier for us. We're very enthusiastic to do it, but enhanced have to have the tooling ready for us to do it. And so version three has to be out. The onboarding process has to be agreed, and they have to technically implement it. But we will take as little time as possible using anything out of date. There's also a question I see from Alexios Chatzigoulas. When is the next big update? Should we wait until then to submit services? I mean, I say don't wait, personally. If you want to wait until the first week of June, fine, because then hopefully we'll be shifting to using version three of the provider profile and the resource profile, that's only a couple of weeks time. And I think that wouldn't hurt. Then you wouldn't have to update data so much. But in case there's any delay, or you need this to be visible to your funders or for your project success update now, the worst that's gonna happen is, you'll be asked to recheck your entry in the provider portal when it goes live and add any missing data. And if you're onboarding now, the delta will be quite small. It'll be biggest for the people who onboarded, for instance, right at the start of the OSCUB with our version 1.0 template, because it was really made quite quickly and there was some gaps that we've identified in subsequent versions. So if you can wait until the first or second week of June, fine, it'll make our metrics for mail look terrible, but we understand we don't wanna waste your time, but I wouldn't be waiting longer than that personally. It's up to you and I'm happy to discuss this in a silent channel as well. Okay, I see there's at least a couple of other questions from the Slido. Are you planning to include repositories on a greater scale? What is in this regard your relation to data site, RE3 data? This one, Reuven shoving them. One thing I have asked from EOSCUB, I think it's something where I can still do with some guidance, is what is our strategy regarding data and repositories? Do we want EOSCUB to list every single repository in Europe? It's not for me to say. I know there are already things like RE3 data, which are lists of list of repositories or a list of lists of repositories. I know the work on data site, which is mostly DOIs, there has to be some EOSC level strategy on how far into data we go, usefully without replicating effort, whatever that is, that is what we will pursue. My work and also the work of enhance is more implementing these strategic questions rather than answering them. Are there questions I've been raising frequently and I hope there is more discussion on them because I think these are really important. Some aspects of data are going to be in the portal very soon, particularly through our work with OpenAir. So I think they're going to integrate the OpenAir graph into EOSCUB portal. I think they want to integrate some other lists of research products. They won't be displayed the same way quite when we see the display of services. This is inevitable. So I'm afraid, Reuven, that probably doesn't precisely answer your question, but I've tried my best, at least, but I think you raise a valid question. From Sophie Selvan, to get an idea of the numbers, how many onboarding requests do you get per week a month, excluding the false Vuitton bags, perhaps? You're mentioning you're waiting for it to soar soon. Is this due to the upcoming onboarding of services from the ES3 and 5B project? I think the month, sort of month's raise, it's somewhere between kind of one a day and, I don't know, 10 a day, something like that. And it's really variable. Some months it's really quite high. Some months it's maybe even less than one a day when we're working down. Still, right now, that represents quite a lot of effort because the effort per service is actually quite high while it's quite a manual process. I expect to see a lot more coming from, as you say, the ES3 and the 5B projects and the thematic clusters. I also know that, for instance, one of the people I work with from EOSCUB Nordic has told me that they have in national portals hundreds to thousands of services which they would potentially onboard. We ask once there is a clear pipeline to do that. So I expect that this is a pipeline which really needs to be scalable to very high numbers. In some ways, we know that we're onboarding people who already are in the club and know about it. And perhaps one of the criticisms you could make, and I know this came up in the Service Provider Forum, is that what is, right now, the benefit of onboarding to EOSC because quite a lot of the people looking at EOSCUB are the ones who already know these services anyway. Through the cluster projects, through the 5B projects and through the Infree OSCUB, 3 and 07 projects, I expect to see the number of people looking at EOSCUB that go up hugely. Therefore, the benefit of participation to go up hugely and the number of people onboarding to go up hugely. However, I would point out that in the last week, in the last 10 days, probably, we've had requests to onboard. I mentioned while there's a couple of ISPs, there was a public sector cloud provider who is definitely not in the EOSCUB domain, as well as the normal kind of people from the wider research community you expect. So it's clear that the message is getting out and we're getting requests from people that we wouldn't necessarily have thought would be onboarding now. And that drives a lot of these discussions about inclusion criteria because there are cases that we're never foreseen. I know that the e-infra-central project, for instance, didn't have to consider this because they were basically just going to EU projects and asking what services to provide in general. There's a bit more than that. Now things have moved on. We talk about an EOSCUB community that isn't just the projects. And lastly, from Frances Madden. When a provider is expected to have to update their info in line with the new profiles. Once the new profiles are in place, so we hope in June, we will have to do a technical exercise of basically mapping all the data. And then we have to have a way to get, let you review that data. I don't think we will do that until the provider portal is online because we don't want you to check your data in a spreadsheet if there is a nice web portal coming soon. I suspect that we will shift to using the new file, albeit manually in June. I expect probably it'll be after the summer when we're asking you to fill in the data. It'll definitely be this year but I'm guessing probably September. I can't say for certain. We really want to make the task as easy for you as providers as possible. We don't think it's fair to get you to do this over and over again. So we want to make this as controlled. And then how many VISTAs are there per month to find services? Do you get any feedback about searching services and training? I have to say I'm actually not the person who keeps an eye on that. There are other people who keep an eye on that. There are statistics that are kept requested by the EC. If you contact, I think Deborah, Testy or Magra Jata Crokovian, you can always send me a message early directly and I can put you in touch with the right people. There are metrics that we collect on a monthly basis for the EC about usage. And I believe there's also a plan to put this into a metrics portal which is publicly available as well. Right, we are one minute left. I've been talking for an hour and 29 minutes. If there are any other last questions, I would also say that if there are questions which are very complicated, probably won't answer them now, but we will keep the slido. I believe that the trust IT people will collate the data out of this slido so that we can look at what was raised and make sure there'd be something that's interesting future. I hope that this was a useful session. I know it was a lot of detail compared to some other sessions. I hope it wasn't too boring. I tried to make it interactive as much as I could, but inevitably it involves a lot of me talking at you. So are there any last comments or questions in either of the chats? No? Okay, well, in that case, it's 1600. We've kept time, which makes me happy. Thank you all very much for attending. I'm impressed how many people attended this session as well. I really appreciate it. I will just stick up my last slide, which has my email address on it. So if you want to get in contact with me, please feel free to drop me an email. And I hope I will see you all at the next event. And please, onboard your services, do we ask? Thanks, bye.