Hello and welcome to this joint Freya and OpenAir webinar on the new developments in the field of persistent identifiers. And we have two excellent presenters with us today here. So our first speaker is Ketil Kopjakobsen from Pangea and Bremen University in Germany. He will speak about Freya project and new persistent identifiers developments. And our second speaker is Dr. Amir Ariyani. And he's ahead of SodaLab in the Swinburne University of Technology. And he's also on the board of directors of Research Graph Foundation. And my name is Irina Kutschmann. And I work for OpenAir and I will talk how OpenAir uses persistent identifiers. And Ketil, would you like to start your presentation? Yes. For questions please use either webinar chat functionality or Q&A functionality and we'll answer the questions. And it is supposed to be interactive so please type as many questions as you can. Thank you and please Ketil, over to you. Yeah, that's good up here. I'm sorry, I have some issues here. Okay, we're here. Okay, all right, I can do that. That's good. Okay, now I'm shared. Now we're here. Sorry about that. A little technical problems with a toolbar that was in the way of making my presentation to full screen. But here we are. So, today I would very much like to thank you for joining this joint webinar from Freyja and OpenAir. And my name is Ketil Kupjekeps and I'm from Pangia at Bremen University. Pangia is a data publisher and we work with data from many different scientific disciplines our primary area is in the natural sciences. Today I'm going to talk about the project Freyja and the new developments that we have done within the area of PID developments. The Freyja project just a little introduction to what it is that we are doing. Overall we are concerned with connecting open identifiers for discovery and access and use of research resources. Well in a nutshell that actually means that Freyja is all concerned with the use of persistent identifiers and if we take this little citation here from our description of work well then it explains what it is that we are actually doing and that is to extend the infrastructure for persistent identifiers as a core component of open research in the EU and globally and what that means is that Freyja is concerned with facilitating a better infrastructure for persistent identifiers meaning we are not the guys who are actually producing the pits but we are the people who are facilitating a better infrastructure to connect existing and emerging PIDs. Freyja is a Horizon 2020 project funded by the European Commission. We build on two preceding projects that some of you may have heard of that also were concerned with persistent identifiers namely Thor and Odin. Freyja started in December 2017 so we are a little bit more than a year into our work now and if you would like to see more about what it is that we do then please take a look at our web page that you can see here and also you can follow us on Twitter. One of the things that really characterizes Freyja is that we work interdisciplinary and that we draw on expertise from a very diverse group of partners and as you can see here we have all our partners listed we have Data Site Crossref Plus, CERN, British Library, SCFC, Pangea, Hundawi Dance and EMBL so a very diverse group including data repositories, publishers, research institution, PID providers and libraries. This means that we can actually face the challenges about improving the infrastructure for PIDs from many different angles and representing many different scientific disciplines. One of the things when you hear about Freyja is that you will pretty much always be presented a PID graph. A PID graph is our basic tool that we work around and here we have a PID graph a basic one that illustrates how different PIDs that are already existing for the most part is connected and let me just walk you through the graph and then afterwards I will extend it so you can see what we mean by expanding it to include new PID types. Okay so we have a situation here if you follow my mouse here you can see that we have author one and author two they both have an orchid that's their PID together they make a publication that publication goes to the publisher it's accepted it's published it gets a DOI the publication has now a PID the author PID the orchid is included in the publication and the publication DOI is included in the orchid page of each author so they're interconnected. The publication is based on the dataset that dataset could come from the author in which case there would be a link between the dataset and the author but it can also come from an open repository like for instance here at Pangea where I work where we have datasets from all different kinds of disciplines available so you can actually search our database find a dataset that suits your purposes and the datasets that we have available are curated and published and have a PID in form of a DOI so the dataset PID is included in the publication and linked to the author through the publication. Now in order to analyze this dataset that the author found he or she might have used a software it could be a software that's available from a repository like Sonodo for instance and also there the software can be given a PID so the software that is used to analyze the dataset can be included in the publication and linked to the PIDs of the author so in this way Friar is trying to link different PIDs so what I talk to you about here that pretty much already exists but if we add go on to talk about institution well then it becomes more difficult because there's no clear PID scheme for institutions if we talk about new PID types like organizations that definitely people working on assigning PIDs for organizations also within Friar some of the our partners are involved with that and the progress is ongoing but there's not a mature PID system for organizations yet either then there's a sample the dataset might have been generated from a physical sample that exists somewhere and that sample has the opportunity of having a PID there are PID systems for samples out there the IGSN number for instance but it only covers like a certain part of the physical samples that could be available I'll get into that later then there's instruments the instruments that were used to analyze the sample to generate the dataset that goes into the publication now there is a lot of this debate about PIDs for instruments right now because there's a great need for it it would be great to have a PID that can identify the instrument that was used to analyze the sample however this is not an easy task because where do you start giving a PID to an instrument do you give it to a platform that has several instruments on it do you give it to an instrument itself that can be identified as an individual unit but what if you have an instrument that consists of several sensors do you give each sensor a PID and what if you then recalibrate the sensors after two years well then the whole foundation for the way that the instrument works is different do you assign on your PID in that case or do you leave it as it is well these are challenges that I mentioned here that I know there is a very nice group in RDA that is working on that right now but there's definitely a need for an instrument PID other new PIDs also could include data repositories needs a PID the grants that is funding it all the research I mean there are PIDs but we need a more universal system here conferences need a PID so this is what we in Freyja mean about extending the PID graph to also include new PIDs but the question is where do we start which new PIDs are the most important which are the easiest ones to take to the next level where they are actually easily implemented that is some of the questions that we are concerned with in Freyja so in order to analyze the landscape of the new PIDs we did an assessment of the PIDs that are out there and identified the gaps so which basically means the PID systems that we need but it's not there yet or is there in a still developing form and the way that we did that was that we explored the need for these PIDs by asking for use cases from the community and I'm going to get into what I mean by that in just a little bit but all this enabled us to identify the requirements for new potential PIDs so three bullet points on what Freyja is doing on the new PID landscape is first of all be assessed the current landscape of new PIDs that is done there's a report you can look it up on our web page what we're doing right now is we're trying to identify the needs for new PIDs and their requirements this is a long this is something that's almost done there'll be a report in a couple of months and then finally what we would like to do is to develop prototype for new PID times but that is a task that is still in progress but if we start up with defining the PID landscape then we did an analysis of the entire PID landscape looking at what's there what's existing what are the PID initiatives what's emerging what are people talking about what do they need and what is the maturity of all of these PIDs that we could possibly find out there in the research different research communities from all different scientific disciplines well altogether we found or identified 25 entities and by entities I mean things that could potentially be a sign of PID like publications conferences researchers organizations data and so on and so forth these entities either have a PID or need a PID however this is also not a simple task because there might be a significant overlap among different disciplines and that actually complicates it when we want to determine the maturity for instance we can hear talk about samples again well samples for geological samples there is an existing PID system the IGSN number but if we talk about cultural artifacts well then there is no good system for PIDs in this regard even though a cultural artifact can actually also be a physical sample well then there's something like historical persona well this is a persona it needs an PID for persons but it doesn't really fit the orchid system well if we talk about the remains of a historical person well then we can call it a physical sample but there's also no good PID in this regard but altogether for all of these 25 entities we identified the PID types that are already there and we assigned them a maturity level and there were actually only three entities researchers publications and data that have services that are deemed fully mature the the rest of them are either emerging which means that there is a PID system but it's under development or they're immature which means that people are talking about the needs for a PID system but they're not there yet you can see a report on this on our webpage then we move on and talk about identifying needs and requirements for new PIDs and this is where the use cases come to the picture because the method that we chose to use for identifying the needs and requirements for new PIDs was we asked the community the research community concerned with PIDs and PID assignment for use cases and I'm going to show you in a little bit what a use case is what a use case is in this regard but we got a lot of information here also from conferences where we asked the audience to give us use cases these use cases enabled us to identify PIDs new PIDs in high demand and identify the requirements for the progress of these new PIDs so what is a use case in the FRIAR context a use case in FRIAR describes a scenario where a PID is needed identifying a user a goal and its benefits and there it basically follows the template that you can see here on the right hand side as a user could be a researcher I want a PID for instruments that is my goal so that I can track all the publications that comes out of this new instruments that to benefit I as a user gain from having this new PID we collected a lot of use cases in a lot of different areas just to give you a few of the headlines here we have cross-linking literature and data we are instruments linking published metadata with instrument metadata tracking reuse of software and tracing outcome of research cruises so we have a very diverse collection of use cases I'm going to give you some examples in just a little bit but just a little bit about the numbers so altogether we collected 72 use cases in total and from 30 of them you could identify a use case that revolved around what we would call a new PID emerging or immature so just to give you an example here about what the use cases were that we collected and we have one use case that revolves around research cruises so it says as a funding agency I would like to trace the outcome of my financial contribution to a marine research cruise by tracking the data generated and articles physical samples and I would also like to track the future data and publications generated from my cruise and the samples it collected so if you boil this down then it's a funding agency that would like a research cruise ID so that it can track the future outcome of their investments we have another use case that revolves around software it says as a software author I want to be able to see the citations of my software aggregated across all versions so that I see a complete picture of reuse so if you boil this down the user is a software author he or she wants a software PID in order to track reuse which is the benefit for this particular user we have a use case that revolves around policy and from a research manager that says as a research manager I want to have policy IDs so that I can easily identify relevant policies and assess the compatibility between different policies so here we have excuse me a research manager who is the user who wants a policy PID that's the goal in order to benefit from being able to assess compatibility between different policies so from all of these 30 use cases we made what we call a popularity index so how many times were different PIDs and need for PIDs mentioned in these use cases some use cases had more than most of them actually had more than one PID mentioned so that's why the total number here adds up to more than 30 but still what we can see from there is that there is a really big demand for instrument PIDs there's a lot of talk and a lot of need for development of a PID for instruments a lot of other entities were mentioned in these use cases so what we're going on in FRIAR and analyzing further is not only instruments but also the repositories organizations physical samples grants and software and we added a few that we have personal interests in from the partners within FRIAR the research campaigns the data management plans and facilities so these are the nine PID systems that we are taking on for further analysis and what we want to do with them is that we want to identify the needs based on the user stories so why do the users want this particular PID and we want to validate the current status I mean here we can draw on the experience that we have from our landscape analysis but we want to analyze what it takes to expand this PID type to a level where it can be used more frequently and this validation also includes across disciplinary approach and here I would like to dwell a little bit on the physical samples again because I find them really interesting we had user stories that all labeled physical samples that revolved around information about sediment cores in a repository and tracing and relocating misplaced cultural artifacts and on top of that identifying samples of bacterial viral and fungal strains and as I told you before we have PID systems that are to some extent working in these areas but they're not fully covering all of them and so our goal here is to analyze what is out there and what it takes to actually find a system that'll work well maybe not for all of these different kinds of physical samples together but that in itself will also be a result if we can say okay we need a split or we need to try to merge them all together this should end up in a report that'll be available by the end of February and we can then try to match the requirements and the needs with the expertise that we have in FRIAR in order to see how we can move forward in terms of prototyping some of these PIDs I'm not going to go too much into the prototyping now but just to give you a little bit of an example of how we want to improve the infrastructure for these new and emerging PIDs I want to give you a use case here from Pangaea on how we have implemented the IDSN numbers so I've set this up as a use case scenario I'm a geologist I'm interested in sediment cores I add it has come to my knowledge through my search of all the literature available that there's something going on in the French Alps they're taking some very interesting samples there and I want to find out what data is available so I search in Pangaea and I found out that Banyat et al 2015 they published data and that is very interesting and I would actually like to know more about it so what kind of information do I get from the PIDs that are implemented in the data set in Pangaea so first of all we have a PID for the authors so most of the authors here have an orchid and the orchid is actionable so when we click on the orchid well then here we go when we click on the orchid as you can see here well then we will be directed directly to the orchid web page but we have additional information about the author in the data set there is also a PID for the data well this is the one that we're actually looking at and that is what we will use if we need to use the data set and cite it in another publication on top of that we have the article PID that will is also actionable and it'll take us directly to the to the journal web page where you will find the actual article where this data was published so these are the mature PIDs that I talked about what we have added further in in Pangaea and in particular to this data set here is we have implemented the IGSN numbers the numbers for the cores that we're taking in the French Alps to generate this particular data set these cores are stored in a core repository and have been assigned a PID and that is now available also in the in the data set from Pangaea here and this means that it's actionable and it'll take you to the IGSN web page where you can get information about this particular core where these data come from what kind of material where it was collected and where it's potentially stored at the moment so if you wanted to you could actually trace it down go get it get a sample and do your own analysis this is a little bit of a view of what it is that we would like to expand the new PIDs to also be included in in this kind of of information here to finish up just out in in conclusion our use case oriented method gave practical orientation about the users demand for new PIDs and we could see that in particular PIDs for instruments organizations physical samples grants and software were in high demand by the community the implementation of some of these new PIDs will definitely improve the users access to additional information and that is what we're trying to pave the way the way for here in Friya and with that that ends my presentation thank you very much thanks a lot Kettle are there any burning clarification questions to Kettle right now because if there are please type them in the chat or Q&A functionality if there are no well I can see raised hands but let me see if I can allow Peter to speak yeah just allowed you to talk if if you want to ask a question Peter maybe it's easy if you type your question in in a chat I think Peter is still mute yeah that's what I'm trying to figure out how to unmute I might be unmute from Peter's side because this is talking parameter yeah okay yeah Peter is saying that he does he doesn't really have a question right now shall we continue with Amir and please think about your questions for Kettle and also for Amir okay so thanks Arina let me start okay so now I think in the second talk I'm going to go a bit across a couple of different for like more philosophical perspective around the PIDs and connecting the scholarly works and I think if it would be in a way complementary to what Kettle said about creating the PID graph that I'm going to basically look at the PID graph more as a user or as an infrastructure that use the PID infrastructure rather than a PID provider so well I have been fortunate enough to work with the PID infrastructure system is almost about six years and all of this time we actually use this platform for a big bulk of connecting its scholarly works so in this presentation what I'm going to do I thought in the short time that we have I can talk about a bit of background that where and how the working group in the research data alliance got to the point to leverage the PID infrastructure I will talk about a kind of living-age technology that right now in this space using the PID and PID graph underneath and also I have a couple of points about the PID graph so that's that's would be almost aligned with the same things that Kettle mentioned and also the other thing is that this slide set is almost an abstract version of a one-hour talk so there is a lot of things here that I'm actually jump over the topics I'm going to mention them but it wouldn't have enough time to actually looking at details if there is a need for further discussion we can always have an offline conversation about any of the quoting code jargon and I'm going to mention as part of the presentation now well on the background side in back in about six years ago we had a problem which is still a lot of repositories still have that problem and that is finding the related data sets if you are running a data infrastructure if you are a researcher who is searching in a data infrastructure for a data set or if you just randomly come across a paper that cited a data set when you are looking at that data set you think okay what are the other data sets on the internet that are linked to this now in the concept of paper we have the paper citation and there are discovery tools and this is the other Microsoft academic graph and Google scholars and lots of different services that provide you with overall context around the publications and a scholar develops in that space but when it gets to the data our options are very limited Google recently launched a data search platform but still that wouldn't directly address the problem of looking at individual data set and find a related work to this now this was the issue for a group of data infrastructures and lots of people in this space in very early days in 2013 this led to creation of the working group that called data description registry interoperability the idea was finding better ways for connecting research data across multiple infrastructure points and one of the earlier partners in this project was Dryout Seam and Ants and I'm going to use some of that data to show you the sort of works that we did in the beginning to actually find some way to actually address this problem now this is a screenshot from the research data Australia that's a service that hosted by Australia National Data Service in Australia and you're looking at one page here which is a description of a data set on the right side you can see some similar data sets linked to this but assume that that thing is not there if you only have the information in the middle you probably if you search for information related to this you have multiple different options in the old days we actually used to grab a title or related keyboard and search in the data site rest services or other related things to find related data sets now the working group at a time okay well we can do better let's do a different method let's actually looking at the name of the author we can google the name of the author you will find a page of the researcher which is a professor Catherine Bill of in the University of Sydney you can go to that page we can go look at all the articles we can read the individual articles and in one of those we will find a link to a data set in a draw your repository which is actually in this case has a persistent identifier we go to that repository and we find another dataset by the same author which in this case actually has a different name or different abbreviation of that name it's called Bill of K so what happened here is actually we went from a dataset to a researcher from a researcher to a publication and from a publication to another data set we technically connected two different data sets by presenting the concept that they might be related we don't know if they're directly related but they're conceptually related they're produced either by the same author or they're the reference in the same publication so there are some links in that space that connect this information together that was the point of the dvri working group and the work that we did was around developing this model to find this will make it production level service the repository can use this for connecting the datasets in their own infrastructure the work was led to creating a piece of software system that called a search data switchboard and it was basically automating the same process that I explained it was using the Google API to link the information across internet and one of the things it was doing that was important it was resolving old identifiers and it was building a model that later on got the name of the research graph now the the core of this activity comes back to connecting different scholarly works and scholarly assets using technically two or two degrees of separation so examples here on the screen are two degrees of separation we have two dataset they're cited by the same paper we have two data sets that are funded by the same grant and we have two datasets that are created by the same researcher and the difference between this and the concept of data citation is that we don't know any causality in this there is no direct relationship between these two datasets we just have some evidence that they might be related the formation of this work underneath with some other study that I said you don't have enough time to go through this so this is actually quite a strong evidence to find related information across the web we published the paper in the scientific data with a cluster of our records that was curated for the purpose of public use and in that nature article one of the things that we found was in our curated dataset 70 percent of our publications had DOI and 46 percent of our datasets had DOI now the significance of this is that they were curating this graph if you like for the nature we were trying to find the clusters that are highly connected so they don't have lots of scattered information it was more frequent and finding interconnected information and that was an interesting observation again this was a quite a small case study with a very limited information and the most of the DOI that we get obviously here from the data site and crossref but it doesn't mean that this is this information can be applied generally so just please don't take this one as a overall statistic across the internet now so this is what we did at a time around the kind of connecting repositories but later on we start developing something that called Occument API and the Occument API is similar concept but it's actually very much driving the information from persistent identifier because of the trust that we had in the relationships of those identifiers and because of the availability of the services that enables building relationships on the fly they give you an example of this so this is a data set from the NCI which is a data infrastructure facilities in Australia they have a data set that called Blue Link and this is one of the major collections in their data repository now if we use the online API of just the PIP providers we can actually traverse graph and build information and as I'm going to show you the the researcher who worked on that data set from the NCI data we know that is a Peter Oak we know Peter Oak has an orchid ID so we can actually go from the researcher in NCI to the orchid record once we so this is our kind of first level connection once we are in the orchid record we get all the publications once we have those publications you can look for the data sets that are cited in those articles and I might just oversimplify this in a more comprehensive version there was a bit of technology involved to actually find in these relationships between the data sets and papers but let's assume for example say that this just magically happens and then you actually have the data set then there are other data sources like as colleagues which is another initiative by research data alliance that give you a link between the data sets and publications so you start to building this graph and the beauty of that is that you can build this graph dynamically because there are rest trusted API for every single of these PIP providers to find the related information now what does it mean for NCI well for NCI we can actually transform their geo network repository to a graph database then we can send this one to the research graph infrastructure we can document this with the information come from research graph and then it gives you a bigger graph lots of blue points which are all the blue as a color coding of research graph blue is the publication and orange are the data sets and green are researchers so the most of the blue information and green ones come from the research graph augmentation API and there's the kind of field the gap the process as I said is kind of in this presentation is oversimplified it doesn't just blow out the graph in degrees of graph crawling it actually just feels the gap it uses a shortest path algorithm but regardless this is the difference between before and after the service so this is NCI graph before augmentation on the left all the orange ones are the data sets and using this augment API and the power of this persistent identifier services we complete the graph on the right so they gave them a better picture and this was completely it was possible using the pit identifiers and also a piece of pit services and in that space and because for every single of this could this graph would be different tomorrow compared to today as these publications and data sets and graphs are evolving now with all of these technologies what did we learn well uh the first thing that was quite apparent to us was uh the kind of the persistent identifiers in a way saves money for a lot of infrastructures prior so this whole journey that I mentioned in the last like 10 minutes is actually like five years worth of investigation in different technologies and we found there are so many ways that you can run complicated disambiguation algorithm to disambiguate authors disambiguate uh titles of publications and so forth and all of those processes are actually very expensive if you do it at live but when you use the pits is actually are encapsulated into your ecosystem as much much easier to implement and for repositories and for universities and for research groups it's actually affordable to build at added value services top of this pit infrastructure the second thing is that not all connections have the same value so during this time we tested so many different methods we use a graph clustering methods we use topic modeling and different data mining techniques we found yes with different level of accuracy we can guess if these two papers are the same if these two authors are the same but just that one example that you go to the conference and present something and job log is not the same job log as you thought he's that's just one false positive it's uh it just puts a big um a dent into the accuracy of the data or using the pits provided with a trusted connections because the provenance of the data is quite clear so we know actually where that information comes from and the other thing is that the using the even if there is a mistake in the problem what in the pit metadata records so you know where is the source so it's more kind of like fixable so you can go to fix it and then that would propagate through the system the second lesson that we learned is that in the beginning when we were doing this was six years ago uh it was quite tempting to just create a big graph we just started from literally from 500 nodes to 5000 nodes to the 5 million nodes to the 50 million nodes as today there are about 250 million records of a scholarly uh communication records and what you find very quickly is that collecting all of these information they're not dynamic data as we collect them they are actually expired because the information is changing in that space so it's kind of like you want to navigate into this if you want to build a service that really adds value like what Ketul mentioned uh about different use cases that's not about just creating the big graph it's actually about finding and creating the fast trusted and sustainable services that enables innovation and other people can actually build and discovery methods that traverse this graph traverse this big uh ocean of data that we have and actually find the right answer for our users lesson three which is there was a most important one we need we need to actually more invest in the business of connecting rather than collecting so uh when as I said when they started it's about six years ago it was quite exciting to create a big graph uh and I have seen a lot of copies of these big graphs so it's getting you quite fashionable to have another curated version of this and we have this in different shape and forms or startup companies rising into this we have different projects but the the problem statement is not to create a very large uh cohort of scholarly connections that cohort is already exists that's the that's the network of scholarly communication that's already available across the web the question is about how do we connect this information so connecting here is the number one priority and at least the most valuable use case for uh any new service or any new uh platform that wants to leverage this ocean of data now about the pete graph uh so given everything that I mentioned the research graph foundation has a quite a strong interest in the success of pete infrastructures I mean the development of pete infrastructures and really the pete graph which is a graph of identifiers underneath is one of the key enablers for everything that we do uh in that space uh where there's lots of collaboration between our work and fryer and based on that collaboration I added a couple of slides I think if these are kind of just repeating what Kethyl mentioned but I'm just repeating my understanding from where the fryer goes because that might also open the conversation in this space that the aim of the pete graph is providing at least a federated and json api and these actually the aim is one is that they have to be disciplinary applications kind of ready services so they can actually implement these services into different repositories or platforms or infrastructures they need to be able to support the european open science cloud applications and also it needs to be able to provide enough level of dependencies in the in the json api that actually enables some level of graph visualization for the end user now this is again another version of the use cases just this is more in the language of research graph if you like so there's a couple of examples one of them is that if you have a data set across multiple different infrastructures with multiple different versions that actually happens a lot in a lot of fields the data actually has multiple versions stored in different places we want to collect the citation for all of them so we should be able to report all of them at once if I have a data set and I put that data set for example in fixture and for simplicity let's say there's only one place for it but we have updated this data set 10 times and there are different citations for different versions of this given that each version has different ui we want to be able to accumulate all of those citations into one and metric something similar about funding if you have a grant and that grant actually mentioned in a data set in a publication and some other activities and research projects and as we just learned that far is working on creating a pit for the projects and grants then we want to actually have this kind of list of connections so we have a grant that grant actually funded some other smaller grants or projects could use some papers and some data sets so it should be one place for a new service or app to go and search for all of this information rather than actually hitting 50 different apis and try to consolidate the data and the last one I actually didn't have any mathematical model because it's kind of it's one of those things that you don't know the answer until you start working on it and what would be the most effective linking method between data and publications and that's one of the things it's this is a text from one of our user stories that careful mention as a researcher I want an easy way to more effectively link all the data to part to publication and as a reader I want to be able to easily find all the data related to a publication now we are what there is a repository of this on github that you can go and see all the flyer work around these user stories some of this might lead to answer the questions of what API we want at the end and potential users and the other thing that I think just listening to both kettle presentation and also more understanding from a work like this is finding the model for prioritizing the work on which API needs to be built first okay so what next from here there is a buff that is planned for our day planner 13 in Philadelphia so the proposal is up there but we don't want to date and the conference program so that would be a good place to follow this conversation if you need more information about the project fire that's website that's website for research graph and that's my contact people mission and I hope this didn't lead to so many open-ended questions but feel free to send me thanks a lot I'm here are there any burning questions too I'm here right now we don't see any so perhaps let let let me show you open air use case of pizza and then we can have Q&A session second opening my slides hope you can see some wall open air is a European Commission funded project facilitating open science in Europe our current phase open advance has been launched around more or less same time as Freya and what we do we collect metadata about publications or data sets or software and other research outputs from repositories of publications or from open access journals from data repositories or software repositories Chris systems and other aggregators we do some validation cleaning the duplication inferring linking and then we present connections between project sources or data sets and other research outputs and we have different services on top of our portal so one of them is Spolix that was already mentioned there and we hope that this aggregated information is useful for measuring impact of research and some research trends obviously we collect different types of publications from different repositories for example from institutional repositories we collect information about publications articles preprints reports but also in some cases data sets then from data repositories we collect data sets from journals and publishers we also collect information about publications and we are looking into software and other research products in open-air advance to see how we can better link them to project publications so we have content aggregation policy and based on the content acquisition policy we build open-air information and this is what our content acquisition policy says so that open-air accepts metadata records of all scientific products whose structure respects the model and semantics as expressed by the open-air guidelines and this means that both open access and non-open access material will be included and links to other products will be resolved where this is possible and this is where we actually use Pids because for us Pids are resolvers of those links this slide shows the role of Pids in open-air because it helps to identify and register content providers it helps to identify researchers it helps in metadata application enrichment and notification because we have a service where repository managers could be notified if a richer metadata is available to be added to their repositories then we also use Pids for resource linking and also for resource metrics and for tracking aggregated usage statistics we have guidelines for data providers so originally we started with guidelines for compatible repositories with publications then we had guidelines for data repositories and for create systems and we're also working on guidelines for software repositories so we sort of started from looking into publications and we're expanding open science areas and our guidelines help to improve interoperability of metadata information exchange we also hope that they support fair data principle and of course we reuse existing standards sir and this is where we extend vocabularies when necessary for example for different PID types and these are some of the examples of Pids that open-air uses for different entities so for example this is what we use for the resource identifier so we extend data sites list of PID identifiers types we also have Pids for alternative identifiers of the resource sir and you can see them listed here on this slide and we have Pids for related identifiers to the resource sir this identifies that are related to the registered resource and they list it on this slide and then of course we have Pids for authors and contributors and they are kind of standards standard ones and Pids for funders and project grants cross-ref funders and I and agreed and this is an example of information displayed on the open-air search portal so you can see a dataset and it's linked to a dataset deposited in Dan's data repository and it's also linked to an article where this dataset was used some issues and next steps sir and that's where open-air is working with relevant RTA working groups and also collaborating with Freya project of course we want to improve the discovery and integration of community specific identifiers and metadata and we also want to improve the integration of DOI Russian in supported by the nodder which is a repository that open-air and CERN manage so that was sir a quick introduction and I'll stop sharing my screen and it's time for your questions to Kettle Amir or Eliana and Ellen from Dancer who are here with us from Freya and open-air project as well so here I stopped screen sharing any questions I don't see any coming up it ties the means that sir we've been all very clear or I don't know thank you so the first question how can we follow your progress in the future I can answer that for Freya at least we have our webpage so there are all the reports that we are producing available we have a list of activities also if you want the direct day-to-day or not day-to-day but week-to-week interaction with us on Twitter is a good opportunity to connect with Freya where you will get tweets about our upcoming activities where we will be presented who you can meet and our information like that okay and I can about the research graph I would probably say the best person so the best place always to meet everyone and get involved is a research data alliance apart from this are also the baby nurse and the website and all other contact points but again as I said that usually every RDA we either have something new or something interesting happening so that's probably the best place to get together also I just noticed we have a couple of other questions on the Q&A board so there is one question for me is about saying something with the links between peds and so it's from alien I don't know exactly what you're asking I can't say about I don't know it's about this you're asking about the statistics that how many peds are connected or if the peds are actually or they're using the connections oh okay yes around the citation and funding so there is one thing is two things one is when it gets to peds that we use peds in two different contexts one is that there is a metadata there is a relationship in the metadata of the peds data site for example has a very good corpus of these kind of connections and api's and the space is very good orchid also is the same in same category and cross if it started to explore the concept of the event data which provides something similar so the the data provider tells you that these two peds are linked so that's one scenario the second scenario is that that's where you get things like the cited by and funded by and so forth and there is the another scenario is whether either repository or a university research management system or a library system that in data space a librarian said this doi is linked to this orchid so in this case you have another authority source that actually link these two different peds together so of course in this scenario the the accuracy or the type of provenance is different around the links but it still is much better what is more trusted connection than something that just drives by a iron machine learning so there's a there are two different type of connections from pete but don't know exactly if that was the question but i'll try my best there was also a question from biliana could you explain a little bit more about current status of pete for organization i think probably careful is the best person to answer that and i'm sorry i must pass on that one too i am that this is not the area that i specialize in so i'm not going to say anything that i i don't know exactly about so i'll pass on that one but contact me and i can put you in contact with the right people and then there's a question from quentin is there someone specifically to discuss historical persona yes within fryer that is something that we have that we have discussed and then we have ongoing discussion so i also suggest here that you to contact me and then i'll put you in contact with the people who are concerned with with personal persona this is i must say a very interesting um entity in terms of assigning a pete and i think it's it's challenging difficult but but definitely needed and interesting and the rest two questions from mariel is anyone walking with wiki data who also have lots of pete for people artifacts locations etc useful and relevant to research and researchers sir so i know that open air collaborates sir a bit with wiki data but unfortunately i uh yes i can also comment on that they just started exploring some of that information so that's one of the items uh one of the kind of engagements that research graph explores and for fryer it's on the radar but it's uh i am not familiar with the current status of our involvement and then also mariel asked anything ambassadors can do for you to help you share progress knowledge uh i think i think elaine might be uh the right one to answer that if she would unmute yes hello everybody this is eliane um i'm from the communications team of fryer and it was also co-organizing this webinar today um yes we are definitely looking for new ambassadors we have an investor program if you go on our website you cannot find all information there we do involve our ambassadors in webinars regularly so we are happy to get information from you so if you are not an ambassador yet please go on the website and have a look thank you uh then there was a question would you recommend implementing this new pizza in an institutional repository now or in the near future what is the time frame until we could use this new pizza effectively yeah that that is a very broad and a very good question and of course it's um it's individual for for each of the pits so it but if you want to have an idea about the time frame i i suggest that you you tune in to the report that's coming out of our analysis of these nine pits that i presented earlier today and and there you'll get an idea about the current status of the development of these are emerging and first in some cases also a bit immature pids and it'll get you an idea about when something could potentially come out of but i mean it's hard to say because it's not like there's a deadline three years down the line and we can say well for instrument pits in three years everything is up and running it's a it's a it's a development in progress and that's always how it is but we're definitely talking uh years in in this case here but i mean in fryer as we we can work on different levels so you heard a mere here from a technical point of view there are some universal technological developments that get that is in progress and will help implement the pid services and on a larger scale and then you saw the presentation that i did uh just from the little last scenario from pangu where we implemented ideas ends so you can say the implementation can go on and at different levels but of course what we want to see is uh something that's happening more generally that can be um taken up and used by the larger community especially in terms of technological developments and i can comment about pids for instruments there is sir i don't remember is there a walking group or an interest group in rda on this topic so perhaps if you are interested in instruments that's a place for you to to check and maybe join some community community discussions muriel said that he's already an ambassador and is there anything he could do apart from sharing uh knowledge with his teams and colleagues sir maybe phrase interested in more user studies sir at sydney or similar ship sorry sorry i don't know you take this one please yeah you are muted is this a question for uh university sydney i can just add something here uh muriel i just remember that the university sydney has been one of the participants in the ddi working group way back about 2014 2015 and there is some ongoing work in the research office in this space uh i don't know about the exact user stories or use cases how it can work but there are some connections there to explore and there are some possibility some capability in place to actually connect library systems to this kind of graph modeling technology at the university of sydney and i would say in regard to the user stories then i mean we are definitely interested in hearing about good user stories who can illustrate what exactly it is that that we are doing in connecting and paving the way for new pid services so let let us know if you have interesting user stories that we can put on our agenda and that we can move forward i think that would be also very useful for fryer thank you and i think uh we once told the questions received so far uh thanks a lot for joining this webinar and apologies that we went a bit over time but i think it was was it there thanks a lot k2 lamir eliana ellen for organizing this webinar like i said the presentation is already on the webinar page we would also make recording available on the webinar page and we will also upload it to open a youtube channel um thank you all and uh have a good rest of the day and a good weekend and happy 2019 thank you bye thanks a lot bye thank you very much


Group meeting for May 24th of the year 2022 and don't forget to put your name in the attendees section just so we know that you're here. The attendees section of the meeting knows that we know you're here. We know if there's something you might have missed if you weren't here and we can reach out to you in case it may be. Let's take a quick look at the agenda. Is there anything that folks would like to add or change? Feel free to do so. If you want to just pop stuff in there in about 30 seconds if folks want to go ahead and have Christian or Vadim. So I think we will be winging it in terms of actual OKD engineering updates. Correct. Yeah. I thought we were always winging it with OKD engineering. I think that's the way open source works is winging it at this rate. But yeah, we're getting there looking at the agenda now. Let's jump into our agenda and release updates. Like I said, we don't have Christian or Vadim here. What I did want to do is bring up the operator account question. I asked Christian about this and he looked and recently the operator account hasn't changed. It's at like 150 something. But I remember it was much smaller and Bruce, I think you mentioned that you remember it being much smaller in previous releases. Does anyone else notice this or is aware of this? I haven't checked in on that in a while. Christian brought this up at KubeCon because I think something went off on his phone or whatever and he noticed and looked and there was like a much bigger list. I know there like Cecil Machado who's a redhead employee who's been doing a lot with the OLM. I know she has, she had some explanation that seemed to satiate Christian's curiosity, but I just don't know enough details about it to remember what it was. I would say maybe reach out to Christian or next time we're all here, you'll have a comment on that. That's Camilla Machado, right? Yeah, Camilla, sorry, sorry. Okay. Yeah. No, I can ping her and ask for what was going on. Yeah, so for context at the docs meeting last week, Bruce, why don't you go ahead, you brought it up, you noticed it first and brought it to our attention. Why don't you go ahead and explain what you noticed? Yeah, well, I guess I was doing something on my test cluster, which is on 4.10 current version. And I noticed that there were a lot of operators, in particular the GitLab operator was one that I noticed because I had been having difficulties with that from long past. And then I looked around and there were several that were that had been deleted going from I think 4.7 to 4.8. And then I went back on my 4.9 cluster, which I had actually made a note to myself going operator by operator of the ones that disappeared, and most of them were back. And so it wasn't associated with an upgrade because my 4.9 cluster hasn't been updated for a long time since, you know, especially the stuff thing came out. So something happened with, I don't know what, like maybe things made it into the operator hub that was being pulled down that had disappeared. And I know that with respect to the GitLab runner one specifically, when it disappeared and I asked some questions, Vadim had said, oh, well, it wasn't currently compatible. So that seemed like a logical reason for its disappearance. But anyway, so that's just history, it doesn't shed a whole lot of light. But I just, well, I mean that the ones that I really care about, so like all the ones that would allow you to GitOps are not there.  A anecdotally, all I know is I did a, I think it was a 4.8 install a while back, like last fall. And I remember that there were only like 40-something or maybe it was like in the early 50 operators. And now looking at a 4.8 that was upgraded to 4.9 recently, but I didn't notice it in the upgrade, now has 152 or whatever that higher number is. And it's like AWS operators and all sorts of stuff that was not there before. So it's pretty snazzy, it's pretty cool. We might want to give that a little bit of promotion if we're sure that that's something that's going to stay around. We should reach out to Christian or the other Red Hat person if they know specifically and find out if this is going to stay like this for a while and then maybe sort of promote that. Sorry, you're muted, I am. I am. I'm always muted. I've got a cold again from traveling, not COVID, which is just a cold this time. I will reach out and start a conversation with Camilla and Christian and get to the bottom of it and find out if it's a permanent upgrade or if it's going to disappear at any time soon and let you know and have one of them send a post to the mailing list. Is there a discussion started about it already? There is not, but we can create one. Let's, Bruce, can you go ahead and pop on and create one sometime in the next like, you know, sort of time soon? Okay, great. And if you tag me in it, then I, you know, then we can see because if it is, hopefully it is. There's also a lot of work going on in the background because as we all know, Vadim has gotten busy with a new promotion doing other things. So there's a trio of customer facing engineers who are taking on learning and building out the CI CD process. And I have a meeting which, Jamie, I may try and get you in, I'll have the first one with him Fabiano Frans, who's an awesome, awesome person, is, is leading, is managing that initiative with the customer facing engineers and he's, I think he's down in Brazil somewhere. But you'll like him, we'll all like him. I'm going to try and get him to start coming to the working group meeting. And they're going to work on the CI CD pipeline for OKD and take the learnings that Vadim had. And this is one of the many conversations that are going on about how to re-resource the build process here inside of Red Hat. And hopefully we can get them to show up at the working group meeting and tell us what they're thinking and get their feedback on it, hoping for the next, not this, not the docs week, but in two weeks' time to have some of them on and get them to start coming. Fantastic. Thanks. But the good news, that is the good news. And that maybe the lift in the operators has something to do with that. But I doubt it, because it's kind of early days for them. I vaguely remember, like, I was talking with Christian and he looked down on his phone and someone said, oh, there's like 160 operators in the catalog now. He thought something must have happened that, like, accidentally brought them in. So he started reaching out. And I thought he spoke with Camilla and it was like, whatever the result of that conversation was, it was like, oh, it's supposed to be like this. So I'm not sure what the detail was, though. Yeah. So, well, we'll find out. But I know I'm not the only person who noticed that after an OKD install of like 4.8 or whatever, there was like a woefully small number of operators, like 40 some odd or 50 some odd. So something happened somewhere. All right. So Bruce is going to create a discussion item and tag Diane and if you can tag me as well. And so that's, is there anything else OKD release oriented that folks wanted to talk about before we move on, even though we don't have any of our redhead engineers here? I think folks want to discuss. Okay. Moving on now to Fcause updates. Timothy. All right. You can hear me correctly. So, I've put in links in the agenda. The main that happened that are happening right now in federal cross lands. And that should impact. Okay. The first one is that the fact that we are making the hiding spot in ignition to remove the ignition configs. We're in the actual box platform by default. So if you had posted an announcement for that on this, but essentially the idea is if you if you have an engine config on those platforms, every impoverished user even containers can access them. So if you saw secrets in those. It's not great. Because they can read them. So this does not directly impacts OCP because as far as I know, I think most of the use case in OCP is you don't have directly secrets into the initial engine config. They are fetched from the MCO MCS. So. And puts don't have containers on OKD don't have access to this server is a block type the firewall. And so, yeah, it's still it's not that great. So we're removing that from those platforms and but we're not removing that from all the platforms yet because we're not have a solution for everybody. Yeah, so it's just to start. So maybe they would be further changed on the road for for this one but we'll see what it goes. One is about the new 10x artifacts so that only ever impacts you if you're using the new 10x platform. Which was fairly recently added I think a couple of weeks or month ago. And essentially we changed the way we should be are the federal chorus images for new 10x. And it's being compressed after the fact we should be made to really compressed is just a change of format should not impact anything else. And essentially, it should make your life easier if you're using the new 10x platform so hopefully that helps. The last one I want to bring up is this last issue here is is an issue about the way we grow or find system by default on the node. So when you have a federal chorus image essentially it starts really small and then it takes up all the space on the node that it has. So essentially doing that with examples but well with almost any file system works well only if you use a rather full image so let's say if you start from 10 gigs and you go to 100 gigs that's okay. But if you go to one to provide for example that's not getting messy because the file system is that's supposed to be room this much from such a small image. So the idea is we want to I want to focus here is that we don't have a fix right now for this but the right way to do things is if you have such large discs on your node is to use multiple partitions and that's what we recommend. So I added the link to the exact part of the ocp documentation or QT documentation that helps you set up machine config to have a separate partitions to actually store your data, which completely works around this specific issue. And that's the recommended way to do things. It's the preferred option. And that's it for me for of course the blades. Any questions or feedback for Timothy in terms of Fedora Coro West stuff. Yeah, Timothy. Do we know when Colonel 517 nine will make it in. Good question. I don't know. Is it in Fedora. Yes, at least there there are 35 and 36 builds of it. Of the package. So 579. It should be interesting soon. Well, it will be in F course but would it be no kitty that's another question. Totally. So federal 35 yes it's in federal 35 so 517 nine right. So it should go into the next OCD and by the more Christian next. Which will be a foot or 36. F cost right. That depends if we. But I don't remember exactly which version the next, the next build of OCD will be based on is the switch for this one for the next one. Well, next and testing are both on 36. Stables on 35. Oh, yeah, so that's the confusing part here is that this federal chorus so we essentially moving. Oh, do you mean for the, for the first image or for the closer. Okay, okay D I know is a whole separate discussion I'm talking about F costs. Okay, and F costs itself. But what's interesting right now. We should, I think we shipping we making a testing release. Okay, so there should be it should get into testings. It's in. It's in the latest thing testing devolve so it's either in this one on next one. It's in this week's testing release. Okay, yeah. Excellent. And this is going to be more helpful as time goes on because as we try to do, okay, the builds of our own and testing and testing with our own versions of F costs. Ideally, I think that this type of information will become very important. And for okay D we're in group members to be more aware of what's happening in the three F cost streams. All right, anything else. In terms of stuff. All right, let's move on to documentation documentation stuff. Brian is not here today, but I can fill you in on some of the stuff that we have so when we met last week, Brian mentioned that he has now merged in. Okay D development. It was sort of in a separate on a clone of the repo that he was working on with a couple other folks. It's now been merged into the website. So if you look the second to last link on the website is okay D development. And it talks about basically modifying okay D release troubleshooting things of that nature. Not, not all of it's filled in yet. But basically, this is going to be where we start talking about building okay D ourselves or modifying okay D getting those images, etc. There's a great conversation that Bruce and who else it's so it's you Bruce and Vadim and John and there's a couple of people on that. John started it. Right. Other brilliant things John has done recently. Right, exactly. So, so John Fortin started a discussion thread that folks should check out in the repo. That is about if I wanted to if any of us wanted to build okay D, where do we find the right images, which, which registry are we going to. And is it the same for all of the components, etc, etc. And where do we find the source for those components so that we can actually provide feedback directly to those components. And so it's a great thread. I'll put a link in the meeting notes to it. Check it out because Vadim's really been doing. He's chiming in when he can and it's been very helpful and Christian has chimed in as well with that, but that will be our that will help form the foundation of the documentation section informing stuff about actually building okay D in the community. Let's see the working group link in the OCD website has changed. It's now OCD working group at the top level. And then there's about charter minutes and then subgroups and the subgroups link goes to the individual subgroups that we have going. Let's see. I'm working on something that explains the release process and how we're not going to be releasing 4.9 any iterations of 4.9 because OCD has been up to this point a once we release a next minor version all efforts go towards that next minor version. And there's no maintenance releases. I'm writing up trying to find a good way to explain that. Um, Steph testers, CRC, we're talking about that. Twitter, as mentioned, we need to change the email address. Diane came up with a solution. Diane, do you want to talk about that a little bit? Yep. Apologies for all the delays. But I did find the problem with Twitter is you need to have a Red Hatter email address that is going to be not change jobs. And it needs to be a human being. It can't be like a shared email address within Red Hat. And I did find Kareem Collis who was in the OpenShift BU in marketing who will own it for us. She's also the person responsible for all social media for OpenShift, OpenShift Commons and owns the other ones too. So she said, yes, we just now have to figure out how to swap the emails out and get Twitter to release it to her. And then she'll share whatever password username, password with myself and Jamie. And if someone else comes up and wants to be the social media manager, that person too. But she also will be able to do some tweets for us when we need them, like when we do events or things so that and she's promised me that she's going to stay forever. She loves her job and she's promised. So the problem with engineers is they get good at their jobs and they get promoted. So a proponent of that, but we need people address, stay stable for. And you should now have the YouTube back. They were doing some spring cleaning on all of the YouTube OpenShift channel admins and you got swept out in the cleanse. I did actually accept the, I did get added and accepted. So I'm, I'm back. Good. All right, you're back because I just don't want to be doing that again. So yeah, that's, that's the social media update. Excellent. Thank you Diane. Survey stuff. Link is to the survey. We do need folks to provide some feedback on the survey. And help us make it good. We do have a deadline of we want to get it out June 1st ish. And we also, we want to start the transition and have that the repo transition start and be completed by July 1st. So we're actually starting in the docs group to create some deadlines to get things done. Sorry, when is the deadline for answering the survey? Well, it's not answering the survey. It's providing feedback on the survey itself to make sure that it captures what it is that we want to ask people. If you look at the survey, there's a link in the, in the meeting notes. If you look at it, if you think there's some questions that maybe we're missing, or if a question isn't clear or something like that. Let us know because we want to have a, and then we're going to release the survey on June 1st to people in the community. Oh, okay. I see. I thought this is actually a feedback on the survey. Yeah. I thought this is actually an old survey because it says which version of OCD are you using and the most recent one is 4.8. Yes, yes, it does. It was a, it was a long time. This has been a long project. I think the survey first got started. The survey project got started in November of last year. I think it was okay. I see. Yeah. Maybe we can just add like the, the most two recent versions there. Exactly. Thank you for that feedback. I hadn't noticed that. Yeah, so folks, please give feedback. I'll send it to the mailing list or in the Slack channel or in the matrix channel or wherever it is that you want to communicate. What was the other thing that getting here? Oh, so there was some discussion about. Diane, maybe this answers somewhat answers the question, but what you said earlier maybe answers this question, but is it possible for the OCD working group to convince the DNS administrator. Administrators at Red Hat to put different MX records, MX records are what point to a mail server and say, oh, the mail server for this domain is such and such. Could you find out if they would be amenable to pointing it to a mail server that the group has control of so we can start creating email addresses that are at OCD.io. Because my sense is that Red Hat doesn't want to actually host email accounts for us or manage aliases. Maybe I'm wrong. If you could also I'm going to just keep pushing to this if you can write that up in the discussion and tag me and then I will see what I can do if I can work any magic. I have seen it done for other projects. So it might be possible. And it might be a good way of managing some of our issues transition issues. So, yeah. We'll see. Right. If anything else that came up out of the docs meeting, Bruce, you were there my missing anything that's not covered in the meeting notes. Important from the docs meeting. I'm just thinking I think that's most of it. Let me just go have a. Oh, one other there was one other thing. Um, zoom, how do folks feel about zoom versus blue jeans. The reason for this is the way things are right now. I don't have access to no one outside of Diane has access to the recordings until she forwards them on. So we can't actually post them. There's some technical limitations with zoom. Everyone that I've talked to seems to be. Have more meetings of the tech, there's technical limitations to blue jeans. There's. More opportunity with zoom and seems like. People I've talked to more of them are using zoom. For more of their meetings than blue jeans. So I said, I bring this to the greater group. Have that the topic. What do what do folks think. I for 1 would love to get out of the jeans. Um, and over to zoom. It's just a matter of creating and getting an account that is available to us to use and. Yeah, I'm, I'm, I'm, I'm game if you all are. All right, I'm going to speak now. Because this one is something I care a lot about having fought all the platforms all the time. I am in favor in. Um, order of usability ease preference, whatever you want to go with. Um, Uh, zoom. Jitsie Google meat. You can whatever order you want to, you want to think of that in. That's basically the 3 that. So far, I had a reasonable experience dealing with them on Linux. And on windows and on Mac costs. And. And at work, I have, I have zoom conference system. So if we use it, I can use those instead of having to use my laptop all the time. So. If I'm not doing it from work, then I don't then zoom falls a little down because it's a little annoying at times, but otherwise. Yeah. Any 1 of those 3 are good. All right, I see some, some chatter folks want to talk. Over the air about what your thoughts are. I was just saying, I don't, I don't have any, I think changing platforms is fine. No objection for me. I think it'd be cool to use an open source platform like Jitsie if we could, but you know, I don't, I don't have really strong feelings about the platform we choose. I just want something I can use on any of my devices. So, and it's not blue jeans though. Yeah. Recording is key. So, Neil, I think it was Neil that, yeah, Neil points out that recording in Jitsie is a pain. That's kind of 1 of the things we want to get around is we want to have recording and posting as easy as possible. So that our recordings are available quickly to the community. Google for recording now with Google. I thought you had to pay now for to get a paid version to record, but I could be wrong. I don't know for recordings. You do. Okay, like, you can, everyone can do meetings. But only people who have paid accounts can do recordings. Right. That's also true with zoom for what it's worth. You don't, you can't do cloud recordings without a paid account being said, I am very aware that our lovely sponsor has both. So those are both equally valid options for us. So, Is there any objection to us attempting to create these meetings in zoom. If I do the do some background work. And see if I can get an account that the Jamie again, like, yeah, cool. Let me see. It may not happen right away. There's nothing happens fast. But let me see if there is a red hat zoom account that we can hijack and use and that Jamie can also as an external have access to that's always been the issue. And, and I, and I really want to have it something that an external person with a non red hat email account can boot up the, the meeting. So it's not. Not me. It's not me all the time. Well, and with zoom, you can do the, you can add someone as a secondary right. The terminology is alternative posts and my don't quite quote me on this, but I think red hat marketing has a premium zoom account because they use it for all of the red hat live streams. All of that is done with zoom. Yeah. Unfortunately, all of our internal meetings are on still on blue jeans. So I'll still be here in blue jeans forever. Oh gosh. So if that doesn't work out, I would be willing to donate my business zoom for use of these meetings we would, or maybe set up a second one, but we'd want to have a plan for handing it off. Should I ever get abducted by aliens or something. Yeah, yeah, I might be able to finagle being able to use daddos zoom I'd have to ask people in whatever if, if need be, but again, we should have, we should have plans when it comes to using zoom because of the way that zoom works. Yeah, let's, let's put it on the agenda for the docs meeting next week. Give me until next Tuesday to do a little bit of research and let's get that we've got the YouTube, the Twitter figured out and let's get the zoom thing going because as much as I love blue jeans, not. It would be more discussion item and fill in the details there. Next week. And then we just have to get Christian to change the fedora calendar and I have access to the calendar. I can change it. We love you. Nice is, is if any of the red hat SSOs could get you on to the zoom meeting. That would be a miracle. That's a longer conversation. So, let's keep moving on because I added a few things to the agenda to just because I figured I'd sneak them in. All right, sounds good. So, um, let's now move on to. Time for docs update issues. Repository transition survey. Rook set status. I don't think there's anything that's changed with, with John's bugzilla. Um, discussion 1, 2, 3, 1, I don't know. Yeah, I don't know that you have a link there somewhere. Well, that's I'm actually going to have to look at the repocus. Yeah, that's that's John's build it from scratch. Oh, that's the 1 there. So yeah, that's that's fine. Yeah. I just, I just sort of wanted to bring up 1 thing related to that, which didn't appear in the discussion because it was a little bit longer. Like Vadim made the comment that you could just try replacing some of the base images. With an open source 1. But it sort of seemed like we did have an action item a long time ago with Christian to go through and look at that. To me, the issue is not just. Can you replace a base image and it sort of seems to work because you haven't quite stumbled into the area where it doesn't. It'd be more useful to know what's what specific red hat proprietary packages were in the proprietary base image. And if there are none, then you could presumably safely. Change it to be passionate. What can you say? Very much none. We don't ship proprietary packages. They were at DC no CP. So there's no thing proprietary. It's just. I think the more accurate term is because some of the content is subscription encumbered and that actually might be the problem. I don't think any of the OCP containers. Use any of that stuff anymore. I think they've all moved to rel UBI quite some time ago and just tried to stop using base real content but one of the things I'm not entirely certain of is if the build engine thing has ensured that rel content is disabled during the build process to make sure that that stuff doesn't leak in. I if that hasn't happened then it's entirely possible through nobody's fault that there's subscription encumbered content inside the images. And that I've done at my workplace was our rel UBI base image basically inherits from the main one and the first thing it does and really the only thing it does is turn off subscription managers plug in so that it cannot actually access the encumbered stuff because if subscription manager text and entitlement on the in in the environment, it will overwrite the repos and replace it automatically with real rel repos. So that's one way to kind of guarantee that that doesn't happen. I tend to agree with Timothy on this I don't I don't think we have any encumbered content going into those but we do have two sets of build images and one of them is behind the gated, you know, authentication. Right. Well, I guess I guess if the if all of the the stuff that we can access to build things. The initial, you know, from image is a gated resource. Yeah, we have multiples. So like not all of our not all of our component teams have done this yet but like we have a publicly available build image, and you can basically swap the from line in the Docker files that make up our components now. Some teams have done it. Some teams have not created multiple Docker files. So I have a feeling we probably just need to audit it and go through and figure out which ones are still using the gated build file, and then just propose like what what our team maintains is like a Docker file dot rel and then like a regular Docker file the community would use like my personal preference is to see more teams do this internally where we have a Docker file. That's a community Docker file and a Docker file. It's like, you know, our build Docker file. As far as I've seen every component I've come across you can just swap the from line to the open builder and they work the same basically. Okay. All right, well let's, I think as we get more into the engineering bits of trying to build our own OKD out in the community will run across that stuff. Timothy points out you can use option from with pod man. Let's now move on to CRC, or I'm sorry, it's no longer CRC it's now open shift local Bruce you notice this I think initially before I go ahead. Yeah, and I noticed that, I guess last week when I was looking at some video that I got from I don't even know where. I guess it would be nice if the marketing people sort of told us these things in advance. Yeah, and some of the marketing choices. You're talking to that. Yeah, yeah. Don't make any sense to me. Like maybe we should just grab a mini shift. Right. Yeah, I don't know. I mean, and then there's marketing. I didn't get a heads up on it. So apologies, like I would have given you a heads up. And maybe I did get a heads up and it went in one year and out the other year. So I apologize because it just didn't. This is like an April 8. But I think you had to go through the, you know, like the developer login to get to it. So it may not have been public at that time like a month ago. But the. Yeah, it's now made into. A number of public places. Yeah, I saw the info week or whatever. Right. Yeah. Branding is never been our forte. So. Yeah, the info world 1 was was recent. And the there is a article on redhead developer what's new and open shift local dot 2. And so it talks about the new branding and. Interestingly, on the same page with related content, they have a link a link to introducing red hat code ready containers. That's lovely. Yes, we are a company of engineers. We are not a great company of marketing people. So, okay. So, here's the question for the group. There is discussion happening. There's that discussion thread. I'll link it in. The meeting docs. There is a discussion thread with Charo and a few other people about who's going to help out. With building. CRC or. Okay, here's the question. So, where do we go from here? Right? Do we assume that it's going to be. Okay, the local or do we come up with another name? Because we will be building this ourselves. Charles says, Charles says he'll have some time maybe in the next couple of weeks to do another build. I'm going to try to make some time to maybe do it myself just to experiment. Do we want to keep this viable and what would we name it? What would we call it? Or do we keep it code ready containers? What do we do for. So, this is the question. I think the last we've been going around a little bit in circles around code ready containers, regardless about whether there is a demand for it. And I think there were three people who came on a call or on the mailing list at some point a month or so back. Are any of those three people on this call who actually use code ready containers. Bruce, is that you were you one of them. Yeah, no, I don't use it. I have built it once and I have downloaded the Charles version once and the red hat version a couple of times, but yeah, we get discussion items and questions from people. There's a couple of discussion items have been created and a couple of people asking in the channels, but when it's posed to them that they help build it. They are not, they are not offering time. Yeah, I haven't, I did actually volunteer at one point to be on a working group, looking at that. But that was mainly with the interest of slimming it down to where it was reasonable that somebody might actually be able to use it. Yeah, I am I concur. So, like also for us, no one is actually using it just because the resource requirements are a bit too insane. And at that point you might just as well run a proper cluster anyway and then you can also, you know, you can actually test the actual thing instead of testing something that kind of looks like it. So, the reason I'm pushing this envelope is because we have a few things coming up on our radar around the CI CD community build process for okay D itself. And I think initially I was the one that pushed for getting a community build process for CRC on the operate first cloud. And after some conversations in a coupon last week in Spain. And as Mike says, micro shift is the new hotness. It's new, new and small it's not really open shift but it does have some okay D in it, but they're just using okay D they're not really. It's not the full thing so it's not quite the same thing, but I don't don't feel like there's any real pent up demand for us to do that. And, and, you know, maybe if we could, if, if charo can get one more build out that's there and do a little publicity about it to see if anyone and some gate. I don't know how to gate keep an open source project well enough to see if anyone's downloading it or anything. I don't see that that's honestly where we should be putting any energy into we have a bunch of other stuff coming up. So, you know, and that's, so I would be okay with tabling for now and focusing on other things, but saying that not saying we're sunsetting or anything but, you know, to host it and have nobody use it is a lot of work. I think the one advantage that I saw to it is whether it was going to be the place for your suggesting, or that, you know, I was going to use it myself even as a test for automation of building stuff. There is some advantage to that as it being like a test case for things like that, but are five users representative out of the community of a need to keep it going. Yeah, and I think the reason I put the operate first thing is the next topic on the list is that after the conversations with them I think we're poised to rather than try and do up a proof of concept that operator first will work with the CRC is to actually do a proof of concept. With okd and fedora coro s on the operate first cloud. And so I'd rather expend our energies and get the operate first engineering resources and Brian Cook's team who's built this building out this new school. The ICD process to, to work, see if we can get it to work on the, what's called the mass open cloud, which is basically Boston University's cloud that we have. We have shares in I guess is the best way we can boot up clusters and create pipelines for multiple things. I'd rather we, and I'm going to invite them. That's why I put it on the agenda to the next full of okd working group to talk about how that might look and what what would need to happen. And I'm really glad that Neil's here too because we've had this conversation about having a community bill managed and hosted build process. And I just think CRC is a red herring at the point at this point and that we should probably try and focus on doing something with operate first cloud because I think I tried to coerce Neil into giving us some data resources and everybody else's cloud to build it. And that's why I'm really pleased that Jack's here too because turn has been building their own rolling their own okd deployment and has their own CI CDE process for building okd with it for running on open stack turn style. So I think it's what we're coming to is a tipping point of where we have enough people who are interested in doing this community managed sort of not. It's probably a bad thing to say but sort of mimicking the fedora infrastructure but doing, but just for okd pipe build pipelines on operate first and having it managed by the community and I think that's a big project for us to take on. And we will get a lot of help from red hat but what I really want to do is have the operate first people come in two weeks time to this session talk about what it might look like and I was actually going to after I talked with L Mike. I keep seeing L Michael but Mike and a number of other folks at KubeCon last week and then I talked to Brian Cook who is the actually the engineer at Red Hat managing the CI CD revamp if you can build service as a managed service which we could host on this operate first cloud or maybe on Amazon. So to get Brian to come and talk about what it would take there's a little bit of questions about whether external people would be willing to use the single sign on to get access to red hat resources if that's ok with the community personally for a build. I would do anything at this point and so I wanted to see if we could use the next meeting to talk about this because you know I wave my hands a lot and talk a lot but I would rather get the engineers who are building the process out in the open and talking to us. And then there's another build process which is the current one. That's we use for building OCP and everything else and there's a group of those customer facing engineers who are doing a three a three six week sprint it build to take on what Vadim has been doing already so not but it's still behind the red hat firewall but that the issue. One of one of the many issues is that right now red hat is entirely responsible for building OKD. I would really love to see it community managed and community hosted somewhere on an open cloud so and there is an initiative there. So that's what I'm hoping next week we can bring to the fold. And then what I'm also hoping with Jack and CERN and all that is we can learn from what you guys did and maybe you can listen in on what Brian Cook and those guys are cooking up for the new revamped build processes which is different than the current ones. The current ones have a lot of baggage. And maybe we can learn from how you've rolled your own over at CERN and use that to inform what Brian Cook's group is doing because they could then just spin you up another pipeline like Mike has a project where he wants a forked version of OKD for a certain thing that he's doing. So we could just build up spin up more pipelines depending on what people wanted to build in this open cloud and learn from each other and then help Brian Cook improve what he's doing. So there's a lot of synergies here and I'm going to shut up now and let you ask me questions and then make Jack talk about what they're doing at CERN. Any questions about all that gobbledygook? So the wonderful thing about Commons last week was that CERN showed up and got some one-on-one time with I think with Christian and Vadim and other people and we got a good earful about what you've been doing there. We would really love to have you talk to the working group in two weeks time if you're willing to to talk about what you're doing at CERN and how it is and maybe give us a little hint about it right now. And then we have another gig coming up on the 23rd of June in Dublin that Christian wanted me to invite you to come to give a talk about what CERN is doing with OKD publicly beyond the working group if you're available. That sounds great, yeah actually I think I won't be available on the 23rd of June but we can just get started for now and I think I will also join in two weeks time to maybe share a bit more about the details but I think you already gave a pretty good hint. So basically we are also just taking OKD as it is on the GitHub and then replacing a few of the operator images, mainly the ones that are handling the integration with OpenStack. So we're not doing a full custom build but actually just replacing a few of the key components and the reason for that is that the OpenStack cloud that CERN has is well rather old because CERN was one of the main also contributors to OpenStack and developed it over time. But that also leads to the fact that our API that we have is not fully like a regular OpenStack API, especially in the networking area. There are some special things in there, in the end it comes down to some API calls not being fully supported or slightly different. So and for that reason we started out with having to fork two of the images so that's the cluster API provider for OpenStack and the machine config operator. So that we can just basically adjust for those differences and in the end it's just commenting out a few lines of go code in there. Maybe making some some different calls and that's it so really nothing fancy but we're also really trying to keep it at a minimum so that we don't introduce huge deltas to upstream that then we need to port to each OKD version. And from my point of view that has been working fairly well, much better than I would have expected and in fact we became pretty comfortable with this approach so now we've actually extended it also to the cluster ingress operator because that one is, at least in my opinion fairly limited if you're deploying an OpenStack like for example it does not have a proper integration with low balancers it doesn't really know what to do with them. Or that it should configure the external load balancer to speak the proxy protocol which is important if you want to preserve the client IP address. So some some kind of well in the end again minor changes like this but that are just really huge because well we want to know from where clients are connecting and we want to have that in our access logs so that's just an absolute must have. And so we are just basically replacing I think it's in total at the moment like for images that that we are we are building ourselves, where we also coming back to the issue that was discussed before that some of the from images in the docker files are not publicly available but instead we just swapped out the ones that are publicly available and we never had an issue due to that. Because in the end, most of the time you just need a working go compiler and that's it. And yeah, then we are in basically nowadays we're just doing exactly what is described on this new OPD development page and if we had that two years ago that it would have been a massive help because. Well, before I have to say before I saw this page now it was always a bit nebulous how you are actually supposed to customize OPD and it's never really clear where where these images are coming from and how they are built but already this page even though it's not fully finished yet is a is a massive help and basically also describes exactly what we are doing so go to your go to your operator that you want to replace make some changes to it build a custom image push it somewhere and then do do create a custom release with the old senior release command again push it somewhere. And that's it and then I guess the only part that's still missing actually is overriding the version in the cluster version operator. And that that's pretty much it what we're doing and of course across several repos and then doing some some integration there. But yeah now that I'm seeing this page it looks so obvious but it was not so obvious when we first had to figure it out for sure. Well Jack we want to have you come back to the next meetings you can talk in more detail about this because this sounds pretty fascinating actually. So if you're available to come on the, what that would be what date is the next meeting. Seventh, so if you could come back on the seventh. Yeah, I think, I think that should be possible there. Okay, great. Can I ask quickly. Can I ask Jack, what version of okay D are you what release are you on. We are currently on 4.9. And we have 4.10 in the pipeline. Awesome. Okay, good. Cool. Excellent. I want to be mindful of folks time because we are at time now. So any last thoughts before we in the meeting. Awesome. This was a great meeting and appreciate everyone's participation and support. And we'll get these videos and meeting notes notes up as soon as possible. Thanks guys. Thanks all.