In my previous blog post, I explained the concept of headless web and how semantic annotation of content and services is crucial in order to conduct certain tasks like e-commerce on this new layer of the web. Annotation of services has an accumulated literature of almost 20 years now. In this blog post, I'll dive into this vast literature to identify lessons learned and draw my future directions. The first efforts on semantic web service were targeting mostly SOAP services, which was focused on providing the means for defining functional, non-functional and behavioural properties of web services as well as the grounding of the service for invocation. Moreover, a few efforts were focused on the execution of services, including aspects like mediation of data and processes.

One of the prominent works in this field is OWL-S [Martin et al., 2007]. It uses OWL (Web Ontology Language) as a base for a semantic web service ontology. It consists of three main components, namely the Service Profile, Process Model and Service Grounding. These components allowed service providers to describe functional, behavioural and non-functional properties of their services and methods of invocation. Similarly, SWSF [Battle et. al., 2005] builds on top of OWL- S and used First Order Logic (FOL) for process modelling. Web Service Modelling Framework (WSMF) [Fensel et al., 2002] offers a full-fledged  decoupled approach for automating the whole lifecycle of web service consumption. It consists of a conceptual model, a modelling ontology WSMO, a structured set of languages WSML and an execution environment WSMX [Roman, 2006]. Aforementioned approaches are also considered as "heavyweight" from two perspectives, (a) semantics and (b) supported protocol. From the semantics point of view, these approaches are very strong and mostly use well defined logical formalisms. This can make it challenging for service providers to describe their services correctly. The second point is that their application is limited to SOAP web services. Lightweight approaches with limited expressivity but lower learning curve have been proposed. Such approaches are mainly used for annotation of RESTful services. The definition of lightweight in this context is that lightweight services, like RESTful services, work directly on HTTP protocol and can support various lightweight data formats without needing any mechanisms like message enveloping [Garriga et. al., 2016]. The initial development in the lightweight semantic web services was naturally influenced by the heavyweight approaches. An example for such an approach can be the WSMO-Lite ontology [Vitvar, 2007] with MicroWSMO format [Maleshkova and Kopecky, 2009]. Unfortunately for many years, none of the aforementioned approaches found widespread industrial usage. The main reason for the weak adoption is the chicken-egg problem, that is, there is no interest in application development since there are no annotated web services and there is no annotation effort since there is no application [Lanthaler and Gutl, 2011].

In the last five years, a movement towards structured description of Web APIs has gained traction. Several formats like OpenAPI have emerged the standardization of Web API documentation. These formats layed a base for semantic annotation and re-ignited the work on semantic web services. An attempt to utilize the popular OpenAPI specification is SmartAPI [Dastgheib et. al., 2017], that enriches the OpenAPI specification with mechanisms for type annotation. Another recent effort for semantic description of RESTful services is described in [Lanthaler and Gütl, 2013]. It proposes a resource-oriented approach rather than an operation-oriented one. A simple vocabulary called Hydra enables the semantic enrichment of hypermedia-driven APIs, using JSON-LD as a data format. This eases the adoption by web service developers. The development of Hydra contributed to schema.org actions vocabulary, which can be used for defining certain actions on entities described with schema.org. In 2014, the vocabulary was extended with types and properties for describing actions. The development of schema.org and schema.org actions create a great opportunity for us since it helps to overcome the aforementioned chicken-egg problem. The annotations are already there, mainly due to motivation for semantic search engine optimization.  By using schema.org and schema.org actions for describing the services as potential action on entities, we can automate the e-commerce processes through semantically annotated RESTful services and data, thus make them visible to new channels on the web.

A detailed comparison of schema.org Actions, Hydra and SmartAPI can be found here. These lightweight approaches are quite promising, however they may be "too lightweight" for description of services probably, especially machine understandable description of functionality. SmartAPI has a very limited expressivity, while Hydra focuses on hypermedia and lacks support for non-functional properties. Schema.org actions is also too broad and lacks formal semantics. In the next step, I will complete the enrichment and restriction of schema.org Actions for Web API annotations.