MEDINFO 2017: Precision Healthcare through Informatics 945

A.V. Gundlapalli et al. (Eds.)

© 2017 International Medical Informatics Association (IMIA) and IOS Press.
This article is published online with Open Access by IOS Press and distributed under the terms
of the Creative Commons Attribution Non-Commercial License 4.0 (CC BY-NC 4.0).
doi:10.3233/978-1-61499-830-3-945

Semantic Web Service Delivery in Healthcare Based on

Functional and Non-Functional Properties
Marco Schweitzer, Thilo Gorfer, Alexander Hörbst
eHealth Research and Innovation Unit, UMIT - University for Health Sciences, Medical Informatics and Technology,
Hall in Tyrol, Austria

Abstract Today’s EHR systems have two major limitations:

In the past decades, a lot of endeavor has been made on the 1. They solely allow access to raw data. Standards like
trans-institutional exchange of healthcare data through elec- HL7 CDA [3] are very comprehensive and new
tronic health records (EHR) in order to obtain a lifelong, approaches like HL7 FHIR [4] allow dynamic and
shared accessible health record of a patient. Besides basic flexible data access but the main focus is set to raw
information exchange, there is a growing need for Information data retrieval.
and Communication Technology (ICT) to support the use of 2. ICT Systems in healthcare tend to be designed in a
the collected health data in an individual, case-specific work- monolithic manner, i.e. a well-designed and
flow-based manner. This paper presents the results on how conceptualized problem-scope is solved by using
workflows can be used to process data from electronic health defined, static functions with limited extensibility.
records, following a semantic web service approach that ena- Changes within the software design require
bles automatic discovery, composition and invocation of suit- reengineering the software, which is correlated to
able web services. Based on this solution, the user (physician) increased effort and costs. Further no individual
can define its needs from a domain-specific perspective, customization of information processing (data
whereas the ICT-system fulfills those needs with modular web processing functions) is permitted, though present
services. By involving also non-functional properties for the publications highlight challenges and burden relating
service selection, this approach is even more suitable for the EHR for routine workflows [5,6].
dynamic medical domain. So the design and implementation of meaningful healthcare
Keywords: software systems need to offer comprehensive functionality
Electronic Health Records; Semantics; Technology based on individual preferences and customized EHR work-
flows and data flows [7] on one side, and on the other side
support adaption to the highly dynamic and quickly evolving
Introduction
medical domain by providing scalable, distributed and in-
teroperable systems [8].
With the advent of electronic health records (EHRs) the
shared trans-institutional data exchange in healthcare has led Existing research on EHR related workflows have mostly fo-
to an unprecedented amount of health data in the past decade. cused on clinical pathways and outline the urgent need for
Today facilitating this data in a meaningful way is crucial for EHRs to comply with workflows [9]. The project OntoHealth 1
high quality healthcare delivery [1]. aims at developing concepts and systems, that are able to pro-
cess EHR-related workflows based on BPMN 2.0, which are
Related information and communication technology (ICT)
executed using semantic web services. Very important and
solutions are necessary to manage this emerging data and use
often not sufficiently considered criteria for present software
it for purposeful and individual diagnosis and therapy. In gen-
systems are given through non-functional properties (NFPs).
eral, medical diagnosis and treatment follow a certain work-
There are approaches that enhance BPMN with NFPs in order
flow, i.e. a sequence of tasks (both, IT-based and human-
to establish quality conditions on tasks [10], but according to
based) is executed by an individual or a group of healthcare
the knowledge of the authors, no literature could be found that
professionals to obtain some business goal. With the means of
try to extend EHR data processing for user defined workflows
business process modeling, such a workflow can be modeled
with semantic web services incorporating NFPs. In the Onto-
graphically using business process diagrams (BPD), e.g. with
Health project NFPs play a crucial role as they define the de-
the business process model and notation (BPMN). The latest
sired quality parameters for service selection and are used for
version 2.0 of BPMN extended the solely graphical tool with
proper service execution. Thus, besides deciding what data
capabilities to execute process diagrams through workflow
from an EHR is needed and how it should be processed by
engines. This opens new ways of integrating BPMN 2.0 with
suitable web services, the user can select NFPs (e.g. perfor-
ICT, in order to improve and automate business processes. Up
mance, costs), which define quality constraints and certain
to 50% of everyday routine tasks for diabetes consultations
service selection needs to adhere when executing a workflow.
belong to recurring IT-related tasks [2], e.g. finding reports,
change a therapy plan or organize a referral. However, there is This paper describes our approach of how we automatically
little experience in automating such clinical processes. These align user defined EHR workflows represented as a sequence
tasks could be modeled as BPD at point of care by the user of tasks with semantic web services under consideration of
(e.g. a physician) and used for automatic execution to support NFPs.
routine work.
1 http://www.ontohealth.org
946 M. Schweitzer et al. / Semantic Web Service Delivery in Healthcare Based on Functional and Non-Functional Properties

Methods problem-based process (modeled with BPMN 2.0) by means

of an automatic semantic web services composition. The over-
Today prominent semantic standards like the resource descrip- all architecture is presented [12]. In this paper, we present the
tion framework (RDF), the web ontology language (OWL) precise execution flow with details on how the different mod-
and SPARQL provide suitable means to use semantic technol- ules are combined to get the related services. An overview of
ogies even in the medical domain, e.g. to structure medical the steps is depicted in figure 1. A given workflow consists of
knowledge like SNOMED-CT. For EHRs, semantic technolo- known flow objects (events, activities and gateways). As de-
gies are crucial to achieve semantic interoperability. However, fined in BPMN a task is a sub element of an activity and for
the use of semantics for clinical functionality is limited. our purpose contains the information about the user defined
requirements. Those requirements comprise for each task in-
A key technology in today’s software development is the
puts and outputs (data elements), a certain function and a set
modular approach of utilizing loosely coupled web services.
of NFPs. All this information is modeled using the OWL2
In so called Service Oriented Architectures (SOAs) several
format and stored in a triple store, which is a special type of
modular functions of a software are outsourced from its main
database that is optimized for storing semantic data in triple
application and processed on isolated services. Those loosely
format (subject-predicate-object). On execution, the workflow
coupled and high cohesive modules are aligned to fulfill cer-
manager platform executes the defined process model with the
tain business needs. The web services are usually realized with
related workflow engine. This workflow engine is also re-
standards like SOAP or the very lightweight REST standard.
sponsible for data management, i.e. to convey the needed data
Beside the way of directly calling a known service (e.g. call- in the process, and handle exceptions. The logic of this engine
ing the service RiskCalculator provided by hospital A with is realized in a basic way (gets executed as defined), which
parameters XYZ) it is possible to find a certain service from a could be extended with special routing or assistance function-
service repository fulfilling one’s business needs. Usually alities in the future. For the execution of one task, related
SOAs provide some kind of service broker that is responsible OWL2 instances from the BPD (modeled also with an ontolo-
to register several services from different providers in such gy representation of BPMN 2.0 [13]) are provided for the Ser-
registries, where each service includes a description document vice Delivery Platform (SDP), which is responsible to allocate
or service contract (JSON or XML) that contains meta infor- and call the right service. Several steps are needed, to find the
mation about the preconditions, capabilities (inputs/outputs, proper web service which includes web service composition,
effects) and interfaces of the service. The service broker also when no proper atomic service may be found. A ranking score
answers requests of the service consumers, e.g. with the in- gets calculated during the steps, which is used to find the best
formation on how to call the interface of the service. The limi- service for invocation. The subsequent sections describe all
tation here is that common web service description documents steps in detail that are necessary to execute one complete task
don’t share any semantic description and thus are not machine within a user-defined workflow. The task therefore describes a
readable. For this purpose, Semantic Web Services (SWS) certain user need (defined as a goal) within a workflow, while
provide the means to combine semantic technologies with web the available services are defined as the building blocks that
services: Each service owns a description that is enriched with need to be assembled in order to fulfill the user’s goal.
semantic content, in order to automate service discovery,
composition, invocation and monitoring.
In our approach we adapted the service delivery structure of
WSMO (Web Service Modelling Ontology) [11]. Based on
this concept we integrated our developed domain ontologies
for EHR web services, containing pertinent data elements as
in- and outputs, functions and NFPs for EHR data processing.
The service contract is modeled using MSM (Minimal Service
Model) with a slight extension for the integration of data ele-
ments and functions. Our idea was to use a direct 2 matching
based alignment of functions, inputs, outputs and NFPs from
user defined tasks and available web services. We build a ser-
vice delivery pipeline which covers the following web service
delivery steps: discovery, composition, ranking and invoca-
tion. For our purpose we aligned those steps with the domain
ontology needs and the workflow-based execution, i.e. the
steps deal with functions, inputs, outputs and NFPs in a suita-
ble way. Further parts for registration and pre-filtering were
added to provide complete service delivery. Rules were de-
fined on how to enable interaction between the steps of the
pipeline process and on how to match the related requirements
Figure 1 - Execution flow of an EHR workflow within the On-
(functions, inputs, outputs, NFPs).
toHealth platform.
The developed service delivery process was implemented as a
prototype application in order to prove the concept. Step 0: Registration

Results Before pre-filtering, discovery, composition, ranking and in-

vocation can take place, services need to be registered in the
OntoHealth SDP. Registration is the process where the service
Within the OntoHealth project, a workflow-based SOA plat-
descriptions are first generated by the service owner, accord-
form has been conceptualized, which executes an individual,
ing to the service contract, based on the semantic service
model [14] and then stored in the triple store and managed by
2 Tasks and services use the same domain ontology.
 M. Schweitzer et al. / Semantic Web Service Delivery in Healthcare Based on Functional and Non-Functional Properties 947

the SDP. These descriptions are given in JSON-LD 3 format 3. Plugin match: The service delivers all output data
following the structure of the service contract. Each function- elements specified in the workflow task, but also
ality of a service is defined by in-/outputs, function type and delivers some additional ones.
all corresponding NFPs. By means of SPARQL queries, the 4. Intersection match: The service only delivers some
service descriptions can be added, updated or deleted from the output data elements but not all of the ones specified in
registry. This step is not part of the actual workflow execution. the task. Additionally, there are also additional outputs
In OntoHealth the definition of service information is task of being delivered.
the related developer, vendor or service provider. OntoHealth 5. No match: The service delivers no relevant output data
will provide a guideline on how to properly create the service elements.
description and register the service in the platform in order to
make the service available for web service discovery.
Step 1: Pre-Filtering + ++ +
+ + Exact match
The first step in the ranking procedure is the pre-filtering pro- + + * ++ x Intersection match
cess. In this step, all the services that do not match the man- * + x
datory NFPs, which are retrieved from the task description, ++ x Subsumption match
+ x * x
are dropped and not considered for further analysis. This helps * * No match
to emphasize the discovery for services that require e.g. cer- * x
tain user permissions or any regional restriction that can be * ++ Plugin match
* +
obtained from the requesting user. The resulting services are
then used as an input for the following step. + Delivered, needed objects (service)
x Relevant objects (task)
It is defined in the semantic model if a NFP has the status of a
mandatory property or will be considered later in the raking * Additional specified objects (service)

step to calculate the ranking score.

Figure 2 - Matching categories for output classification.
Step 2: Discovery
The goal of the discovery step is to identify the services from Input Classification
all available services that fit the tasks’ requirements defined In this part, the services are classified based only on their
by the user. The discovery of the services can be achieved functional properties based on matching the inputs of the task.
based on functional classification and in- and output classifi- We distinguish between two different categories of matching:
cation. Non-functional properties are considered in the ranking match and no match:
step (see Step 4).
1. Match: The services within this group match some or
Matching based on functional classification all input data elements specified within the task. This
After the pre-filtering is completed, the services have to be group is suitable for further service delivery
filtered according to the function they offer. Therefor the ser- consideration without additional processing.
vices are classified according to the following categories: 2. No match: The needed inputs specified in the task are
1. Full Match: Services in this group do match according not fulfilled by this category. The services in this group
to the function classification requested in the task and require different data elements than the ones specified
don’t receive any penalty score during the ranking in the task and are considered for composition (see
process. step 3).
2. Partial Match: Services in this group do not match the All services, that are classified as subsumption, intersection or
function classification requested in the task, but the no match in at least one of the categories are not considered
function belongs to the same category (defined in the directly for the ranking step, but could be used in composition
semantic model) as the one specified within the task. (see step 3). Related SPARQL-based queries consider depend-
These services receive a penalty during ranking. encies of the functions, inputs, outputs and NFPs related to the
3. No Match: These services do not match according to semantic model. As all requirements are modeled using the
the functional classification requested from the task. developed WISE-DM ontology (see [14] for more details),
They are not considered during ranking. inference could be used to get more precise results in pre-
filtering and discovery.
The reason for defining those different categories is due to the
further handling of each category in the further process. In order to get more possibilities and freedom in requirements
provision, a composition of services can be generated where
Output Classification
outputs of service A can be used as the inputs for service B or
In this part the services are compared with the related task and both outputs can be combined to fulfill all the requirements
are classified based on their functional properties for the out- specified within the task.
puts. We distinguish between five different categories of
matching as illustrated in figure 2: Step 3: Composition
1. Exact match: The output data elements of the task and After the matching from the discovery step has been complet-
the ones from the service match perfectly. There are no ed, the resulting services are classified in the categories. While
additional data elements delivered by the service. all services classified as full match for functions, exact- and
2. Subsumption match: The service only delivers relevant plugin match for output classification and match for input
output data elements, but not all of the functional classification do fulfill all functional properties without further
requirements specified in the task are met, hence not all effort, some additional processing is needed to probably make
needed outputs are provided. use of all other classifications. This is where composition
comes in: all available services are arranged in groups where
3 http://json-ld.org/ the outputs of service A plus all the already obtained outputs
from other services fulfill the input of service B and so on.
948 M. Schweitzer et al. / Semantic Web Service Delivery in Healthcare Based on Functional and Non-Functional Properties

The result of this service chain must then fulfill the functional managed by the workflow manager. Those could be either
properties of the related task. A composed service can then used for further service calls, as a result presented to the user
again be part of other composed services. The complete com- interface or any other process function defined within the
position algorithm uses a graph-based structure as well as workflow.
modified pathfinding algorithms. However, the detailed de- Input: Service S, Goal G
scription would go beyond the scope of this paper. Output: Score of Service S

A challenging part of composition is the NFP merging pro- Ng = extracted NFPs of Goal G
cess, i.e. when combining the services to a group, also their Ns = extracted NFPs of Service S
NFPs have to be combined in a way that depends on the type score = 0;
of NFP. For example, for NFP “availability” the combined
for ns in Ns do {
value is the lowest value of all involved services, while for ng = getCorrespondingNfp(ns,Ng);
NFP “price” the combined value is the sum of all involved tempscore = ng.weight * callRankingService(ns, ng);
}
services. The logic of the NFP considerations needs to be de-
veloped as a special ranking service that will be part of the score = tempscore * functionPenaltyScore;
next steps in the project. For the present conceptualization it is return score;
seen as a black-box or as a module with defined logic that
follows a hardcoded pattern.
Step 4: Ranking Table 1 - Pseudocode of ranking algorithm. The “Goal”
relates to the extracted workflow task.
The ranking algorithm is responsible to find the best fitting
service of all registered and composed services according to Task 1
x Function: cardiovascular risk calculation
their NFPs. It takes as input the set of services (atomic or x Inputs: age,gender,total cholesterol,HDL cholesterol, blood pressure
composed) and generates a list of ranked services ordered by x Outputs: risk percentage
x NFP: Availability=Austria (mandatory), Costs=min
their ranking score, which is defined as a unit-less number.
During the ranking phase, all atomic or previously composed Service 1 Service 2
services get a ranking score based on how their NFPs fit com- x Function: cardiovascular risk x Function: Body Mass Index
pared to the ones specified in the task. The pseudocode of the calculation (BMI) calculation
x Inputs: age,gender,total x Inputs: body weight, body
algorithm can be found in code Table 1. cholesterol,HDL cholesterol, height, gender, age
The actual score is not directly calculated from the NFP in- blood pressure x Outputs: BMI, interpretation
x Outputs: risk percentage x NFP: Availability=Austria ,
formation (e.g. performance indicator), but is calculated via a x NFP: Availability=Austria , Costs=€8/100k calls
distinct ranking service. This service is specified in the NFPs’ Costs=€8/100k calls

ranking instructions and is called during the ranking process. Service 3 Service 4
The arguments for the ranking service are all instances of an x Function: cardiovascular risk x Function: cardiovascular risk
NFP from the task and the corresponding ones (same class) calculation calculation
x Inputs: age,gender,total x Inputs: total cholesterol,HDL
from the service. The idea of this ranking service is to define, cholesterol,HDL cholesterol cholesterol, blood pressure
what criteria makes a good or a bad score for a specified NFP, x Outputs: risk percentage, x Outputs: risk percentage
decision support x NFP: Availability=Germany
e.g. a ranking service for NFP costs determines, that a service x NFP: Availability=Austria , Costs=€8/100k calls
with high costs should lead to a lower score. Each ranking Costs=€10/100k calls
service reveals a number as the percentage of suitability,
which is then mapped to a score value for further calculations. Figure 3 - Example Web Services. All information is semanti-
The range of the score value is not predefined and can be ad- cally modeled and processed.
justed.
During the workflow creation, the physician can specify an Service selection example
individual NFP weight depending on how important the NFP
Let’s assume the physician wants to analyze the cardiovascu-
is considered on an individual base (  1). An NFP
lar risk (function) considering the data “age”, “gender”, “total
adds its score multiplied by its weight to the score of the ser-
cholesterol (mg/Dl)”, “HDL cholesterol (mg/Dl)” and “systol-
vice. The function penalty score (0 <     1) is
ic and diastolic blood pressure (mmHg)” (inputs) with a ser-
integrated according to the functional classification (see step
vice highly available in Austria and with minimal costs
2) to reduce the score in case of a partial match. The final
(NFPs). The output is given through a percentage score value
score defines the suitability of the service. A higher score
for “10-year risk of heart disease or stroke”. All this infor-
means, that more (or in the best case, all) NFPs are fulfilled by
mation is specified as a task and modeled semantically using
the service and thus increases the probability of getting select-
our developed ontologies. The considered task and the availa-
ed for further processing.
ble and registered services are depicted in figure 3. For
Step 5: Invocation demonstration purposes, the amount of NFPs has been limited
to Availability and Costs. Although some of the services in
The final phase in the service delivery process is the actual
this example share the same functionality, they differ in other
invocation of the service, which was previously discovered,
relevant properties such as in-/outputs and NFPs.
ranked and selected according to the highest ranking score.
Invocation enables the actual link between the semantic de- Considering the risk calculation task and the available services
scription of the service, according to the service model devel- in figure 3, Service 4 gets removed during pre-filtering, as the
oped in earlier stages of the project and the actual service im- mandatory NFP is not supported. Service 2 does not fulfill the
plementation. As we support various underlying implementa- function, and Service 1 and 3 will be considered for the fol-
tions of services (e.g. REST, WSDL) the invocation would lowing ranking. Service 1 would relate to an exact match for
need to provide a generic interface for calling a service, but output classification, Service 3 relates to a plugin match and
also be able to perform specific interaction calls, depending on both services are related to a match regarding the input classi-
the implementation of the service. Service usage including the fication. The ranking part would select Service 1 for final in-
service calls, related results and potential interaction will be vocation, as the NFPs of this service lead to a better score
 M. Schweitzer et al. / Semantic Web Service Delivery in Healthcare Based on Functional and Non-Functional Properties 949

(considered NFP cost of Service 1 with €8/100k calls has a even use the information for more sophisticated and efficient
better score than Service 3 with €10/100k). No composition is composition.
needed for this example.
Acknowledgements
Implementation
This work has been supported by the Austrian Science Foun-
The service delivery platform was developed as a Java appli- dation (FWF), project number P 25895-B24.
cation. Based on the semantic model from past project results,
the RDF model was used with Apache JENA 4 to model se- References
mantic dependencies during execution. The service delivery
platform was designed according to the principle of a SOA. [1] Hsu W, Taira RK, El-Saden S, Kangarloo H, Bui A a T. Context-based
This means every step in the delivery process was realized by electronic health record: Toward patient specific healthcare. IEEE Trans
a single decoupled service. The services themselves can be Inf Technol Biomed 2012;16:228–34.
[2] Schweitzer M, Lasierra N, Hoerbst A. Observing health professionals’
seen as black-boxes. They were realized using the Jersey workflow patterns for diabetes care - First steps towards an ontology for
RESTful web services framework 5 and communicate using EHR services. Stud Health Technol Inform 2015;210:25–9.
JSON-LD. A manager web service was then introduced to [3] Dolin R, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron P V, et al.
facilitate the use of the platform by bundling service calls to HL7 clinical document architecture, release 2. J Am Med Informatics
Assoc 2006;13:30–9.
the individual components to provide functionalities like, reg- [4] Bender D, Sartipi K. HL7 FHIR: An Agile and RESTful approach to
istering a new task or invoking a service based on a task. healthcare information exchange. Proc. 26th IEEE Int. Symp. Comput.
Med. Syst., IEEE; 2013, p. 326–31.
[5] Kruse CS, Kristof C, Jones B, Mitchell E, Martinez A. Barriers to
Discussion Electronic Health Record Adoption: a Systematic Literature Review. J
Med Syst 2016;40.
The developed Service Delivery Platform project is able to use [6] Unertl KM, Weinger MB, Johnson KB, Lorenzi NM. Describing and
Modeling Workflow and Information Flow in Chronic Disease Care. J
proper web services according to the business process model
Am Med Informatics Assoc 2009;16:826–36.
of the user related workflow. The workflow engine processes [7] Saleem JJ, Flanagan ME, Russ AL, McMullen CK, Elli L, Russell S a,
the tasks and allocates proper web services based on in- et al. You and me and the computer makes three: variations in exam
put/output data elements, functions and non-functional proper- room use of the electronic health record. J Am Med Inform Assoc
2014;21:e147-51.
ties. The discovery process got extended within this approach
[8] Raghupathi W, Kesh S. Interoperable Electronic Health Records
by using semantic technologies to find related suitable ser- Design:Towards a Service-Oriented Architecture. E-Service J
vices (e.g. when a data element or function shares the same 2007;5:39–57. doi:10.2979/ESJ.2007.5.3.39.
parent element, the parent or related siblings could be used as [9] Gooch P, Roudsari A. Computerization of workflows, guidelines, and
care pathways: a review of implementation challenges for process-
well) and composition, which uses semantic enriched service oriented health information systems. J Am Med Informatics Assoc
descriptions to compose several services in order to get the 2011;18:738–48.
needed result. In contrast to approaches like FHIR, which is a [10] Pavlovski CJ, Zou J. Non-Functional Requirements in Business Process
service-oriented approach for accessing EHR data, the service Modeling. Proc 5th Asia-Pacific Conf Concept Model 2008;79:103–12.
[11] Keller U, Lar R, Lausen H, Polleres A, Predoiu L, Toma I. Semantic
delivery platform is responsible for the user-determined func- Web Service Discovery. Semant Web Serv 2005:240–80.
tionality in the sense of how accessible EHR data should be [12] Schweitzer M, Hörbst A. An Approach for the Support of Semantic
processed to extract, use and present the needed information Workflows in Electronic Health Records. "In Press 2017.
related to the users’ needs. The project SMART (Substitutable [13] Rospocher M, Ghidini C, Serafini L. An ontology for the business
process modelling notation. Front Artif Intell Appl 2014;267:133–46.
Medical Applications and Reusable Technologies) on FHIR
[14] Lasierra N, Schweitzer M, Gorfer T, Toma I, Hoerbst A. Building a
[15] provides a platform for medical apps, that can be inte- semantic model to enhance the user’s perceived functionality of the
grated into EHR systems based on individual user preferences. EHR. Stud Health Technol Inform 2016;228:137–41.
The main difference to our approach is, that SMART does not [15] Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. SMART on
FHIR: a standards-based, interoperable apps platform for electronic
support the automatic discovery or composition of web ser- health records. J Am Med Inform Assoc 2016:1–10.
vices nor is it including non-functional properties for service
discovery in order to reach the goals defined as a workflow.
The service delivery platform as part of the ongoing project Address for correspondence
OntoHealth, will be refined based on future developments and Marco Schweitzer
will get its final evaluation at the end, when the complete
[email protected]
software prototype will be tested and evaluated with real
world scenarios and related end-users (physicians). https://ehealth.umit.at

Conclusion
Providing means for users to define their information retrieval
needs based on functional and non-functional properties at the
point of care offers new ways of efficient EHR utilization. A
workflow-based EHR-access is seen as a major advantage in
efficient healthcare outcomes and even in user satisfaction.
The next steps in the project will cover to enhance the usage
of the semantic model for leveraging the service delivery pro-
cess. This means, that related semantic reasons or related logic
should provide better results on matching the requirements
given from the workflow to the set of available services or

4 https://jena.apache.org/
5 https://jersey.java.net/