 And maybe just while we're waiting to get started, I'll paste a link in the chat for everybody. Just the second version of the PID policy has been released just recently. And I think Brian, you'll probably talk through some of those policy updates and, you know, some of the feedback we got touched on the implementation side. So that's why we'll pick up on that today as well. Okay, I actually don't do much of that. But yeah, it's a very brief summary. Yeah, well, and Sarah, you were allowed for a small commercial. No, I'm just kidding. I think by that time, now that we've gone through various sessions on top of the plenary, it's clear that we have now a corpus of documents that are either on their way or in draft version or and so on. And it's normal at this moment since our goal is to be ready by the end of the year. So we have this, this consultation day today in the course of the work. And so that's why we have documents at various stages and it is by design, so to speak, right for some of them we're really looking. That's why the title of the event is consultation. We're really looking forward to feedback. So that for the pit policy, it's been available a few days ago this morning for the enterprise. Interoperability framework it was yesterday on on AI. Similarly, I mean documents are coming up in the coming weeks and on and on and on. That's, that's the status we're in. I think the event today is illustrating the current state of affairs and also looking forward for feedback. That's why we call the event consultation. I mean, feedback either during the call today or, you know, commenting on those documents that are available on the web. Okay, with that as an intro and thanks for the, you know, that the opportunity to share the pit policy version two. So this session is on as the title says on persistent identifiers. Brian will provide an introduction and then Rafael will highlight the work that is going on in the architecture working group while the policy is a joint effort between the fair working group and the architecture working group. That's the mechanics anyway. So we will get into with Rafael into the technical architecture for persistent identifier in the second part of this of this presentation. So with that, I will hand over to Brian who will introduce the whole session. Yes, hello everybody. Good afternoon. That's coming back. So I'm going to give a very brief overview of the current work on position identified policy. A lot of this was said in the session this morning so I don't repeat that. But for some of you who weren't at that session we felt it be worth just spending a few minutes and saying what we're doing here and what the status is, and then we'll hand over to Rafael to looking at the more, more implementation issues. So, here's the, right. So, so what I'm going to look at is very briefly. Look at the purpose of the people for who's been creating for what we've been doing a little bit about some of the principles, not so much about the scope but some of the principles of the policy and what we're trying to what we're trying to cover. And then where we are what the next steps on and how people might get involved for consultation. So, who's involved. Well, this has been a joint activity between two working groups. Firstly, that the fair working group led by Sarah Jones, which has been mostly been done by Peter Wittenberg, Rachel Kotarski, Anders Conrad and Andre, who go back. But also, the, the architecture working group. Jean Francois has been heavily involved and here we've, it's been quite a large group of people but involved in this, but mostly myself, Paul Amanghi, Rafael Ritz, Tobias Weigl, and more recently, Maggie Hellstrong and Mario Vallet got very heavily involved. A joint piece of work between two groups. I think that's what that's, that seems to work quite well. I think we've been quite collaborative. So, just to go over some of the purposes of what we're trying to do this for. So this is about for decision makers within providers of your services and providers of your infrastructure to guide how they should deliver those services. And it defines a set of expectations of how persistent identifiers should be used to support an environment for fair research in European open science cloud. And as such, it sets some basic requirements of what providers should provide what position identifiers properties of his buyers should should. We should expect them to have and the basic services offer so we can have a trusted environment a trusted infrastructure available to support this isn't identifiers. Or should I say a set of a infrastructures for this isn't identifiers we don't necessarily think there's going to be one definitive one in the end and maybe a set of set of ones with different purposes. And following on from that policy the implementation of that will be guided through recommendations on which is in in tandem with the technical architecture work, which is going on in the architecture working group. And that's what Rafael is going to talk about later. And then this pit policy will, as we heard this morning on the discussion around governance. This is going to be taken into future us governance processes through the rules of participation, which refers to the policy and on the future governance processes to be defined. So our approach. Well, I'm going to a lot of details approach, but we'll mention some of the principles we were using, we applied. What we wanted to do is design a, well, to be able to enable a sustainable trusted pit infrastructures, which is suitable for a long term sustainability. So open up in science cloud, which accommodates a range of use cases and not try to put up barriers to people using pids in different ways. We recognize that there is a range of pit practices, and suppliers already in existence, and that those pit infrastructures must have and do have a global scope so they have to have. This is not just a European thing this is, this is a throughout the whole world they have to be just identifiers. And as I mentioned before that this should be largely aimed at well should be aimed at support the fair principles and an essential component of the structure that we need to provide to support fair research. So we don't. So, all that take into account we're trying to be balanced without a preferred approach or technology or provider. But rather a set of of requirements and definitions and requirements that we would expect people to adhere to when they're providing and using pids. And to have a number of services that we can, we can adopt in the eosk at a suitable level of maturity, but also encourage innovation and new services, new users pids new new new ways that pids are provided. So that is pretty well I wanted to say just a little bit on our progress and next steps. We released a first draft of community comment back in December. That has been quite extensively commented on and then we've gone through a revision period over the last two months or so just released over the last week. So we have a revision publicly available for comment for a second draft. And which is now available. We'd love people to comment on this. There are, it's released onto the pit forum which is what the link, which Sarah's put up is on so you can comment on the pit forum. You can do what meetings like today, or you can just contact us or through the, your secretariat site, or, you know, there's several different ways of contacting us so please do. If you haven't commented on it already. Take a look at it and do comment in the second version, we tried to clarify some of the points. We've tried to add some extra stuff around, we've tried to add some extra stuff around some of the governance issues, some of the, and some of the issues around things like the roles of pit colonel pit colonels. And so that's going on so going on that we expect that to be finished by in the summer we expect to get a final version out of this. In the early autumn and certainly ready by the the symposium. And as I mentioned, there's a second strand of work started up in the architecture working group looking at recommendations around architecture and implementation. And that's been started by a team led by Richard Fordman Martin Fenner Raphael involved I'm involved in both others involved now as well. I'll leave you with the with the link to the new version and then if there are no questions I'll. Well, any questions now or should we just hand over to Raphael. If there are any clarification question. Maybe now really specific to the policy. Otherwise, we will move to Raphael. Please raise your hand. If you or send message in the in the chat. Meanwhile, Raphael has taken control. And that was the interval window that was available for clarification question. And now we can move to the first presentation. Of course, there will be a Q&A session at the end anyway. So, Raphael, your turn. Thanks Jean Francois. Do people hear me and can see the screen. Yes. Okay, great. Thank you. And thanks Brian for setting the scene. So as Brian already outlined another line of activities in the context of this eos architecture working group in the context of pids specifically working out a proposal for an architecture. Of course, not completely out of the blue, but based on what we have as we will see in a moment. But before I dive into that. Let me show you who are the people involved. And this, I think Brian mostly also already mentioned Ulrich Wartmann from GWDG. Not actually being a member of the eos architecture working group, but an invited expert, as he has a lot of experience, decades of experience in fact with pids systems and other people you see here somehow actually currently in the room. And somehow I have a problem moving my slides, but anyway, what I'm trying to get at today is to introduce you to the approach that we have taken, which can mostly be taken for the time being from a collaborative document where we pool all the things together that we work on. And I will provide a link to that document in a very moment, but I will also briefly mention what we do not consider here. After the introduction that shouldn't come as a surprise to you. Then for the larger part of this presentation, I'll give you a status report on where we are. And in closing, I would like to mention something slightly different. As many of you know, the working groups also contribute to the forthcoming strategic research and innovation agenda for the eos in the horizon Europe program in the forthcoming one. And in that context, the group is also contributing a section on pids and this is what I will mention in the end. So the document that we have set out to produce focuses first and foremost on components and activities in the pid architecture and I mentioned specific also activities. As you will see in a moment because this is the approach that you have adopted to get at the technicalities that we think we should be addressing here in this context. The intent is then to continue with concrete implementations based on various approaches that we have available to us today, some more mature some more forthcoming some more generic some more with a specific scope. But then this should be further illustrated by concrete examples also linking of course to the architecture decisions. And highlighting a few of the maybe somewhat hidden facts with regard to interoperability and complexity as people not that much familiar with pid systems may wonder where is the complexity hiding here because from a more general point of view, the real scope or function that we are looking at here seems almost trivial. But mind you, the devil is in the details. So something that has for some aspects at least certain similarities and that is the DNS system and so we thought it might be a good idea to compare to that, which may also provide insights in terms of performance and scalability which is something you want for a substantially that endeavor such as AOSC and the scientific activities at large. And then let's not forget that in order to be trustworthy attention needs to be paid to security reliability resilience and all of that. And I'll close with current gaps. So what is not in scope here being an architecture group probably no wonder is policies, but also not actors in the at least not in the sense of who is performing which actions or who should be providing which service or which service component, or then somewhat more specifically, we are also not concerned with business or sustainability or more about he's speaking who pays. That is in part covered by the policy but not here in the architectural context, same for operations governance rules of participation, policy enforcement and all of that, or maybe only to the extent that we can envision that architectural decisions or components may help in these but without putting any of those topics here primarily in the focus. So here the link to the document that I've just mentioned a few times now I understand that those slides will be available to you after this meeting. So essentially this is where you can watch us working and what I should probably point out right from the beginning. Many of us people involved here are experienced with the handle system that is a technology and software stack that has been around for something on the order of 25 years at least by now. Of course we understand that this is not the only approach yet actually a couple of PID providers that you may be more familiar with such as data site who provides the digital object identifiers, the European PID consortium, EU.Speed to Handle Service, Crossref, they are all based on the handle system, which is why we thought it is probably a good idea to start out with that and try to generalize from there. And so to now dive more concretely into the details, one approach that we have taken is to summarize and illustrate the matter at hand through UML diagrams and sometimes UML activity diagrams. And they look similar to this. So this is a very simple example, mostly meant as an introduction. Some of you I'm sure are familiar with that kind of notation. So sometimes it actually matters to pay attention to detail. So as I illustrate in this example here, how do the arrows that you see connecting those two boxes here actually start with a diamond, a filled diamond or no diamond at all. May actually already tell you something. So in the example here, whether you need credentials or contract or whether it's open access and the like. And really from a bird's eyes views, if there is such a thing as a PID system, a consumer actually interacts with that. And here are six of the most basic interactions. Getting something like an account in the system or a namespace or in the parlance of the handle system that would be a prefix, which is the term denoted here that you see. And that can then be used in order to register PIDs. The system can then be queried PIDs can be resolved and so on and so forth. This is how this is meant to be read. If you then go a little bit further and start looking for instance at the consumer in a slightly more detailed fashion. Then one not uncommon use case is that a user actually does not directly interact with the PID system, but rather with a repository where she or he publishes data. Or accesses data that have been found in response to a query for instance, and it is for a large part at least the repository that interacts with this global PID architecture. And this is how this could then be denoted. Using the approach that I just started to explain and you see the different kinds of actions also being denoted here and you can then go further and, for instance, pay a bit more attention to the inner workings of what's here referred to as global PID registration and resolution system. It is understood from the onset that this is essentially a federation based approach so there can be any number of providers actually contributing to this. We denote those here as local PID providers and the local PID provider together with the global registration and resolution system then provides a PID service with which the consumer mostly interacts. And what kind of interaction goes where is also what you can take from these kinds of diagrams. If you now put these things together, it already looks slightly more complex, but this is essentially what I've just shown. Now the consumer and the provider show a bit more detail, but the story doesn't stop there. You can also elaborate further on the resolution and looking at existing PhD systems. This is actually what we already have in place for some PID systems at least for performance, robustness, resilience and all that. As I said, the system is from the ground up designed as a federated system, but not only that, there is also a certain hierarchy of authorities or there could be at least and that allows then for more manageable delegation of control, for instance, who is allowed to do what where this allows for mirroring failovers in the resolution and those kinds of things. I don't even want you to look in close detail at all those different errors. That's why I'm trying to explain why you want to turn to such an architecture eventually. And so far I've not really explained something new as I've been referring to systems that we have already up and running some since years still. This now is something slightly more different, what I call adding types and profiles. In fact, what we are picking up here is a recommendation or should I rather say a bunch of recommendations that grew out of the research data alliance over the past couple of years. Some of you may even be aware of the fact that within the context of the research data alliance from the onset, essentially, there was a certain group of people interested in PID systems and how to develop and take them further. And two notions specifically were brought on the agenda, right at the onset of the research data alliance. One being the topic of data typing and concepts such as the data type registry and more powerful machine-readable data types grew out of there and that has been recommended by the RDA for future adoption. And it has actually also been picked up in the meantime by the European Commission as this is an endorsed ICT specification that also the Commission now actually accepts in certain administrative and financial contracts, procurement processes and the like. And the other term mentioned here are then profiles and with profiles we mean that it should be possible to add certain a set of metadata to PIDs. So not just what people usually assume to be a scope of a PID system, you have something globally unique that resolves to some place else and if that place changes you adapt the registration and so you don't lose the reference. That's of course the first and foremost feature and functionality that people expect from a PID system and rightly so, but it doesn't stop there. And what I'm getting at here now is the possibility and in fact the handle system provides that capability from a technical point of view already today that you are able to associate certain metadata, in fact any metadata or whatever you can cast into proper key value terms and if the value is a reference to some place else then that can be arbitrarily complex in principle, but the idea being that in addition for a PID system to be able to resolve to a object in question, it should also be possible to obtain a certain set of information about that object without in fact actually accessing the object itself, you may still decide later that you want it anyway, but on the other hand this additional information could also help you decide, oh no this is not what I'm interested in. And the kind of information that you may add to a profile could be, well, simple technical properties such as size or a checksum that you may want to use in order to check for consistency, whether you've really gotten what you expected to get, but it could also be information about access rights, for instance, or rights holder, whether it's something open, if they refer to object as open access or if it's available under a certain license, or you may have information there regarding version, whether what you are about to get it, if you were to resolve that PID is that the current version of something or is there a predecessor or successor, people have been thinking in different directions and there have been quite a number of contributions and proposals, what exactly to put there and how, so what kind of metadata and it is generally accepted at least in the PID community that this would be a useful feature to adopt and use and as I've tried to outline this can be used in many ways and in which ways is still to be elaborated upon. So, if we then put all these things together, again, I called it an almost complete view, because I'm sure we are not there at the end yet, there are further questions that we are considering to what extent we might want to incorporate those here. And this is what I summarized here now again in text form, namely, should we go through further iterations to make the federation aspects more explicit and this is driven by the observation or the simple fact that admittedly a lot of what we produced so far is based on our experience with handle based systems, but of course we are aware, as I've already mentioned in the beginning, that there are other technologies in place to establish similar kinds of functionality. And if we ask ourselves how it should become possible to federate across technology stacks, then we need to pay more attention to interfaces and protocols and to what extent we then agree to cover that within this specific architecture document here. We haven't really answered yet that's one of the current discussions going on. The other thing where I've just tried to explain by way of example almost the two main functionalities of a PID system as we understand it, namely in addition to resolution. Also the option to retrieve associated data metadata profile or kernel information. It's referred to by different terms in different contexts and actually coining a term to be used in the context of EOS maybe also something where we make a proposal. But then another open question that we are currently considering and asking ourselves to what extent this should be incorporated in architectural discussions results from the fact that when a PID registration or it's associated metadata so at the PID record level needs to change because something has changed it's not the current version any longer or there's something else related or it's been moved to a different place than more often than not the person or authority that would be aware and responsible for that change or responsible for reflecting that change in the system may not have the immediate rights to do so because after all we want to PID system to be stable and trustworthy and correct and reliable so we can't allow just anyone to change anything here and so most likely there should be a process through which updates changes additions to already existing PID records could be managed and what impact that has on the architecture is one of the questions that we are currently also addressing as I said and this essentially covers the two bullet points here the delegation and the request and then from the outline of the document that I've just briefly mentioned in the beginning by far not all sections have been fully elaborated some have only sketches of the content just some are just bullet points so of course there is a lot of work left to do and on the one hand that is probably not too surprising given that this group was actually put in place and started its activities only three months ago so while the architecture working group has been around for more than a year or almost a year and a half formally and more than a year effectively we first contributed to the generation of the PID policy document which has reached a certain level of maturity by now and so it's been only more recently that we've shifted focus within the group now to work on this architectural document so this is why we don't even have something a draft ready to the extent that we would be able to circulate that and solicit feedback that way but on the other hand we thought it's actually a good idea to reach out here and point you to our working document because I think now is actually a good time as it should already become apparent what we are thinking where we are coming from where we are heading and most likely we might be missing something or maybe if you've gotten certain things wrong and of course we would appreciate feedback along those lines in order to get us straight but maybe even more importantly what I want to say here is that at least some of you might actually be contacted by us in the not too far distant future as some of the sections specifically those on the concrete implementations and on the concrete examples we may not even be able to properly write ourselves so we would need then help by people who have their respective expertise and I just wanted to give a heads up here so that to prime you should you be in scope for these kinds of questions and with that I now switch gears again a little bit as already announced in the introduction what we already also were able to do is based on the current state of affairs both within the policy as well as the architecture work to provide input to the forthcoming strategic research and innovation agenda for ESC and summarized this on essentially two slides one being this one here now the first part where it's more on stats I think that is explaining what we have today but the gaps are probably more interesting that we have identified and some of the things mentioned here probably does a surprise to many of you so in essence people agree that in order to know what we are talking about we need identifiers quote and quote for everything so not just publications or data sets or data collections but all four well the other types of resources or entities of the scientific process being that people organizations funding agencies projects on the one hand or software workflows other artifacts of the scientific process on the other hand services for instance so for all of those it would be advantageous to have PIDs but then you may be also able to see already from from this enumeration that the moment we start to look at accompanying metadata so additional information to go with the PID itself that may actually require different kinds of additional information as different entities of different nature are simply described in different ways how to properly do that is actually a challenging task and for most application domains not really established yet then another at the moment PID systems specifically when we are then also considering the PID records are only to a very limited extent machine actionable by the time specifically not when we consider machine action ability beyond the PID system itself named by the refer to objects that's then where the notions of data types and the like come into play another issue where we are currently at well have nothing available to us is if we if we just consider the fact that PID systems may be based on different technologies organized by different organizations and authorities so far there is no overarching meta-resolve we call it here so a service where you can turn to with any PID whatsoever and you will get what you expect I mean a resolution or to the object itself or to the additional data again back to the handle system technically for the handle system that would be straightforward as the handle system supports the design even there mostly based on policy decisions not all PID service providers that use the handle system actually support resolving PIDs issued by another organization just a matter of fact today and something like that even more generalized we consider a gap next thing may sound something more specific namely the PID graph but that would be an example of what I mentioned earlier potential use case for the PID records namely to hold information about relationships of the refer to object to other objects and that then could build the basis for integration of PIDs into a more general fair data management system as we envision it for EOS yet another angle that may need attention and where understanding so far is limited at best is how to deal with sensitive data and again there the problem is mostly on the side where we are talking about additional information the metadata record the data itself is sensitive and needs protection then that typically also applies at least to a certain subset of the associated metadata that then means you need access control both for viewing and of course also for adding or changing that information quality of services new PID technologies you can probably imagine what this may mean and for the last slide here in some ways this is written into the previous slide it's a subset of those terms but with a bit more verbose phrasing I just pasted literally the current state of the priorities section from the 3R contribution this is on this end our current state of discussion so highest priority would be PIDs for instrument services organizations and software second priority emitter resolver third priority SCADA so essentially a specification or a model for the PID records or kernel information as some say type definitions protocols for exchanging information between PID systems and tools to support the certification of PID infrastructure with that I would like to open the floor for discussion I think I hope I've now provided a fair account of the status of where we are with our discussions and considerations and to see this is something well right from the engine room we are by no means finished yet but as I said this is probably also why now I think it is a good and rewarding time to open this up and solicit feedback and I'm happy to receive your contributions thanks so for any question please raise your hand and you will be unmuted and so you will speak thank you I'm not sure I should still share my screen or what would people prefer somehow I just tried to get a glimpse on the chat or see who is raising hand but I failed to see the presentation view of my slide and the controls from the Zoom meeting so I would appreciate if somebody could moderate this and yeah that's fine so this is Sarah so I can read a few questions out of the chat so Oya's raised one about how easy it would be to substitute a PID system are there any measures to mitigate a lock-in situation well as I've been trying to explain one key design decision is to have this based on a federated approach which is to say that there won't be any single or central PID service so you can add quoting quote arbitrary that's at least the goal PID service providers and that I consider an important prerequisite in order to be able to substitute potentially a PID service providers should one run out of business so to be taken over by others the other means that we already have in place today in many situations is to mirror the information between PID service providers so that if one goes out of business or goes just down for whatever reason it is taken over by others so I would say in principle we are thinking that this is accommodated in detail there is probably a lot more to be considered rather than just the technical prerequisites as that of course also involves a number of substantial questions with respect to authority and control which need to be made more on the governance and policy level rather than the architectural level but if I understood Oya's question correctly then I would say caring for such a situation or providing the technical means at the design level of the system yes this is in scope and we think this is accommodated for excellent thank you can I add to that yeah yeah go ahead Brian there's a preference in the policy to say that we would expect community standards and governance so there'd be a certain degree of openness in the standards under which a PID scheme would work so it would be available to public view what the standards the systems following so that should give a level of assurance that you can move to a different system which is compatible okay sorry we are some people have raised their hands yeah yeah I noticed that so Milan and Yuri are the two I see raised I think Milan can I have one question yes and you have we have a lot of bits for the same entity for example for people for organization for project who will work on alignment of these bits because I think is the most important is that we have some unique alignments him for example Mila Moistak shekin orchid Mila Moistak shekin VIP or the searcher ID I have different bits for the for me for example for a person yeah I think I perfectly understand I think I perfectly understand where you are heading and also where you're coming from and I absolutely agree with you I mean it's just a matter of fact that we have this fragmented landscape I also actually I even don't know how many different identifiers I would have for myself and the being in the context of a researcher a person an infrastructure provider and you name it I would consider this actually an important application domain for the PID graph that I briefly mentioned in the sense that it should be possible to connect PID records and so to in order to establish relationships between them and one such relationship could be something like same as or also known as and then a meta resolver I would envision to be able to return more than just one hit on saying the identifier that you provided me with points here but this is also known as or it's also the same as ABCDE whatever it then finds so based on that information assuming those relationships were established aligning those even further to the extent that in some bright future there may only be one identifier for a single individual entity and that's it personally speaking I don't think this is a state that we will ever achieve as we are already starting out from such a fragmented landscape as you've been referring to and actually maybe that's not even wrong because some identifiers have only a certain limited scope and at least from a functional perspective sometimes even limited lifetime even that this is somehow contradictory but when we consider persons for instance they also have a finite lifetime and I have a passport number I have an ID number I have a personal number at the Max Planck society where I work for and somehow we get that sort of aligned but certainly we should be able to do better that is not to say that we encourage your proliferation of PIDs all the contrary but I think we should be able and prepared for dealing with the situation as we find it and I would not be surprised if other people have a different view here but that would be my stance another thing is scalability for example if you have a lot of things of data and every this data stream has their own PID how you will resolve these scalabilities of PID if I understand you correctly then you are referring to the question of granularity and by that at least in my understanding I mean what should the PID actually point to or be issued for should that be a macro entity something substantial or could that be a minor detail of something and from an architectural point of view I'm not so sure that we should even make statements here I would consider that rather a policy question but of course it is a very relevant one and the answer on the other hand is again related I would say at the performance of the system and that then in turn is again depending on the architecture so in that sense yes it is also nevertheless in scope so many of the experimental scientists today are collecting every increasing amounts of data and do you give a PID to each observation trace image from your microscope you name it or not and if you were to do so if you start out at a very fine granular level we would easily be overwhelmed by PIDs and that could be actually quite a challenge for a global PID system probably almost unfeasible for the foreseeable future at least the approach that people then typically take in addressing this is or a recommendation often also start assigning identifiers early in your system in your observation system simulation software or whatever it is that you are dealing with but maybe produce those identifiers first and foremost locally and organize your data then in the form of certain collections and maybe only to those collections then in the end provide a PID but there are also hybrid approaches I would even be aware of in a concrete example that I'm just thinking of the novel materials discovery repository what we have adopted there is that we issue a handle based PID that we mint ourselves for each and every data set but as I said data sets can be organized in collections and those collections then often done for a specific purpose for instance they may contain all data that went into a certain publication or we're underlying the analysis and the results then published in a certain publication and for those collections then people can request to get a DOI DOI is a bit more effort because the policy there is that you are required to provide a certain minimal set of metadata which you may not be willing or able to provide for and may or may not make sense for for each and every bit that you might want to be able to refer to but those would then be individual decisions at the level of a project or for a community and for the PID system as such as we are considering it here I think as long as we can support those different approaches and those different policies I think we are fine but I agree with you if you take it to the extreme we will certainly hit limits. But that's also why I mentioned towards the end that also scalability and performance are certainly issues because the limit how far you can stretch that depends on this. Thank you. Excellent so Yuri if we can come to your question and then we'll see if we get chance there's a few more in chat but we're running out of time now so Yuri if you could ask your question. Mostly not ask my question simply comment that actually PID is very important would be service but first of all we have example what I mentioned also in Budapest that we have a nice example of global identification of any object that exists in the infrastructure is a cloud modern cloud systems. You can understand that scale of cloud systems is equal to maybe in the future scale of research infrastructure, but the only problem with them is that they are entirely inside inside. So cloud provider doesn't solve the problem across border cross cloud referencing and indeed the referencing a federated infrastructure for PID is very reasonable but we need also to understand that many infrastructure research infrastructure will have own internal PID system for objects and what will be exposed outside. This is what also some said so so architecture should include a so called hybrid infrastructure intra organization and between organization inter organization. Second is that actually comparing to DNS, maybe slightly misleading because DNS is a low level protocol and what we expect services from PID infrastructure is actually like service level protocols so where we can use rather web services and API architecture than DNS low level protocols and if we agree on this kind of or accept this kind of a basics or a key issues we may faster forward this development of PID architecture and infrastructure. Thanks Yuri for your comments and if my if I may comment on your comment. I think I actually agree and I think we've seen already in the discussion. Two examples for the first point that you were making. The this interplay between internal organization and what you expose to the external world. And yes of course I agree that in cloud based systems providers have to deal with the identification process all the time and it's hard from trivial. But yeah, people managed to do so. It gives a hint on scalability you're right and of course you can also run a PID system in the cloud and have it scale there, whatever you can afford. And that things should be able to work across organizations. Yes, I absolutely agree. I think I was even making that as an example or motivation for what I recall the extension of this federated approach and the potential consequences being that you should have a well established way how those different PID systems that operate under different governance can actually inform each other or technically speaking become interoperable nevertheless. And and and your your final remark with respect to the DNS system. I meant this to be an example for the kind of functionality that you nowadays take for granted. You open up a browser you type in the URL, not an IP number. And it goes somewhere and you as a user you don't need to care how this is actually resolved how the respective node in the network is found how the application on that delivers the web presence and all these kinds of things the user shouldn't care. Absolutely agree. And this is the level that we think you should be able to achieve for BDS as well. If you have a PID from somewhere you want to get at this you don't need to know and you don't need to care this issue of this PID. There is a maybe web service or some kind of service where you can approve that PID that you have input and you get what you expect. This is. This is an example of functionality. I was trying to you to and why I use the DNS as example for comparison. I did not mean to imply that a PID system should work under the hood and at the same level and in the same way as the DNS system sorry if that got misunderstood. So I see some of the questions have been addressed in the chat as well Brian and others have commented. Does anyone have final questions or reflections, Jean Francois or Raphael or Brian, if things you'd like to comment on before we close. So there is one more question left on sensitive data in the chat. I, I think that might be coming out of another session Raymond are you in this session. I'm feeling the chat is actually merged because I think this might come out of the MVE one but all possibly it's for here. Sarah, I'm in this session. Yes. Oh, you are in this session. Okay, sorry for ignoring that. Yeah, I need to try to understand what what what are these categories of sensitive data. So. Sensitive data. What is this sensitive data about. And by sensitive data in this context here could be anything that requires protection and for that reason access control, whether it's personalized data clinical data, social science data. A lot of research is actually performed on data that for one reason or another can't be made open. You want to be able to assign a PIDs to such data. Now, sometimes this is already considered problematic if that would imply that you make certain information, you make information available that there is something there. Say this is access control, or if you add further information like this is from a certain experiment, which itself might already be sensitive data that needs to be protected. What we mean here when we say in order to support sensitive data in a PID system. The system itself should provide means by which data it deals with the PID itself the resolution target, the associated metadata in the PID record or a subset thereof. Can be protected themselves as well in order to not break things open that shouldn't be broken. So, whatever then falls into that domain and whatever the level of protection is needed. It should not be a non-supported use case. Let's put it the other way around. And what that then implies in principle and how that could be accomplished, what architectural constraints follow from there in order to support these kinds of functionalities. We haven't really worked out in detail. I have to admit, there are certain ideas at least at the level of protecting individual properties or attributes within the PID record, but that's essentially as far as we've gotten up to now. But I don't know whether that now answered your question. Yes, but because originally what I was wondering was that the sensitive data could this be data that we think that has difficulties in its access. Because for example you'll find some institutions they want their data to only be accessed when you have paid for it. Yet we have been discussing open access, free access, all that kind of things. But when you brought in this sensitive category I was wondering what exactly is this data type. And here in Africa, most of the data to be accessed unfortunately most of the government agencies might want their data to be paid for. So that's why I wanted to put it to that level for it to be sensitive. Thank you. I think we're out of time. So Sarah, back to you for a conclusion if you want to. Yeah, well just a thanks to all of you for participating and particularly to Raphael and Brian for presenting. And also in spirit of openness I think it's fantastic for people to be able to see the working documents as things are happening there. So do tune in, see what's happening and thanks for your feedback here.