 a little slowly perhaps while people filter in and someone was saying in the chat I think that perhaps a different session was announced but I think this is a great one. My name is Evan Appleton and I work for EGI where I'm the Service Portfolio Manager. I do as I think Dale said in my introduction to the last session much the same for the USCUP project so I lead the task that's related to Service Portfolio Management and to onboarding so I think that's why I've been asked to give this talk today. Let's do the regular housekeeping we I think have for all of these sessions the events being recorded a link will be available so all mistakes or coughs or anything else will be recorded in perpetuity. Please don't activate your microphone and video unless the host gives you permission so for this session there'll be a couple of speakers and then there'll be a couple of others helping out later on in the session we've been answering some for questions and I think for this session we will use Zoom for questions. If you do want to speak you can raise your hand and one of one of the team will try and indicate that someone wants to speak but you can also write your questions in the chat. Okay let me give you the overview of the session. The session is about onboarding in general and service catalogs. I'm going to give a kind of general introduction to the current status of onboarding first and this will hopefully tell you where we are today which is some good some bad some complicated as I think most people expect but then I want to move on from that to talk about what's coming next. So we will have Jorge Sanchez from JNP and the EOSK Enhanced Project who will present their soon to be released provider and resource profiles which you would previously probably see called service description templates which is something that will be available very soon and will probably be the basis of onboarding into EOSK for at least quite a large number of projects and participants how widely it goes will be up to the participation of you here. Then I will come back and I will talk a little bit about a slightly more aspirational vision of where I think we're going to go or need to go because what we have today is an intermediate solution and I think it definitely has a lot of room for improvement and I want to make sure that we have some shared vision of where we can go and what benefits we can bring in terms of how we onboard resources into EOSK, how we connect with EOSK so I think that's an important thing to do. Then we will have a space for for discussions at the end one of the things I would quite like to discuss is how we implement the needs of participation and for that we'll have the participation of a couple more of my colleagues so we'll have Mark Randers-Sandon from surf and Matthew Villian from EGI who are both intimately involved in the onboarding process. So that's our outline let me go ahead this is what I want to talk about what's onboarding how does it work today I will mention the catalog an onboarding interest group at the end. Right there's an let me know that I love a diagram I have yet another one for you to look at again not a perfect representation but an attempt to show what onboarding is for those of you that perhaps might not already be very aware of this if you're from the broader community. So in this view of the world in which we're working up top in pride of places the research community understandably below that there is a layer which I've called the portals and APIs how they interact with the rest of EOSK there is a space for the researcher facing resources which would be called the exchange in the Tinman vocabulary I think and then under that underneath that there are the core services the internal services the federating core depending on your terminology and then below that the providers who support those core services. So we have some set of different actors in this space we have obviously users from the research community hopefully more every week and every month we have providers who provide services within this researcher facing resource space and those providers come with resources they come with services they come with data there will be other kinds of resource as well research products papers software and this terminology of resources I think Jorge will mention as well a little bit later but it's an important way to be able to cover all of the different kinds of entity we expect to see in EOSK there is sometimes a tendency to focus just on services and compute or just on data neither of them are a complete picture so by resource we mean any of those then of course we have some core services in the core of EOSK these are the internal services which keep things running the AI the accounting the monitoring the help desk and there are some providers who support them and when a user wants to benefit from EOSK they will through some portal or some API try and access some services some resources they will be connected through these portals or APIs to a service provider and their resources and this provider will then be supported hopefully by the core services of EOSK for instance by AI and this is supported by a core provider underneath what we mean by onboarding is adding to this pool so bringing providers into the researcher facing resource area and bringing their resources with this what we say is onboarding so I would define this as connecting providers and their resources to EOSK such that they can be accessed by researchers and can build over core services so they can interact with both sites hopefully that is is clear to everyone just forward now my slides frozen so let me just try that one more time no sorry we're having a typical technical problem let me try that again I'm afraid we may be experiencing a slight issue I will stop sharing my screen and start again it was going so well right I mean if you can display EOSK hub one that would be useful I don't know why it's glitching from my side it seems to be a zoom issue it's quite a lot of animation but I'll tell you where to go okay we'll try it this way apologies yeah so stop there I'll tell you where to go forward so in order to move forward a little bit we have to unfortunately understand where we've come from because the current practice of onboarding is very much related to the different actors who are involved so both the EOSK hub and the Infra-Central projects have both been onboarding providers and services in the past if you can go forward these go into their own catalog yeah that's fine these go into their own catalog the EOSK hub marketplace in the Infra-Central catalog there was then a request from DC which came somewhat unexpectedly but was a positive move forward to create EOSK portal so to combine these two different listings of services or resources into a single space and this is what we see with the EOS portal website and the EOS portal catalog marketplace depending on how you've how you see it listed which is embedded within the EOS portal if you go forward while that has been what we've been doing up to now there is now a new path for onboarding which is just coming online this is from the EOSK Enhanced project which of Sanchez I'm going to talk about so EOSK Enhanced brings together a lot of the people who were anyway involved in generating the EOSK portal but he's meant to take over a lot of the technical responsibilities around providing the portal around the tooling and the platform that's used for it it also more explicitly brings the open air community in so previously open air were involved in the development of the portal but we weren't onboarding data or other research products from open air into the portal now this is definitely something which is which is intended you can go forward and then lastly there is a another path for how we how we bring things into the portal which is from the other groups whether they are thematic projects national and regional projects or any other community portal community group who have their own registry of services registry of resources in which to add them to the EOSK and we see it as a necessity that there will be a way for them to bring them into EOSK as automatically as possible so I've used here some of the logos from the InfraEOSK 4 and 5 B projects but I think we can see this is representing our large group if you go forward so as I said before this top blue path this is what's working now and it works but it's a little bit messy because it's in the process of integrating a number of different efforts the path through enhance is being launched really right now we're moving to an enhanced based onboarding or an enhanced sponsored onboarding process very soon and data we hope to see showing up later in the year and then this last path is planned there are some experiments but it's not yet in I'm not yet to a finished level there right now what we're onboarding is services because that's the only thing which we have been set up to onboard but in the long run we definitely have to be thinking about onboarding all resources so services working first we're looking how to expand into data and particularly the research products that are coming out of open air and in future it has to really cover all possible resources but we're not there yet right now it's really based on services partly trying to answer questions that pop up what we took. Can you move forward? So this is the current what I would call it meta process for providers if I can go forward another one as well and this is the the process the providers have to go through in order to get right now a service but in principal learning resources we ask first they have to somehow submit a request this can happen in a couple of different ways and this is maybe showing that the process is a little messy for instance there is a form on the os portal which you can fill there is also an email address join it mailman.ios couple to you on the slide there or indeed we do get onboarding requests through personal emails to people involved in the process and this is not ideal but this is the reality of the world we're working we definitely want to make these processes stronger and push everyone through them rather than have many different ways in but this is how it's looking right now still pretty much however you contact at least the os cup you end up in the same place which is being asked to fill an online or offline form or hopefully students provide data by an API which describes your service and describes your provider this information gathering phase we internally called shifting if you ever hear that term although it's not particularly useful to the outside from here we have to go into a validation step so we have to check the appropriateness of a resource does it comply with the now emerging rules of participation is there something which should be part of the os as much as we're empowered to say that certainly and then lastly there's a publication step where the resource appears in public pages which is what we'll see in a sec if you go forward one more step I've highlighted some of the problems with this process as it stands today like I said before the the entry point there's multiple entry points and perhaps the documentation could be better I think a lot of this documentation needs to be moved to EOS portal it partly sat on different project websites up to now filling a form there they're fairly long right now although not all of them are required we'll see this later and if you come to the training for onboarding services tomorrow we'll go through the current EOS cup form in some detail there are also various versions of the different onboarding forms depending on whether you talk to the infra central or you talk to EOS cup or when you talk to one of these projects they do get updated over time some of file some of web forms validation actually works pretty well within EOS cup but at the same time it's going to be challenging to scale it effectively to a very high volume of services or other resources which we expect to see so we're well aware that this validation has to be improved and then lastly the the publication step frankly right now is very very manual and this is something that sometimes frustrates providers publication takes some time because there's some transcription information checking back with providers that it's acceptable showing them a draft of an entry in the EOS portal before things go live this is certainly somewhere in the future we expect to see a lot more to mention go forward right and this in fact we can almost skip over directly to the next slide because they're covering indeed much the same stuff I talked in terms of validation about the criteria which are used to decide whether a service should be in EOS and this is something which I think is important for everyone to understand and you don't have to read the fine details of this now and this is also available on the web on the service provider documentation part of the EOS cup weekly which is public but even if you fill in all of the forms that are provided accurately it may be that you're simply not the kind of resource service that we see as fitting the EOS we try to take a relatively liberal view but they do have to be some restrictions for instance about once a week we have an organization trying to sell Louis Vuitton handbags or Pandora bracelets trying to import their webshop to the EOS which we consider is out of scope the EOS and this is a real issue this may go up over time we will have to deal with this amount of spam but we have to have some criteria so if you go to the next slide I can show you not the criteria we've been using up to now but the criteria that we are moving to based on some recent discussions and I don't want you to go through all of this because you can do that at your leisure I want to highlight the part that's involved in the middle that basically it is very important that services are somehow related to EOS if we're going to bring them to EOS so the way we've tried to convey this although with some notes is that the service must be targeted to EOS in the EOS communities or it must build on or leverage EOS capabilities to serve some other community let me give you a brief example of that being targeted to EOS or EOS communities I think of this and I've given this example many times in other talks as the Dutch post office question what would happen if the Dutch post office wanted to onboard a service to EOS would we consider that that was actually an appropriate thing to be part of EOS Dutch researchers my colleagues at surf might choose to use the post office to send information to their colleagues there's nothing wrong with that but it doesn't seem particularly suited so what we're trying to say is that it's not so much that a service or another resource has to come from the research community or be for what could be for the research community in general but it should somehow address EOS to give you an example of this if if we accept commercial services in the EOS in the exchange and Google wanted to come with their Google cloud engine I would probably not accept that because it's of a generic service that frankly serves any community if they were to make a slightly more specific service offer that was the Google cloud engine for EOS I think this would be far more compelling and far more likely to be accepted or if they onboarded one of the science specific services they have I think that would be more acceptable but we have to have some sort of dividing line here and I have to tell you that we have questions that make this line difficult to understand on probably a weekly basis especially you know the other criteria there building on or leveraging EOS capabilities I think probably most of the people really interested in industry are perhaps in the other session that's going on right now about industry in EOSC but EOSC hub supports the EOSC Digital Innovation Hub which is a platform for collaboration with industry where SMEs are invited to come in to build on the expertise the resources the infrastructure that is available through EOSC to create new commercial services these are not targeted at us as researchers they're targeted at the commercial sector but they are still an added value coming out of EOSC so because they're building on or leveraging EOSC we would consider them as as valid for inclusion in EOSC can you go to the next slide so that's really all I wanted to say about onboarding today I'm a couple of minutes behind but not anything too much but I do want to make one last pitch which means saying after the last time we all met physically then rather than virtually in Budapest for the EOSC symposium a number of interest groups were formed so these interest groups were supposed to be places to discuss issues across all of the projects involved in the EOSC landscape the 30 to 50 then I guess projects that were going on one of them is the service and research product catalogs interest group which also definitely covers issues around onboarding up to now these groups or certainly this group has not been active at all it has some members of which I am one but I think it's lacked input to get so one thing I want to say coming out of this event when I think the onboarding is increasingly of interest to all of the certainly the cluster projects and 5p projects is can we start to use this platform to discuss some of these issues so I think we need to discuss the kind of catalogs we have the profiles which Jorge is going to present in a moment and I think a consultation on these profiles is something that will be well done there the onboarding process and the criteria that I just presented and I think we can certainly after this event upload the slides from this session and the recording of this session and then hopefully enhance and the EOSC hub will start to put some material here for wider consultation because I think this is a really important thing to do the next slide yeah so that was the end of my presentation thank you very much I did see some some questions which we'll try and return to at the end I think because I'd like to move on to Jorge's talk because there's some of the questions I think will be answered by that others will try and capture later on so I will try and scroll back in the chat later if not please retype your question and get to the question section afterwards so now I will mute myself in the handover to Jorge Sanchez who is from JNP and from the EOSC enhanced project where he leads the activities around profiles onboarding and other issues which are very relevant to the discussions we're having today Jorge go ahead good afternoon to all from Sani Athens today we are at 34 degrees so the summer is already here for us and I hope really that very soon this it will be possible for all of you to travel and fly to your preferred place for the summer I'm going to cover the provider and resource profiles version 3.0 as Owen said previously known as the service description templates later on service and resource description templates one of the major challenges that the european open science clouds aims to address is the historical lack of interoperable online catalogs of research resources that will enable european researchers to explore those across europe is something very very similar even worse in many other domains except from the research domains where even some interoperability at a large extent is possible our researchers as you very well know most of you are part of this ecosystem live work or conduct research across borders and this mobility needs to be supported by cross border services and seamless exchange of data unfortunately in many cases the environment in which this data exchange takes place is very complex creates many semantic interoperability conflicts that are in many cases caused by lack of commonly agreed data models the absence of universal reference data etc etc you very well know that the eos is part of a significant european initiative that is the single digital market therefore in the same context the eos is trying to break the borders of research data services across europe to achieve that goal we need to harmonize all those resources provided by european providers to increase the the user base by making those resources discoverable we need to widen the pool of users across all scientific communities and domains including also industry government and even citizens we also need to support the providers in this set language and pathway users to support all the community to become more user-oriented user-centered and business focused also it is significant for the overall european economy to identify through those efforts overlapping efforts but also gaps and last but not least to via this increased competition to facilitate continuous improvements and speed up innovation and as you very well known many european research providers have already their own public catalogs they are making their offers publicly available to any researcher many others are at very early stages of developing their catalogs they are following diverse standards framework and approaches some are describing their resources with a variety level of detail and complexity and others have still no discoverable or accessible path to their resource offerings to move to in the presentation i would like to provide here two definitions for the resources and the providers that are actually the two first entities that we are providing those profiles so the resources are assets made available by means of their system and according to the osc rules of participation to the end users to perform a process useful to deliver value in the context of the osc in some years ago a central later on those can have another projects mainly work on services but resources include the services data sources research products and any other assets currently we are also working into incorporating instruments and other similar assets physical assets also in the osc the providers are the air system user responsible for the provision of one or more of those resources to the osc and they are either organizations a part of an organization or a federation that manage and deliver the resources to the end users they take various forms as you know they can or they are called differently resource providers or service providers or data providers service develop research infrastructures distributed research etc etc in this complex and domain one of the projects that is supporting this unification homogenization is a osc enhance the main objectives of the project is to facilitate the underoperability of air provide the same resources across all the scientific disciplines and the project is mainly focusing on unification of processes specification guidelines and tools as well as APIs for the exchange of information among providers second the project is trying to enhance the discoverability of those resources through a number of technical enhancements mainly focusing of course on the osc portal and those enhancements are both for the air providers and the end users we are going to consult with the air ecosystem on all key results to allow for this wide adoption of an underpin interoperability and last but not least a osc enhance is also trying to establish the osc portal as one of the distribution points or points of access depending on how you see as a provider or as a user for the osc resources we fully understand that the osc is a system of systems that we have catalogs of catalogs so we are trying to allow all the possibility for to develop all those distribution points and open the market those key results are currently supported by a partnership that includes the four a flag cp infrastructure cgi udachi antenna opener as well as the five cluster projects and a number of partners that have the capacity to develop software as well as specifications and some other supporting functions to achieve the goals that i presented before within the osc enhance we have a specific action that is working on osc portal specification interoperability and quality framework in this one we are developing a framework for defining and describing those osc entities and also to exchange the information the metadata of these entities automatically to allow this scalability and sustainability of operations that are needed the first one we call os provider and resource profile the second one are the osc open rest apis this is the big picture that we want to serve providers are providing resources some of those resources are cataloged in registries in repositories in marketplaces in distributed research infrastructures in regional clouds or thematic clouds and what we are trying to do for the purpose of allowing all those distribution channels to exist as well as the eosc a single point also to be able to gather all those resources at european level are the profiles and the apis so the way that we describe those entities that we need to exchange the metadata as well as the interfaces that are implemented by the entities that exchange that that information in an automatic way without human intervention the description templates the profiles are also equally significant for the onboarding process because this is the way that we can actually have a homogeneous and if you want eos compliant onboarding process including the validation the validation that happens based on the information that the provider gives to us as well as the information on the resource as we speak we are working on the main onboarding process or when already presented the status of it also the onboarding process is in a we're working on the unification of that for the next version of the eos portal and as you can understand in the future other profiles for other entities may be needed to be also defined for the specifications that we have at hand for the two profiles that has been a lot of work in the past that started in 2016 by a group of projects that defined the first infrastructure catalog of services a number of commercial also companies are working on various areas like the team forum is one of those as well as a significant activity a european project fed the same that provided one standard for lightweight service management fit the same that also provided some groundwork on what we are currently trying to achieve those prior efforts consolidated in a number of versions by various activities the current version that the infra central has been onboarded is version 1.13 eos hub version 1.3 and a new version that has been developed with the incorporation of a quite a significant number of background information on the definition of those entities in catries version 2.0 so we leave all this back in the past because we are moving to a new version version 3.0 that we hope that this will be a de facto standard for the description of providers and resources and the definition of the apis for the eos as i said before we are we have defined two profiles the provider and the resource at this point of time and the specification provides the full data model the conceptual model that includes the for all the attributes of the model the coding scheme a definition the type compliant to api specifications at the f etc multiplicity whether the attribute is compulsory or not and furthermore whether the information we collect here is something that will be made available based on the eos private policy the model also provides a significant of a code list and classifications that are there to facilitate the implementation of onboarding schemes to facilitate the incorporation of the metadata by the providers but more significantly to support the user journey in any catalog including the eos portal so some of the code list are code lists that we have just using from organizations that are maintaining those continuously and some others that have been actually developed through the activities infra central eos have caters and others in the past the the specification also provides the an onboarding guide that is very useful for the providers that want to onboard to have guidelines for each one of the attributes but also gives also guidance for the human base and machine-based validation on each one of the attributes of the specification the specification also provides a transition plan from previous versions of the specification to new ones and as we speak those transitions are already happening from infra central and eos have registries to the new model that we have presented very fast to tell you that currently the two profiles include some blocks of information as you can see we have tried to homogenize also the description of the various entities that we are defining for the provider we have the basic marketing classification location contact maturity information and a number of other attributes that are under the other information block and similarly to the resource profile we have a number of information blocks some of which are similar to the provider and some new ones like dependencies attribution management access and other financial information the minimum set for interoperability on the two profiles is the following so if anyone wants to be interoperable with the eos portal or the eoskin general whether this is adopted overall you need for the profile to provide only the id name of aviation website description logo others and some contacts and similarly for the resource profile there is a number of minimum set of attributes this minimum set means that when you are able to exchange this information you are able to communicate with other entities in the eosk including the eos portal and that you can of course provide additional information whether this is needed for other purposes for the purpose of the eos portal and for the overall cataloging functionality and the user journey that we want to offer there there is a number of additional attributes specified in the profiles furthermore any other entity can include and extend the model with additional blocks of information for their own purposes the only thing that is needed is that this minimum set is maintained at least by all of us the specification provides also a large number of classifications i mentioned before some of which are here from scientific domains count etc all this is coded to facilitate and homogenize all the exchange of information and the apis and i finish here by saying a number of topics that could be of interest to the overall community apart from those profiles as owen mentioned before we have been also working on the specification of the eos portal onboarding process in april this process is also finalized there are still a number of small things that we need to complement basically the tooling behind the onboarding process some ticketing system behind to support that we have also concluded with the specification of the eos portal new requirements collection validation prioritization implementation and provision process the specifications for the eos profile will be delivered this month we are expecting a final approval by the project management board of eos can hands and then we will be working in may additionally for the on the placement of the metadata on the provider ux ui in june on the placement of the metadata of the end user ux ui later on we will provide uml rdf and xml for all for the two entities also to prepare the all the possibilities for exchange of information and the apis we will extend the eos resource profile for research products in july a number of online training tutorials will be offered for all these onboarding use of the specifications the profiles etc in august and in september we will extend the eos resource profile with four four data sources in october the specification of the eos portal apis based on version 3.0 will be ready and this specification means that the actual implementation of the api is also in place fully tested for anyone to onboard through this api the specification of the the quality assurance and support measures framework will be ready in number in november 2020 in the meantime the eos portal is currently being updated with all the requirements that have been collected a fully design of the user journey user component as well as the provider component is currently being taken place via an agile method where every week additional requirements are implemented and in december 2020 or a little bit earlier before the end of eos hub we are planning to update all the above specifications to version 4.0 and in this process we expect to receive and incorporate in the specifications the feedback from the community that's for from me now i want to mention as the last point that all the material produced specifically the one that they provided now but most of it is created under creative commons attribution 4.0 for everyone to make use of it in their similar activities thank you and i give back the floor to you Owen thank you thanks for that comprehensive talk through what's going on in the service and and provider profiles and i think like we said we will try and do some of the consultation using the interest as well as other channels as well because i think this is definitely something we need to do more of okay i'm going to try presenting my screen again and we'll see what happens if it fails then i will switch back to trying to do this the old-fashioned way with one of the other people presenting their screen but it's worth a go because i have more animations in the next talk as well so hopefully you can all now see my see my presentation i won't be able to chat right okay so now we've heard from Jorge back to me we've had the sort of current status we've had the immediate next steps of what's going on the austin hans i want to talk about a little bit of a further vision for what it looks like to connect providers and resources to us and i have a few points i want to touch on in this i want to talk about the end goal which i see as a system of systems hopefully this is something which is shared by other people i wanted to look at what that means in terms of a user view and in terms of a provider view and then i want to have a couple of examples of adding value on top of these basics of the osc and then hopefully we'll have time at the end for some discussion as well so a system of systems i think one thing i want to say straight away and hopefully this is also something Jorge kind of intimated i don't see an appetite for a single monolithic eosc and i really don't see anyone that does i see a lot of people who are enthusiastic about the osc who want to build it but at the same time they want them to make sure that they're not having their own community pushed out in favor of a central path into the osc that everyone was taking i don't think this is going to happen i think there is definitely enthusiasm for bridging as i've said on the slide here national thematic and community boundaries we want to extend research we want to extend science but not at the cost of the communities that brought us to and the system of systems approach is definitely one of the most realistic ways of doing this it's an approach i think from systems engineering where you deal with a collection of cooperating groups they are tied together they have some harmonization but they maintain independence in terms of operation in terms of management and the hold is greater than the sum of the parts you should see emergent properties of these systems where by putting everything together you'll see new innovations new opportunities that arise which you wouldn't have seen if they're all separate yet we still avoid this monolithic approach so we take a european federated approach hopefully the uk is involved so how does this look from the user side more diagrams i'm afraid so we have a user they are a researcher presumably and they are happily existing in a world where eosk is stressing user choice and empowerment and i think this is definitely where we want to be they're going to have a number of different ways for me that they can get into eosk that they can access eosk resources i would say that they can stick with perhaps a community a way of getting into eosk so if they're part of a particular community i've suggested panosk here on the right so perhaps we have a photon or neutron scientist they've been working in that field for 20 25 years they have relationships there are community organizations they can still access eosk through say a panosk portal they can also if they so choose access eosk via a different kind of portal still not the central one but something which is regional or national or some other grouping clearly we're going to have these sort of portals coming out of the 5p projects so i expect to see some from perhaps eosk pillar here or they have the opportunity to go to eosk portal being the sort of central access point i don't see that these are all going to be the same but i see that at least we should strive that the basic benefits of eosk are available to researchers whichever accessory they choose and that means for me wherever they come in we're going to have the same AI so the same credential system i hope we can have the same approach to access policies policies will be different in different areas but we will try and harmonize them so they describe the same will have somewhat integrated help desks monitoring and accounting will span across these uh these different routes into eosk so that it might not be that you're grouping data on monitoring and accounting for a provider but maybe for a user to see what you've used where to be able to show this in the research i would also hope that public good open data sets things from the open access world these should be available everywhere within the system no matter your end but at the same time i think there have to be different advantages and disadvantages to the different ways he might come into eosk and i've suggested some you know possible ones here so if we look at the sort of regional national way in we might have access to local language services which are really not relevant outside of the area and i know this is particularly relevant for for instance the social sciences and digital humanities where a lot of content is in local languages by necessity and we lose a lot if we force everything into English there might also be nationally subsidized resources i know these access policies exist today if we go via a community portal a community marketplace you're going to have a lot of subject specific expertise and talking to for instance recently eosk life i was having a conversation with them they were saying that they have a level of annotation the ontologies and the categories for their data which is never going to be replicated realistically in other portals because it's so specific to their communities that's fine it can be a unique differentiator of that kind of way into eosk and then through the central way in through eosk portal here we would hope to have obviously a very comprehensive registry of all the resources available but also through the the next round of projects we're really hoping to see experiments and composability so the ability to take say this data set this visualization algorithm this processing system and this archiving system and plug these together all yeah as seamlessly as possible now i think we know that's not available today but that's certainly the direction we want to be pointing in and i think eosk portal needs to support that in its user space i would also see eosk portal as a place where we'd see some innovative value add services which make most sense in the central largest portal rather than one of the automatic original ones obviously from this is a great story from the user perspective but it's going to require some sort of coordination so i think apart from looking at this from the user side we also have to take a slightly more technical look of what this might mean from the provider side so this is a different rendering of the same thing i'll give you a moment to to digest this at the top we have the research community and then we have a layer of portals and apis which is likely how the research community is going to interact with the the services the resources that come out of eosk on the right side you see so the central way into eosk so this is at the top of the eosk portal there's some website content and there's also the marketplace of services and other resources this is supported by what i've chosen to call here and this is a term i've seen from a few people now the eosk platform so here i'm trying to differentiate between what is fundamentally the website part of eosk and the platform of internal core services and the resource registry that go with it which not only power the website part and the marketplace but also allow allow for connection to services from other actors within the space for value added services for connection to regional and thematic portals so i think this eosk platform maybe lessens the fear i have sometimes that when we talk about eosk we think of eosk as the portal and if we're just making a website i think we've failed to really have the ambition we need and show the added value we're trying to bring so this eosk platform includes the central resource registry so this is the profiles that uh hoho was just talking about we think we'll include eosk ai accounting help desk other core services other resources and there are obviously providers behind this who are mandated probably by the eosk legal entity to provide these services if we look at say a community organization like a thematic or national portal we'll see the same sort of structure so we'll see a marketplace and a portal there's a web part of it they'll have their own catalog of resources they'll have their own community internal services and providers and there are connections between the two we definitely need to see connections between the catalogs or registries of resources that are on the eosk portal and on a community organization and this is really what Horta was talking about but we also below that want to see connection in terms of the internal services so we will never i think telecommunity they must use eosk ai but they have the option to or they have the option to connect their existing solutions to the eosk ai such that credentials can be shared across a wider space so let's uh let's work this as a slightly more realistic example um and here i've decided to mention randomly eosk Nordic and escape as two examples one of a community and one of a national portal um they really have the same structure as this central structure which i've simplified a little bit in terms of onboarding what i would hope is that if a provider on boards to eosk portal through the central eosk channel they will have their resources entered in this central resource registry and therefore these will be exposed through eosk portal to the to the research community but because of these lateral connections they will also automatically be propagated to just Nordic perhaps into escape and will appear in in their portals as well i think there's no reason for that not to happen as long as we make sure we have agreement from providers that this is the case we want to want to look at and then conversely if you're on board just to eosk Nordic perhaps i would expect that to propagate back to the central registry and then across back to escape as well so i really want to see or at least i'm hoping to move to forward the structure where there is a free flow of the data about resources services data other research products between the different registries in this system of systems that we have a central resource registry in the that sits behind the eosk portal in this platform which empowers the eosk portal and is a service provided to the others should we say a bus for information about resources and that offers some opportunities for some added value services as well but that its purpose is not simply to create the eosk portal website and i think this is a more inclusive view of what onboarding means and benefits indeed so in the system of systems view the idea is on board once appear everywhere hopefully that there's something which is shared that means that the basic provider and resource profiles need to be essentially used everywhere and this means that we have to have a good basis of for them and get people to agree on them afterwards i think we will all agree that there will be actually say a core set of profiles that can be extended by specific communities there's no problem if the astrophysicists want to add extra data about their resources as an extra data block to the profile it doesn't affect others i think this is perfectly reasonable solution but the core parts remain the same and we need to make sure that there is a free flow of these these entries between the different portals catalogs and registries we also need to make sure and i think there are other sessions about this today as well that these internal services are connected to one another across the community that we have really good eosk level internal services and that they are made available to other communities and providers so your credentials work everywhere your support is somehow if not integrated at least interconnected and you can collate data across the whole community both for users and also for funders who want to see the impact of their funding and lastly there's the opportunity to add value to this picture so i'm just going to take two examples one is from the open air and the other you'll see in a moment so in looking at this sort of picture of eosk one thing that sometimes i'm not sure where to place are the added value services which are not addressing a specific research domain but neither can you say they are absolutely necessary for eosk to be running at all so i think if we don't have some ai system there is no eosk i don't know if that's true or for instance the open air research graph on the other hand the open air research graph as i've mentioned in a moment is something that can be extremely valuable and add a lot to eosk so we have this sort of middle space between very basic keep the lights on internal services and the researcher focused for a specific community or a specific use for services in the exchange that we somehow need to find a space for and this will be an example so as i understand it the open air research graph and i think i stole some text from some slides from my colleague perlomandy on this um it basically interlinked the data about scientific products from the open access such that you can use it in a whole load of different ways you can mine this data for business purposes for research purposes to understand the impact of your work there's a there are a lot of opportunities that come from connecting data about a research product with its publications software the communities within the organizations the project etc and i think this is something which certainly by adding it somewhere into this picture can make the eosk greater and i think that extending the graph as i say here to the wider eosk community would really increase its impact and in a system of systems there can be spaces for this um it would work in a monolithic uh kind of model but there's no appetite for it but in a fully distributed model there's sometimes a risk that we don't do these common public good added value services and i think this is one of the ones that we should one of the reasons we should look at a space for this and the other example is more really on the tool side so this is uh this is uh thinking about if you have this basic structure what additional tools might you want or need which are useful to the communities which do something which isn't otherwise nearly provided and one such example is agora which is a service portfolio management tool developed i think originally by grnet in greece but now in use by a whole bunch of different people the idea here is that what he may on board to a specific registry or even to multiple registries at the same time um you may not want to always be providing all your data straight away into that registry as an organization that may have multiple services you may want to manage that data internally first while you prepare it to make sure it's harmonized to make sure that it's really ready to be put out on the wider community and certainly this is a case that we see from the agi an organization and i know it's also something that shows up in in other organizations like eu data indeed using agora so the idea here is to have a platform where you can essentially fill in these these profiles that we've discussed before in a coherent way you can't just you can not only just fill them in but you can also connect them so if you have a larger umbrella organization such as my own which includes multiple organizations you can have all of those providers included and connected together through relationships you can create all your different resources and relationships between them as well and then when you want to publish them into out into eosk you select a target and hit hit publish it's done and this is still certainly in progress but the idea here would be not only can i publish i can also update my services and manage my the descriptions of my services much more easily than if i'm doing it separately on a whole bunch of different so this is another kind of space for an added value service which i think you will see in the systems of systems right that's the end of my my aspirational part of this talk and we're not far off time in fact and so i'd like to thank you for your attention and i'd like to move to a question and answer session we have quite a lot of time because i didn't want to make this session too long so i'm very happy to take quite a number of questions i'm going to put a few up if that's okay and i'm going to invite Jorge to join me in helping answer them and also my colleague mark van der sanden from surf i don't know if Matthew Villan is here i was also invited him but i don't know if he's been able to connect and perhaps we can answer some of the questions that have come up in the chat so let me uh let me put up this slide i'm going to pop out of presenter mode just so that i can see what's happening for a moment that's okay hopefully while i've been talking you're all still there so uh Jorge are you still there yes yes great and mark you're there as well yes fantastic so i have a number of questions that i've put up for discussion but i can see that there are quite a number that have popped up during the the discussion um i thought i'd maybe select one to start with uh because i wasn't able to to scroll through the chat while uh while we were while i was talking and maybe we can go from there so uh dian asked whether services should expire after a period of time to make sure that they're still fresh and live and i saw some discussion of this in the in the chat but maybe maybe mark do you want to give your give your view by voice and publicly and then we can discuss a little bit before we move on uh yeah no problem uh also provide a little bit of answer in the chat um the the serve descriptions that the resource profile should should be maintained so we need a process that those uh uh descriptions are being maintained on the regular pro on the regular basis and that should be part of the responsibilities of the service providers for for doing and if this can be stimulated uh more uh actively so that resource providers are doing this then we can automate this as possible uh as far as possible but uh to certainly part of the responsibility that services are being maintained so descriptions are maintained uh and services are out of business then those services are being deprecated also within the service catalog yep i agree i also think that um yeah we have to we have to have a clearer agreement with providers this is one of those things that's been pending for a while but it's been hard to do until we get to a certain maturity that um we have to be much clearer about what reciprocal i mean for what we're offering providers what do we require from them part of that will be periodic updating of their data so it may not be an expiry so much as you must log in and update your data every six months every one year uh to make sure that uh you're still connected you're paying attention this is a that's maybe also a basic level of monitoring can be in place so that you can monitor if the services are available uh you should see how we can automate this process as much as possible yeah and this is actually an interesting question of monitoring because one of the balances we have to achieve in integrating uh these sort of core EOSC processes like monitoring and counting AI is how we are what are we requiring of the providers how easy is it to offer us to monitor whether a service is alive or not we can check whether the web page is up but does that tell us anything about the service and how much work is it for them to integrate some sort of heartbeat into their service which can be read by the EOSC in the central way on the other hand i think there's something that could be really valuable to do as well um if i may just pick up on that as well hello there hi uh yeah so i think it's really important that we retain the quality of the list of services if we populate any catalogue and have no uh ongoing verification that the information is live and also that the service is still live then that will very quickly degrade the whole point of having such a catalogue there should be a way of checking that services are alive and there should be a way that service providers can easily update the information we have about them um yep i agree okay um so uh we have some questions in the chat as well as the questions that i've put up but let's try some of the ones from the chat i'm i see a lot of questions from Dushan which i will try and answer at some point but they're pointing at slide numbers so some of that might be slightly harder for me to pull up uh so let me see what do we have from Anna here from a very practical standpoint how is it possible to make it an obligation for service providers to keep their service descriptions up to date so this is really building on what we just said so anyone want to want to try and answer that i think you already answered it a little bit in the previous comment uh we need better agreements between a service providers uh for registering services but also for maintaining information within the service catalogue yeah i think this also comes down to what is our what is our uh recourse if people don't do things and this is something that's been discussed in the rules of participation as well in the end all we can do and the only real final outcome we have is disconnection from the OSC somehow and i guess it really depends how important that is for providers how seriously they take it it's not something i think any of us want to do but we are going to have to have some sort of way to deal with that i suspect that should we say suspension might be might be the the first thing that you do if someone isn't updating their service after a significant period of time so maybe it still exists in a registry but is listed as inactive or maybe it's delisted entirely but the data is still there or maybe you literally just remove them from the system there is going to have to be some way to deal with that in terms of escalation or appeal as well which i think will relate to the rules of participation to the legal entity right i'm going to try and see if i can tackle some of Duchenne's very large number of questions especially since some of the other one other people were also asking about them so give me a moment to process this according to the figure at slide seven all resources will be registered within the same catalog both services and repositories is this correct um i'll i'll try and answer that basically in the end we see that the osc should include registries of all kinds of resource uh on on the other hand we have this very strange situation where much just a lot of the language in the osc really focuses on data all of the registries focused on services and we have to somehow bring these two things together in a realistic way i think that uh it may not it well it may be a single registry with two distinct areas or it may be two registries that sit next to each other on the same page how the technical solution happens is really a decision that's open but i do think that some amount you know as many of the resources as possible for me should be exposed through the through yours portal and through also the other portals from the other communities as well that's my view at least uh does anyone else want to comment on that you're happy with my answer uh yeah i'm happy with that was the answer good um there's also some questions about um uh are there is there one procedure or several um this for onboarding i think this is something which i was trying to trying to talk about but then we hit some technical bumps there are there have been a number of procedures that lead to the same place for at least about four or five months now so there is a single list of services certainly on your support which get there some from the central entries some from entries that are onboarding via yours cub um we are trying to move towards a a a combined process for onboarding for both of those groups the question then goes to uh what about the infreos fire b projects should they have to use this process and i think this is a really interesting question for me at least um we can't tell other projects how to do their onboarding but i think we're going to have to agree that if we want to shift data about resources between registries it has to be in a common or mappable format and if we want to do that without revalidating services and other resources every time they move between catalogs we have to have a common approach to validation so certainly what i've been pushing in uh yours cub and we've been discussing in enhance and also in some of the preparation with some people for the infreos go through projects is there needs to essentially be a common approach to validating services and the anyone who wants to share uh resource profiles needs to agree with each other they will validate things the same way so that we don't have to have these constant barriers so anyone else want to comment on that no i fully i fully agree this this is our recommendation and nonetheless uh issues like those are things that are currently being discussed in the working groups and certainly this is a topic also for the legal entity to conclude on the rules of participation the code of conduct privacy policy and these type of things that are crucial to allow for uh distributed onboarding and the uh system of system as is envisioned by many in this community yeah um i think also there is a related question here which um i have on the on the slide that's popped up um basically i said uh where is it should we validate before publication or audit after publication uh this is something we've discussed a little bit in enhance um right now how onboarding has worked for eos cub uh is that every service was checked before it went live um and had to be explicitly allowed i think in the central this was slightly different that essentially the first service was validated is that correct for me then after you could yes the the provider was validated then the first service was validated and then after that we consider the that the provider has enough maturity to go on and on board all the remaining services nonetheless uh a validation is required uh at some point of time and therefore uh through these uh we could allow the scalability needed especially in heavy times with a lot of onboarding but keep the quality with the validation that still is possible at the later stage so what i'm suggesting for the next stage of this personally is that we validate providers to check that providers are are basically the right sort of groups so that we avoid the people who for instance are trying to sell the e-vita handbags because they do exist and then probably with resources we ask people to essentially self certify that they're that the resources they are then onboarding are compliant and if they're not we have an ability to suspend them there is a an interesting reason for perhaps taking this approach which certainly i think would be easier because it reduces the load it makes things more scalable and if you explicitly approve something you are in some way taking responsibility for the content and i think in the days when the infra central was starting they were essentially polling EU projects this is where they as i understand started off so that they understood that the base of people they were asking about their services were all parts of the same world that we're in this has changed a little bit already now with the osc cup and now i think with the osc is a bigger thing mentioned by senior members of the european commission you will have people trying to join who aren't really appropriate so there is a risk that we validate a service that then turns out to for instance be doing bitcoin mining and we didn't realize that and that if we've explicitly said yes to it perhaps we have some legal responsibility so apart from a scalability argument i think there's a liability argument that perhaps onboarding providers then allowing services to basically be self-certified is compliant but suspending them if we feel they are not compliant is probably a more scalable and more realistic approach um this is certainly what i think i see there is a lot of chat in the chat so if we can go back to that but does anyone else want any of the other the mark or matthew want to comment on the validation issue yeah the validation is a certain challenge on this there's also a separation of responsibility we can do as much as possible but we cannot do everything there was also a comment in the chat of the quality of the service and therefore you need very specialized expertise to to to assess the quality of the service and i think that is also challenging but also in separation of responsibilities that service providers provide information crucially as far as possible and assure that the quality which they mention as the quality of the service is a smack we use the the technology ready list level for for showing quality of service but that is a very difficult to assess and validate and many people have different opinions on this so it can be challenging on this level anyone else want to comment on that if we try another question so skipping about slightly i see a question from tim pinchetti what are the responsibilities of resource consumers to ensure good quality and continuity of service e.g. contracts monitoring data processor agreements i assume that what we're talking about here is the users their responsibilities as well as the providers of services this for me is probably covered somewhere by rules of participation but again probably needs to be clarified i think rules of participation definitely need to be directed not only at providers but also at users of the osc they have their own responsibilities there are terms of service there are things they mustn't do with the osc but i don't know if that's exactly what the question was asking and that's why i was crossing over that one briefly however here's another one which we can definitely try and answer for this carry on is uh is surprisingly if you've been in other sessions this week asking about dashboard trend users which is a topic he's raised elsewhere as well so he says are you considering a customizable personalized dashboard for you that can be individualized for each user the current list of services when everything will be ready will be very long and users may not want to spend time in searching around also some tagging for individual specific disciplines sub-disciplines based on some standards kind of glossing over this a little bit so the question here is do we foresee a user space which is somehow customizable to them this is i think certainly something which in Hans has some views on right yes certainly there is already a requirement on that for some time and the development team is currently already developed the the space for the users to declare to state some of their um profile which will hugely help to build functionality to support a prediction as what is stated here based on on that and previous use or use of similar profiles so this is certainly something that will be very soon available on the on the portal yes there's also a comment from Matthew I see here the answer in photos which i think is is correct that enhance is meant to do quite a lot of the more basic functionality the things we really need and then we're hoping that in free osc 3 will add some additional features as well some of the extra added value things on top of what enhance is built whatever in free osc 3 project is funded will overlap with enhance by pretty much a year i think so there will be a good amount of time to do some sort of into the handover so i see another question how many services have been on boarded up to now to eosk and how many of them have been suspended as you mentioned in one of the answers and i see mark then linked the eosk marketplace um so the eosk marketplace i think has somewhere in the region of 200 well high 200s at the moment 261 results um just to mention that these 261 results because they merged two different lists probably more onboarding has gone on than 261 events because quite a lot were in both lists and have been merged that's roughly where we are now and it does go in fits and starts i can tell you there are some weeks where you have a very very great number of requests and some words rather some rather fewer especially when there are funding deadlines or christmas um the question of how many have been suspended um this isn't well i see two questions related how have been suspended and how many have been or have we rejected any service providers i'll come to the rejection in a second because i think perhaps mark and matthew can also talk about that but in terms of suspension honestly one of the weaknesses of the process today is that we call it onboarding and what it should actually be called is portfolio management or registry management and onboarding is is only one activity within that which is populating a registry or a portfolio and the process is updating and then decommissioning or or shutting down and checking the life liveliness of resources are not as well developed as the processes for populating registry that is an artifact of basically the fact that the hospital was an unplanned activity from the projects that put it together and a huge amount of effort had to go into getting getting resources in and finding way to bring resources into it now really is a time when we definitely have to improve those other steps so we need to look at our services still alive have they been updated recently and then have a more structured process for keeping them out but in terms of rejection maybe since mark and matthew both involved in the onboarding team and validation you might want to talk about the kind of rejections we do okay yeah we have some rejections some onboarding requests are automatically almost rejected because these come from commercial websites try to onboard selling everything what they want but also we have some some rejections basis of longer discussions because then those are in a gray area how far does this fit within the criteria of what we have selected for the onboarding criterion and then you go for example to organizations who wants to onboard the whole organization and not a specific service which they offer that can be in a human service or a technical IT service but also services which are very very generic which they offer to everyone so it is not really as specific to what is the added value of providing the service to research organizations or to eosk so we engage with those service providers to optimize what kind of service they are able to like to onboard or to say what would be the offer for eosk instead of a very generic offer so we have regular engagements on this but also internally we have different discussions to see how does this fit within the criteria should we reject should we ask more information or should we adapt so we have different approaches yeah Matthew did you want to say something just another class of rejection that I can think of is when we determine that a service that is requesting to be onboarded is clearly not of adequate maturity so we use the TRL the technically readiness level to assess the maturity of a service and if it's nowhere near TRL8 then we would explain the reasons why they would not be mature enough to onboard now and that may be you know do some more work and then come back in the future and try again I think it's really good sorry enough team work yeah I think certainly on the TRL level we have some some frequent discussions also on this because the TRL is not really the old way of specifying the maturity we have seen some discrepancies between how the TRLs being listed for the onboarding service or how the service is being promoted towards researchers within their own catalog environments within a theater website and that is also more an area of negotiation discussing with the service provided to reflect that the information which is onboarded within the service catalog reflects as much as possible also how the service is being promoted towards the researcher Yeah there's something else I want to mention here which is there is something between acceptance and rejection which is providers who essentially have to come up with new information that they didn't previously have available in order to meet our requirements if you look at the requirements for onboarding really there are two sets one is you have to fill the form and you have to fill all the required fields in the form and it's I mean Jorge and Mark and I have had many long discussions about what should be required and what shouldn't some of the things that are required so EOS conference since requires a privacy policy if you want to onboard a service we feel that in the era of GDPR of information security being a big issue we don't we don't validate the quality of your privacy policy but we expect a mature provider to give some view on the privacy of the information that they are gathering and to make that public and so we use that as a filtering step to try and see if they're mature enough a lot of providers don't have this or they have it for their institution but not for the actual service and quite often you find that terms of use privacy policies even help desks and by help desk I don't mean like a ticketing system I mean even just a generic email request help for a service are being created because we're asking for them so when I'm only asking people to describe their services we aren't kind of slowly drawing up the maturity of the services from the research community through what we asked them for and I think this is something which has proved actually really quite successful so I see that the flow of questions has slightly dried up I see more comments from photos that some of our views need to get up to the executive board I'm always happy if that happens are there any other questions that are recently from Hassani Muhammad which resources are allowed for IA research and what is chemistry of I'm afraid I don't quite get the the subject of your question Hassani I mean we did show some criteria early earlier really anything targeted towards EOSC and the research community would in principle be allowed although there are some discussions about whether commercial services should be in or not this suddenly came up yesterday as well this whole concept of free of point of use and I do would like to use this opportunity to bring in this issue here implementing the rules of participation there were questions about you know what it's what precise criteria need to be meant to on board the rules of participation one would expect would provide these but in fact EOSC and the Central were having to come up with criteria for what to on board before the working groups were created in the first place and they are providing some very interesting work but we have had to in the meantime go forward as best we can based on what we think is our goals and our missions and what our projects are meant to do and align that with the rules of participation as they and the other things coming out of the working groups as they emerge and that's sometimes challenging because there the rules of participation can be at a much higher level than the practical considerations of to improve suppose so I see a question from Brenner Silva does EOSC have our funding that goes beyond 2021 what developmental world activities are expected in the near future briefly EOSC have only has funding for 2020 however there is a call which ends in June called in for EOSC 03 which appears to include many of the functions that one would see in EOSC hub and this is for a very very large scale project starting presumably first of January next year so there is funding for the continuation of this efforts precisely which services are in how it's run who is involved is still to be seen but there is funding right now from the commission for I think through 2021 2022 and into 2023 for this there are also some calls in pretty also that's seven right but there is also EOSC enhanced which also supports for the development of EOSC which is on the end of 2021 pretty much yeah so we only have a couple of minutes left according to our schedule does anyone else have any other questions or are there any questions which people asked earlier and I missed when there was a very fast pace of questions and they would like to re-type or react no okay and is there anything else any of my panelists colleagues Matthew Mark or Jorge would like to say before we end this session just a shameless plug for the service provider forum tomorrow midday good call yes this is actually something I should have mentioned Matthew Matthew's running a very interesting session for service providers tomorrow based on I think surveying some experiences of a longboard in using EOSC and I think that there's some interesting discussions to be had there so I encourage you to go to that session there is a question can you save the chat if there's anyone here from yeah we save the chat there you go that's pretty much what I knew someone from first IT was going to say because I know they've been on this all week so that's that would be helpful and we'll look at the other questions there and try and get some answers to okay in that case I think I think we should stop I will just say apart from the plug for the service provider forum there is also a session which is training the service providers on how to on board which is really going to be going through in much more detail the current EOSC hub process from boarding looking at really all of the forms that you have to fill in I do have to say that this is material which is useful that will soon change somewhat using the profiles which Jorge was presenting earlier but this gives you an idea of the kind of information that we will be asking or whatever the name of the particular file your opinion is so I believe that's tomorrow afternoon and that's a rather longer session which I'll be running other than that I'd like to thank you all for participating I think we have really quite a good number of people here and for the very lively questions in the chat I know this is a question which also a topic which always drives a lot of discussion and I appreciate your participation okay thank you all very very much and hopefully next time I'll see you all in person rather than virtually okay goodbye thank you bye bye bye bye find all the links for tomorrow in the main agenda that has been updated on the EOSC hub website excellent thank you bye bye