Service Semantics

Abstract

The chapter looks at how to enrich the description of cloud services with semantic knowledge. This enrichment is conducted using Linked USDL (Unified Service Description Language), a service description language built with semantic web technologies. Linked USDL provides a business and technical envelope to describe services’ general information and their Web API. This improves the search and contracting of services over the web. Using the LastFM cloud service as a starting point, the chapter delves into semantic description and explains the development of a Web API build using the REST paradigm to access cloud services pragmatically.

5.1 Review Section

Review Questions

• 1. What are the differences between interfaces and services? What is a Web API?

• 2. Why is a keyword-based search insufficient for the search for a services or an API?

• 3. What is the purpose of the operational perspective on services. Compare it to the technical perspective, which also includes a formal description of the operations.

• 4. Draw the RDF graph of the RDF document shown in Listing 5.13 on page 57.

• 5. Create a SPARQL query to retrieve the business and corresponding interaction roles of all the entities involved in an interaction from the RDF document given in Listing 5.13. The correctness of the query and the obtained results can be evaluated with existing tools such as Jena TDB or AllegroGraph.

• 6. Explain the concept of a collection resource?

• 7. Why does REST restrict the set of available interaction methods? Is this constraint too restrictive?

• 8. Which aspects of a service can be modeled in the business perspective of Linked USDL?

• 9. Name use cases in which structured information about the service provider can be useful.

• 10. What is the relationship between an interaction point and an operation in Linked USDL?

• 11. What is the main benefit of the use of hypermedia controls?

• 12. How is the state of a resource described? What kind of information is included?

• 13. Graph-patterns have been used to describe input and output data of an API. Is it possible to use RDF(S) descriptions instead?

• 14. In which cases can other relationships (than the ones introduced in Formulas 5.1–5.2 on page 65) between the patterns in service and service template descriptions be useful?

Project

The implementation of services is an extensive task. Besides traditional design, implementation, and testing of the software that already provides the service functionality, a number of further task have to be considered in order to effectively provide a functionality as a service. As this chapter conveyed, the interfaces provide access to resources and methods of the underlying software systems. Further, a formal, i.e., machine-readable and machine-interpretable, description of the provided service is a prerequisite for managing large services automatically.

The use of formal service descriptions increases the degree of automation that is necessary when a large set of service are managed. Different task of management may require that information about different perspectives on services. Due to the importance of expressive and formal service descriptions, the goal of this project is to practice, apply, and gain a more detailed understanding on service descriptions. Within this project, we will continue to use Linked USDL as a service description model in combination with the Semantic Web technologies.

• 1. Find a service that is publicly available in the Internet. The service should expose at least a few number of different resources and methods, which are provided by a public Web API. This API is described in semi-structured web pages that describe resources and methods in natural language.

• 2. Make yourself familiar with the involved resources and methods. Identify two non-trivial methods of the API that will be formally described in the subsequent steps.

• 3. At this stage, a vocabulary of the domain of intercourse is needed. Create an RDFS vocabulary describing the resources of chosen methods. The vocabulary can be sketched in form of an RDF graph drawn on paper. Alternatively, existing modeling tools like Protégé or a simple text editors can be used alike.

• 4. Furthermore, the Linked USDL service description model is used to create a description for this service and its chosen methods. A complete overview on Linked USDL can be obtained fromhttp://www.linked-usdl.org.

• 5. Create a Linked USDL description of the technical perspective of the service. This description should cover the methods and all the involved resources, like input and output parameters. Since Linked USDL service descriptions can be serialized to regular RDF documents, a plain text editor or any RDF modeling tool can be used. A dedicated Linked USDL editor is currently under development.

• 6. Extend this service description, such that the business and operative perspectives are added. The provider of the service describes legal terms, service quality, and other information related to these perspectives within web pages, which may contain large text blocks. The relevant information needs to be identified and expressed formally. The RDFS domain vocabulary can be extended accordingly, if required.

Within this project, it should become obvious how tedious it can be to deal with and to interpret natural language text descriptions of services. It is easy to imagine how difficult it can be to analyze, search, or invoke services from a large service repository. The need and the benefits of formal descriptions as well as the broad spectrum of perspectives gained by the use of Linked USDL were conveyed.

Key Terms

Web API :

The acronym API stands for application programming interface and enables applications to exchange data. A Web API is the web version of this interface. It is leveraging web technologies (e.g., URI, HTTP, HTML, JSON, and XML) to enable companies to make their data assets available to external developers.

Service Description :

A service description defines and characterizes the services offered to customers. It includes functional and non-functional characteristics (properties). Typically, services are described in natural language, but more modern approaches use semantic web technologies.

USDL :

The Unified Service Description Language (USDL) was the first comprehensive language to describe services using computer-understandable formats. It described aspects such as legal constraints, pricing models, service level, and interactions between customers and providers [27,37].

Linked USDL :

Linked USDL is a simpler version of USDL which was designed using Linked Data principles. It is more adequate to work on web environments since it uses solely web protocols and specifications, and it describes services semantically [28].

Semantic Web :

The Semantic Web is a technology stack originally developed by the W3C which enables people to share knowledge beyond the boundaries of websites. The specifications which are part of the stack, and include URI, RDF(S), OWL, and SPARQL, strive to turn unstructured data into computer-readable formats.

Linked Data :

Linked Data is a paradigm which applies the principles and technologies of the web to share and link data. It can be viewed as a pragmatic way of applying the technology stack provided by the Semantic Web to build worldwide networks of linked knowledge.

Turtle :

Turtle (Terse RDF Triple Language) is a serialization for capturing knowledge expressed using the Resource Description Framework (RDF). It is relatively simple to read/write when compared to other serializations, e.g., XML.

Further Reading

Jorge Cardoso and Amit Sheth.Semantic Web Services, Processes and Applications. Springer, 2006.

Rudi Studer, Stephan Grimm, and Andreas Abecker.Semantic Web Services: Concepts, Technologies, and Applications. Springer, 2010.

Leonard Richardson, Mike Amundsen, and Sam Ruby.RESTful Web APIs Paperback. O’Reilly Media, 2013.