Open Research OnlineThe Open University’s repository of research publicationsand other research outputs

An Approach to Construct Dynamic Service Mashupsusing Lightweight SemanticsConference or Workshop ItemHow to cite:

Liu, Dong; Li, Ning; Pedrinaci, Carlos; Kopecky, Jacek; Maleshkova, Maria and Domingue, John (2011). AnApproach to Construct Dynamic Service Mashups using Lightweight Semantics. In: The 3rd International Workshopon Lightweight Integration on the Web (ComposableWeb 2011) at The 11th International Conference on WebEngineering (ICWE 2011), 20-24 Jun 2011, Paphos, Cyprus.

For guidance on citations see FAQs.

c© 2011 The Authors

Version: Accepted Manuscript

Copyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copyrightowners. For more information on Open Research Online’s data policy on reuse of materials please consult the policiespage.

oro.open.ac.uk

An Approach to Construct Dynamic ServiceMashups using Lightweight Semantics

Dong Liu, Ning Li, Carlos Pedrinaci, Jacek Kopecky, Maria Maleshkova, andJohn Domingue

Knowledge Media Institute, The Open UniversityWalton Hall, Milton Keynes, MK7 6AA, UK{d.liu,n.li,c.pedrinaci,j.kopecky,

m.maleshkova,j.b.domingue}@open.ac.uk

Abstract. Thousands of Web services have been available online, andmashups built upon them have been creating added value. However,mashups are mostly developed with a predefined set of services and com-ponents. The extensions to them always involve programming work. Fur-thermore, when a service is unavailable, it is challenging for mashups tosmoothly switch to an alternative that offers similar functionalities. Toaddress these problems, this paper presents a novel approach to enablemashups to select and invoke semantic Web services on the fly. To ex-tend a mashup with new semantic services, developers are only requiredto register and publish them as Linked Data. By refining the strategies ofservice selection, mashups can behave more adaptively and offer higherfault-tolerance.

Keywords: Mashup, Semantic Web Services, Service Selection, ServiceInvocation.

1 Introduction

More and more companies and organisations expose their core functionalities asSOAP or RESTful services on the Web, so that third-party developers can createnew Web applications atop of these services in a more agile way. Repositoriesand marketplaces such as ProgrammableWeb1, Seekda2 and Mashape3, havebeen established to collect and publish descriptions of Web services. On theother hand, mashups integrate data, services and contents available online intoa coherent application that creates new value [20]. Tools such as Yahoo Pipes4

and IBM Mashup Center5, have been available for assisting the development ofmashups.

1 http://www.programmableweb.com2 http://webservices.seekda.com3 http://www.mashape.com4 http://pipes.yahoo.com/5 http://www.ibm.com/software/info/mashup-center/

2 Dong Liu et al.

However, the mashups built with these tools are essentially static, i.e. de-pending upon a predefined set of APIs and components. This has an impacton the extendibility and fault-tolerance. Developers of a mashup have to workon the programming code, even if they just want to extend it with services orAPIs offering similar functionalities. For instance, there are a few companies nowoffering local business searching services, e.g. Scoot API6, Yahoo Local SearchAPI7, Yelp8 and CityGrid9. New local business searching services might alsocome to the market at some point. Combining new business searching servicesto an existing mashup requires both hard coding and re-deployment.

Online services might be unaccessible for reasons such as expiration of APIkeys, connection failures, request timeout, etc. End-users will suffer from thelong response time of the mashups built with these unaccessible services. Onepossible way to overcome this issue is to switch the mashups to other alternativeservices. For example, although most of the local business services cover differentregions of the world, they (e.g. Yelp and Yahoo Local Search) may have someoverlaps with each other. When one of them is off-line, the mashups can use theother one instead.

To address these issues, we propose a novel approach to build dynamicmashups using Web services with lightweight semantics. The UI componentsinteract with unified interfaces of each kind of services, rather than invokingthose services directly. iServe, together with its extensions, performs service se-lection and invocation behind those interfaces. The services to be invoked by themashups through iServe are controllable and determined at runtime. Therefore,mashups built following our approach are more flexible and robust.

The rest of the paper is organised as follows: Section 2 discuss principles re-lated to semantic services and mashups. Section 3 details the proposed approachto build dynamic service mashups. Section 4 summaries related work. Finally,Section 5 concludes this paper and highlights our future work.

2 Services, Mashups and Semantics

A Web service is a set of operations on resources, which are accessible online.Accordingly, there have emerged two types of Web services: operation-orientedservices (e.g. SOAP services) and resource-oriented services (e.g. RESTful ser-vices). Both SOAP and RESTful services can be exploited as reusable buildingblocks for new applications. Efforts made to integrate Web services are regardedas service composition [15]. Service composition is usually performed on thebusiness logic layer, and results in executable workflows or plans that fulfil cer-tain requirements of the new Web application. Mashup is an innovative way todevelop Web applications by syndicating contents, data and functionalities fromdistributed sources on the Web. Different from service composition, mashup can

6 http://www.scoot.co.uk/about-us/add-scoot/reference.html7 http://developer.yahoo.com/search/local/V3/localSearch.html8 http://www.yelp.com/developers/documentation/v2/search_api9 http://docs.citygridmedia.com/display/citygridv2/Places+API

Construct Dynamic Mashups 3

be carried out on layers ranging from data to presentation. Rather than enact-ing a predefined workflow, components of a mashup are more loose-coupled, andcan interact with end-users. In this paper, we focus on service mashups that areaim to bring them together mashups with easy-to-accomplish end-user servicecompositions [3].

Semantic technologies have been adopted to automate service annotation,discovery, composition and invocation [1]. Ontological models such as OWL-S [10] and WSMO [16] provide formal languages for semantically describing Webservices, whereas annotation-based approaches (e.g. SAWSDL [19], hRESTS [7])enable the creation of lightweight semantic Web services. We employ MinimalService Model (MSM)10 to capture the semantics of SOAP and RESTful ser-vices, which are essential for selection and invocation of hybrid services. InMSM, a Service is defined as a set of operations plus links to functional clas-sifications and non-functional properties. An Operation is an atomic unit tobe invoked, having properties like input messages, output messages, addresses,faults, etc. Instances of MessageContent are containers of the input and out-put messages exchanged during the invocation of services. A MessageContent

may comprise a hierarchy of MessagePart. Additionally, modelReference bor-rowed from SAWSDL enables the linking of service elements to semantic modelsvia URIs, while liftingSchemaMapping and loweringSchemaMapping are usedto specify data transformations from a syntactic representation to its semanticcounterpart and vice versa.

Dynamic Mashup

Web Service A Web Service B

iServeSPARQL Endpoint RESTful API

Fig. 1. Mashup model.

From all above, dynamic mashup is defined as a Web application implementedby selecting and invoking Web services described using MSM. Figure 1 showsthe conceptual model of dynamic mashup. By querying against iServe’s SPARQLendpoint, a dynamic mashup selects some relevant APIs, and then quests iServeto invoke them. Service invocation through iServe is always in a RESTful way,and some of the inputs might be from the Web of Data. Some of the key featuresof dynamic mashups are outlined as follows:

10 http://cms-wg.sti2.org/ns/minimal-service-model

4 Dong Liu et al.

– Dynamics Mashups can determine which services to invoke on the fly.– Transparency The technical details of service selection and invocation are

transparent for the UI components of a mashup.– Configurability Maintainers can easily control the behaviours of a mashup

just by revising the strategy of service selection, yet without programmingwork.

– Extendibility To integrate more services offering similar functionalities,developers only need to formally describe those services, and publish themon the Web.

– Robustness When a service is temporarily unavailable, a dynamic mashupcan smoothly switch to the alternatives.

3 Building Dynamic Mashups

In our previous work [13], we have presented iServe, a public registry for semanticservices. It can import service descriptions conforming to heterogeneous schemas,and publish them as Linked Data on the Web. iServe exposes a set of WebAPIs for manipulating the published service descriptions11, as well as for servicediscovery on higher level of abstraction12.

The proposed approach to build dynamic mashups centres upon iServe andits extensions for service invocation [8]. This section elaborates how to constructdynamic mashups by taking advantage of iServe’s capabilities of service discoveryand invocation, and also by following the steps listed below.

– Semantic Services Authoring This step includes 1) annotating servicedescriptions with concepts of the MSM and domain ontologies; 2) publishingthem as Linked Data via iServe.

– Specifying Strategies of Service Selection This step can be done byeither exploiting iServe’s built-in service discovery mechanisms, or writingSPARQL queries to be executed against the RDF dataset of iServe.

– Defining Lowering and Lifting Schema Mappings This step outcomesXSPARQL [2] queries for translating RDF triples into parameters used toinvoke services, and also for rewriting the invocation results as RDF state-ments.

– Merging Service Invocation Results This step deals with issues regard-ing to put together invocation results from different sources, e.g. eradicatingany duplicated items, sorting by specific properties, etc.

In order to demonstrate the workflow of building a dynamic mashup, anexample is given in this section, which visualises the local business search resultson a map (see Figure 2). Besides the Web APIs for local business searching

11 http://iserve.kmi.open.ac.uk/wiki/index.php/IServe_RESTful_API12 http://iserve.kmi.open.ac.uk/wiki/index.php/IServe_Higher_Level_

Discovery_API

Construct Dynamic Mashups 5

mentioned previously, the mashup also makes use of Google map API13 andGoogle Web Toolkit14.

Fig. 2. Screenshot of the example of dynamic mashup.

3.1 Semantic Services Authoring

Essentially, semantic services authoring is to add annotations to the originaldocuments of service descriptions, so as to make them more understandablefor machines. Tools such as SWEET and SOWER [9], have been developedto facilitate annotating both HTML and WSDL files. Although authors canarbitrarily annotate services descriptions, we argue that semantic services willbe easier to be discovered and invoked, if being annotated following principlesand patterns shown below.

– Service categories should be attached to services rather than operations ormessages. This can simplify service discovery based on functional classifica-tions.

– The addresses and types of HTTP methods, e.g. GET, POST, PUT, etc.,should be declared, otherwise operations will not be able to be invoked.

– Information related to groundings of input messages should be provided.– Lowering schema mappings must be associated with input messages. When

an input message has a hierarchical structure, lowering schemas are usuallyutilised to annotated message parts on the lowest level. Section 3.3 showshow this can help in the preparation for service invocation.

13 http://code.google.com/apis/maps/14 http://code.google.com/webtoolkit/

6 Dong Liu et al.

– In principal, lifting schema mappings are for output messages only.– In many cases, messages are annotated with concepts of domain ontologies,

while their sub-parts are annotated with properties of such concepts. Thiscan ensure the alignment of formal semantics of input/output messages andthe ontological knowledge. In addition, it also gives hints on writing andunderstanding the lifting and lowering schema mappings.

For instance, Listing 1 shows the aforementioned Scoot API described inRDF, using the vocabulary of MSM and several domain ontologies such as DB-pedia ontology15, Service Categories ontology16 and W3C WGS84 vocabulary17.service:Scoot a msm:Service;

msm:hasOperation operations:search;sawsdl:modelReference finder:InternetSearch .

operations:search a msm:Operation;msm:hasInput inputs:query , inputs:place ;msm:hasOutput outputs:result ;hrests:hasMethod "GET" ;hrests:hasAddress "http :// www.scoot.co.uk/api/find.php?format=xml&what={p1

}&lat={p2}&long={p3}" .inputs:query a msm:MessageContent;

sawsdl:modelReference rdf:Literal ;hrests:isGroundedIn "p1" .

inputs:place a msm:MessageContent;sawsdl:modelReference dbp -ont:Place ;msm:hasPart types:lat , types:lng .

outputs:result a msm:MessageContent;msm:hasPart types:result -item .

types:lat a msm:MessagePart;sawsdl:modelReference geo -pos:lat ;sawsdl:loweringSchemaMapping lowerings:lat ;hrests:isGroundedIn "p2" .

types:lng a msm:MessagePart;sawsdl:modelReference geo -pos:long ;sawsdl:loweringSchemaMapping lowerings:lng ;hrests:isGroundedIn "p3" .

types:result -item a msm:MessagePart;sawsdl:modelReference dbp -ont:Place ;sawsdl:liftingSchemaMapping liftings:result -item .

Listing 1. Description of Scoot API in RDF.

As depicted by Listing 1, Scoot API is assigned to the category of InternetSearch. It has one operation called “search”, which takes keywords and an in-stance of dbp-ont:Place as inputs, and returns a list of relevant local businessesalso as instances of dbp-ont:Place. Note that the input message inputs:placehas one model reference dbp-ont:Place and two sub-parts types:lat andtypes:lng. And, the model references of types:lat and types:lng are respec-tively geo-pos:lat and geo-pos:long, which are two properties of the conceptdbp-ont:Place.

3.2 Service Selection

This sub-section focuses on SPARQL-based service selection, which enables theon-the-fly refinement of the selection strategies. Listing 2 gives an example seek-

15 http://wiki.dbpedia.org/Ontology16 http://www.service-finder.eu/ontologies/ServiceCategories17 http://www.w3.org/2003/01/geo/wgs84_pos

Construct Dynamic Mashups 7

ing for the services used to implement the mashup mentioned before, i.e. thoseunder the category of “Internet Search”, taking a rdf:Literal value and an in-stance of dbp-ont:Place as inputs, and returning instances of dbp-ont:Placeas outputs.

SELECT DISTINCT ?s WHERE {?s rdf:type msm:Service . ?s sawsdl:modelReference ?c .?c rdfs:subClassOf finder:InternetSearch .?s msm:hasOperation ?o . ?o msm:hasInput ?in1 .?in1 sawsdl:modelReference rdf:Literal .?o msm:hasInput ?in2 . ?in2 sawsdl:modelReference ?in2mr .dbp -ont:Place rdfs:subClassOf ?in2mr .?o msm:hasOutput ?out . ?out msm:hasPart ?outpart .?outpart sawsdl:modelReference ?outmr .?outmr rdfs:subClassOf dbp -ont:Place .

}

Listing 2. SPARQL query for service selection.

By means of rewriting the SPARQL query above, the mashup can behavemore adaptively, namely, dynamically choose the services to invoke. Three ex-amples for the typical usage are listed as follows. Mashup developers can createmore complex queries to satisfy their own requirements.

FILTER (?s != service:Scoot)

When the Scoot service is now unavailable, this filter can avoid the attemptsto invoke it. In this way, it also can meet the requirement for smoothlyswitching between services at runtime.

?o hrests:hasAddress ?addr FILTER regex(str(?addr), ".uk") .

This clause with the regular expression can select services having addressesthat contains “.uk”, i.e. services provided by companies registered in theUK.

LIMIT 3

The solution sequence modifier LIMIT can restrict the number of services toinvoke, so as to reduce the response time of the mashup.

3.3 Service Invocation

The overall process of service invocation includes dereferencing, lowering, ground-ing, invoking and lifting. When identifiers of resources on the Web of Data areused as parameters for invoking services, iServe will first attempt to retrieve RDFtriples describing those resources, i.e. dereferencing the resources. After that,RDF statements are lowered to literal values by executing XSPARQL queries.Those values are then used to instantiate requests to be sent to the service end-points. Grounding refers the instantiation of service requests, which is the laststep of the preparation for the actual invocation of services. After receiving theresults in the format of XML, another set of XSPARQL queries will be executedto transform them into RDF.

As stated in the beginning of Sectionn 3, iServe provides RESTful APIsfor publishing and removing the descriptions of semantic services. And, all theservices stored in iServe are to be invoked as RESTful APIs. Therefore, an action

8 Dong Liu et al.

http://.../services/Scoot/operations/search/invoke?query=pizza&place=http://dbpedia.org/resource/London

http://www.scoot.co.uk/api/find.php?format=xml&what={p1}&lat={p2}&long={p3}

http://www.scoot.co.uk/api/find.php?format=xml&what=pizza&lat= 51.507221&long=-0.127500

dbp-res:London a dbp-ont:Place ; geo:lat "51.507221" ; geo:long "-0.127500" .

{ for $place $latfrom <London.rdf>where { $place geo:lat $lat.}return {$lat}}

{ for $place $lngfrom <London.rdf>where { $place geo:long $lng.} return {$lng}}

XSPARQL Execution Engine

51.507221 -0.127500

Fig. 3. An example for preparing the service request.

<rdf:RDF> <dbp-ont:Place>

<foaf:name>Prezzo plc</foaf:name><dbp-ont:address>31-32 Northumberland Avenue, London, Greater London</dbp-ont:address><geo:lat >51.5071000</geo:lat><geo:long>-0.1276490</geo:long>

</dbp-ont:Place>...</rdf:RDF>

return <rdf:RDF> { for $entry in $doc//results/entry let $companyname := $entry/companyname let $longitude := $entry/longitude let $latitude := $entry/latitude let $l1address := $entry/l1address ... let $l6address := $entry/l6address return <dbp-ont:Place> <foaf:name>{data($companyname)}</foaf:name> <dbp-ont:address>{data($l1address)} ..., {data($l6address)}</dbp-ont:address> <geo:lat>{data($latitude)}</geo:lat> <geo:long>{data($longitude)}</geo:long> </dbp-ont:Place>} </rdf:RDF>

<?xml version="1.0"?>...<entry> <result>1</result> <companyname>Prezzo plc</companyname> <l1address>31-32 Northumberland Avenue</l1address> ... <l5address>London</l5address> <l6address>Greater London</l6address> <postcode>WC2N 5BW</postcode> <description></description> <longitude>-0.1276490</longitude> <latitude>51.5071000</latitude></entry>...

XSPARQL Execution Engine

Fig. 4. An Example for Lifting.

Construct Dynamic Mashups 9

resource [6], named “invoke”, has been added to each operation of the services.In other words, the template of the addresses to invoke services stored in iServeis:

http://.../services/service-id/operations/operation-id/invoke?

parameter1=V1&parameter=V2&...

Figure 3 illustrates the preparation for calling of the search operation of theScoot service. iServe first found a dereferenceable URI, http://dbpedia.org/resource/London in the original request, and got a piece of RDF by sendingthere an HTTP GET with header Accept: application/rdf+xml. Then, theXSPARQL query engine loaded that piece of RDF as well as the lowering schemamappings shown on the right hand side of Figure 3, and extracted the latitudeand longitude of London. Finally, variables in the URI template were replacedwith the query keywords and the values of latitude and longitude. Part of theraw XML file returned by Scoot API is shown in the upper left of Figure 4,while the XSPARQL query guided the lifting of service invocation results is inthe upper right. And, some of the generated RDF triples are shown in the lowerpart of Figure 4.

3.4 Extensions to Existing Mashups

As stated in Section 1, one of the key features of dynamic mashups is the ex-tendibility. Developers can integrate new semantic services to built-up mashupswithout efforts on the modification of the source codes. Taking as an exampleCityGrid18, another local business searching service, the following things have tobe done to ensure being found by executing the SPARQL query in Section 3.2:firstly, put it into the category of Internet Search by adding a model reference tothe service; secondly, use the DBpedia ontology and W3C WGS84 vocabulary toannotate the service description. Moreover, to make it invocable, developers haveto specify the lowering and lifting schema mappings for the CityGrid service. Thelowering schema for Scoot API is particularly reusable in this case. Therefore,the developers only need to write the XSPARQL query (see Listing 3) for datalifting on the basis of analysis on the sample results of invoking the CityGridservice.

return <rdf:RDF > {for $entry in $doc// locations/locationlet $name := $entry/namelet $address := $entry/addresslet $street := $address/streetlet $city := $address/citylet $state := $address/statelet $postal_code := $address/postal_codelet $longitude := $entry/longitudelet $latitude := $entry/latitudereturn <dbp -ont:Place >

<foaf:name >{data($name)}</foaf:name ><dbp -ont:address >{data($street)}, {data($city)}, {data($state)}, {data(

$postal_code)}</dbp -ont:address >

18 http://docs.citygridmedia.com/display/citygridv2/Places+API

10 Dong Liu et al.

<geo:lat >{data($latitude)}</geo:lat ><geo:long >{data($longitude)}</geo:long >

</dbp -ont:Place >} </rdf:RDF >

Listing 3. XSPARQL query for lifting CityGrid invocation results.

All the results of service invocation are transformed into RDF through datalifting, and they conform to the same ontology. Thus, developers can easily mergethem together by adding them to a common RDF model before serialising andsending them to the client side.

4 Related Work

Several platforms have been established to facilitate the design and developmentof mashups. For instance, IBM Sharable Code is an online platform to supportthe whole life-cycle of Web APIs and service mashups [11]. Mashup developersare required to use Domain Specific Language (DSL) to specify data mediation,process mediation and UI customisation. A lightweight framework, Mashlight,is proposed in [5], which is composed of four components: Block Builder, BlockLibrary, Mashup Builder and Run-time Engine. Developers can use the BlockBuilder to encapsulate functionalities as Mashlight Blocks, and save them intothe Block Library. Mashup Builder is a visual tool for defining the workflow,and the Run-time Engine is the execution environment to enact the mashups.The overall architecture of Mashlight is similar to our work, but lack of explicitsemantics and effective discovery and selection mechanisms.

MatchUp built on top of the IBM Mashup Center provides a solution tothe mashup autocompletion [4]. The proposed autocompletion algorithm canrecommend relevant components and the connections between them to helpusers building mashups in a more convenient and intuitive way. Comparing withMatchUp, our approach intends to enable mashups to automatically select andinvoke services at runtime, rather than design time.

In the context of Web services, RESTful service composition is another re-lated topic to our work. Bite, a lightweight and executable language for RESTfulservice composition, is proposed in [17]. Bite offers a basic set of language con-structs for specifying the business logics of Web-scale workflows, and inheritsconcepts from scripting languages such as dynamic data types. Bite has fourruntimes to satisfy different requirements. In contrast to introducing a new lan-guage, minor extensions are made to BPEL for the composition of RESTfulservices [12]. Efforts also have been made to automate the process of RESTfulservice composition [21].

The work stated above adopts little semantic technology. SA-REST, an anno-tation-based approach to add semantics to RESTful services, is briefly describedin [18]. Mashups created using SA-REST, denoted with smashup (semanticmashup), are to be hosted at a proxy server together with domain ontologies.Similar to our approach, the data mediation is carried out through lowering andlifting, but implemented with XSLT. To my best knowledge, SA-REST does notaddress the issues of service modelling, registry and discovery.

Construct Dynamic Mashups 11

Apart form SA-REST, Semantic Web Pipes (SWP) proposed in [14] is arapid prototype method of semantic mashups on the data layer. SWP provides aset of operators for merging, splitting and transforming RDF triples in the cloudof Linked Data. It extends SPARQL with workflows, and implements dynamictransformations of RDF data using XQuery and XSPARQL. Our approach alsofollows the principles of Linked Data and applies SPARQL, XSPARQL for datamediation.

5 Conclusions and Future Work

In this paper, we present a novel method of building mashups using Web ser-vices with lightweight semantics, which is implemented based on iServe and itsextensions for service invocation. By applying our approach, mashups gain theability of selecting and invoking semantic services. Moreover, developers caneasily extend a mashup without programming work, as well as switch it to thealternatives with a service is unaccessible. In short, our approach is effective forbuilding mashups more flexible, robust and extendible.

Our future work will involve realising the caching mechanisms for serviceselection, and filtering services by QoS parameters, e.g. availability, responsetime, throughput, etc. In addition, we will also focus on the context-awarenessof mashups, i.e. automatically change the strategies of service selection accordingthe running state of the involving services. For example, when a service is down,mashups can be aware of it and automatically switch to alternative ones withhigh semantic similarity.

Acknowledgements This work is partly funded by the EU project SOA4All(FP7-215219) and NoTube (FP7-231761). The authors would like to thank theEuropean Commission for their support.

References

1. Agarwal, S., Handschuh, S., Staab, S.: Annotation, composition and invocation ofsemantic web services. Web Semantics 2(1), 31–48 (2004)

2. Akhtar, W., Kopecky, J., Krennwallner, T., Polleres, A.: XSPARQL: Travelingbetween the XML and RDF Worlds - and Avoiding the XSLT Pilgrimage. In:Proceedings of the 5th European Semantic Web Conference (ESWC2008). pp. 432–447. Springer-Verlag (2008)

3. Benslimane, D., Dustdar, S., Sheth, A.: Services Mashups: The New Generation ofWeb Applications. Internet Computing, IEEE 12(5), 13–15 (2008)

4. Greenshpan, O., Milo, T., Polyzotis, N.: Autocompletion for Mashups. Proceedingsof the VLDB Endowment 2(1), 538–549 (2009)

5. Guinea, S., Baresi, L., Albinola, M., Carcano, M.: Mashlight: a Lightweight MashupFramework for Everyone. In: Proceedings of 2nd Workshop on Mashups, EnterpriseMashups and Lightweight Composition on the Web (MEM 2009) at WWW 2009(2009)

12 Dong Liu et al.

6. Hadley, M., Pericas-Geertsen, S., Sandoz, P.: Exploring Hypermedia Support inJersey. In: Proceedings of the First International Workshop on RESTful Design.pp. 10–14. WS-REST ’10, ACM, New York, NY, USA (2010)

7. Kopecky, J., Gomadam, K., Vitvar, T.: hRESTS: an HTML Microformat for De-scribing RESTful Web Services. In: The 2008 IEEE/WIC/ACM International Con-ference on Web Intelligence (WI2008). IEEE CS Press (2008)

8. Li, N., Pedrinaci, C., Kopecky, J., Maleshkova, M., Liu, D., Domingue, J.: TowardsAutomated Invocation of Web APIs. In: Poster at the 8th Extended Semantic WebConference (ESWC2011) (2011), to appear

9. Maleshkova, M., Pedrinaci, C., Domingue, J.: Supporting the Creation of SemanticRESTful Service Descriptions. In: Workshop: Service Matchmaking and ResourceRetrieval in the Semantic Web (SMR2) at 8th International Semantic Web Con-ference (2009)

10. Martin, D., Paolucci, M., McIlraith, S., Burstein, M., McDermott, D., McGuinness,D., Parsia, B., Payne, T., Sabou, M., Solanki, M., Srinivasan, N., Sycara, K.:Bringing Semantics to Web Services: The OWL-S Approach. In: Cardoso, J., Sheth,A. (eds.) Semantic Web Services and Web Process Composition, Lecture Notes inComputer Science, vol. 3387, pp. 26–42. Springer Berlin / Heidelberg (2005)

11. Maximilien, E.M., Ranabahu, A., Gomadam, K.: An Online Platform for WebAPIs and Service Mashups. IEEE Internet Computing 12(5), 32–43 (2008)

12. Pautasso, C.: RESTful Web Service Composition with BPEL for REST. Data andKnowledge Engineering 68(9), 851–866 (2009)

13. Pedrinaci, C., Liu, D., Maleshkova, M., Lambert, D., Kopecky, J., Domingue, J.:iServe: a Linked Services Publishing Platform. In: Proceedings of Ontology Repos-itories and Editors for the Semantic Web at 7th ESWC (2010)

14. Phuoc, D.L., Polleres, A., Tummarello, G., Morbidoni, C., Hauswirth, M.: RapidSemantic Web Mashup Development through Semantic Web Pipes. In: Proceedingsof the 18th World Wide Web Conference (WWW2009). pp. 581–590. Madrid, Spain(2009)

15. Rao, J., Su, X.: A Survey of Automated Web Service Composition Methods. In:Cardoso, J., Sheth, A. (eds.) Semantic Web Services and Web Process Composi-tion, Lecture Notes in Computer Science, vol. 3387, pp. 43–54. Springer Berlin /Heidelberg (2005)

16. Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M., Polleres,A., Feier, C., Bussler, C., Fensel, D.: Web Service Modeling Ontology. AppliedOntology 1(1), 77–106 (2005)

17. Rosenberg, F., Curbera, F., Duftler, M.J., Khalaf, R.: Composing RESTful Servicesand Collaborative Workflows: A Lightweight Approach. IEEE Internet Computing12(5), 24–31 (2008)

18. Sheth, A., Gomadam, K., Lathem, J.: SA-REST: Semantically Interoperable andEasier-to-Use Services and Mashups. Internet Computing, IEEE 11(6), 91–94(2007)

19. W3C: Semantic Annotations for WSDL and XMLSchema (2007), http://www.w3.org/TR/sawsdl/

20. Yu, J., Benatallah, B., Casati, F., Daniel, F.: Understanding Mashup Development.IEEE Internet Computing 12(5), 44–52 (2008)

21. Zhao, H., Doshi, P.: Towards Automated RESTful Web Service Composition. In:Proceedings of 7th IEEE International Conference on Web Services(ICWS2009).pp. 189–196. IEEE Computer Society