A Semantic Workflow EnginePowered by Grid Reasoning

Sam Coppens, Ruben Verborgh, Erik Mannens, Rik Van de WalleGhent University – iMinds – Multimedia Lab

Gaston Crommenlaan 8 bus 201, B-9050 Ledeberg-Ghent, Belgiume-mail: firstname.lastname@ugent.be

Abstract—In this paper, we provide a novel semanticworkflow system, based on semantic functional servicedescriptions and a rule file that can be scheduled on agrid. The workflow engine follows a three-step process.First, it determines for all the resources in its knowledgebase the functionality they need to progress in theworkflow. This uses a phase-functionality rule file whichbinds phases of the workflow to functionalities. Duringa second phase, the functionalities are mapped to RESTservice calls using RESTdesc functional descriptions.During the third step, the engine executes the gener-ated service calls and pushes the resource it acted on tothe next phase in the workflow using a phase-transitionrule file. On a grid, each step will be fulfilled by anothertype of node. The grid architecture of the workflowengine guarantees its scalability.

I. IntroductionToday, applications on the Web increasingly rely on

Linked Open Data [2] and RESTful services [3]. Both have aresource-oriented architecture that exploit the links betweenthese resources. The increasing speed at which LinkedOpen Data, Web services and APIs are being deployed,demands an intelligent, expandable workflow engine growsin various domains, such as factories and Smart Cities.Process control in factories is often hard-coded into thecontrol software of the production machines. Whenever theywant to introduce a new sensor to steer the process, softwareneeds to be adapted, recompiled, and re-deployed on everymachine. An even bigger problem arises for Smart Cities,which use millions of wireless sensors. Existing workflowengines try to make this manageable, yet they are mostlymanually created. Moreover, the intelligence of a platformis often distributed over the software code and the workflowengine, making the management of such a system a hugeburden. Novel workflow engines should be able to integrateresources of any kind, i.e., Linked Open Data and RESTfulWeb services, to even become resource-agnostic. The onlydifference is that resources describing RESTful Web servicesand APIs get a functionality attached to them.

In the solution we envision, the software intelligenceand the workflow engine are unified into one systemthat can be scheduled on a grid. Its first cornerstoneis that workflows do not require manual compositionanymore, since they are composed automatically usingsemantic service descriptions and workflow description filesthat captures the intelligence of the platform. By relyingon functional service descriptions, services offering thesame functionality become interchangeable. The declarative

workflow rule files steer the reasoning engine by describingthe whole process in terms of functionalities. This way,services become interchangeable and the platform becomesa loosely coupled system. Adaptations in the services or theworkflow rule files are straightforward, without the needto adapt software code.

The second cornerstone of the envisioned platform is theautomated execution of generated workflows. Workflows aredynamically recomposed when needed and automaticallytriggered when needed.

A third cornerstone of the platform is its extensible gridarchitecture. This feature of the workflow engine allowsit to scale to the application its needs. Together with theautomatic workflow composition, the whole system becomesself-sustaining, easily adaptable and extensible, and highlyportable.

This unique combination enables our system to formthe backend platform for a broad spectrum of applications,ranging from home domotic systems, long-term preservationplatforms, process control software for factories to largeSmart Cities. The only manageable assets are the servicedescriptions and the worfklow description rule files. Atany moment new services can be described, which willautomatically be incorporated into the newly generatedworkflows. Even the whole process can be changed, bymaking alterations to the workflow description rule files.All this happens in a declarative way, eliminating the needto redesign, recompile, and redeploy the software, keepingthe system more manageable. These three characteristics,i.e., manageability of the services, speed-up of develop-ment process and extensibility of the system, are key toour solution and distinguish it from traditional workflowengines.

II. Concept and ArchitectureWhen composing a workflow, our platform basically

needs to following information, as shown in Figure 1:

• Knowledge Base: The knowledge base containsactually the information to be acted on. This isactually Linked Open Data, coming from a localtriple store or optionally the Linked Open Datacloud.

• Phase-Functionality rule file: A phase-functionalityrule file is a declarative file, stating how the differentphases of a workflow are mapped to functionalities

The Eleventh EEE International Workshop on Managing Ubiquitous Communications and Services, 2014

978-1-4799-2736-4/14/$31.00 ©2014 IEEE 460

Fig. 1. Basic building blocks of the self-sustaining platform.

to move the resource to the next phase in theworkflow. Rules are described in N3 [1], as willbe discussed in Section III-A.

• Phase-Transition rule file: This file is actually re-sponsible for routing the different phases (and hencefunctionalities) of a workflow such that it compliesto a certain overall functionality or company policy.

• Functional service descriptions: These service de-scriptions describe the individual services theworkflow engine can make use of to compose itsworkflows. RESTdesc [10] describes services, as willbe detailed in Section III-B.

The phase-functionality rule file, the phase-transition rulefile and the service descriptions in combination with theknowledge base, and optionally even external knowledgebases from the LOD cloud will generate the needed servicecalls by means of reasoning. This happens by the workflowgenerator. Because we rely on monotonic rule reasoning,this is a single threaded process. The generated servicecalls will be executed by the workflow executor. Of course,this can be a multi-threaded process.

The operation behind the self-sustaining platform actu-ally consists out of three phases, as illustrated in Figure 2:

1) In the functionality generation phase, thephase-functionality rule file will tell for eachresource which functionality it needs to get tothe following phase of the workflow. This willhappen by reasoning with the rule file over theknowledge base. This will entail triples describinga functionality the resource needs to get to thefollowing phase of the workflow.

2) In the service call generation phase, thesefunctionalities are mapped to service calls usingthe service descriptions. This is also done byreasoning over the entailed triples of the previousphase. The entailed triples of this reasoning cyclewill describe service calls to be executed during thefollowing phase. Splitting up the functionalities ofservice calls has a great advantage for the man-agement of the services and generated workflows.

3) In the service call execution phase, the gener-ated service call is being executed. If the serviceexecuted successfully, the phase-transition rule fileis used to move to the next phase within theworkflow.

Fig. 2. Schematic operation of the self-sustaining platform.

Fig. 3. Example workflow for publishing LOD.

Determining the needed transition is performed by meansof reasoning over the entailed from the previous phase. Theentailed triples of this phase will be stored to the knowledgebase and a whole new reasoning cycle from the first phaseis started. The next sections, will discuss the different stepsin detail.

To demonstrate our idea, we will focus on the use caseof publishing Linked Open Data. Publishing Linked OpenData typically consists of four steps: harvesting the data,mapping the harvested data, reconciling the mapped data,enriching the reconciled data, and finally, publishing theenriched data.

III. Operational Phases

A. Functionality Generation PhaseThis phase-functionality rule file will split up the

workflow into different phases and it will list for each phasethe functionality it needs to get to the following phase.If we take back the example of publishing Linked OpenData, then its workflow consists of the following orderedlist of functionalities: harvesting, mapping, reconciliationand publication. Each of the functionalities give rise toa new phase. An example is schematically shown inFigure 3. Every phase is characterised with a functionalityto complete the phase.

The phases, and the functionalities connecting them,form a functional workflow description. This is a composi-tion of functionalities that need to be performed in order tofulfil a certain policy or achieve a certain goal. Such a goalor policy can be described using a rule file and a rule-basedreasoner. In this rule file, the phases and functionalities

The Eleventh EEE International Workshop on Managing Ubiquitous Communications and Services, 2014

461

need to denoted with URIs. Taking back our example ofLOD publisher, the rule file looks like the following.@prefix wf: <http://example.org/workflow#>.@prefix fn: <http://example.org/functionalities#>.

{?object0 wf:hasStarted wf:phase_0} =>{?object0 fn:harvestRecord ?object1.?object1 wf:hasCompleted wf:phase_0}.

{?object1 wf:hasStarted wf:phase_1} =>{?object1 fn:map ?object2.?object2 wf:hasCompleted wf:phase_1}.

{?object2 wf:hasStarted wf:phase_2} =>{?object2 fn:reconcile ?object3.?object3 wf:hasCompleted wf:phase_2}.

{?object3 wf:hasStarted wf:phase_3} =>{?object3 fn:enrich ?object4.?object4 wf:hasCompleted wf:phase_3}.

{?object4 wf:hasStarted wf:phase_4} =>{?object4 fn:publish ?object5.?object5 wf:hasCompleted wf:phase_4}.

This phase-functionality rule file actually describes thedifferent phases of a resource in a workflow and for eachphase its functionality. It doesn’t tell how the differentphases should be coupled in order to achieve a certainworkflow. These transitions are described in the phase-transition rule file, discussed in Section III-C. During thesecond step, this functional workflow, actually describedas entailed triples, is being materialised to explicit servicecalls. Assume we have an URL of a resource we want topublish as LOD. e.g., http://foo.org/res/1234. If weadd the following triple to our triple store/knowledge base,we get the publishing procedure starting:<http://foo.org/res/1234> wf:hasStarted wf:phase_0.

Reasoning over this triple with our example rule file yieldsthe following triples:<http://foo.org/res/1234> fn:harvestRecord ?object1.?object1 wf:hasCompleted wf:phase_0.

These triples are passed to the next step, where func-tionalities are translated into REST service calls. Duringthis step another reasoning cycle will happen. All theentailed triples will be added to the knowledge base afterthe successful execution of this phase of the workflow duringthe last step. After this step, a new reasoning cycle is fired.Another reasoning cycle over these triples would yield thefollowing triples, which in turn are passed to the next step:?object1 fn:map ?mappedResult.?mappedResult wf:hasCompleted wf:phase_1.

Eventually, after several reasoning cycles, the entire work-flow will be executed.

B. Service Generation PhaseAs explained, this step is going to turn the result of the

functionality generation phase into a service call description,which will be fed to the service execution and transition

phase. The result of the functionality generation phase isactually a set of entailed triples, as shown in the previoussection. For each phase in the workflow, we have a tripledenoting the functionality it needs for the next phase. Thesetriples should actually result in a description of the of aREST service, which serves the functionality.

For the service description, we rely on RESTdesc.RESTdesc is both a description and a discovery methodtargeting restful Web services, with an explicit focus onfunctionality. It consists of well-established technologiessuch as HTTP and RDF/Notation3 and is built uponthe concepts of hyperlinks and Linked Data. Its goal isto complement the Linked Data vision, which focuses onstatic data, with an extension towards Web services thatfocus on dynamic data. All RESTdesc descriptions are:

• self-describing: using Notation3 semantics;• functional: explaining exactly what the operation

does;• simple: descriptions are expressed directly using

domain vocabularies.Since RESTdesc entails the operational semantics of

Notation3, it allows for versatile discovery methods. We canindeed use the power of Notation3 reasoners to determinewhether a service satisfies at set of conditions. Evenmore advanced reasoning is possible to decide on servicematching, and to create complex compositions of differentservices. We see this as an important prerequisite forservices in order for them to contribute to the future Webof Agents, since new functionality can only be obtainedby on-demand compositions tailored to a specific problem.Such a RESTdesc description of a service that harvests arecord, looks like this:@prefix fn: <http://example.org/functionalities#>.@prefix http: <http://www.w3.org/2011/http#>.

{ ?url fn:harvestRecord ?record. }=>{ _:request http:methodName "GET";

http:requestURI ?url;http:resp [ http:body ?record ].}.

It actually says: If you have a URL from which you want toharvest a metadata record, then you can do this by an httpGET request on the URL and the response will containthe record in its body. POST requests are also described inthis way. The following mapping service is a good exampleof a POST request.{ ?record fn:map ?mappedRecord.}=>{ _:request http:methodName "POST";

http:requestURI "http://service.org/map/";http:body ?record;http:resp [ http:body ?mappedRecord ].}.

Thus, during this second step, we only need to reason withthe RESTdesc service descriptions over the entailed triplesof the first step in order to get the service call descriptionsthat need to be executed during the next step. If we takeback the example of Section III-A, the entailed triples fromthe first reasoning cycle being feed to this step are:

The Eleventh EEE International Workshop on Managing Ubiquitous Communications and Services, 2014

462

<http://foo.org/res/1234> fn:harvestRecord ?result.?result wf:hasCompleted wf:phase_0.

Reasoning over these triples with the service descriptionof the harvest service, inferences the following triples thatare fed to the workflow execution step:_:request http:methodName "GET";

http:requestURI <http://foo.org/res/1234>;http:resp [ http:body ?record ].

If you have in your repository with RESTdesc service de-scriptions multiple services covering the same functionality,this phase would yield multiple REST service calls beingdescribed. Not all these service descriptions need to be fedto the service execution phase, only one needs to. For thisreason, this phase stops after the first RESTdesc servicedescription that entails a service call description. Thisseparation of functionalities and services that cover thesefunctionalities greatly enhances the management of theservices and the workflows. It makes services with the samefunctionality interchangeable.

C. Service Execution and Transition Phase

In this step, the entailed triples of the previous step areprocessed. The entailed triples of the previous step actuallydescribe a REST service call, explaining the HTTP GET re-quest can be done on the URL http://foo.org/res/1234and the record’s metadata will be returned into theresponse’s body. Thus, an execution agent can processthese entailed triples, describing a service call. If the agentexecutes the service call successfully, the phase transitionrule file is used to progress to the next phase of the workflow.This phase-transition file actually routes all the differentphases of the workflow. This is done by reasoning overthe entailed triples of the previous steps. For our LODpublication example, this phase transition file looks likethis:@prefix wf: <http://example.org/workflow#>.@prefix fn: <http://example.org/functionalities#>.{?object wf:hasCompleted wf:phase_0} =>

{?object wf:hasStarted wf:phase_1}.

{?object wf:hasCompleted wf:phase_1} =>{?object wf:hasStarted wf:phase_2}.

{?object wf:hasCompleted wf:phase_2} =>{?object wf:hasStarted wf:phase_3}.

{?object wf:hasCompleted wf:phase_3} =>{?object wf:hasStarted wf:phase_4}.

For our example, these entailed triples fed to this step are:<http://foo.org/res/1234> wf:hasCompleted wf:phase_0._:request http:methodName "GET";

http:requestURI <http://foo.org/res/1234>;http:resp [ http:body ?record ].

The service-executing agent detects the service call descrip-tion and executes it. If the execution was successful, thereasoning with the phase-transition file is started, yieldingthe following triples:

<http://foo.org/res/1234> wf:hasStarted wf:phase_1.

After this last reasoning cycle, all the entailed triples ofthe three steps are being ingested into the knowledge baseand a new functionality generation phase is started, asshown in Figure 2. If the execution of the service call wasunsuccessful, the operation breaks up, storing nothing tothe knowledge base, because you cannot state the phasehas already finished. Thus, the triples being added to theknowledge base are:<http://foo.org/res/1234> wf:hasCompleted wf:phase_0._:request http:methodName "GET";

http:requestURI <http://foo.org/res/1234>;http:resp [ http:body ?record ].

<http://foo.org/res/1234> wf:hasStarted wf:phase_1.

IV. Advanced Features

In this section, we are going to discuss some advancedfeatures of the workflow engine. Until now, only the basicoperation has been discussed. By adapting the phase-functionality, file, the phase-transition file and the servicedescriptions, some more advanced features are possible inthis framework. The advanced features discussed in thissection are: how to integrate feedback loops, cron jobs,and nested functionalities. The advanced features are notlimited to these ones. Other features are, e.g., the possibilityto include Linked Open Data into the workflow, such thatworkflow are adapted or triggered by external data fromthe Linked Open Data cloud. SPARQL endpoint resultscan be integrated into the workflows. For this, SPARQLrequests are modeled as RESTful service calls. The resultsfrom these endpoints can then be used within the rulefiles make the workflows adapting to this external data.Another feature that can be integrated into the workflowengine is basic workload balancing. For this, we can includecounters attached on the service endpoints, such that theload for a functionality is shared across the different services,serving the same functionality. A last feature to mentionis that it becomes easy to integrate authorisation into theworkflows. To integrate this in the workflows, a new phasemust be integrated into the workflow, e.g., in our example,for validating the generated enrichments. The transitionfrom this phase is then actually steered by an externalREST service, which is triggered by the authority.

A. Feedback LoopsFeedback loops can be built into the workflow. In our

example, we can introduce a update process by introducinga recurring reharvest of the record. This is achieved byadapting the first rule and adding a rule to the phase-functionality rule file:@prefix dc: <http://purl.org/dc/elements/1.1/>.@prefix dcterms: <http://purl.org/dc/terms/>.@prefix time: <http://www.w3.org/2000/10/swap/time#>.

{?object0 wf:hasStarted wf:phase_0} =>{?object0 fn:harvestRecord ?object1.?object1 wf:hasCompleted wf:phase_0.?object1 dc:source ?object0.?object1 dcterms:modified time:localTime.}.

The Eleventh EEE International Workshop on Managing Ubiquitous Communications and Services, 2014

463

{?object5 wf:hasStarted wf:phase_5.} =>{?object5 dc:source ?url.?url fn:reHarvestRecord ?object6.?object6 wf:hasCompleted wf:phase_5.}.

With these rules, we define an extra phase for the workflow,i.e., wf:phase:5, which is coupled to the functionalityfn:reHarvestRecord. Next, this phase needs to be in-tegrated into the phase-transition rule file. The phase-transition file will get the following extra rule:@prefix func: <http://www.w3.org/2007/

rif-builtin-function#>.@prefix pred: <http://www.w3.org/2007/

rif-builtin-predicate#>.@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

{?object wf:hasCompleted wf:phase_4;dcterms:modified ?lastHarvest.

(time:localTime ?lastHarvest)func:subtract-dateTimes ?difference.

(?difference "P14D"^^xsd:dayTimeDuration)pred:dayTimeDuration-greater-than true.} =>

{?object wf:hasStarted wf:phase_5}.

{?object wf:hasCompleted wf:phase_4} =>{?object wf:hasStarted wf:phase_1}.

B. Nesting

The functionalities can be nested using multiple rules. Inour previous example, the reharvest functionality consistsactually of a new delete and an already existing harvestfunctionality. The following rules for the phase-functionalityrule file shows reharvesting:{?object fn:reHarvestRecord ?result} =>

{?object wf:hasStarted wf:phase_6.}.

{?object wf:hasStarted wf:phase_6} =>{?object fn:delete ?delete.?object wf:hasCompleted wf:phase_6}

And the following rules are added to the phase-transitionfile:{?object wf:hasCompleted wf:phase_6} =>

{?object wf:hasStarted wf:phase_0.?object wf:isReharvest true.}

{?object wf:hasCompleted wf:phase_0} =>{?object wf:hasStarted wf:phase_1.}

{?object wf:isReharvest true.?object wf:hasCompleted wf:phase_0} =>{?object wf:hasCompleted wf:phase_5.}

This needs a little explanation. There is no service providingthe reharvest functionality, there are services for the deleteand harvest functionality. Whenever our semantic workflowengine cannot trigger a rule with the entailed triplesfrom the functionality generation phase during the servicegeneration phase, these entailed triples are taken to theservice execution and transition phase. This reasoningcycle, only defines phase transitions without delivering

Fig. 4. Grid based architecture.

a service call description. During the subsequent reasoningcycle, our newly defined rules, bringing our object fromthe deadlocked reharvest state to the delete state for whichit has a service description. In turn, the delete phase willgive rise eventually to the harvest phase and this is howfunctionalities can be nested in our platform. After thisharvest, the nested loop needs to be closed. This is donewith the last rule from the phase-transition file, which saysthat if the harvest is finished and is part of a reharvestoperation, the reharvest operation is finished.

V. Grid based SolutionThe whole workflow engine can be scheduled on a

grid. The grid consists of three type of nodes. One typeof node, the functional worklow composition agents, willdo the workflow composition, i.e., the phase-functionalityreasoning and the phase transition reasoning. Anothertype of node, the RESTful service repositories, containall the service descriptions and will generate the servicedescription via rule reasoning. The last type of node, theRESTful service execution agents, will execute the servicedescriptions. This grid architecture is depicted in Figure 4.

Communication between the nodes of the grid is deter-mined by a controller node, which acts as a proxy for theexchanged messages. This controller nodes knows whichnodes fulfil which functionality and will round-robin themessages to the appropriate nodes.

Because thw whole system is easy configurable viatwo rule files and a set of service descriptions, the gridis easily configurable, extensible, and manageable. Thisfeature of the workflow engine makes it suitible for largeinfrastructures like smart cities.

VI. Related WorkOur self-sustaining platform relies on two basic tech-

nologies: Semantic service descriptions and automaticworkflow composition. “Semantic Web Services: a RESTfulapproach” [4] has a RESTful grounding ontology that mapsOWL-S [8] and WADL [6]. OWL-S is a W3C submissionfor Semantic Web service descriptions. Web ApplicationDescription Language (WADL) is a W3C submission fordescribing REST over HTTP Web services. The Semantic

The Eleventh EEE International Workshop on Managing Ubiquitous Communications and Services, 2014

464

Automated Discovery and Integration (SADI [11]) offerWeb service Design-Patterns, an API and a referenceImplementation that simplify the publication of servicessuch that they can easily be discovered and integrated.

When it come to automatic workflow composition, Data-Fu, a language and interpreter for interaction with read-/write Linked Data, is related to our research. Data-Fu is adeclarative rule language for specifying interactions betweenweb resources. Another platform, supporting automaticworkflow composition is the work of Krummenacher [7].In this work, he investigates the composition of RESTfulresources in a process space. The work is based on resourcesdescribed by graph patterns. Similar work is carried out bySpeiser and Harth [9], which also relies on graph patternsfor RESTful Linked Data Services. In this context, it is alsoworth mentioning WINGS, (Workflow INstance Generationand Specialization [5]). WINGS is a semantic workflowsystem that consists of the WINGS Portal, which is its userinterface, and the WINGS Semantic Workflow Reasoner,which contains its constraint reasoning and propagationalgorithms.

For our workflow composition, we rely on rule-basedreasoning. All the intelligence of an application is gatheredby three rule files. This centralisation of the application’sintelligence allows easy management of the services, becauseservices become interchangeable if they provide the samefunctionality. At the same time, it allows easy adaptationand extensibility of the application through the adaptationof the three rule files. There is no need anymore torecompile, and redeploy the software.

VII. ConclusionsIn this paper, we presented a novel workflow engine,

based on Linked Data, RESTful Web services and rule-based reasoning. Our platform will generate workflowsdescribed in terms of phases and functionalities connectingthe phases. In a later phase, these functionalities aremapped into service call descriptions, which are finallyexecuted. This three-step operation of the workflow engineallows it to be scheduled on a grid with three types ofnodes, covering each one of the steps. A main feature of ourplatform is that it is easily adaptable and expandable. Thewhole system captures the application intelligence throughthree N3 rules files. One for describing the different phasesof a workflow and for each phase the functionality it needs.Another describing the phase transitions, and finally onedescribing the RESTful Web services the platform relieson. These files can be adapted at runtime, but at the sametime aggregate the platform’s intelligence. Another mainfeature is the explicit separation between functionalitiesand services. By this, services serving the same functionalitybecome interchangeable. This makes both the managementof the workflows and the services a lot easier. Our generatedworkflows can be steered by external Linked Data, so thatthe platform can act on this external data. A last feature ofthe platform is its ability for error handling. These featurestogether make the platform self-sustaining.

References[1] Berners-Lee, T. and Connolly, D. Notation 3. Avail-

able at http://www.w3.org/DesignIssues/Notation3.2006.

[2] Bizer, C.;Heath, T. and Berners-Lee, T. “Linked Data– The Story So Far”. In: Int. J. Semantic Web Inf.Syst. 5.3 (2009), pp. 1–22. url: http://eprints.ecs.soton.ac.uk/21285/.

[3] Roy T. Fielding and Richard N. Taylor. “Princi-pled design of the modern Web architecture”. In:Proceedings of the 22nd international conference onSoftware engineering. ICSE ’00. Limerick, Ireland:ACM, 2000, pp. 407–416. isbn: 1-58113-206-9. doi:10.1145/337180.337228. url: http://doi.acm.org/10.1145/337180.337228.

[4] Otávio Freitas Ferreira Filho and Maria Alice GrigasVarella Ferreira. “Semantic Web Services: A REST-ful Approach”. In: IADIS International ConferenceWWWInternet 2009. IADIS, 2009, pp. 169–180. url:http://fullsemanticweb.com/paper/ICWI.pdf.

[5] Yolanda Gil, Varun Ratnakar, Jihie Kim, Pedro A.González-Calero, Paul T. Groth, Joshua Moody, andEwa Deelman. “Wings: Intelligent Workflow-BasedDesign of Computational Experiments”. In: IEEEIntelligent Systems. 2011. url: http://www.isi.edu/~gil/gil-etal-ieee-is-09.pdf.

[6] Marc J. Hadley. Web application description language(WADL). Tech. rep. Mountain View, CA, USA: SunMicrosystems, Inc., 2006.

[7] Reto Krummenacher, Barry Norton, and AdrianMarte. “Towards Linked Open Services and Pro-cesses”. In: FIS. Ed. by Arne-Jørgen Berre, AsunciónGómez-Pérez, Kurt Tutschku, and Dieter Fensel.Vol. 6369. Lecture Notes in Computer Science.Springer, 2010, pp. 68–77. isbn: 978-3-642-15876-6.

[8] David Martin, Mark Burstein, Erry Hobbs, OraLassila, Drew Mcdermott, Sheila McIlraith, SriniNarayanan, Bijan Parsia, Terry Payne, Evren Sirin,Naveen Srinivasan, and Katia Sycara. OWL-S: Se-mantic Markup for Web Services. Tech. rep. W3C,Nov. 22, 2004. url: http://www.w3.org/Submission/OWL-S/.

[9] Sebastian Speiser and Andreas Harth. “IntegratingLinked Data and Services with Linked Data Services”.In: ESWC (1). Vol. 6643. Lecture Notes in ComputerScience. Springer, 2011, pp. 170–184. isbn: 978-3-642-21033-4.

[10] Ruben Verborgh, Thomas Steiner, Davy Van Deursen,Jos De Roo, Rik Van de Walle, and Joaquim GabarróVallés. “Capturing the functionality of Web serviceswith functional descriptions”. In: Multimedia Toolsand Applications 2 (2013), pp. 365–387. doi: 10.1007/s11042-012-1004-5. url: http://link.springer.com/article/10.1007/s11042-012-1004-5.

[11] Mark Wilkinson, Benjamin Vandervalk, and LukeMcCarthy. “The Semantic Automated Discoveryand Integration (SADI) Web service Design-Pattern,API and Reference Implementation”. In: Journal ofBiomedical Semantics 2.1 (2011), p. 8.

The Eleventh EEE International Workshop on Managing Ubiquitous Communications and Services, 2014

465