OntoTrans is developing and using a number of interfaces, for example
OntoTrans has developed the OTEAPI framework for the purposes of two-way communication between the applications in OntoTrans and specific external resources. OTEAPI is an open state-of-art Python framework for connecting data consumers to data resources via pipelines consisting of filters connected by pipes to download, parse, map, filter, convert and process data from a source. The filters are small modular components that can be reused and combined into new pipelines for other data resources or needs. The pipelines themselves are also reusable and can at a next level be combined into workflows. For this to work, OTEAPI relies on an underlying interoperability framework. By itself OTEAPI is agnostic to the choice of interoperability framework, but it has been used with the SOFT/DLite, which is a lightweight interoperability framework based on simplistic data models. DLite achieves full semantic interoperability by mapping properties in the data models to ontological concepts. The combination of OTEAPI and SOFT/DLite lowers the threshold of onboarding new data resources by a clear separation of data models that are easy for data engineers to work with, and ontological mappings expressed as simple RDF triples. The use of ontologies provides very powerful transparent conversion between data models as well as semantic data discovery.
OntoTrans will provide access to a range of materials databases from the Open Translation Environment (OTE). This is achieved via an interface to the OPTIMADE API. The OPTIMADE API is an open-source REST API specification for materials data providers on how to present and query their repository data. The OPTIMADE API specification is written and maintained by several major materials database providers such as Crystallography Open Database (COD), Materials Cloud, the Materials Project, NOMAD, OQMD, AFLOW, and more. The specification focuses on materials structures and is currently quite sparse concerning unified fields and the expected available information. However, the specification is being continuously updated, as is the associated Python tools package to easily interact with OPTIMADE APIs via Python.
More information about OPTIMADE can be found at their website, www.optimade.org, as well as the organization's GitHub page, github.com/Materials-Consortia. The OPTIMADE Python tools2 will be used to effectively handle and parse responses from an OPTIMADE REST API, the source code can be found on GitHub at github.com/Materials-Consortia/optimade-python-tools.
OntoTrans has developed the application-independent interfaces which aim to connect existing external resources to the OntoTrans OTE-Environment. The specific objective is to provide interfaces between the ongoing European Materials Modelling Marketplace EMMM initiatives (MarketPlace and VIMMP), and the OTE components. In the case of MarketPlace, the connection to the OTE Environment is based on OSP Core technology. For VIMMP, the connection is achieved by accessing the VIMMP-service via its REST (Representational State Transfer) web-technology and implementing a DataResource plugin for the OntoTRANS core components. As major outcome of this work, the VIMMP Plugin Interface has been released on GitLab.
OntoTrans has worked on the implementation of a plugin for the OTE-API, in order to interface the OSP (open simulation platform)-core facilitated by SimPhoNy, which is a semantic interoperability framework written in Python. One of the major applications of SimPhoNy is the MarketPlace, which is offering the opportunity to model material properties with open-source software and to interconnect those applications by the means of knowledge graphs.
The implementation is based on the structure of pipelines orchestrating the developed microservices, which can create CUDS-objects (Common Universial Data Structure) for the semantically based third-party tool interaction in the OTE (Open Translation Environment).
This SimPhoNy-plugin for the OTE-API is able to create CUDS-objects from a specific DLite Entity, to apply an ontological mapping between them, to send the CUDS to any remote OSP-server through a generic client and to retrieve the result in the form of CUDS back from the server, once the simulation is finished.
The DLite Entity has to be written specifically for any use-case, which is featuring individual properties and dimensions. The same also applies for the ontological mapping between DLite and the ontology to which the CUDS is related, since they have to be done by the hands of an ontologist, whom is aware of EMMO and the representation in the models of both technologies. Nevertheless, the semantic mapping is done only once either in the definition of the CUDS or the Entity mapping. The OSP-client in the plugin can be configured generically to any external OSP-server, which is exposing an individual REST API and based on SimPhoNy.
Overall, the user is able to generate its own data model with individual properties, to describe them ontologically, to use it as an input for any externally running simulation service and generate new properties as output from this service.
OntoTrans works on the implementation of a generic CMCL MoDS interface in order to integrate it with the OTE platform. To support wider exploitation, this interface is implemented via the SimPhoNy-OSP, which will make it possible to use MoDS from any SimPhoNy-based OSP as well as via the MarketPlace platform. Integration of this interface into the OntoTrans platform (which uses OTEAPI internally) is achieved by combining it with the CUDS-OTEAPI interface.