Linked Service System USDL (LSS-USDL) – Perspectives, definitions and objectives

After Cardoso, J, R Lopes, and G Poels – Service systems: Concepts, modeling, and programming – Ch 1 White-box service systems – 2014


Research on services has been approached from different directions, although some strands are more mature than others. This section provides an overview of the main contributions.

Technical Perspective

From a technical perspective there is a lot of work done regarding the description of software-based services, the description of service-based architectures, and service composition into higher-level business processes [8].

The interfaces of the popular web services have long been described using WSDL (Web Service Description Language), a machine-readable format that allows systems to find out how to perform invocations and what results to expect. Later efforts focused on adding semantics to those descriptions, giving rise to initiatives such as SAWSDL, OWL-S, and WSMO [9]. It became possible to account for domain knowledge and not just technical syntax.

Standards for the organization and behavior of registries (in essence, catalogs of available services) also emerged, notably UDDI, which, again, was later complemented by semantic extensions or variants that enabled the search of services by business goals and not just strictly by the service name. Several other standards, collectively known as the WS-* family, addressed issues such as policy, security, reliability, among others.

The shift from silo applications to pools of services, that could be recombined as needed, called for efforts to describe service-oriented architectures (SOA). SoaML [10] is such an initiative for the model-driven software engineering of services. It addresses, for instance, service requirements, dependencies, functional capabilities, policies for use and provision, partitioning, or constraints.Soon the need for a Reference Model for Service Oriented Architecture was felt, and SOA-RM was created [11]. SOA Ontology [12] is an alternative, in the form of ontology. Along the lines of SOA-RM, there is also the Reference Ontology for Semantic Service Oriented Architectures (RO-SOA) [13]. Orchestrating or choreographing services to achieve the end goal of a business process has been the focus of initiatives such as BPEL, BPMN, or WS-CDL [14].

All these efforts show the considerable progress that has been done so far in service-orientation from a technical point of view.

Business Perspective

From a business perspective, the most notable effort to represent and reason about business models, services, and value networks was the e3 family of ontologies, which included the e3service and e3value ontologies [15]. These initiatives constituted perhaps the most evolved suite able to reason about services and value networks from an economic perspective. The research has, however, not been much concerned with the computational and operational perspectives covering the actual enactment or interaction with services, nor with the technical issues related to enabling a web-scale deployment and adoption of these solutions.

Complementary work in this area is GoodRelations [16] (GR), which focused precisely on this last concern by introducing a vocabulary to describe products and services in a structured way so that, for example, web searches and comparisons could be more easily and systematically done by customers. Nonetheless, although GR originally aimed to support both services and products, in practice it has mostly been centered on products to the detriment of its coverage for modeling services.

Multiple Perspectives

Linked USDL (Unified Service Description Language) [17] was developed to fill an existing gap in service descriptions by proposing a specification language, which enabled the unified formalization of business, operational, and technical aspects. It takes a multi-perspective approach.The goal was to propose a language for describing business, software, or real-world services using computer-understandable specifications to make them tradable on the web [18].

Linked USDL takes the form of a normalized schema which is an approach used in many fields to facilitate the exchange of data and integration of information systems. For example, online social networks rely on FOAF to describe people and relationships; computer systems use WSDL to describe distributed software-based services; eCl@ss is used to describe products; and business-to-business systems use ebXML to describe transactions, orders, and invoices. Adding to these existing standards, Linked USDL describes services in a comprehensive way by providing a business or commercial envelope around services. Therefore, Linked USDL is seen has one of the foundational technologies for setting up emerging infrastructures for the Future Internet, web service ecosystems, and a web of services [19].


Despite the importance of the service sector, there is still no accepted definitions for the various terms related to the concept of service [2]. Different meanings have generated inconsistencies not only across disciplines, but also within them [23]. Therefore, it is necessary to disambiguate the meaning of service terms and provide clarifications to be used as a shared understanding.

According to the ITIL library, “a service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks” [24]. The W3C defines service as “an abstract resource that represents capability of performing tasks that form a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent” [25]. Hill states that “a service may be defined as a change in the condition of a person, or a good belonging to some economic unit, with the prior agreement of the former person or economic unit” [26].

Based on these definitions from various fields (e.g., IT management, computer science, and economics) and also from other authors (c.f. [2, 23, 27–29]), we can provide the following definition for the term service (from R Lopes, LaNDLESS: Integrating Linked Data with Linked Services, 2013):

Definition 1 service is a previously agreed exchange of competences and knowledge between a provider and a customer in order to provide value to both parties.

When studying services, we are faced with other terms that need clarification, namely service system, service model, service instances, service description, and business model.

A service system is described in the literature as “[…] a system comprised of facilitator and appraiser systems for generating value through the provision and consumption of services” [30], “[…] complex adaptive systems made up of people, […] dynamic and open, rather than simple and optimized” [2], among other definitions (e.g., [27, 29, 31–33]). Therefore, we can provide the following definition:

Definition 2 A service system is a collection of resources, stakeholders, processes and other service assets that, combined, enable value co-creation between producer and consumer.

Models “[…] help by letting us work at a higher level of abstraction […]by hiding or masking details, bringing out the big picture, or by focusing on different aspects”[34]. Their essence is abstraction: “[…] the removal of fickle and distracting detail of implementation technologies as well as the use of concepts that allow more direct expression of phenomena in the problem domain. […] the only effective means that we have of dealing with complexity that overwhelms our cognitive capacities” [35]. Crossing these statements with others in the literature (e.g., [36, 37]), we reach the following definition for service model:

Definition 3 A service model is an abstraction of a service system that highlights its structure, its elements, and the relations between elements, hiding its complex nature from who does not need to know it.

Modeling is the activity of creating abstractions and representations, i.e., models, of a service system to provide guidelines for its design, implementation, deployment, and management. Each service model is created to answer important questions about the characteristics, behavior, and structure of a service: M is a model of a service S if M can be used to answer questions about the characteristics and structures of service S.

Each service model is an abstraction of a service system. It is created through abstraction by ignoring some aspects of a service to highlight other more important characteristics. An abstraction is a generalization of content and/or suppression of details to allow for a broader view, decrease complexity, or focus on a specific viewpoint. A common way to raise the level of abstraction is to rely on models, architectures, business rules, and meta-models. The best model, indeed, should be the result of a balance between realism and simplicity since it is an abstract representation of reality. As a rule, and in most modeling efforts, details that are unnecessary are not included.

While the model consists of classes, representing things of significance for a service system and relationship assertions about associations between pairs of classes, a service instance assigns actual values for those classes.

[Note: R Lopes, LaNDLESS: Integrating Linked Data with Linked Services, 2013 provides a different discussion of Service model and a definition for service architecture:

The term architecture is defined by IEEE 1471 as “… the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles of its design and evolution.” Zachman, while explaining his framework for enterprise architecture, defines architecture as “… that set of design artifacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change).” [Zachman, J, Enterprise architecture: The issue of the century, 1997].  Cardoso et al states that service architectures “… look into the organization of software-based services, how they are connected, and what service information is exchanged between consumers and providers.” [Cardoso, J et al, Open Semantic Service Networks, 2012] Building on top of our service definition and these architecture definitions (including Kruchten’s contribution [Kruchten, P, The rational unified process: An introduction, 2004]), we can define service architecture as:

Definition 4 Service architecture is the set of rules and guidelines for the components, relationships and interfaces of the structural elements of a software-based service that guides the organization of that service.

Lopes then jumps to definition of business model.]

Definition 5 A service instance (or service description) is an instance of a model. It captures the information describing a particular service. It is the result or output of the activity of service modeling.

Service descriptions “[…] bring various ways to describe services ’interfaces using schema, models and semantics” [38]. A service description is a descriptive representation of (part of) a service system used to educate the different stakeholders about its properties and interactions.

[R Lopes adds: A WSDL service description “… indicates how potential clients are intended to interact with the described service. It represents an assertion that the described service fully implements and conforms to what the WSDL 2.0 document describes.” [Chinnici, R et al, Web services description language (WSDL) version 2.0 part 1, 2007]. Oberle et al argue that “Information systems such as a service marketplace will manage descriptions of a service and not the service itself. The service itself is an event (…) that can be executed arbitrary times used by different consumers” [Oberle, D, et al, Countering service information challenges in the internet of services, 2009]. Cardoso et al state that service descriptions “… bring various ways to describe services’ interfaces using schema, models and semantics” [Cardoso, J et al, Open Semantic Service Networks, 2012]. Hence we can define service description as follows: {and leads to definition of service instance (service description)}]

A business model is defined by Timmers [39] as “[…] an architecture for the product, service and information flows, including a description of the various business actors and their roles, a description of the potential benefits for the various business actors, and a description of the sources of revenue”. Osterwalder and Pigneur [40] state that “a business model describes the rationale of how an organization creates, delivers, and captures value”. Based on these descriptions and other definitions found in the literature (e.g., [41–44]), we can summarize the definition of business model as follows:

Definition 6 A business model is a conceptual representation of the business of an organization intended to describe its services, stakeholders, interactions, value propositions, explanations on how the organization meets customer goals, and how it makes profit.

Figure 1 builds on the terms explored previously to contextualize the scope of a service system model like the one we intend to develop. A business model is a higher-level model that contains many service systems. A service system is modeled by one or more service models, which may contain models for its internal elements, such as process models.

Levels of abstraction with business models, service models, and process models

Figure 1. Levels of abstraction with business models, service models, and process models.

Different stakeholders can “see” a service system from different views or perspectives by accessing various service descriptions (Figure 2).

Business models, service systems, service models, process models, and service descriptions

Figure 2. Business models, service systems, service models, process models, and service descriptions.

Since previous work mainly took a black-box approach, we now take the challenge of defining a model to describe a service system using a white-box approach. The model opens new doors for Service Science including service simulation and analytics and the automatic comparisons of different service systems. This is still a recent research field and, thus, not many contributions have been made so far. Most of them are conceptual.

This book approaches the development and implementation of a service system model by fulfilling four partial objectives:

  1. Conceptual Framework.The first objective was to conduct an extensive research to identify the most common service model concepts found in the literature (c.f. [7, 40, 45–49]). A framework was developed to compare and contrast existing approaches. The most important concepts and building blocks were identified and a conceptual model to capture service systems was developed.
  2. Model Implementation. The second objective was to implement the conceptual model. The implemented model, called Linked Service System for USDL (LSS-USDL), was built using Semantic Web technologies and its construction followed Linked Data principles [50]. The model was build with RDF, the standard for Linked Data, and reused existing vocabularies found in the Linked Data Cloud (to maximize compatibility and reusability and minimize engineering efforts) making use of the recent developments towards organizations and governments publishing data on the web [51].
  3. Service Programming. A third objective was to demonstrate how a real-world service system could be modeled with LSS-USDL and how it could be accessed and queried programmatically. The service system modeled was the Incident Management (IM) service from the Information Technology Infrastructure Library (ITIL), a set of best practices for IT service management widely adopted by large enterprises. The programming language used was Python since libraries to access and modify RDF models are available and are stable.
  4. Service Tooling. For the model to be accepted by managers, and other nontechnical service system modelers, tools need to be available. Hence, the fourth objective was to develop a tool that hides technical details and is easy to use and understand. This creates the challenge of hiding as much complexity as possible while still making full use of the capabilities of the model. It also requires a basic understanding about what is cognitively difficult for users and what metaphors may be used. Ideally, service description languages capturing different views should interoperate. It is possible to export/import an LSS-USDL service model into/from the Linked USDL service description language. This type of interoperability demonstrates that a black-box and white-box perspectives can co-exist.

The white-box perspective on services given by LSS-USDL brings several benefits for organizations. The degree of automation of service delivery and provisioning can increase since service systems are fully modeled with a computer-understandable language.

Previous: Linked Service System USDL (LSS-USDL) – Transparency of services
Next: x


  1. Robert Glushko and Lindsay Tabas. Designing service systems by bridging the front stage andback stage. Information Systems and e-Business Management, 7:407–427, 2009.
  2. Jim Spohrer, Paul Maglio, John Bailey, and Daniel Gruhl. Steps toward a science of service systems. Computer, 40(1):71–77, January 2007.
  3. Holger Luczak, Christian Gill, and Bernhard Sander. Architecture for Service Engineering The Design and Development of Industrial Service Work. In Dieter Spath and Klaus-Peter Fähnrich, editors, Advances in Services Innovations, pages 47–63. Springer, Berlin Heidelberg, 2007.
  4. Henry Chesbrough and Jim Spohrer. A research manifesto for services science. Communications of the ACM, 49(7):35–40, 2006.
  5. Paul Maglio, Savitha Srinivasan, Jeffrey Kreulen, and Jim Spohrer. Service systems, service scientists, SSME, and innovation. Communications of the ACM, 49(7):81–85, 2006.
  6. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing. Journal of Marketing, 68(1):1–17, 2004.
  7. Andreas Zolnowski, Martin Semmann, and Tilo Böhmann. Introducing a Co-Creation Perspective to Service Business Models. In Enterprise Modelling and Information Systems Architectures (EMISA), page 243, 2011.
  8. Thomas Erl. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice HallPTR, Upper Saddle River, NJ, USA, 2005.
  9. Carlos Pedrinaci, John Domingue, and Amit Sheth. Handbook on Semantic Web Technologies,volume Semantic Web Applications, chapter Semantic Web Services. Springer, 2010.
  10. Service oriented architecture Modeling Language (SoaML) Specification, 2012.
  11. Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter Brown, and Rebekah Metz. Reference Model for Service Oriented Architecture 1.0.
  12. The Open Group. Service-Oriented Architecture Ontology, 2010.
  13. John Domingue, Michal Zaremba, Barry Norton, Mick Kerrigan, Adrian Mocan, Alessio Carenini, EmiliaCimpian, Marc Haines, and James Scicluna. Reference Ontology for Semantic Service Oriented Architectures Version 1.0, 2008.
  14. Mike Papazoglou. Web Services: Principles and Technology. Prentice Hall, 2012.
  15. Hans Akkermans, Ziv Baida, Jaap Gordijn, Nieves Pena, Ander Altuna, and Inaki Laresgoiti. Value webs: Using ontologies to bundle real-world services. IEEE Intelligent Systems, 19(4):57–66, July 2004.
  16. Martin Hepp. GoodRelations Language Reference, 2011.
  17. Carlos Pedrinaci, Jorge Cardoso, and Torsten Leidig. Linked USDL: A Vocabulary for Webscale Service Trading. In 11th Extended Semantic Web Conference, Crete, Greece, May 2014.
  18. Jorge Cardoso, Alistair Barros, Norman May, and Uwe Kylau. Towards a unified service description language for the internet of services: Requirements and first developments. In Services Computing (SCC), 2010 IEEE International Conference on, pages 602–609. IEEE, 2010.
  19. Jorge Cardoso, Konrad Voigt, and Matthias Winkler. Service Engineering for The Internet ofServices. In Enterprise Information Systems X, volume 19, pages 17–25. Springer, 2008.
  20. ChristianBizer,TomHeath,andTimBerners-Lee.LinkedData-TheStorySoFar.InternationalJournal on Semantic Web and Information Systems, 5(3):1–22, 2009.
  21. Henry Chesbrough. Open innovation: The new imperative for creating and profiting fromtechnology. Harvard Business Press, 2003.
  22. Wil van der Aalst. Process Mining: Discovery, Conformance and Enhancement of BusinessProcesses. Springer Publishing Company, Incorporated, 1st edition, 2011.
  23. Roberta Ferrario, Nicola Guarino, Christian Janiesch, Tom Kiemes, Daniel Oberle, and FlorianProbst. Towards an ontological foundation of services science: The general service model. Wirtschaftsinformatik, Switzerland, pages 16–18, 2011.
  24. The Official Introduction to the ITIL Service Lifecycle. ITIL Series. Stationery Office,2007.
  25. Web services glossary, 2004.
  26. Peter Hill. On Goods and Services. Review of Income and Wealth, 23(4):315–38, 1977.
  27. Steven Alter. Service system fundamentals: Work system, value chain, and life cycle. IBMSystems Journal, 47(1):71–85, 2008.
  28. Roberta Ferrario and Nicola Guarino. Towards an ontological foundation for services science. Future Internet-FIS 2008, pages 152–169, 2009.
  29. Paul Maglio, Stephen Vargo, Nathan Caswell, and Jim Spohrer. The service system is the basic abstraction of service science. Information Systems and e-business Management, 7(4):395– 406, 2009.
  30. Manuel Mora, Rory O’Connor, Mahesh Raisinghani, Jorge Macías-Luévano, and Ovsei Gelman. An it service engineering and management framework (its-emf). International Journal of Service Science, Management, Engineering, and Technology (IJSSMET), 2(2):1–15, 2011.
  31. Ketki Dhanesha, Alan Hartman, and Anshu Jain. A model for designing generic services. InServices Computing, 2009. SCC’09. IEEE International Conference on, pages 435–442. IEEE, 2009.
  32. Manuel Mora, Mahesh Raisinghani, Ovsei Gelman, and Miguel-Angel Sicilia. Onto-servsys: A service system ontology. The Science of Service Systems, pages 151–173, 2011.
  33. Robert Glushko. Seven contexts for service system design. Handbook of service science, pages219–249, 2010.
  34. Introduction to OMG’s Unified Modeling Language (UML), 2012.
  35. Bran Selic. UML 2.0: Exploiting Abstration and Automation, 2004.
  36. Eva Söderström, Birger Andersson, Paul Johannesson, Erik Perjons, and Benkt Wangler.Towards a framework for comparing process modelling languages. In Advanced Information Systems Engineering, pages 600–611. Springer, 2006.
  37. Jang-Eui Hong and Doo-Hwan Bae. Software modeling and analysis using a hierarchical object-oriented Petri net. Information Sciences, 130(1):133–164, 2000.
  38. Jorge Cardoso, Carlos Pedrinaci, Torsten Leidig, Paulo Rupino, and Peter De Leenheer. Opensemantic service networks. In International Symposium on Services Science (ISSS), Leipzig, Germany, 2012.
  39. Paul Timmers. Business models for electronic markets. Electronic markets, 8(2):3–8, 1998.
  40. Alexander Osterwalder and Yves Pigneur. Business model generation: a handbook for visionaries, game changers, and challengers. Wiley, 2010.
  41. Mutaz Al-Debei. The design and engineering of innovative mobile data services: An ontological Framework founded on business model thinking. School of Information Systems, Computing and Mathematics, 2010.
  42. Edward Faber, Pieter Ballon, Harry Bouwman, Timber Haaker, Oscar Rietkerk, and MarcSteen. Designing business models for mobile ict services. In Workshop on concepts, metrics & visualization, at the 16th Bled Electronic Commerce Conference eTransformation, Bled, Slovenia, 2003.
  43. Joan Magretta. Why business models matter. Harvard business review, 80(5):86–93, 2002.
  44. Alexander Osterwalder, Yves Pigneur, and Christopher Tucci. Clarifying business models: Origins, present, and future of the concept. Communications of the association for Information Systems, 16(1):1–25, 2005.
  45. Rainer Alt and Hans-Dieter Zimmermann. Preface: introduction to special section-businessmodels. Electronic Markets, 11(1):3–9, 2001.
  46. Erwin Fielt. An Extended Business Model Canvas for Co-Creation and Partnering. http://, 2010
  47. Jim Spohrer and Paul Maglio. Service science: Toward a smarter planet. Introduction to serviceengineering, pages 3–30, 2009.
  48. Reuven Karni and Maya Kaner. An engineering tool for the conceptual design of service systems. Advances in Services Innovations, pages 65–83, 2007.
  49. Reasoning about substitute choices and preference ordering in e-services. In Advanced Information Systems Engineering, pages 390–404. Springer, 2008. 50. Tim Berners-Lee. Linked Data – Design Issues, 2006.
  50. Sebastian Speiser and Andreas Harth. Towards linked data services. In Proceedings of the 9th International Semantic Web Conference (ISWC), 2010.