http://www.diva-portal.org

Preprint

This is the submitted version of a paper presented at the 3rd International Conference onComplexity, Future Information Systems and Risk (COMPLEXIS 2018).

Citation for the original published paper:

Peng, C., Bai, G. (2018)Using Tag based Semantic Annotation to Empower Client and REST Service InteractionIn: Proceedings of the 3rd International Conference on Complexity, FutureInformation Systems and Risk - Volume 1: COMPLEXIS (pp. 64-71).https://doi.org/10.5220/0006682500640071

N.B. When citing this work, cite the original published paper.

Permanent link to this version:http://urn.kb.se/resolve?urn=urn:nbn:se:bth-16087

Using Tag based Semantic Annotation to empower Client and RESTService Interaction

Cong Peng, Guohua BaiDepartment of Creative Technologies, Blekinge Institute of Technology, Karlskrona, Sweden

{peng.cong, guohua.bai}@bth.se

Keywords: Web Service Description, Semantic Annotation, REST, OpenAPI, Service Discovery, Semantic Web Services.

Abstract: The utilization of Web services is becoming a human labor consuming work as the rapid growth of Web. Thesemantic annotated service description can support more automatic ways on tasks such as service discovery,invocation and composition. But the adoption of existed Semantic Web Services solutions is hindering by theiroverly complexity and high expertise demand. In this paper we propose a highly lightweight and non-intrusivemethod to enrich the REST Web service resources with semantic annotations to support a more autonomousWeb service utilization and generic client service interaction. It is achieved by turning the service descriptioninto a semantic resource graph represented in RDF, with the added tag based semantic annotation and a smallvocabulary. The method is implemented with the popular OpenAPI service description format, and illustratedby a simple use case example.

1 INTRODUCTION

The Web is growing exceedingly, either for hu-man or for machines (Web APIs). It is, on the onehand, bringing an imaginative utilization of the ser-vices on the Web. On the other hand, it also bringsabout a problem that the utilization of Web services isbecoming a tediously repetitive work, such as searchfor services required, read documents to know howto invoke, and program similar clients to utilize ser-vices. Those works currently are more of humanlabor-centered works other than intelligence-centeredworks, which they are supposed to be.

For enabling a more autonomous usage of Webservices, it requires the client to have a certain levelof capabilities for interpreting the resources, such asthe understanding of what the resources are and thepossible actions to the resources. And it should alsoreduce coupling between client and service. There-fore, a machine understandable service description isimportant to facilitate a more autonomous Web ser-vice utilization from discovery, invocation to compo-sition.

However, there are very few semantic service de-scriptions available for the current Web services. Thereasons are multi-fold. The existed semantic ser-vice description standards are lacking links to the ac-tual Web service development technology stack. Itrequires extensive manual work to annotate or even

recreate the descriptions of existed Web services. Be-sides, the attempt to achieve fully semantic under-standable at once made those solutions (Kopeckýet al., 2007; Vitvar et al., 2008) complicated andhighly expertise requisite, which caused the reluctantof application.

In this paper, we propose a method called Sem-REST (Semantic RESource Tagging) to add semanticannotations to REST service description in a simplemanner to make the client service interaction moregeneric and autonomous. To mitigate the semapho-bia (Lanthaler and Gütl, 2011), our approach aimsto avoid much knowledge requirement on Seman-tic Web by adding tag based semantic annotationsto the service description, which will be presentedwith the widely used OpenAPI specification1 in anon-intrusive way. An example case is presented todemonstrate how this approach could work.

2 RELATED WORK ANDPROBLEM ANALYSIS

There have been extensive works done on bothsyntactic description and semantic description to Webservices. Here we only discuss those works that have

1https://swagger.io/specification/

strong influence and are considered most relevant tothe work in this paper.

The Semantic Annotations for WSDL and XMLSchema (SAWSDL) aims to add semantic annotationsto a WSDL (Web Services Description Language)document’s input/output message, interfaces and op-erations (Kopecký et al., 2007). An annotation mech-anism is also defined in SAWSDL to specify the datamappting between XML Schema types and an ontol-ogy. SAWSDL is regarded as a lightweight approachto annotate Web services described in WSDL, andrecommended by the World Wide Web Consortium(W3C) in 2007.

As SAWSDL only provides a way to attach se-mantic annotation in WSDL documents but withoutthe specification and standardization of the concreteservice semantics, WSMO-Lite was then proposed tomodel service semantics within the SAWSDL frame-work (Roman et al., 2015). WSMO-Lite is a serviceontology inspired by the WSMO (Web Service Mod-eling Ontology) ontology that uses SAWSDL as an-notation mechanism. It defines a a lightweight setof semantic service descriptions in RDFS (ResourceDescription Framework Schema) to annotate WSDLelements (Vitvar et al., 2008). WSMO is a top-downconceptual model for semantic Web services, whereasthe WSMO-Lite is a bottom-up model to provide alightweight ontology (Dieter Fensel et al., 2010).

In addition, in order to combine the commonRESTful Web services and WSDL-based servicesinto one semantic Web service framework, Romanet al. added hRESTS (HTML format for describingRESTful Services) and MicroWSMO, the two HTMLmicroformats mirror WSDL and SAWSDL, to worktogether with WSMO-Lite (Roman et al., 2015). Inwhich the WSDL and hRESTS work as the servicedescription layer, SAWSDL and MicroWSMO workas the semantic annotation layer points to conceptsdefined in WSMO-Lite.

RESTdesc is RESTful Web services semantic de-scription method with an emphasis on hypermediaAPIs. It describes service’s request preconditions,postconditions and quantifiers in RDF/Notation3 toenable a more automatic service composition (Ver-borgh et al., 2011).

The Hydra framework is a set of technologies triesto make semantic enriched Hypermedia API for Webservices to enable generic clients to consume services2. It is based on the Hydra Core Vocabulary, which isa lightweight vocabulary that defines some fundamen-tal concepts commonly used by Web APIs (Lanthalerand Guetl, 2013).

These solutions enabled the semantic annotations

2http://www.hydra-cg.com

to service descriptions, but they suffer a problem thatdenoted by Lanthaler et al. as Semaphobia (Lanthalerand Gütl, 2011). It requires too much knowledge onSemantic Web to annotate with these solutions, whichcauses the reluctant of application.

Another problem with these solutions is user un-friendly. Though the semantic service description ismeant to be understood by machines, it requires hu-man to create, with handy support tools and humanreadable formats. This is why the description stan-dards like OpenAPI Specification, API Blueprint andRESTful API Modeling Language (RAML) are be-coming popular these years. OpenAPI Specification(widely known as Swagger) is a definition standardproposed by Open API Initiative to describe RESTfulWeb APIs 3. OpenAPI is the mostly used syntacticdescription format currently, thanks to its easy to useeditor and multiple languages supported code genera-tion tools.

However, due to lack of machine understand-able semantics, these syntactic API descriptions arestill inefficient for service consumers to discover thespecific resources within the service in a more au-tonomous manner with a generic client. The workdone by Lucky et al. presented an approach to addsemantic annotation to the response data schema inan OpenAPI description (Lucky et al., 2016). How-ever, it did not mention how can the service client beimproved by the semantic annotation to a more auto-matic way. And it is more an approach to empowerstatic service composition.

In this paper we try to use a tag based approach toadd semantic annotation to the popular and easy to useOpenAPI Specification, to achieve a more generic andautonomous client service interaction in a extremelysimple manner, at the same time take advantage of hu-man readable description format and supporting tools,and keep its simple to start, well-integrated to theexisting web service work/development flow, easilyachievable with minimal intrusion, to overcome theSemaphobia.

3 SEMANTIC RESOURCETAGGING WITH OPENAPI

3.1 Semantic Tag Annotated OpenAPI

As the mostly used API description standard with atooling ecosystem for both API developing and con-suming, we firstly implement the SemREST with the

3https://swagger.io

OpenAPI Specification. Here in Listing 1 is an exam-ple OpenAPI description fraction of the activities re-source in YAML format (which is a path object in theOpenAPI description) from Fitbit service API whenthe time this paper is writing, we modified a little forbrevity. Fitbit is a health and fitness service that offerswearable devices to track activity data and hosts Webservice to provide access to data4. And this Fitbit ser-vice description will be used as an example throughout this paper.

paths:

# Resource1-2

/1/user/-/activities/calories/date/{base-date}/ c{end-date}.json:↪→

get:

summary: Get Activity Time Series

description: Returns time series data for activities

calories resource.↪→parameters:

- name: base-date

in: path

description: The range start date.

- name: end-date

in: path

description: The end date of the range.

responses:

200:

description: A successful request.

schema:

$ref: '#/definitions/CaloriesTS'

Listing 1: Service Description Fraction of a Fitbit Resource

As analyzed in the previous section, the currentOpenAPI service description lacks machine under-standable semantics that can provide the meaning ofwhat the resource represents. So we propose to addtag based annotation to the resource. For the sake ofnot violating the standard OpenAPI specification, thesemantic tag annotation will be added through speci-fication’s built-in optional field, tags. A list of tags toeach operation object in OpenAPI is one kind of ad-ditional metadata, it is for the similar purpose as oursemantic tag.

A semantic tag comprises 2 parts, which are a pre-fix and a suffix joint by a colon. The prefix is anabbreviation of the used open vocabulary’s Interna-tionalized Resource Identifier (IRI) (M. Duerst andM. Suignard. IETF, 2005), the suffix is the term inthe used vocabulary to indicate the semantic meaning,which is case sensitive aligned to those vocabularies.The two parts as a whole is equivalent to the IRI ofthe term. This way of expressing semantic tag follows

4https://www.fitbit.com

paths:

# Resource1-2

/1/user/-/activities/calories/date/{base-date}/ c{end-date}.json:↪→

get:

summary: Get Activity Time Series

description: Returns time series data in the

specified range for a given resource.↪→tags:

- schema:calories

- schema:activities

- schema:ConsumeAction

parameters:

...

responses:

...

Listing 2: Annotated Service Description Fraction of a Fit-bit Resource

tags:

- name: schema

description: the schema.org vocab

externalDocs:

url: http://schema.org

description: uri of the schema.org vocab

Listing 3: Used Vocabulary Stated as OpenAPI Tags Object

the abbreviation mechanism of OWL (Web OntologyLanguage) (W3C, 2012).

The Listing 2 shows the semantic tag annotatedversion of the resource shown in Listing 1. The onlydifference, which is highlighted, is the additional tagslist for a resource’s description. As in the OpenAPIspecification, all the used tags could be declared ina tags object under the OpenAPI root object, so asthese semantic tags. The second additional informa-tion will be added to the plain OpenAPI description isthe IRI of each tag. The IRIs will be indicated by theurl field of each tag object’s externalDocs objectunder the root tags object. But for the simplicity, wecan just state the vocabularies used in the root tagsobject (as shown in Listing 3), which is compatible.

For serving the annotated service description tothe client, an OPTIONS method under the service’sroot path / will be added to each service to respondthe service description (as shown in Listing 4). Asa method for describing the communication optionsfor a target resource in HTTP/1.1 specification (R.Fielding, J. Gettys, J. Mogul et al., 1999), it makesOPTIONS method a good way for discovering relatedresources for the target resource (Steiner and Alger-missen, 2011). Since a service description containsall the resources, which can be regarded as all the re-

paths:

# Resource1-1

/:

options:

summary: Returns service description

produces:

- application/json

- application/ld+json

responses:

...

Listing 4: OPTIONS Method of Root Resource for ServingAnnotated Service Description

lated resources to the root resource, it is natural to usethe OPTIONS method to retrieve the service descrip-tion, as the same in (Lucky et al., 2016).

When the annotations are added, now we can gen-erate the semantic description of the resources to RDFbased on it and together with the OpenAPI model anda small SemREST mapping vocabulary, which sim-ply contains some mapping entities to be expressed inRDF. Table 1 only lists the entities those are neces-sary to generate the resource graph, a more completevocabulary can refer to the work done by Musyaffa etal. (Musyaffa et al., 2016).

The generated RDF depicts the resource in the ser-vice is presented Figure 1 as a graph. To be notedthat in Figure 1, the resource IRI is manually replacedby a human readable name for readability. The re-source IRI in actual fact is identified by calculatingMD5 hash of the resource’s OpenAPI description pathstring. With the semantic tags indicating what the re-source represents, now we can use the semantic tagsto enable service client for the discovery of requiredresources in the service by semantic inference. Forexample in the case of different vocabularies are usedamong different services and client but indicating thesame or similar entity, the client can infer all the re-sources annotated in different different vocabularieswith the help of a simple ontology.

3.2 SemREST Framework

Since the server cannot predict what the client willrequire for the next step, so many computations ofresource discovery will be done on the client side (re-source URL query and inferring). Although it can beprocessed also on the service or third party serviceregistry for different purposes, we only demonstratethe client side resource discovery in this paper.

The architecture of framework is shown in Fig-ure 2, include the extended components to the officialOpenAPI framework, the server side of service, andthe client side with a semantic module. As we propose

Figure 1: Resource Graph of a Fitbit Resource

to add tag based semantic annotations to the OpenAPIservice description, here we explain how the processis for generating the semantic annotated service de-scription.

Figure 2: Architecture of SemREST

When the service developer completed the normalOpenAPI description, the semantic tag annotationscould be added. The annotated OpenAPI service de-scription could be registered to third party service reg-istries for enhanced semantic service discovery. Thenthe annotated OpenAPI description will be served atthe service’s root path via OPTIONS method in certaindata exchange format, either JSON or YAML.

The client contains an additional semantic mod-ule, which is responsible for parsing service descrip-tion into resource graph, and inferring for required re-sources. Firstly the the client need to register whatservices it connects to by setting the service root

Table 1: Named Entities Used in SemREST

Name/Abbreviation Type Descriptionsemrest:tag Class A semantic tag that annotates a resourcesemrest:method Class A HTTP method that a resource supportssemrest:options Class A HTTP OPTIONS method, a subclass of semrest:methodsemrest:get Class A HTTP GET method, a subclass of semrest:methodsemrest:paths Class The paths of all resources in a OpenAPI description filesemrest:template Class An URL of a path, string value of a path objectsemrest:hasResource Property To state a description of service contains which resourcessemrest:hasTag Property To state the annotated semantic tags of a resourcesemrest:hasMethod Property To state the supported HTTP method of a resource

URL. The registration of services is a one time job,and in the work of this stage, we leave aside the secu-rity and authorization, but it is achievable with certainOpenAPI objects. The client can retrieve the anno-tated service description under the services’ root pathvia OPTIONS method after registration meanwhile set-ting required resources by semantic tags.

For generating a semantic resource graph, the re-source graph generator component in the semanticmodule will parse the annotated description togetherwith the small SemREST vocabulary into a RDF doc-ument, which could be in any RDF compatible formatsuch as RDF/XML, JSON-LD or Turtle. The gener-ated resource graph, it can be used multiple times andcan be renewed when the service description changedby retrieving a new version. When the semantic re-source graph is generated, the semantic inferrer com-ponent can then query in the graph which resourcesto request by the set semantic tags. The semanticmodule of client can suggest which tags to use un-der the same vocabulary as the services used, whichcan reduce some inference work. When the requiredresources are found, the metadata (URLs, parameters,etc.) will be passed to the request module to send therequests to the services.

4 FEASIBILITY OF SEMREST

4.1 Tooling and Implementation

Our current proof-of-concept prototype is a very sim-ple implementation supported by openly availabletools. The creation of the normal OpenAPI servicedescription is completed by the official Swagger on-line editor5 in YAML format. For the semantic tag an-notation, the vocabularies are searched via the LinkedOpen Vocabularies6, and the adding of semantic tags

5https://swagger.io/swagger-editor/6http://lov.okfn.org/dataset/lov/

is completed by Swagger editor as well. As the pro-cess of creation and editing of service description isonly a text editing work, it could be achieved by anytext editor.

We implemented both the imitation services andthe client in Python. The imitation services, whichimplemented with Flask framework7, imitate how theactual service receive requests and return responseswith fake data, and only include the resources thatappear in the example case in the next section. Theclient is comprised by 2 modules, a REST service re-quester and a semantic module. In our prototype, wesimply integratively use the Python client generatedby the Swagger CodeGen framework to handle theservice requests. The semantic module is built uponthe RDFLib8 for a quicker implementation. Other-wise, the Apache Jena9 is a more powerful SemanticWeb framework that enables more functionalities likeinference API. Currently, we use the JSON format ofthe annotated description file in the prototype, sinceit is easier to transfer the description into a JSON-LD document (Manu Sporny et al., 2014), which isa concrete RDF syntax, by add the vocabularies as acontext object.

4.2 Example Case

Here we will use an example case to demonstratehow the proposed SemREST can achieve a more au-tonomous and generic client service interaction in asimple and non-intrusive way. The example caseinvolves the forementioned Fitbit service and Hu-man API service. Human API is a health data plat-form that aggregates clinical data from comprehen-sive sources such as Electronic Health Record, healthdevices and wearable devices, and makes data acces-sible as RESTful API10.

7http://flask.pocoo.org/8http://rdflib.readthedocs.io9https://jena.apache.org/

10https://www.humanapi.co/

The scenario is set as, a service consumer Aliceuses Fitbit service to record her activity data includecalories consumption, and uses a blood pressure mon-itor that the data of which can be consumed from Hu-man API. Alice wants her health agent client with asemantic module can gather her data from the 2 ser-vices to have a comprehensive view of the health sta-tus.

Although both Fitbit and Human API provide WebAPIs with documentations, the data are stored andneed to be retrieved separately, Alice still need to readthe two documents and develop two different clientprograms in order to gather her data from the two ser-vices. If both Fitbit and Human API can provide theirservice description with semantic tag annotations asthe approach proposed in this paper, then it will re-duce much repeated works. We will present how theprocess will be for the two service providers and Al-ice’s client.

Since it involves the service providers to servetheir services with description, and clients to interactwith the services, so this example case consists of 2stage processes that are Semantic Service DescriptionGeneration and Serving, and Client Service Interac-tion.

4.2.1 Description Generation and Serving

Firstly we will create the Fitbit SemREST service de-scription. Besides the activities’ calories consump-tion resource shown in Section 3.1, the resource ofthe foods’ calories intake data is also added to thisexample. Since the original OpenAPI service descrip-tion of Fitbit is already provided for API consumer (asmany other web service providers do), here we can di-rectly add semantic tag annotations to the resources.

As we described in Section 3.1, the resource1-2 is annotated from Listing 1 into Listing 2. Theonly place we changed is the tags field. We addtag schema:calories11 to resource1-2. Consider thecalories data for activities can be regarded as consum-ing, so we can add schema:ConsumeAction12 to re-source 1-2. For the resource of the foods’ calories in-take data, which we call it resource1-3, the annotatedservice description is shown in Listing 5. We addtag schema:calories to it as well, and obviously tagschema:FoodEvent13 can be added to resource 1-3.Combine these 2 annotated resources with Listing 3,in which described the used schema vocabulary statedin tags object, and Listing 4, in which described theroot resource path for serving service description, we

11http://schema.org/calories12http://schema.org/ConsumeAction13http://schema.org/FoodEvent

paths:

# Resource 1-3

/1/user/-/foods/log/caloriesIn/date/{baseDate}/{endDate}:

get:

tags:

- schema:calories

- schema:FoodEvent

responses:

...

Listing 5: Annotated Service Description Fraction of a Fit-bit Resource

tags:

- name: m3lite

description: The M3-lite Taxonomy

externalDocs:

url: http://purl.org/iot/vocab/m3-lite#

description: uri of the M3-lite Taxonomy

paths:

# Resource2-1

/:

options:

summary: Returns service description

produces:

- application/json

- application/ld+json

responses:

...

# Resource 2-2

/v1/human/blood_pressure:

get:

summary: Returns the latest blood pressure reading

description: The latest blood pressure reading

tags:

- m3lite:BloodPressure

...

Listing 6: Annotated Service Description of Human API’sRoot and BloodPressure Resource

get the annotated SemREST description fraction to beused in this example case.

Now we will create the Human API SemRESTservice description. Since Human API has not pro-vided API description in OpenAPI specification yet,so we need to compose its OpenAPI description im-itated from their API documentation first. The imi-tated OpenAPI description is shown in Listing 6, inwhich the blood_pressure resource 2-2 is given thesemantic tag m3lite:BloodPressure14 under TheM3-lite Taxonomy (Gyrard et al., 2016). As the samein Fitbit description, the service description is servedunder the path / via OPTIONS method.

14http://purl.org/iot/vocab/m3-lite#BloodPressure

Figure 3: Interaction Sequence of the Example Case

4.2.2 Resources Look up and Request

Now we have the two services serving their re-sources and service descriptions with semantic tagannotation, Alice’s health agent client can startto work. Alice will firstly tell her client wherethe services are serving by setting the root URLsof the 2 services, and then set what resourcesshe want to retrieve by setting semantic tagsschema:calories and schema:ConsumeAction tothe calories data she wants for her activities, and tagm3lite:BloodPressure for her blood pressure datashe wants. Then the client starts to interact with theservices. It will firstly send OPTIONS request to thetwo services’ root path to get their service descrip-tions. Figure 3 depicts the client service interactionprocess of the example case.

Once the client get the service descriptions, thesemantic module parses all the resources into a com-bined resource graph in RDF, which is shown in Fig-ure 4 (the graph is simplified for brevity). The seman-tic module can then reason about required resourcesby the semantic tags set by Alice. So here the resourcetemplates of resource 1-2 and resource 2-2 are foundby schema:calories + schema:ConsumeActionand m3lite:BloodPressure, respectively. Each re-source’s path, parameters and other metadata in itsOpenAPI description will then be determined by re-source templates and passed to the request module.For the resource 1-1, the client requires baseDate andendDate as parameters to retrieve the representationform Fitbit service. With all the metadata and param-eters of a service request being available, the actualHTTP request could be achieved in various ways. Inthis example, we use the automatically generated ser-vice client by the Swagger CodeGen framework to

send the requests.

After Alice’s health agent client get the caloriesof activities data from Fitbit and blood pressure datafrom Human API, it can then utilize them more com-prehensively, simply like a graph to present the trendand correlation between calories consumption andblood pressure.

Figure 4: Combined Resource Graph of 2 Services

The interactions of client between Fitbit serviceand HumanAPI are achieved by the same client thatsupported by the tag based semantic annotation in avery simple way, without breaking the normal webservice interaction process.

5 CONCLUSION

In this paper, we proposed SemREST, an ex-tremely lightweight and non-intrusive method, to en-able semantics to resources of REST Web services.With this initial work, we identify a simple and fullycompatible way of adding tag based semantic annota-tions to the widely used OpenAPI service descriptionformat. The small SemREST vocabulary we speci-fied together with the tag annotation mechanism pro-vide a bridge from the syntactic OpenAPI descriptionto the semantic resource graph, which enables a moregeneric and automatic client service interaction thatcan reduce many repeated human labor consumingwork. The method we proposed also provide the po-tential for service discovery and composition, as theresources of the annotated services are semanticallylinked. The semantic resource graph could be gen-erated and host on service side or third party serviceregistry for the clients to query required resources.

However, in this initial work, we only realized theGET method for resources to make it as a data ag-gregation agent for different sources. And we onlyshown some naive cases to demonstrate this method,it leaves the authorization and security issues out forthe sake of briefness.

For the future work, we plan to validate thismethod with more different services and realize otherHTTP methods like POST and PUT, and evaluatethe usability by performing survey with Web serviceproviders and consumers. For the invoking and com-position of services, it could be achieved in 2 differ-ence approaches, one is the code automatic generationlike OpenAPI framework provided, the other is thesemantic way like what Hydra (Lanthaler and Guetl,2013) is trying to do. We will try to explore how ourmethod can integrate with approach like Hydra.

REFERENCES

Dieter Fensel, Florian Fischer, Jacek Kopecký, RetoKrummenacher, Dave Lambert, and TomasVitvar (2010). WSMO-Lite: Lightweight Se-mantic Descriptions for Services on the Web.https://www.w3.org/Submission/WSMO-Lite/. Ac-cessed: 2017-09-19.

Gyrard, A., Gomez, D., Bajaj, G., Lanza, J., Sanchez,L., Agarwal, R., and Elsaleh, T. (2016). TheM3-lite Taxonomy. http://ontology.fiesta-iot.eu/ontologyDocs/fiesta-iot/doc. Accessed:2017-09-19.

Kopecký, J., Vitvar, T., Bournez, C., and Farrell, J. (2007).SAWSDL: Semantic Annotations for WSDL andXML Schema. IEEE Internet Computing, 11(6):60–67.

Lanthaler, M. and Guetl, C. (2013). Hydra: A Vocabu-lary for Hypermedia-driven Web APls. In Proceed-ings of the 6th Workshop on Linked Data on the Web(LDOW2013) at the 22nd International World WideWeb Conference. CEUR.

Lanthaler, M. and Gütl, C. (2011). A semantic descriptionlanguage for RESTful Data Services to combat Sema-phobia. In 5th IEEE International Conference on Dig-ital Ecosystems and Technologies (IEEE DEST 2011),pages 47–53.

Lucky, M. N., Cremaschi, M., Lodigiani, B., Meno-lascina, A., and De Paoli, F. (2016). EnrichingAPI Descriptions by Adding API Profiles ThroughSemantic Annotation. In International Confer-ence on Service-Oriented Computing, pages 780–794.Springer, Cham.

M. Duerst and M. Suignard. IETF (2005). RFC3987: Internationalized Resource Identifiers (IRIs).http://www.ietf.org/rfc/rfc3987.txt. Accessed: 2017-08-15.

Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lan-thaler, and Niklas Lindström (2014). JSON-LD 1.0.https://www.w3.org/TR/json-ld/. Accessed: 2017-08-08.

Musyaffa, F. A., Halilaj, L., Siebes, R., Orlandi, F., andAuer, S. (2016). Minimally Invasive Semantificationof Light Weight Service Descriptions. In 2016 IEEEInternational Conference on Web Services (ICWS),pages 672–677. IEEE.

R. Fielding, J. Gettys, J. Mogul, H. F., L. Masinter, P. Leach,and Berners-Lee, T. (1999). Hypertext Transfer Pro-tocol – HTTP/1.1. http://tools.ietf.org/html/rfc2616.

Roman, D., Kopecký, J., Vitvar, T., Domingue, J., andFensel, D. (2015). WSMO-Lite and hRESTS:Lightweight semantic annotations for Web servicesand RESTful APIs. Web Semantics: Science, Servicesand Agents on the World Wide Web, 31:39–58.

Steiner, T. and Algermissen, J. (2011). Fulfilling the hy-permedia constraint via HTTP OPTIONS, the HTTPvocabulary in RDF, and link headers. In Proceedingsof the Second International Workshop on RESTful De-sign - WS-REST ’11, page 11, New York, New York,USA. ACM Press.

Verborgh, R., Steiner, T., Van Deursen, D., De Roo, J.,de Walle, R., and Gabarró Vallés, J. (2011). Descrip-tion and Interaction of RESTful Services for Auto-matic Discovery and Execution. Proceedings of theFTRA 2011 International Workshop on Advanced Fu-ture Multimedia Services.

Vitvar, T., Kopecký, J., Viskova, J., and Fensel, D. (2008).WSMO-lite annotations for web services. In ESWC2008: The Semantic Web: Research and Applications,pages 674–689, Berlin, Heidelberg. Springer BerlinHeidelberg.

W3C (2012). OWL 2 Web Ontology Language StructuralSpecification and Functional-Style Syntax (SecondEdition). https://www.w3.org/TR/2012/REC-owl2-syntax-20121211/#IRIs. Accessed: 2017-09-08.