Countering Service Information Challenges in the Internet of Services

Current trend witnesses the application of value networks, i. e., complex networks of social and technological resources that create economic value, also on the web (Basole and Rouse 2008, pp. 53–70; Speiser et al. 2008; Vervest 2005). Such occurrences of value networks are often called Future Business Value Networks or Business Webs (Kagermann and Österle 2006). The platform for realizing ad-hoc business webs is called Internet of Services (Heuser et al. 2008, p. 100), which is considered a comprehensive ecosystem, where services are deployed, published, discovered, delivered to different business channels through specialist intermediaries (e. g., payment, authentication, and mediation services), and monitored (Barros and Dumas 2006, pp. 31–37; Jensen and Kletzer 2005; Papazoglou 2003, pp. 3–12; Rai and Sambamurthy 2006, pp. 327–331; Rust and Kannan 2003, pp. 36–42).

We conjecture that the Internet of Services will certainly have to deal with a great variety and amount of information about services along several service information dimensions. We extend and refine upon Papazoglou (2003, pp. 3–12) who implied some of the dimensions: (1) Aspects: Service information can cover different types or aspects regarding the content level. One aspect could be legal service information comprising general terms and conditions. Another one could be technical service information, i. e., any information that a software engineer is interested in to invoke a service. (2) User roles: Different user roles will provide and use different aspects for describing the service. Software engineers will provide technical information, e. g., a WSDL description, if the service is delivered electronically. Legal experts might provide and interpret the general terms and conditions, and business experts might provide the pricing information. (3) Phase: The different kinds of information will be created and used in different phases of the service lifecycle. General terms and conditions might exist as soon as the service is offered; later on the broker might add special kinds of quality of service parameters. Feedback and ratings will exist only after service usage. (4) Location: The different kinds of information might be spread throughout the Internet of Services. Quality of service parameters might reside centrally on a platform or on the service provider’s page. Ratings might reside on a consumer community page. (5) Structure: The different kinds of information will be represented in different structured and unstructured formats. (6) Tools: The different aspects captured by the different user roles will be provided with different tools. A software engineer might use Eclipse to create a WSDL file for a Web Service. Eclipse will certainly not be a desired tool for legal or business experts.

Managing all dimensions in a central platform is certainly a doable task. However, as soon as brokerage, discovery, or community feedback parts are decentralized, there emerge service information challenges as described in the following. These challenges are also identified in Barrett et al. (2008), Basole and Rouse (2008, pp. 53–70), Nadhan (2004), Petrie (2008), and Vervest (2005) though with different labels. (a) Modeling: How can service information be modeled in a holistic and consistent way, capturing the intended meaning of terms, applying best practices, and enabling the traceability of modeling decisions? (b) Documentation: How to ensure documentation of the modeled information without media breaks? This includes formal knowledge representation as well as natural language descriptions and UI labels in multiple languages. (c) Interlinkage: Because of the different user roles, phases, locations, and structures, it is difficult if not impossible to weave service information. For example, how can a service rating on a consumer’s site be formally linked to service offering information on the broker’s site? (d) Interoperability: Along the same lines, different user roles should be able to author their information with heterogeneous tools. (e) Querying: Obtaining information in a structured way, e. g., “give me all services of type x which are cheaper than 5 € and have at least an average of 3 star rating” needs to be implemented. (f) Compliance: Information has to be processed and stored according to (international) specifications or policies, standards or laws. (g) Inconsistency: If a sensible information management is not in place, information will become inconsistent since different user roles might introduce the same kind of information independently and differently. (h) Cooperation: How can information be modularized such that different user roles can maintain and contribute information in different phases? Although belonging to the same service, a legal expert is not interested in the technical description of a service, for example. In addition, new service categories might have to be introduced, updated, and documented, others become obsolete, etc.

In this paper, we build and evaluate two artifacts to counter the challenges (a) to (h). The first artifact is a model according to Hevner et al. (2004, pp. 75–105) and comes in the form of a Service Ontology. The Service Ontology provides a holistic and consistent way of capturing service information responding to the challenges (a) modeling and (b) documentation. We apply the recommendations of the W3C Semantic Web Activity (constructs in the sense of Hevner et al. (2004, pp. 75–105)) which allows addressing challenges (c) interlinkage, (d) interoperability, as well as (e) querying. However, building and prescribing an ontology in standardized languages is not enough to address all challenges mentioned above. Therefore, the second artifact we provide is a method according to Hevner et al. (2004, pp. 75–105) that acts on the Service Ontology. The method is called Semantic Business Web approach, since we build on W3C Semantic Web standards, use and extend them in the Business Web setting. The Semantic Business Web approach is constituted by a service governance framework, guidelines for applying the W3C Semantic Web recommendations, a lifecycle-spanning tool chain, and different levels of applicability. The first two constituents represent standardized procedures to access the information and address the challenge (f) compliance. The latter two constituents tackle the issues of (g) inconsistency and (h) cooperation.

The paper is structured as follows: Section 2 discusses related work. Section 3 describes the Service Ontology and its construction in more detail. The Semantic Business Web approach acts on the Service Ontology and, therefore, the approach and its construction are described subsequently in Section 4. The evaluation of both artifacts follows in Section 5. In order to show the utility of both artifacts, we evaluate via a scenario carried out in the lighthouse project of the German Federal Ministry of Economics and Technology called THESEUS/TEXO.^{Footnote 1} The goal of TEXO is to make services tradable on the internet, composable into value-added services, and allows the integration of customized services into the environment of service consumers. Finally, we conclude in Section 6.

The paper contributes the Service Ontology and the Semantic Business Web approach. Consequently, we discuss related work and show how both the Service Ontology and the Semantic Business Web approach are progressive in comparison to the state-of-the-art.

2.1 Works related to the Service Ontology

There are many approaches that deal with capturing service information in different representation languages. In this section, we position our model, viz., the Service Ontology, to the efforts by means of what we believe are the five distinguishing criteria that set our model apart from related efforts: First, we distinguish between approaches that adopt a black box or glass box view. Efforts adopting a black box view focus on the aspects related to data and control flow considering mainly Web services and their interoperation. Our model follows a glass box view describing services in terms of their internal structure and properly characterizing service level agreements and non-functional attributes. Second, most approaches only contribute a model without a corresponding method. In contrast, we propose the Semantic Business Web approach including a service governance framework, guidelines for applying the W3C Semantic Web recommendations, a lifecycle-spanning tool chain, and different levels of applicability. The third criterion considers the construction of the model. Our ontology is constructed by an interdisciplinary team of experts in different areas such as legal, ratings, business models, etc. Each expert is devoted his or her own ontology module with an overarching governance body in place. Most efforts, however, are constructed solely by the authors and, thus, have a limited scope. Fourth, our ontology is built by applying best practices. Best practices comprise using a foundational ontology (e. g., (Gangemi et al. 2002, pp. 166–181)) for the sake of having a sound modeling starting point, the consideration of ontology quality criteria (Guarino et al. 2002, pp. 61–66), and the usage of ontology design patterns (Gangemi 2005, pp. 262–276) to avoid arbitrariness in modeling. In fact, best practices are rarely applied in existing service ontologies. An example of the advantages gained by applying best practices can be found in (Mika et al. 2004, pp. 563–572). The last criterion reflects whether the model is built using W3C Semantic Web recommendations.

The criteria are depicted as columns in Tab. 1. The efforts are listed per row and are grouped in the following categories. The first category represents ontologies in the field of Semantic Web Services (McIlraith et al. 2001, pp. 46–53) which has proven a popular research field in recent years. We only list here the most prominent efforts, viz., OWL-S (Ankolekar et al. 2001, pp. 411–430) and WSMO (Roman et al. 2006, pp. 516–522). Many surrounding and similar efforts have surfaced in literature, e. g., (Bansal et al. 2005, pp. 214–225). In summary, the ontologies differ in purpose, design, and content. According to the black box view, their purpose is mainly to automate the tasks of discovery, composition, etc., (cf. for instance, (Traverso and Pistore 2004; Vetere and Lenzerini 2005, pp. 887–903; Brogi et al. 2008)) while our Service Ontology captures the business content of a service which might not even be a technical Web service. In line with (Sycara 2007, pp. 8–15), we enable the semantic representation of business relations, general conditions, contracts, or business rules in a machine-understandable way. Also, ontologies of Semantic Web Service approaches are usually not built on a rigorous foundational ontology with explicit use of ontology design patterns in order to capture the intended meanings of terms and to achieve a clean design.

The second category is represented by Other Service-related Ontologies outside the field of Semantic Web Services. One instance belonging in this category is the OASIS Reference Ontology for Semantic Service Oriented Architectures (Domingue and Zaremba 2007) which is however not built on best practices and in a very early stage. Similarly, The Open Group currently drafts a reference ontology for Service-Oriented Architectures (SOA Ontology) (Harding 2008) from both the business and technical perspectives. Another effort is (Ferrario and Guarino 2008) which is founded on the basic principles of ontological analysis. In this view, services are modeled by means of a layered set of interrelated temporal activities, each one with its own participants and spatiotemporal location. In fact, this effort captures an ontologically sound glass box view on a service and is incorporated in our Service Ontology. Oberle et al. (2006, pp. 163–202) present a black box ontology built on best practices and with Semantic Web standards. The ontology of the OBELIX project by (Akkermans et al. 2004, pp. 57–66) focuses on describing the ecosystem and value chain relationships between services, aspects of service bundling, graphical modeling and does not build on best practices. Similarly, the work presented in (De Kinderen and Gordijn 2008a; De Kinderen and Gordijn 2008b, p. 318) introduces the e3Service ontology to model services from the perspective of the user needs. This offers constructs for service marketing, but in a computational way, such that automated reasoning support can be developed to match consumer needs with IT-services. The main focus of this work is to generate service bundles under the consideration of customer needs.

The third category is represented by UML-Based Efforts aiming to support model-driven software engineering for services. Bitsaki et al. (2008) introduces the Service Network Notation (SNN) which captures similar aspects to the e3Service ontology. However, SNN is an UML model. The UML Profile and Metamodel for Services (UPMS, (Berre 2008a)) is an effort from OMG (Object Management Group) that supports both top down and bottom up modeling, and utilizes UML collaboration diagrams and UML 2.0 component diagrams with a new concept of service interfaces. It is also linked into a business modeling framework with business process modeling (BPMN) and goal modeling (BMM). The Service-oriented architecture Modeling Language (SoaML) for UPML describes a UML profile and metamodel for the design of services within a service-oriented architecture. The goals of SoaML are to support the activities of service modeling and design and to fit into an overall model-driven development approach. The SoaML profile supports the range of modeling requirements for service-oriented architectures, including the specification of systems of services, the specification of individual service interfaces, and the specification of service implementations (Berre 2008b). The survey UML-based Modeling of Web Service Composition (WSC) gives an overview of different approaches, e. g., structure-based WSC Modeling, behavior-based WSC Modeling and hybrid WSC modeling etc. (Rauf et al. 2008) Emmerich (Emmrich 2005) uses UML to structure product-related services, such as maintenance, where the focus does not lie on model-driven software engineering, however.

Besides ontological formalizations of service information, there are several XML-based efforts. Most prominently, there is the recent W3C recommendation called SML (Service Modeling Language) (Pandit et al. 2009). SML offers support to build a rich set of constructs for creating and constraining models of complex IT services and systems. An SML-Model consists of interrelated XML documents, which contain information about parts of IT services and constraints. The constraints are captured with XML Schema documents and Rules documents. SML uses XML Schema and also defines a set of extensions to XML Schema to constrain references and Schematron (ISO/IEC 19757–3 2006) and XPath (Clark and DeRose 1999) for rules. An SML model could contain information about the parts of IT services, e. g., configuration, deployment, monitoring, capacity planning etc. Another early effort is the Universal Service Description Language (USDL) (Cardoso et al. 2009). USDL is basically a comprehensive XML Schema covering business and organizational aspects of a service. The PAS 1018 (Public Available Specification) by the German Institute for Standardization (DIN) DIN PAS 1018 (2002) describes standardized elements, e. g., service, provider, category, capability, etc. Emmrich (2005) describes a conceptual model for product-oriented services from different perspectives, e. g., product, enterprise, market and environment, and lifecycle. Both approaches DIN PAS 1018 (2002) and Emmrich (2005) are based on XML Schema. O’Sullivan (2006, p. 232) analyzes a set of existing informal service descriptions in order to identify relevant functional properties of a service. ORM (Object-Role Modeling) is used to represent the results also available as XML Schema serialization. The significant contribution of O’Sullivan also influences the design of the Service Ontology. For the sake of completeness, we would also like to mention the WS-* specifications, such as WSDL or WS-BPEL, which consider only Web services and assume a black box view.

Furthermore, there are informal efforts such as Alter (2008, pp. 71–85), O’Sullivan (2006, p. 232), or Baida et al. (2001) or DIN PAS 1018 (2002). The informal approaches share many similarities, in their main inspirations, with the abovementioned work of (Ferrario and Guarino 2008), and, thus, also to our work. That means they try to capture a glass box view with primary focus on the business aspects. For example, the German norm PAS1018 (Public Available Specification) describes elements, such as, service, provider, category, location, etc. in the form of a table to structure tenders.

2.2 Works related to the Semantic Business Web approach

One of the most striking differences between our work and the efforts mentioned above is that most of them do not feature an accompanying method according to (Hevner et al. 2004, pp. 75–105). However, there are other works that are related to our Semantic Business Web approach. As we will outline in Section 4, the Semantic Business Web approach consists of the service governance framework, guidelines for applying the W3C Semantic Web recommendations, a lifecycle-spanning tool chain, and different levels of applicability. Consequently, each of the four constituents is positioned to related work separately in the following four subsections.

Works related to the Service Governance Framework

Section 4.2 introduces the Service Governance Framework as part of the Semantic Business Web approach. Governance is a holistic long-term management model to exercise control and mitigate risk. It establishes organizational structures, processes, policies, and metrics to ensure that the adoption, implementation, operation and evolution of the subject is in line with the organization’s strategies and objectives and complies with laws, regulations, standards, and best practices. In relation to business webs, governance focuses on the decisions across the entire information lifecycle to enable organizations reaping the benefits of the Internet of Services.

There is no framework readily available for this task. However, numerous IT governance frameworks exist such as COBIT, ITIL, ValIT, ISO 20000, ISO 17799 (ISO 17799 Central 2006), etc. Each of them focuses on a specific aspect of a company’s IT governance. While the IT Infrastructure Library (ITIL), for example, mainly deals with management and support process definitions (Office of Governance Commerce 2007), the ISO 17799 standard primarily targets security management (International Organization for Standardization 2006). When these approaches are juxtaposed, they do not exclude but rather complement each other. In comparison, COBIT is a high level governance and control framework, more tightly aligned with the business objectives of an organization than with operational issues (IT Governance Institute 2007).

Concerning SOA and Service Governance, many software companies introduced their own definitions in white papers. A large number of different approaches have been proposed which cater for specific aspects of governance concerning an SOA that are clearly not covered by existing IT Governance frameworks. Some are limited to change management aspects of an SOA while others do not even include roles and accountabilities and predominantly cover service design. In summary, they lack framework scope and are often driven by own market interests (Janiesch et al. 2009; Niemann et al. 2009). To counter the service information challenges, a framework needs to address several requirements as argued above.

We already provided a comparison of related work in Niemann et al. (2008). An extended version is shown in Tab. 2. We investigate and assess service governance approaches along the following characteristics. Organizational Impact targets restructuring and introduction of governance positions or boards and correlates with the definition of roles and responsibilities. Maturity Models such as the CMMI (SEI 2007) or the one provided by Johannsen and Goeken (2007) help to assess a system by categorizing its processes into maturity levels. Measurement models such as a structured catalog of key performance indicators support the quantitative output and performance assessment of processes. Governance processes represent structured best practice activities in coarse and fine granularities that are linked to roles and organizational entities via the defined responsibilities. The last column shows the consideration of a distinct service lifecycle as part of the governance approach.

The main conclusion drawn from the survey is that in contrast to the analyzed approaches only our Service Governance Framework includes all of the specified characteristics. In particular, none of the investigated approaches focuses on the service information challenges identified in this paper. Currently, there is no other framework that specifies in detail how processes, roles and responsibilities, maturity levels, and goals and metrics need to be specified in a cooperative and interlinked scenario such as the Internet of Services.

Works related to guidelines for applying the W3C Semantic Web Recommendations

It is not only necessary to establish effective management processes which are properly measured and owned, but modeling also requires guidelines and conventions to provide meaningful models. Therefore, another constituent of the Semantic Business Web approach are guidelines for applying the W3C Semantic Web recommendations as discussed in Section 4.3. The W3C Semantic Web recommendations are OWL (McGuinness and van Harmelen 2004), SPARQL (Prud’hommeaux and Seaborne 2008), SA-WSDL (Farrell and Lausen 2007), and RDFa (Adida et al. 2008). Their standardization has already opened new possibilities for the service information challenge of (d) Interoperability since many tools, especially for OWL and SPARQL, are already available. OWL is used to formalize and distribute the Service Ontology. SPARQL can be used to query the distributed information structured by the Service Ontology. OWL, SA-WSDL, and RDFa allow interlinking the service information to each other and to existing sources, viz., WSDL and HTML, arbitrarily on the web. To the best of our knowledge, we are the first to give guidelines on how to apply the standards comprehensively in an Internet of Service setting.

Works related to the lifecycle-spanning tool chain

The Semantic Business Web approach proposes a lifecycle-spanning tool chain (cf. Section 4.4). The THESEUS/TEXO project introduces the service lifecycle consisting of the service innovation, offering, matchmaking, usage, and feedback phases (cf. also Section 5). Different project partners contribute different tools to the individual lifecycle phases such as the Service Browser (Bhatti and Weber 2009) for end users or the NeOn Toolkit (Tran et al. 2007, pp. 508–522) for expert ontology authoring. The novelty of our approach is to integrate the tools across all lifecycle phases via the Service Ontology and to propose a way to cope with changes and maintenance of service information in a multi-user and distributed environment through the reference processes of the Service Governance Framework.

Works related to different levels of applicability

Another constituent of the Semantic Business Web approach is the consideration of different levels of applicability (cf. Section 4.5). Introducing and working with different levels of applicability on an ontology was basically introduced by (Guarino 1998, pp. 315) who differentiates between the notion of reference and application ontologies. Reference ontologies are there to capture the intended meaning of terms serving as highly formal glossaries to facilitate mutual understanding. Application ontologies work at run time in information systems and are typically expressed in less expressive languages than reference ontologies to allow for efficient reasoning. This differentiation was refined by Guarino and Schneider (2002), and applied by Rosse and José (2003, pp. 478–500), Oberle (2005), or Oberle et al. (2007, pp. 156–174) in different settings. The Semantic Business Web approach goes beyond the mentioned efforts in that we allow for both reference and application purpose by a sensible modularization. Besides, the related efforts do not take into account different user roles and responsibilities.

In this section we discuss how an ontology has to look like in order to counter the service information challenges. We start by deriving requirements and, subsequently, design decisions in Section 3.1. The remaining sections detail the resulting artifact, i. e., the Service Ontology, and its construction.

3.1 From requirements to design

In the following we identify requirements that drive the overall design of the ontology. As depicted in Fig. 1, the service information challenges are the source of the requirements which in turn lead to design decisions.

From service information challenges to requirements and design decisions for the Service Ontology

Full size image

The first requirement, viz., avoid arbitrariness in modeling, is derived from challenges (a) and (b). We talk of arbitrariness of modeling when modeling decisions are taken in an irreproducible way. That means users are unable to reconstruct why and how something was modeled in the ontology. In order to counter the arbitrariness of modeling decisions one has to look at two levels. The first level considers what is actually modeled. Domain experts are required who can ground their modeling decisions in scientific literature of the corresponding domain. For example, we have to model pricing schemes for services what requires not only an ontology expert but also a business expert who can justify how a sensible pricing scheme must look like. Similar holds for the legal domain, technical domain etc. of services. Therefore, the THESEUS/TEXO project brings together experts in the field of the Internet of Services such as Lehmann and Buxmann (2009) whose first author happens to play the role of the business expert responsible for modeling pricing schemes. The experts need to be interoperable and therefore need to be integrated into a single, preferably concise, knowledge base. Domain knowledge, however, is distributed across the ontology building team. Therefore, a modular approach to ontology construction is required, where domain experts carry the main responsibility for their corresponding module. We basically follow Oberle et al. (2007, pp. 156–174) and build on a foundational ontology as a means to facilitate the integration of the remaining ontology modules in a collaborative way. Several group meetings are required over the course of the project to achieve a consistent and stable version of the Service Ontology where each expert was devoted his or her own module. Each expert is requested to align the module to the foundational ontology, thus avoiding common pitfalls and in order to disambiguate meanings and to explicate implicit design decisions from the very start. A governance body is put in place where ontology experts are required to work hand-in-hand with domain experts with little theoretical or hands-on experience in ontology engineering. In contrast to Oberle et al. (2007, pp. 156–174), the collaborative ontology engineering effort of the Service Ontology is supported by a collaboration server provided by TEXO partner ontoprise. A collaboration server is an ontology store that can be accessed remotely and collaboratively via ontology editors by ontology engineers.

The second level of arbitrariness of modeling considers how something is modeled. Here we distinguish between the coarse- and the fine-grained level. The coarse-grained level deals with the content structure where the use of ontology design patterns (Gangemi 2005, pp. 262–276) prescribe best practices. Such patterns capture recurrent issues in many domain modeling needs, independently of the particular modeling language adopted, such as patterns for modeling who does what, when and where?, which objects participate in a certain event?, what are the parts of something?, what’s an object made of?, etc. Consequently, we strive to apply existing patterns in the Service Ontology whenever possible in order to ground our modeling decisions. In contrast, the fine-grained level deals with issues such as naming conventions for classes and relations, prescriptions of applying UI labels and natural language documentations, etc. Therefore, we define and stipulate specific modeling guidelines which are not further discuss for the sake of brevity.

The second requirement depicted in Fig. 1 is called enable distribution of information and follows mainly from service information challenge (c). This challenge poses the question of how service information can be formally linked across the web. As already discussed in Section 2, the use of W3C Semantic Web Recommendations can meet this requirement. At the same time, the W3C Semantic Web Recommendations meet the fourth requirement of Standards compliance originating in the challenges (d) interoperability (e) querying. (d) stipulates that different user roles should be able to author their information with heterogeneous tools. This is enabled by using tools relying on the same representation languages W3C RDFS and W3C OWL. (e) asks for obtaining information from potentially distributed sources in a structured way. This is achieved by using the W3C SPARQL query language (Prud’hommeaux and Seaborne 2008).

Though the challenges of (f), (g), and (h) mainly affect the methodological aspects (cf. Section 4), they also entail the last requirement of the Service Ontology, viz., extensibility and specialization. The challenge of (f) compliance, e. g., requires that all information is stored in a future-proof format so that information is still accessible after years. We ensure this by using standardized languages. (h) is concerned with how the information can be modularized such that different user roles can maintain and contribute information in different phases. In essence, we need to capture stable core knowledge during the project by domain experts as explained above leading to a modularized core layer. However, we also need to enable specific industries to introduce their service categories and specialized knowledge. We expect that corresponding industry modules will be created and populated at run time. Finally, service providers need to be able to define concrete service descriptions leading to a separate instances layer.

Overview Service Ontology

Full size image

The resulting model, viz., the Service Ontology, is depicted by a pyramid in Fig. 2. The pyramid is a metaphor for the number of classes and relations that increases from top to bottom. The Service Ontology is specified in OWL-DL (McGuinness and van Harmelen 2004) and consists of several ontology modules. Each ontology module basically coincides with an OWL file that imports other OWL files. The modules are depicted as parts of the pyramid. The ontology modules can basically be divided into four layers according to the requirements: First, the upper level module consists of a concise foundational ontology providing us with a generic set of classes and relations as well as ontology design patterns. Second, a set of core modules consists of the Core Service Description module which captures information common to every service (e. g., service provider or quality of service parameter, etc.). In addition, different aspects of a service description (legal, business model, technical, rating, UI, etc.) are placed in separate modules and linked to the classes in the Core Service Description. All modules in this middle layer are aligned under the common roof of the foundational ontology. In doing so, we leverage the sound foundational ontology leading to a cleaner ontology design. Third, industry modules (e. g. automotive, healthcare, or public services modules) can be modeled by exploiting the aforementioned ontology modules. Finally, instances of the classes and relations (depicted as a mesh below the pyramid) can potentially be distributed across the Internet of Services.

The intended meaning of each class and relation is formally captured by axioms in the Service Ontology. In addition, OWL introduces standardized modeling primitives for natural language documentation and UI labels in multiple languages. Thus, the Service Ontology addresses both the challenges of (a) modeling and (b) documentation.

3.2 Foundation and core service description

After discussing the design decisions and construction of the ontology, let us now turn our attention to the artifact itself. We start off by looking at the Core Service Description module which plays a central role as its name suggests. The Core Service Description module contains information common to every service independent of a specific aspect or industry. As such it introduces the fundamental notions of service, service description, service provider, service consumer, service attribute etc., and defines their interrelationships. A formalization of the central module needs experts as well, so we collaborate with the authors of (Ferrario and Guarino 2008) who work on providing ontological foundations of service science. The outcome of this work is a reference axiomatization of the fundamental terms basically representing the Core Service Description module.

Ferrario and Guarino’s work relies on the DOLCE foundational ontology (Gangemi et al. 2002) which represents the Upper Level module. DOLCE serves the following purposes: (1) DOLCE can be used as a modeling starting point because it provides a basic set of generic classes and relations valid in any domain. Using a foundational ontology as a modeling basis means relating core classes and relations to some proposed invariant categories of human cognition (which are reflected in the foundational ontology itself). This prompts the ontology engineer to sharpen his notions with respect to the distinctions made in the foundational ontology. What is typically gained is an increased understanding of one’s own ontology as well as a cleaner design. (2) DOLCE also provides ontology design patterns (Gangemi 2005, pp. 262–276) as best practices for reoccurring modeling needs. One such pattern used later on is called Descriptions & Situations (Gangemi and Mika 2003, pp. 689–706) which allows expressing views or context-specific information.

Two central notions of the module are the classes called Service and ServiceDescription. What is the difference between both classes with respect to their intended meaning? Information systems such as a service marketplace will manage descriptions of a service and not the service itself. The service itself is an event according to DOLCE that can be executed arbitrary times used by different consumers. DOLCE provides us with an ontology design pattern, viz., Descriptions & Situations, which prescribes a best practice on how to capture descriptions in a generic way. We apply and specialize this pattern to capture the intended meaning of a ServiceDescription. Using such patterns avoids arbitrariness in modeling and gives guidelines to the ontology engineer – an advantage that is usually neglected by related efforts.

3.3 Core modules

The Core Service Description has adjacent ontology modules each of them concerned with a specific thematic aspect. That means the classes and relations of such modules concentrate on subjects such as legal issues, ratings, service classification schemes, UI-related information, business model (pricing in particular), etc. We separate such aspects from the common aspects of the Core Service Description following formal modularization criteria according to Cuenca Grau et al. (2007, pp. 298–303). Such a holistic and interdisciplinary approach, in combination with a sensible modularization, has not been undertaken by related efforts. The reasons for applying this kind of modularization are as follows: (1) the overall Service Ontology will otherwise be too complex. (2) A modularized approach will allow for coarse-grained views, e. g., legal experts are enabled to only import and work with their module and to omit technical aspects. (3) Modularization favors the interdisciplinary and collaborative modeling as discussed in Section 3.1.

Despite the complexity and size of the ontology, we would like to give a glimpse of the overall interconnection between the modules, the Core Service Description, the industry modules (Section 3.4), and instances (Section 3.5) in Fig. 3. As outlined above, the Core Service Description module contains necessary information common to every service and independent of a specific industry or aspect.

Modules of the Service Ontology in more detail. The classes and relations framed in boxes correspond to the parts of the pyramid in Fig. 2. The non-framed classes and relations at the bottom correspond to the “instances spread in the Internet of Services” of Fig. 2. Dotted lines represent relations identified by the given label. Lines with a white triangular arrow represent the specialization (subclass-of) relation. Note that many classes and relations are omitted for the sake of brevity

Full size image

The Legal module contains the major judicial information around a service. For instance, the module introduces that a service might obey to some regulation as depicted in Fig. 3. Also, each service expresses the general terms and conditions following Gangemi (2007, pp. 65–85) who introduces special ontology design patterns to express such information. The Legal module depends on the Core Service Description module, and, thus, has to import it to be fully understandable.

Further modules depicted in Fig. 2 but not discussed here are: the Rating, Functional, Business Model, UI, Classifications, Workflow, Idea, and Integration modules. Additional modules can be added as required. We briefly discuss the contents of the remaining modules which are currently developed. As already indicated in Fig. 3, the Rating module formalizes the structure of a rating with relations to the user and attributes such as number of stars, and text description. The Functional module contains everything a developer has to know about the service: the location of a service archive, links to WSDL files, or other WS* descriptors etc. The Business Model module is mainly concerned with defining pricing information which can become quite complex. In our running example, we oversimplified the pricing information to a simple attribute for the sake of brevity. The UI module addresses information relevant if the service is integrated in the consumer’s UI. The Classifications module basically contains existing product and service classifications, such as UNSPSC or eClass schemes, in an ontologized format. This allows classifying services to such existing scheme in a formal manner as presented in (Hepp 2006, pp. 72–99). The Workflow module proposes means to describe the process structure as well as pre and post conditions. The Idea module (Riedl et al. 2009) is an application-internal ontology for the Innovation Cockpit developed by TEXO partners (cf. Section 5). Finally, the Integration module aims to declaratively capture details of how to interface between an existing application and a given service.

3.4 Industry modules

The core knowledge specified in the Core Service Description and adjacent aspect-related core modules discussed above can be specialized for specific industries. Industries can define their own hierarchies of service categories as subclasses of csd:ServiceDescription. We expect that the modules will be populated at run-time by industry consortia or the like (please also refer to Section 4.2).

In order to give an idea of this procedure we refer again to Fig. 3 where a tiny part of the automotive industry module is depicted. The automotive module of the Service Ontology contains information specific to the automotive industry. Therefore, this module might introduce the notion of an auto:EcoCalculatorServiceDescription service category as special kind of csd:ServiceDescription.^{Footnote 2} The difference between both is that the first always has to obey an Eco-calculator regulation and has to specify all of the three following csd:QoSParameters: csd:Availability, csd:ErrorRate, csd:ResponseTime. It is exactly this knowledge that is captured by the Service Ontology and allows asking competency questions à la “what is the difference between an Eco-calculator service description and a general service description?,” “what are the necessary parts of a service description?” etc. Fig. 4 shows this knowledge encoded in OWL Abstract Syntax (Patel-Schneider and Horrocks 2004) including the natural language documentation and UI labels.

Knowledge representation in OWL syntax

Full size image

The automotive module basically introduces all categories of services that are valid in this industry (another example would be the category of a material lookup service) and further classes and relations required.

3.5 Instances

The bottom of Fig. 3 shows some of the instances which can potentially reside anywhere on the web. For instance, the fictional company CDE of our scenario in Section 5 instantiates a concrete auto:EcoCalculatorServiceDescription along a price description and concrete quality of service values (not shown). The information resides at http://www.cde.de in an OWL document. Further, the CDE service obeys the eu:Eco-Label whose description resides at http://eur-lex.europa.eu. We also assume that a rating was given at an external service rating Wiki that links to this concrete service description.

Building and prescribing our model, viz., the Service Ontology, by the W3C Semantic Web recommendations allows countering the challenges (a) to (e). For the challenges (f) compliance, (g) inconsistencies, and (h) cooperation we need to consider methodological issues, such as processes to maintain the model. Therefore, the second artifact we provide is a method that acts on the Service Ontology to counter (f), (g), and (h).

4.1 From requirements to design

In the following we identify requirements that drive the overall design of the Semantic Business Web approach. As depicted in Fig. 5, the service information challenges are the source of the requirements which in turn lead to design decisions. As argued above, the requirements (a) to (e) are mainly covered by the Service Ontology. However, from a methodological perspective, these challenges still have an influence on design decisions of the Semantic Business Web approach.

From service information challenges to requirements and design decisions for the Semantic Business Web approach

Full size image

Let us start our discussion with the requirement called standards, policy and law compliance which is mainly fueled by the service information challenge of (f) compliance. This challenge poses the question of how service information can be formally managed in an Internet of Services setting. As already discussed in Section 2, the use of W3C Semantic Web Recommendations can support this requirement as they provide a standardized and open means to represent service information. Also, Guidelines for applying the W3C Semantic Web recommendations are indispensable. However, on their own, these guidelines are insufficient from a methodological perspective as they only support the processes of interlinking service information. The organizational management of information access and maintenance must be provided by a larger, holistic Service Governance Framework. Governance frameworks are used to achieve compliance of IT and the organization with various requirements of internal and external stakeholders. Internal stakeholders are those, who are somehow related to the Service Ontology and its direct application. The requirements of internal stakeholders are often driven by economic considerations, e. g., the increase of profitability, to improve the quality of the offered information, or the advancement of the reputation of the ontology. Other aspects are more control-oriented with respect to the employed staff, e. g., the prevention of fraud by the application of the four eye principle and sign-off rules. But also political goals can influence parts of the requirements of internal stakeholders.

Various legal and regulatory requirements also have a strong impact on the Service Ontology and therefore have to be reflected by the governance framework. These requirements can be divided into branch-independent and branch-dependent legal requirements and regulations. An example for a branch-independent requirement is the European directive 95/46/EC for personal data protection: the EU directive addresses the protection of personal data with respect to its processing and movement of such data. It is implemented in the EU partner countries by national laws. An example of a branch-dependent requirement is the Health Insurance Portability and Accountability Act of 1996 (HIPAA). The act addresses all healthcare providers and companies related to the health care sector and defines rules, e. g., for data protection of patient data.

We derive necessary procedures and responsibilities for a service governance framework that has a dedicated perspective for the service information challenges. Governance frameworks are also the foundation of risk management. In the case of information governance this refers to inconsistent or outdated service descriptions, unauthorized changes, data entry or processing errors, or fraudulent behavior that can have massive impact on the stakeholders. Implications range from loss of customers or their satisfaction, via trust and reputation loss at the service platform to incorrect billing due to wrong categorization or pricing schemata at the service provider side. Risk management and information governance target these severe yet avoidable legal and cost intensive implications.

The requirement ensure desired behaviour in distributed environment is derived from challenges (a), (b), and (c). While the ontology is designed in a way that arbitrariness in modeling is minimized, we still need to ensure that in a distributed environment proper procedures are in place to govern information in the service lifecycle. This involves, e. g., the correct use of modeling languages and modeling patterns. This requirement is also met by the Service Governance Framework as well as the guidelines mentioned above.

The requirement tool interoperability across lifecycle phases originates in the challenges (c), (d), and (e). It is a direct consequence of the requirement to enable distribution of information as outlined earlier. The challenges of interlinkage, interoperability, and querying of information can only be tackled in a holistic way with an integrated, service lifecycle-spanning tool chain.

Finally, the requirement distributed and cooperative access to specific information modules is derived from the challenges (g) and (h) and clearly articulates the need for an overarching framework to govern the modeling and maintenance processes and tools as argued before. While most of the issues that are addressed by this requirement can be tackled with governance, guidelines, and integrated tool support, the socio-technical aspect of information access has been disregarded so far. Information is always accessed individually. This often leads to inconsistencies and problems when cooperating. Therefore, we introduce different levels of applicability to narrow the scope of operation of each individual accessing the information by means of modules.

The Semantic Business Web approach is constituted by the Service Governance Framework, guidelines for applying the W3C Semantic Web recommendations, a lifecycle-spanning tool chain as well as different levels of applicability

Full size image

The four design decisions discussed above represent the constituents of our Semantic Business Web approach depicted in Fig. 6. We discuss each of the four constituents in more detail in the following subsections.

4.2 Service Governance Framework

After deriving design decisions in the previous section, let us now discuss the first constituent of the Semantic Business Web approach, viz., our Service Governance Framework. Governance and coordinated distribution of responsibilities are necessary to counter the particular challenges of (f) compliance, (g) inconsistencies, and (h) cooperation. The Service Governance Framework developed in the THESEUS/TEXO project consists of four main areas: a process framework, a stakeholder map, a measurement framework, and a maturity framework. For the sake of brevity, we focus on the process framework and the stakeholder map in the following.

The process framework cares for governance of service description processes throughout the service lifecycle. The service lifecycle loops between the innovation, offering, matchmaking, usage, and feedback phases. In the following, we would like to discuss the different phases and their corresponding processes relevant for service description. The innovation phase allows for new business models and new consumption and development paradigms. Governance processes regulate variant management and the setup of maintenance processes related to service description, i. e., the ontology. In the offering phase, services are supplied to the market. Once a service is designed and developed, it needs to be turned into a commercial offer. In order to create a commercial offer out of a service implementation, several parameters need to be described and published on a service marketplace. In this phase, it is important that uniform/ defined guidelines for service description are adhered to, i. e., standards, naming conventions, and defined description as well as ontology maintenance procedures including defined responsibilities, etc. The matchmaking phase denominates the process of matching a service provider’s service offer to a service consumer’s service need, i. e. the central application of service description. Processes for description governance cover the monitoring of this application, as well as ontology consistency checks, the monitoring of the use and meaning of terms used in the ontology, and trend analyses. They precede the usage phase in the service lifecycle: the delivery of services. The process framework prescribes the verification and monitoring of adherence to description guidelines on both instance and schema level, i. e., the assurance of certification of compliance with the current description guidelines. Feedback for future iterations of the service lifecycle concerning description governance is channeled back to the service provider during the feedback phase. This includes the analysis of the feedback from the applications monitoring, as well as the change of maintenance processes.

The stakeholder map contains role descriptions and their relation to the processes. Generally, in the Internet of Services, several main stakeholders have been identified: service provider, service broker or intermediary, and service consumer (Barros and Dumas 2006, pp. 31–37). While the service consumer and the service provider are companies or natural persons, the service broker is a virtual entity, a marketplace, or a piece of software. Nonetheless, it is operated by actual persons. In the context of THESEUS/TEXO, the emphasis is on the complete service lifecycle, including the inception of a service and its after-sales, i. e., the community around a marketplace. As outlined above, the service might involve a piece of software. However, supporting stakeholders, such as the platform host, need to be established.

The Service Governance Framework is a superset that generally contains more processes and stakeholders than needed in a specific case. Consequently, the framework has to be configured to the needs of the deploying organization by various characterizing attributes. We provide, e. g., maturity levels, capability profiles, or focus areas to facilitate the customization for an individual application scenario. A focus area describes topics that have to be addressed to successfully govern an enterprise and groups related processes. Examples for focus areas are risk, resource or information.

Considering the focus area of information the platform host distinguishes the roles of ontology engineers, an ontology governance council, and several industry councils to maintain the Service Ontology centrally. Each service provider employs people who support different aspects of service development such as service engineers, business experts, and legal experts. The governance framework prescribes a number of processes to be executed by these roles. We exemplify them in Tab. 3. The focus area information is structured into two subdomains: concrete service description (i. e., instances of the Service Ontology) and Service Ontology setup and maintenance (considering only the schema level of Service Ontology modules). While the first supports the actual service description processes done at provider side, the latter targets the maintenance processes for classes and relations of Service Ontology modules at platform side.

The framework can be applied to the Service Ontology in the following way: the Upper Level is pure reuse of a foundational ontology, maintained by the ontology engineer. The core modules, i. e., Core Service Description, Legal, Functional, Rating modules etc., are maintained and prescribed by the platform enacted through a master governance council. The industry domain modules (automotive, healthcare, etc.) are maintained and governed by industry-specific sub-platforms or industry councils. The industry councils report to the master governance council if changes in the core layer are required. The master governance council consolidates modeling requirements and reflects them in the middle part (e. g., if two or more industry councils need the same extension). Industry councils collect feedback and requirements from service providers in their domain. Finally, service providers are responsible for providing information to their specific services, modeling and interlinking them.

For example, several providers might demand the addition of a new service category for eco-calculator services. The platform provider has to capture knowledge (in an ideal case formally, informally, and in multiple languages) that such services can potentially fulfill different types of eco regulations, and have to provide the following three types of quality of service parameters: response time, availability, and error rate. In addition, the platform provider might check whether its definition of the new category is consistent with potential definitions in other platforms. This corresponds to adding a new service class in the automotive module.

4.3 Guidelines for applying the W3C Semantic Web Recommendations

The second constituent of the Semantic Business Web approach are guidelines for applying the W3C Semantic Web Recommendations. This constituent is mainly concerned with the service information challenge of (c) interlinkage which is twofold. The first type of interlinkage considers relating information within the scope of the ontology. As an example consider an ontological relation between a service description and a rating or that of service description and its general terms and conditions. This type of interlinkage is defined by the Service Ontology modules as discussed in Section 3 and can be instantiated accordingly (as indicated by the edges in the mesh at the bottom of the pyramid in Fig. 6).

Second, and more importantly, ontologically described service information can be linked to existing WSDL, XML-Schema, or HTML resources (as indicated on the left hand side of Fig. 7). In the case of WSDL and XML-Schema, we can apply the W3C recommendation called SA-WSDL (Semantic Annotations for WSDL) (Farrell and Lausen 2007) to establish the link. The idea here is to enrich an existing web service interface description with all remaining information such as general terms, quality of service parameters, or ratings. Since our approach considers services in general and is not limited to technical web services, we would like to establish the same interlinkage between a natural language service description given, e. g., on an HTML page, describing the service for potential consumers on the platform or even on the provider’s site, and its structured ontological representations. This is possible by applying the W3C RDFa recommendation (Adida et al. 2008). Note that in all cases, the interlinked information might reside anywhere on the web.

When adhering to such guidelines, service descriptions are eligible for search functionality such as Yahoo! SearchMonkey^{Footnote 3} or Google Rich Snippets. Both harvest RDFa annotations of web pages thus allowing the creation of specialized search engines with improved result presentation.

4.4 Lifecycle-spanning tool chain

The THESEUS/TEXO project introduces a service lifecycle consisting of the service innovation, offering, matchmaking, usage, and feedback phases (Fig. 6). Every phase is targeted at different user roles and, consequently, different tools. However, each phase and tool requires interoperability with the adjacent phase and tool, probably at different locations. Therefore, our approach suggests applying the Service Ontology throughout all phases. While the concrete service descriptions, i. e., instances of the ontology, might be distributed across the web, the Service Ontology modules reside in one or more collaboration servers. A collaboration server is a remotely accessible ontology store which allows ontology engineers to simultaneously author the ontology modules.^{Footnote 4} The collaboration server also features content management functionality. For example, the ontology engineer responsible for maintaining the automotive module might submit change requests to the Core Service Description residing in the realm of the platform provider. The responsible ontology engineer of the platform provider might accept or reject this request or propose an alternative. Besides the collaboration server, this requires tools for expert ontology authoring. Thus, the collaboration server allows (h) cooperation to enable and facilitate the governance process outlined in Section 4.2.

As mentioned above, service providers are responsible to author their concrete service descriptions (e. g., the response time of a specific service) but also service consumers might provide feedback or service brokers might provide additional quality of service information. In all cases, such concrete service information is represented as instances adhering to the ontology, relations between instances, and concrete attribute values. Consequently, end-user tools for lookup, editing, and visualization of such instance information have to be provided for different user roles in different phases of the lifecycle. We give concrete examples of such tools in Section 5. Tool interoperability (cf. challenge (d)) is facilitated a great deal by relying on W3C standards since many tools for OWL editing and visualization are already available. In turn, this facilitates (h) cooperation also for the end-user side. Furthermore, (e) querying becomes possible by the W3C SPARQL recommendation which is intended as distributed “SQL” for information represented by the W3C Semantic Web recommendations.

4.5 Different levels of applicability

The bars on the right hand side in Fig. 6 classify the modules of the Service Ontology in different levels of applicability. The levels allow choosing the right module with respect to the specificity of the modeled information, to choose the target user, and to omit specific modules at run time. We detail the bars in the remainder of this section. Although the difference with respect to specificity and relevance has been introduced before, the Semantic Business Web approach goes beyond the mentioned efforts in that we allow for both reference and application purpose of a specific ontology module by a sensible modularization. Besides, the related efforts do not take into account different target users.

(i) Specificity: The specificity of the modeled information increases from top to bottom. While the foundational ontology in the upper level contains generic knowledge, the modules on the lower layers contain knowledge specific to an industry domain (e. g., the class of an EcoCalculatorServiceDescription in the automotive module as discussed in Section 3.4). In between, we have knowledge that is specific to services but independent of the domain. For example, the notions of service description or quality of service parameters in the Core Service Description module (cf. Section 3.2) or the notion of general terms in the Legal module. (ii) Target User: Corresponding to the specificity of the service information, the upper layer can only be understood and maintained by ontology engineers. As discussed in Section 3.2, the upper level module and foundational parts of the core service description module contain intricate notions and ontology design patterns that require in-depth expertise. In contrast, the lower layers should contain information that is fully comprehensible by an end-user. (iii) Relevance: The Upper Level ensures a clean design of the overall Service Ontology by prescribing ontology design patterns and quality criteria for modeling. Therefore, the upper part of the Service Ontology is rather relevant at design time, and, thus, can be omitted at runtime since the end-user might not even be able to understand its generic notions. Vice versa, the industry domain modules at the bottom are the ones which are populated, edited, maintained, and displayed during runtime of the platform.

In order to show the utility of both artifacts, we evaluate via the scenario of the lighthouse project of the German Federal Ministry of Economics and Technology called TEXO (also discussed in (Bhatti and Weber 2009); (Janiesch et al. 2008, pp. 71–79)).^{Footnote 5} The goal of TEXO is to provide a platform which makes services tradable on the internet, composable into value-added services, and allows the integration of customized services into the environment of service consumers. The so far fictional TEXO scenario is about the automotive manufacturing industry in Europe. It assumes a platform, called Service4Engineers, for offering, looking up, trading, and maintaining services related to the automotive manufacturing industry. Service4Engineers applies the Service Governance Framework and makes use of its best practice processes to support a uniform service description as well as consistent ontology maintenance. Therefore, Service4Engineers keeps control of processes for risk minimization and ensures traceability. The scenario further assumes that the European Union has recently introduced a voluntary scheme for the automotive manufacturing industry to encourage businesses to market products and services that are environment-friendly. This scheme should eventually allow public and private consumers to easily identify environment-friendly products by an Eco-label. In fact, the Eco-label is non-fictional and is currently discussed by the European parliament.

Concrete tools for realizing the Semantic Business Web approach in our scenario

Full size image

In the following, we show an exemplary instantiation of the Semantic Business Web approach by walking through the stages of the TEXO service lifecycle (Fig. 7). The fictional company CDE GmbH plays a major role in the scenario with its innovative eco-calculator service.

Service innovation phase

Let us assume that different communities in the web, e. g., blogs and message boards, are discussing the Eco-label as potential candidate for new value-adding services. Such new ideas can be discovered with the TEXO Innovation Cockpit (Stathelet al. 2008) contributed by TEXO partners Fraunhofer IAO and TU Munich, which allows performing the following tasks:

• identification and processing of Eco-label relevant user discussions in blogs and message boards

• identification and presentation of news items and press releases related to the user’s area of interest

• specification of new service ideas according to the Idea module of the Service Ontology

Let us further assume that three experts, viz., chemist C, developer D, and environmentalist E, use the Innovation Cockpit and find that providing an eco-calculator service would be a value addition for the automotive industry. An eco-calculator service takes the bill of material of a product as input and calculates an eco-value, e. g., the amount of CO₂ generated by manufacturing the product, given a specific Eco-label. Consequently, they decide to combine their expertise and launch a spin-off called CDE to develop a specific eco-calculator service. At this point, it is important for the Service4Engineers platform to set up variant management or adjust it, respectively, as well as to define or adjust ontology maintenance processes in order to allow for the description of new services.

Service offering phase

In the service offering phase, the idea for an Eco-calculator is realized by CDE. Consequently, CDE would like to publish their service on the Service4Engineers platform. For publication, service information has to be provided by different employees of CDE. The legal expert will provide the general terms and conditions. The software engineer will provide technical aspects, and the business expert will provide the pricing information. Here, the challenges of (h) cooperation and (d) interoperability come into play. All three employees have to provide their information in cooperation potentially with different tools in an interoperable way. In order to respond to their need, we apply the commercially available Knowledge Portal of TEXO partner intelligent Views. The Knowledge Portal can be used CDE-internally to author the information but also as a web presentation to the public. It is an end user tool, so that no separate ontology engineer is needed to enter service information. The resulting OWL file can be published on CDE’s web site and registered on the Service4Engineers platform. In case the service categories on the Service4Engineers platform were insufficient, if, e. g., there was no category for services with an emphasis on ecological aspects, this could be escalated by the service engineer to the industry councils and the master governance council by the process described in Section 4.2. An exemplary OWL description is depicted in Fig. 8.

http://www.cde.de/eco-calc.owl – the OWL description of CDE’s Eco-calculator. As can be seen, this ontology imports the automotive module which resides on the Service4Engineers platform

Full size image

In addition, CDE might also want to publish an HTML site to advertise the service for human users on its page. In order to formally link both natural language HTML and formal OWL description, the W3C RDFa recommendation can be used. First, it is possible to apply the link tag to point to the OWL file shown in Fig. 8 (cf. Fig. 9). Second, instead of having a separate OWL file, the HTML document can be fully annotated with inline RDFa tags.

http://www.cde.de/eco-calc.html – the HTML page of the service also points to the OWL document depicted in Fig. 8 via the link/meta tag

Full size image

The actual Eco-calculator web service is also residing on CDE’s page. Consequently, CDE is publishing the WSDL file on their web server. Similar to the link between HTML and OWL, we can now establish the formal link between the technical interface description given by WSDL and all the remaining information given as instance of EcoCalculatorServiceDescription in OWL. For this purpose, the W3C has introduced Semantic Annotations for WSDL (SA-WSDL) as depicted in Fig. 10.

http://www.cde.de/eco-calc.wsdl – the WSDL file of CDE’s Eco-calculator service points to the corresponding instance in the OWL document depicted in Fig. 8 via SA-WSDL

Full size image

Service matchmaking phase

In the service matchmaking phase, we switch our view to a potential service consumer, called David, who works in the design department of a car seats manufacturer. David would like to make his car seats compliant to the EU regulations and the Eco-label. Therefore, he consults the Service4Engineers platform and looks for a suitable service providing him an eco-value for the car seat bill of material. This step has to address the challenges of (e) querying, (d) interoperability, and (c) interlinkage. David is looking for all eco-calculator services which are cheaper than 5 € and have at least an average of 3 star rating. The platform combines several discovery techniques (statistical, natural language processing, etc.) provided by TEXO partners to obtain a sensible set of results. Among them, the platform applies structured SPARQL queries to the contents of the platform, an external service rating wiki, as well as an additional broker.^{Footnote 6} As indicated at the bottom of Fig. 11, the whole interlinked graph of information can be queried.

SPARQL query for obtaining all eco-calculator services which are cheaper than 5 € and have at least an average of 3 star rating from distributed sources

Full size image

Let us assume that four specific instances of auto:EcoCalculatorServiceDescription are discovered. The results are visualized and explored by the Fraunhofer IGD Service Browser (Bhatti and Weber 2009) developed in TEXO. David browses and navigates the results (e. g., the concrete quality of service parameters) and finally chooses CDE’s Eco-calculator. Visualization tools such as the Service Browser exploit the documentation of the Service Ontology. UI labels and natural language descriptions of terms are taken from the ontology and can be switched according to the preferred language. In the background, governance processes are in place to ensure that David’s search results are analyzed. Such analyses can be used to optimize the search results for future searches by further evolving and improving the information representation in the Service Ontology.

Service usage phase

David applies the Eco-calculator service by CDE in the service usage phase. Consequently, he configures his car seat with proper materials in order to be compliant with the Eco-Label. The service is certified to be compliant with the current description guidelines prescribed by the governance framework. David is assured that no changes to relevant classes of the ontology occurred since the service was first searched for. During the usage phase of the service, David uses his Product Lifecycle Management (PLM) application to adapt the car seat’s bill of material such that the eco-value conforms to the EU regulation. The CDE Eco-calculator provides a widget that can be integrated in the PLM application. UI elements of this widget are described using the UI ontology module. This allows context-aware assistance for the service as developed by TEXO partner Fraunhofer IGD for David since he has to familiarize with buttons and text fields of the widget.

Service feedback phase

Since David is satisfied with the Eco-calculator service offered by CDE, he would like to give his appraisal. This step represents the service feedback phase. The Service4Engineers platform does not provide any means for giving consumer feedback. Consequently, many consumer sites have emerged outside the realm of the platform. One of them, i. e., http://www.service-rating.com/, applies an extension of the Semantic MediaWiki technology^{Footnote 7} (Krötzsch et al. 2006, pp. 935–942; Hansch et al. 2009, pp. 211–215), provided by TEXO partner ontoprise, as well as the Rating module of the Service Ontology, to structure its contents. Here, each Wiki page coincides with one instance of ServiceRating in the Rating ontology module. Individual consumer ratings are attached to the site as comments with the number of stars, short, and long description. As shown in Fig. 3, the relation rating:appraises references the cde:eco-calc instance residing at http://www.cde.de/eco-calc.owl. The contents of each Wiki page can be dynamically retrieved via an RDF(S)/OWL export. The Wiki also offers a complete export of all ratings (http://www.service-rating.com/contents.owl) as sketched in Fig. 12. The ontology engineer can analyze the feedback and derive improvements of the Service Ontology. The improvements can be discussed in the master governance council for approval.

http://www.service-rating.com/contents.owl – the dynamic OWL export of the rating Wiki. The appraises relation links to the instance on CDE’s page

Full size image

We argue that the Internet of Services has to deal with service information along several information dimensions. This leads to challenges (a) to (h) addressed in this paper. We contribute both a Service Ontology and an accompanying Semantic Business Web approach. Both design artifacts, in combination with the W3C Semantic Web recommendations, allow us to counter the service information challenges. Fig. 13 summarizes the paper in a schematic way.

Service information challenges, their origin, and remedy

Full size image

For future work, we will further extend and refine the ontology in cooperation with the TEXO expert team. The TEXO scenario will be evaluated with industrial partners. We expect important feedback to refine the Semantic Business Web approach by this exercise.