 Our next presentation is on reservoir DDMS. Marcus and Alice, our colleagues from France, unfortunately, had a travel disruption. And so, Philippe Verne will be doing the presentation on reservoir DDMS on their behalf of that. Bill. Okay, hello everybody. So, as Denis said, I'm not Alice, I'm not Marcus, and I don't pretend to be as great as them, but I'm going to do my best to present to you this presentation about the second example of capability and alignment related to the reservoir DDMS. So, first, a bit of story about the RDDMS and mainly the reservoir domain in OSDU. So, we started with two teams three years ago. One team for data definition part, and one team for the DDMS part. On the data definition part, the operator, we started with the operator's lead initiative by providing a lot of reservoir data definition that we have merged into the master branch in M-term. At the same time, on the DDMS side, there has been a first contribution of Aspen Tech of the code of the RDDMS. But then in 2022, we decided to merge the two teams together in order to save some resources and to be more predictive because it appears that actually the same people were in the two teams and there were some topics that were duplicated or repeated. So, we tried to save a lot of resources and time and we merged the two teams together in 2022. Then from 2022, on data definition side, we addressed on-demand additions. So, for example, currently we are working on biostratigraphy with the input of Equinoa and CGG. And we focus also on different topics for the RDDMS. So, on RDDMS, there was a second contribution of Aspen Tech for the code of the RDDMS. And then after, we had our first deployment on Azure. You can see a star next to it. It just means that a star, it's a public presentation that we have done using WebEx, for example, in order to show exactly what has been done to the whole OSDU community. Then after this deployment, we have worked on ACR support, SSL, ETP client support and providing REST API. Again, with a public presentation. Then we worked on the manifest builder that provides a link to the indexing system and some improvements about ACR support and a second deployment this time on IBM. So, this is where we are today and of course, we are exciting to continue. What we want to show in this presentation is our specificities of this team of the Resolve RDDMS. We have done since the beginning a big choice to leverage adoption by using existing energetic standards. So, we have not reinventing the wheel. We have not started from scratch. We have started from something that was already done and available. So, we use the rescue ML data model to define the metadata in data definition. We use also the nodder energetic standard which is called ETP for energetic transfer protocol. We use it as the API for the data exchange to implement the Resolve RDDMS. And in our Resolve RDDMS, the storage format is exactly the rescue ML object. They are stored exactly as is. And as some of you have been involved I think yesterday in the EnerGistics meeting, you can see that those standards are still answering, addressing the community requirements. So, that's something that is important for us as well. A second important point is about developers, architects and SMEs attending the data definition and DDMS tracks. So, we believe that we have a right balance, between vendors and operators. Our approach in RDDMS is workflow and use case oriented. And we have not decided to do everything but we try to limit the schema that we do, the schema definition to only the most important entities. Finally, we contribute the code in the community GitLab that allow collaboration on top of this code and that allows to create a community around the RDDMS. Third important point is to adapt APIs to different client categories and needs and don't limit to a single API type. So, in different client categories and needs, we can mention data analytics using metadata versus data screening including numeric values, data visualization and last but not the least the manufacturing generation from the DDMS in order to be able to index our data. So, the key point of all this slide is that we have used a standard that is approved, validated and integrated in industry SMEs, operational workflows. And this has allowed us to use the existing software connectors to test resolve RDDMS use case and client workflows saving us a lot of time and a lot of resources. So, what worked well and what does work well? So, the OSDU specific guidance for from the data definition team and core concept team. And also the regular communication with the PMCs. We also think that to split the lead and the responsibilities in our team is something that worked well. The merge of the two teams also is something that worked well. We are working with a single team allow us more reactivity between data definition and DDMS. The testing of our use case was also something great because we have done the best to use an existing standard with some existing implementation. And then it was quite quick actually to test what we have done because again, we did not start from scratch. We started from the energetic standards. Another point is that when we talk about reserve work that's on your word, but behind this word there is really a large data scope. And we, because it is large, it involves a lot of interaction with other domain with other group in OSDU. And for example, we have worked recently in Paris especially at the face-to-face about some interaction with seismic team and this is something that we have liked a lot because we have some first outcome and we definitely, this is something that worked well. Last thing that worked well is CSP involvement. So even though it is not continuous and varying from providers, but actually we thank CSP for their involvement. What can be improved now? So two parts in OSDU organization and more reservoir specific. So in OSDU organization, it would be good if we could have clearer guidance on DDMS certification that's been a bit discussed just before but the certification of DDMS and even from the beginning when we start to develop it would be helpful. Again, for development purpose, having more pre-shipping environment would be helpful. Also what can be improved, the CSP deployment pace for testing. So it's not continuous and it is varying from providers. We think that it can be improved. The cross-DMS work group is also a way for improvement because for now the DDMS are only about one domain. This is the first 2D, but we need some cross-DMS work group. And also a more generic point about less run map objective with more active community. So maybe what we generally call do less but do better. So do a little bit less but do much more better. This is more what we mean. About some reservoir specific potential improvements. So we think that we are a bit understaffed to attend all meetings. Again, that's a large data scope in reservoir. So we would like to be part and to go to other team that would be really helpful in order to avoid some duplication of that definition, for example. But it takes our own resources so it's hard to understand how to do that. So there is no clear decision on cross-DMS management. We don't know exactly how to interact with other DDMS. Even if the standard is documented, we use a rescue ML as I said earlier. It can be a bit hard for people that have never looked at the documentation which is available, but if they have never looked at it, it can be a bit difficult for them. So we need to find a way to educate them in order to make them understand what exactly is rescue ML. One of the examples is that rescue ML use a graph data model that we use. And but this graph data model can lead to slow down CSP deployment, for example, because it might be new for some other team. So this is quite a summary of what worked well and what can be improved. And that's the last slide if you have no time, so I don't know if I have spent my 10 minutes or not, sorry if it was too long. But just some statistics about the DDMS GitLab repository, so 18 months ago it has been built with 18 different contributors, more than 200 commits, seven releases, available build and install documentation, operational CI CD pipelines, officially already deployed on two CSPs and multiple presentation with testing on official demo environment. I thank you and I keep available and I will be happy to discuss with you if you have further question during a break.