 I'd like to invite Frank Goldbrock on the stage from TGS, and he's going to present TGS Well Data OSDU integrations. Thank you, Frank. Yeah, hello. So TGS is a provider of subsurface data, geophysical and geological, and kind of data for renewable energies, so just to set the stage. So we joined OSDU about three years ago, so 2020. And I want to present to you our view on OSDU and kind of how we, our integrations with OSDU in the Well Data domain. So yeah, our view. So I actually, first I need to thank ThoughtWorks for their nice and interesting presentation and also because it actually provides me with a nice intro. You see, I put the vision there on top, and in ThoughtWorks' presentation it was set how important the vision is. And so I actually put that on there before knowing that this other presentation happens and kind of, so this vision really got us hooked up. So kind of saying, yeah, we want reducing data silos, enable transformational workflows. Yeah, we want in, essentially, we said so, three years ago. And for us, really kind of as a data vendor, so the OSDU form kind of, so that really has a potential to revolutionize the industry so because it provides a standard for accessing, searching, and visualizing data with minimal configuration. And also kind of, it solves the trouble that data vendors of the last decade and more consistently had kind of this so-called last mild challenge to get the data to the end user in a format to make it usable. And I heard in this auditorium there were things mentioned previously earlier today kind of about accessing quality data with low latency or in the summary of the previous session, it was also mentioned that, yeah, it's good to hear that OSDU actually, the feedback that comes is more about the data and not really that much about the platform issues with the platform. And for people who are passionate about data, writing data, this drives the code. So, yeah, exactly. We want, when we get contacted by customers about things, we want to get asked about our data. So why is the data this way or that way? So rather than kind of having trouble with how we provide it. Key trends we see kind of in OSDU that are important to us is kind of first, so the use of the external data system. So to be used to keep your data library up to date. So this is work done by an OSDU project team at the moment. And kind of that would allow us now being selfish here again. So of course, that would allow the customer to keep their data library up to date with the latest version of TGS data that is available. And the mastering and tagging that is built in will also allow the customers to collate the data and ensure that they can easily meet contractional obligations with the terms of use. And then the other key trend we see kind of or we have utilized in TGS is actually to directly connect to the data library through OSDU APIs. We actually announced OSDU-compatible APIs for well data back in 2021, May 2021. So that's almost two years ago. So yeah, accessing this data then through the OSDU or OSDU-compatible APIs will kind of give the confidence that the decisions are based on accurate, complete, and updated data sets available. So the OSDU schemas TGS uses, there are four of them. So the well scheme, the well board scheme, as the master data scheme, schemas, then the product component schemes, well log. So last data, well board trajectory, directional survey data, and all they are currently in version 1.0.0. So there are newer versions released by OSDU. So our aim is actually to upgrade our compatibility to the up to date version of OSDU in master data in the product component data reference data. So we are working with the or in the external data services project team together with other data vendors. So the external data services application or service, EDS enables the communication between OSDU platforms. So between kind of one operator and kind of a provider. So this can then pull the metadata, master data, work product component, so forth from the data provider. And bigger data sets like there would be last data, well log data, or well board trajectory data, direction service, would actually then kind of pull it from the provider side. So you actually get linked from your OSDU platform to the provider side and get the data from there. So this is an ingestion test. We did in the last milestone 16. So we loaded kind of master data, well board, geopolitical entity. So where is this well? Which state? Which kind of province? And so forth. So in which field? In which geological basin? Which organization? Does it belong to? Then obviously you see the direction survey, last data. And then reference data, unit of measurement, azimuth reference type. Kind of this is important for the directional survey data and so forth. So the second trend kind of is connecting directly to our data library in our data lake. So as I said, this is since May 2021. So we are enabling clients to directly connect their data library through OSDU compatible APIs. And the content in the API is also mapped to the OSDU data platform. So you can use the OSDU documentation. And here we are using kind of one of the tools on the open group website. So there's a Power BI OSDU connector by well developed by Krishnan Mihil Redarummudi. Apologies if I do not pronounce this correctly. It's a long name. So we use this just to prove that our kind of to simulate end user consuming our data through our APIs. We also have an API documentation for our services available on Swaggerhub, which complements the OSDU documentation. So as I said, you can use the OSDU documentation. But in addition, there's also documentation on Swaggerhub about our OSDU services. Outlook, so where do we want to go? So as I mentioned, we want to extend the compliance to the latest version of the OSDU data platform. So as I said, for some schemas, that's 1.1.0, others it's 1.3.0. We want to support more entities for master schemas. So expand actually what we're using. Then obviously, as it's always on the kind of in the mind of data providers, or should be in the mind of data providers, so improve data coverage and data quality. We are currently working on some schemas. So we kind of worked on a RustLock schema. We did a TDS version of it. And we reached out to OSDU, so because we are fully aware that having a TDS OSDU dialect of a RustLock schema is not really how it should be, kind of not good practice. So we want to work with the OSDU and actually have a RustLock schema developed that serves all. And we also looked at a well-documented schema, but we haven't progressed on that yet. So that would be depending on feedback of our customers, whether they want such a schema. So in a summary, kind of so our OSDU services, so we use a well-locked and well-bored trajectory schemas, we are aligned with the OSDU data platform 1.0.0. So we aim to kind of upgrade this compatibility to the latest OSDU version that there is. We work in the external data services team, so this is for us very important as a tool to update data libraries. So on a customer side, kind of getting our data to the end user. We use the Power BI connector available in Open Group web server to simulate and test the data consumption with our own APIs to ensure that their OSDU compatible and documentation of our APIs is on Swaggerhub. And I want to actually give thanks and credit to a number of people. So from TDS first, Artwo Gupta, who works in with the external data services team, Jay Gilbrus and Jim Burke. Then I also want to give many thanks and give praise to the external data services team, all external data services team themselves so that they're doing a great job and kind of looking forward to the result of the next milestone and to the testing there. And then Krishnanikh Veduramundu, who's Microsoft Power BI OSDU connector will be used kind of to test these things. So with that, thank you very much.