Home | Legals | Sitemap | KIT

Service Semantics

Summary
The chapter looks at howto enrich the description of cloud serviceswith 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 chapterdelves into semantic description and explains the development of a Web API build using the REST paradigm to access cloud services pragmatically.

 

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 163.

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 170) between the patterns in service and service template descriptions be useful?