Transforming OpenAPI Specification 3.0 documents into RDF-based semantic web services

Abstract

AbstractWeb services are provided with documents that at the very least specify the endpoint, input parameters, and output or response of each operation to expose their capabilities. This should be considered through an understandable format for humans and/or machines. In the Representational State Transfer (REST) architectural style, the OpenAPI Specification (OAS) is used as a reference to create web service descriptions. However, it only supports syntactic interoperability, leading to the incapability of supporting the automated selection process. To overcome this, OAS documents must be enhanced by including semantics to each resource to provide “understandable” services. Therefore, this study aims to develop a system capable of transforming resources in OAS documents into RDF-based semantic web services. To begin, a relational database schema based on the OAS structure is created to store all objects in the OAS document. The published open-linked vocabulary was then used to create the ontology, which maps resources and their relationships on the RDF data model. To build RDF-based semantic web services, R2RML was used to generate the relational database model into triple RDF. The proposed system was also tested through prototyping and using a dataset of 106 OAS documents, which were downloaded from APIs.guru between 5–10 May 2021. The number of triple RDFs generated per document varied with resource rate. An OAS document generates 36 to 16,505 triple RDF in a dataset. The end product was a triple RDF knowledge base maintained by a graph management database. It is now possible to find service operations, input and output parameters, and service composition requirements utilizing the repository semantic web services using SPARQL. On the other hand, the use of relational databases to store OAS resources increased reuse efficiency by approximately 48%, owing to service developers designing interoperability between uniform parameter services, which were then used as input and output.