 Hi, everyone. My name is Feng Yan Zhang, and I got my future degree in NGNM University. I'm now working as a post-doc in the Hong Kong Polytechnic University. I'm happy to attend a CES-B, I'm in your meeting here. My topic of my presentation is interoperability, engine design for the modern sharing and reuse among the OMI, GMI, and OVGMSIS modern standards. Here, this is my main context of my presentation. First I will introduce the background. For modernization, it's a key method in the geographic research. Models are obstruction in the expression of a geographic phenomenon and the process. It can be used to enhance the capacity of the geographic analysis for traditional keys. And we can use many files to reverse the past, the future, the past, and its current rules. And we have a massive geographic analysis models that are in different domains, including heterologic, atmosphere, economic, environment, and others. And we can also have different special and temporary scales and different processes. And so, how to make a score use of these results and easy to use is a big question for us. So, more and more standard was designed by different platforms and organizations for understanding, sharing, and reuse, just like CES-CMS is a big organization here. And we also have just an OMI, OVGMS, and the OMI app. We also have some protocols, just maybe a standard like ODD, OVGMS, metadata, and UTS. Here, we just introduced three specific in our research. The first is the open MI, it's called the open modeling interface. It's a standard for the real-time exchange of data between software components for environmental management. It has, it's focused on the linking and the integration between the modern components. And second one is the CES-CMS, as we know, it's our meeting organization. It has a big modern expository. And then, of course, it's DMI is the most standard for modern encapsulation. And, you know, the modern expository here can also show us the metadata of the massive modern resource. And we can download the resource here and to understand it with an easy way here. And OVGMS is my, maybe, I just found the OVGMS. And it's just a model sharing, modeling and simulation resource for geographic applications. It has a, maybe we can call the OVGMS interface site for modern sharing and reuse on the web. It's, of course, just sharing our modern resource as a model service. So, we have challenges now. And the models that follow specific standards can be shared and reused with their own standards. It can be easily reused by the framework or applications following a specific standard. But it cannot be reused by another standard. It's a key problem, just like you can see in this picture. Just like an N that's a standard just like an N and the Z doesn't have any rules with another N. It maybe has some obstacles in between them. Here we list some main detail changes here. The first one is the hydrogenarity of the modern descriptors. And two key points. First is the different scripting files. As we say, we have always, we have some same information with the same file. Same input, output, like this one. But sometimes we can have some same information with the different files. In some standards, the instruction, maybe we can call it abstract or something. In some standard, we can call it a sort of instruction. And then we have the sensor also have also totally different files. Some generally depends on the grid and some different steps with their files. So, it cannot be in the operation with directly with others. And the second one is they have different. As the descriptor and loaders. It may just like an open JS, we can reuse the files. We close the metadata for the model. And just in BMI, we must to work the some interface to get the descriptor of the models. The second one is the hydrogenarity of the data input and output. Different standard have different data input out of them. We had different standard has different data standard. So they have the rules. So, we use trivial div to exchange the data. And we sometimes some say we can not exchange it with different. Maybe it's just three or just with both. And then they also have different extreme messages. Okay, we can have different styles. Sometimes we use it as a parameter. And then we use sometimes we just different input output here. And the second one, we can say hydrogenary. We have different in working message. And then creating different in working logic. Different type of programming languages. Different running styles. I can say that the state one, one here. We use the pattern. We work it. But then we use strap and then the standard one. We write it as the web service. And the place be just like a component. By file. So, we read some maybe some of the potential solutions for model inter operation. We take upon my system and we add some here. First, first one, we want to use that we can build as inter operation between the area to standard directly, we just to do the inter operation. And then we can build between areas to standard. That kind of one. We can give it a universal standard as a big area to unify. Unify different islands here. The third one. We can do it about physics standard as a bridge and the some, and some extra. And then we can do inter operation. First, it's an area to standard for advanced intervention. This one. For all of them. Okay. The one thing or the big one. For the first one. Maybe it's very easy. It's easy to build a social solution. Because we can just do it. We can build two standards with another. It's very difficult when the standard are more and more. And the second one. The main challenge is to defend the universal standards in the middle. It's very difficult to build it. So, we choose the third one, we just to build a basic rules for the universal. You know, you know, so physical standard, and to suppose our into our ability engine design. amongst our three standards. We list the three ports to design our interoperate interoperability engine. Firstly, it's a failed machine. And the second one is the is a function conversion and the third one is a component organization. This is the key point to can you talk interoperate the modern in source standards to the modern entire centers. The first one. Well, maybe as you can see, we can have some felt in the first left Sunday. We use the common felt table to map some. Some the spells in the standard a to the standard B. So this one, we can also can can feel some missing felt by the computer table to and the pros of some maybe some. figures or fails. There is a part of the hour. Maybe the common bills table with different some visit bills here. The second one is common section table in here. We also the first one we need to link the different functions between the standards. And they can see we also different common table here to link them together. Here is the function table here. And then we also use the we also need to to transfer the different data from it and commit to map the data contest in the output data and the input data. So we use your universal data exchange model in our team to do it. The final one is a combination of the regulation. We also do in the physics to your way you also need to press the in the modern in standard a and copy the maybe the fail and the combination with with reference and revamp them at this time to be. Here is my hour hour hour of a bit of the mission, really close here, the open source in the GitHub. We also need some we can also use some. The first one is here. The first one is open my to the open CSS, we can have. We have the, we use some of my common here to wrap it as a sum, some one source here. And we give all we also very different, it really did is it was a type of data. And it's open to open my okay we wrapped open service links it links it to the open my as open my components here. The first one is the BMI to open CSS we wrapped from our modules for is a first number common here is the decision modern for in the EMI and the way we read it as a water service here. The final one is also the as guess more than in open gms we wrapped it, we can we wrapped it as a BMI common it and you work it in by BMS interface. So here we have some questions to discuss. First, we found the latest laws here, the data, all fields and functions in the comments are decided by the interaction of the from the net native model to the final model for the model in final standard. So like this one, we, you can see the final to finally, the more than the best and the functions in final, in final standards, just a per just can pursue the functions is by the interaction of all of us. The second one is a tip point we will do the further research over them and quite to pursue the more fails and finishes. The second one is the river or linker. We have to come in as he has to come to pursue all fails of the of the motor and by standards and they could just set to link the models remote, literally, and to grab these other standards. You are the one here and this one is just like a rapper rapper is more maybe more sustainable and reliable because they copy all fails. You're all PC. And the linker just can save more space in your PC, and they are easy to use and it's complicated region. So here we come to the conclusion with the development of the different standards for modern sharing modern inter operation model different different is increasing potent. It may be in our, I mean, in our research topic. So for in the future, we have also have some work to do. First, we also want to build a universal standard for more than you know, it's very difficult, but it's a tree. And the third one, we will use what we are going where we are ongoing is to do the data exchange solution among the different standards. The one we also want to develop a more physical standard plug extra tools, and the final one, we need more study summarize the set up practice engine. This is our team here this way is my PhD advisor, and our team which success them all. And that's all. Thank you for the team.