Modeling Service Systems with LSS-USDL

After Cardoso, Lopes, and Poels – Service systems, concepts, and modeling – Ch 4 Modeling and programming (2014).

Here we consider how a service system can be modeled with LSS-USDL using semantic web languages and technologies. Later we will consider:

  • how a service system model can be accessed and queried programmatically (we chose Python because stable software libraries to access and modify RDF models are available)
  • how a service system model can be annotated with background knowledge from the Linked Data Cloud (we chose DBpedia since it is one of the largest existing knowledge basis)


The methodology we have followed consisted in

  • looking at the IM service as a flow of interactions
  • using the LSS-USDL model to capture each interaction

In other words, each interaction was analyzed by answering the questions: who, why, where, when, what, and how. The answers to these questions provided detailed information about the more relevant interaction features, such as: roles, goals, locations, time, resources, and processes, completing the model information.


The modeling exercise with Turtle and using the LSS-USDL model begins by specifying a set of prefixes. Prefixes are a convenient method for representing a name space URI with a short string. Prefixes facilitate the reference to other ontologies in an easy and unambiguous way. Each prefix refers to a basilar ontology which is used to model the service.

There are some common ontologies used by many models or instances: rdf, rdfs, owl, and xml. The most specialized ontologies we have used are:

  • GoodRelations (gr) [1] references the GoodRelations ontology, a standardized vocabulary to describe product, price, store, and company data.
  • Friend of a Friend (foaf) is an ontology describing persons, their activities, and their relations to other people and objects.
  • Time Ontology (time) covers basic temporal relations. The ontology allows to capture temporal relationships such as before and during.

The use of external vocabularies and ontologies enables to integrate the service instance to a large base of knowledge made available by many organizations and initiatives.


As a first step to build our IM service instance, we define a new instance of service system named IncidentManagementService. It is a new class that inherits all the properties of the class lss-usdl:ServiceSystem. To provide descriptive information to this new service, we used the RDFS predicates label, comments, and the LSS-USDL term hasGoal. See lines 1–4 of Listing 4.2.

The incident management service handles incidents (e.g., failures, questions, or queries reported by users) and consists of the following steps:

  1. Identification
  2. Logging
  3. Classification
  4. Prioritization
  5. Diagnosis
  6. Escalation
  7. Investigation and diagnosis
  8. Resolution and recovery
  9. Closure

Steps were captured as instances of lss-usdl:Interaction with the predicate hasInteraction (Listing 4.2, lines 6–14). Thus, IncidentIdentification, IndicentLogging, etc. are instances of lss-usdl:Interaction.

  1. :IncidentManagementService  an lss-usdl:ServiceSystem ;
  2. rdfs:label “ITIL Incident Management Service”;
  3. rdfs:comment “A service system for Incident Management, based on ITIL specs. The main objective of the incident management process is to resume the regular state of affairs as quickly as possible and minimize the impact on business processes.” ;
  4. lss-usdl:hasGoal :SolveIncident ;
  5. lss-usdl:hasInteraction
  6. :IncidentIdentification ,
  7. :IncidentLogging ,
  8. :IncidentClassification ,
  9. :IncidentPrioritization ,
  10. :InitialDiagnosis ,
  11. :IncidentEscalation ,
  12. :InvestigationDiagnosis ,
  13. :ResolutionRecovery ,
  14. :IncidentClosure .

Listing 4.2 The first building block to construct a service system.

The following sections will detail how each interaction was modeled.

4.2.3 Interactions

Since there are nine interactions (i.e. nine instances of lss-usdl:Interaction, we will only describe two of them, which is sufficient to illustrate how modeling is performed: IncidentLogging and Initial Diagnosis. The complete specification of the interactions can be found at http:// Each interaction answers to six questions: who (roles), why (goals), where (locations), what (resources), when (time), and how (processes). Incident Logging

Essential step in managing incidents is to receive and record them. This is carried out by the Incident Logging interaction. When it is determined that an incident has occurred through a Service Desk telephone call or automatically detected via an event alert, the logging interaction will document the incident. All relevant information describing the incident must be logged so that a full historical record is maintained. Logging should at a minimum record the date and time of the incident, the person/system reporting the incident, and a description of the problem. Listing 4.3 shows the complete specification for this interaction.

  1. :IncidentLogging  a lss-usdl:BackstageInteraction ;
  2. rdfs:label “An incident is logged”;
  3. rdfs:comment”Incidents reported to the Service Desk must be logged with the date and time stamp when they were generated.” ;
  4. lss-usdl:performedBy :ServiceDeskManager ;
  5. lss-usdl:hasGoal :DealWithReportedIncident ;
  6. lss-usdl:hasLocation :ABCompany ;
  7. lss-usdl:belongsToProcess :ITServiceIncidentManagement ;
  8. lss-usdl:consumesResource :ReportData ;
  9. lss-usdl:consumesResource :IncidentData ;
  10. lss-usdl:createsResource :IncidentID ;
  11. lss-usdl:createsResource :IncidentRecord .
  12. lss-usdl:hasTime
  13. [a lss-usdl:Time ;
  14. lss-usdl:hasTemporalEntity :IncidentLoggingTime] ;
  15. :IncidentLoggingTime a time:ProperInterval ;
  16. time:intervalAfter :IncidentIdentificationTime ;
  17. time:intervalBefore :IncidentCategorizationTime .

Listing 4.3 The Incident Identification interaction.

The example illustrates that the interaction is described as a Backstage Interaction, which is performed by the ServiceDeskManager role; it has the DealWithReportedIncident goal; it is performed at the ABCompany location; it belongs to the ITServiceIncidentManagement process; it consumes two knowledge resources (IncidentData and ReportData) and it creates two knowledge resources (IncidentID and IncidentRecord). The interaction has also a temporal entity associated which allows specifying that this interaction occurs before the IncidentCategorization interaction and after the Incident Identification interaction.

The knowledge resources IncidentData and ReportData typically include the following information:

  • Basic information needed to handle the incident, such as date and time of the occurrence, description of the incident, and systems affected.
  • Supporting information for the resolution of the incident that may be asked to the submitter using, possibly, a specific form.

The IncidentRecord will aggregate these information and will assign a reference to the incident to uniquely identify it in both internal processes and when communicating with the person affected by the incident. Initial Diagnosis

The Initial Diagnosis is the fourth step in the incident management process.It follows the incident categorization. The initial diagnosis is the first attempt at resolving an incident. Typically, the technical staff of the Service Desk will carry out an initial diagnosis and will try to understand the incident being reported.He will try to discover the full symptoms of the incident, determine what went wrong, and how to solve the problem. If available, diagnostic scripts and known error information is valuable in allowing an earlier and accurate diagnosis. The interaction described in Listing 4.4 represents the initial diagnosis of an incident performed by the technical staff of the Service Desk.

  1. :InitialDiagnosis a lss-usdl:BackstageInteraction ;
  2. rdfs:label “An initial diagnosis for the incident is performed”;
  3. rdfs:comment”The initial diagnosis of incidents is mainly a human process. The Service Desk technical staff looks at the information within the incident and communicates with the user to diagnose the problem.” ;
  4. lss-usdl:performedBy :TechnicalStaff ;
  5. lss-usdl:hasGoal :HandleIncident ;
  6. lss-usdl:hasTime [a lss-usdl:Time ;
  7. lss-usdl:hasTemporalEntity :InitialDiagnosisTime] ;
  8. lss-usdl:hasLocation :ABCompany ;
  9. lss-usdl:belongsToProcess :ITServiceIncidentManagement ;
  10. lss-usdl:consumesResource :IncidentRecord .
  11. :IncidentInitialDiagnosisTime a time:ProperInterval ;
  12. time:intervalAfter :DetermineIfIncidentIsMajorTime ;
  13. time:intervalBefore :DetermineIfFunctionalScalationIsNeededTime .

Listing 4.4 The Initial Diagnosis.

The interaction is described as a BackstageInteraction which is performed by the ServiceDeskStaff role; it has the HandleIncident goal; it is performed at the ABCompanylocation;it belongs to the ITServiceIncident Management process and it consumes the knowledge resource Incident Report.The interaction has also a temporal entity associated, which allows specifying that it occurs before the DetermineIfFuntionalScalationIsNeeded Time interaction and after the DetermineIfIncidentIsMajorTime interaction.

4.2.4 Roles

Each interaction has a performedBy predicate indicating who is participating in the interaction. In some cases, there are many roles for the same interaction. Roles can belong to an entity. In such a case, the concept Business Entities from GoodRelations is used. While the number of roles depends on the ITIL implementation that a company chooses to make, we have compiled a list of 5 roles which are typical:

  • Service Desk Manager. Functions as the primary point of contact for incidents reported from users. The role owns the results of the service desk function.
  • Problem Manager. Responsible for managing the life-cycle of all problems. The primary objectives are to prevent incidents from happening and to minimize the impact of incidents that cannot be prevented.
  • Incident Manager. The role assigned to the person who owns the results of the Incident Management service and of its effective implementation.
  • Technical Staff. Aggregates the first,second,and third-tier support groups,including specialist support groups and external service providers.
  • End User. The end users and employees of a company that experience difficulties with IT and which rely on services to restore a normal processing as quickly as possible after an incident has occurred.

Listing 4.5 describes these roles using the LSS-USDL model.Each role has a label and a brief description as well as an assignment to a business entity it belongs to.Most of the roles belong to the ABCompany company, except the role ProblemManager which belong to the ExtCompany company.

  1. :ServiceDeskManager a lss-usdl:Role ;
  2. rdfs:label “Service Desk Manager”;
  3. rdfs:comment”Functions as the primary point of contact for incidents reported from users.”;
  4. lss-usdl:belongsToBusinessEntity :ABCompany.
  5. :ProblemManager a lss-usdl:Role ;
  6. rdfs:label”Problem Manager”;
  7. rdfs:comment”Responsible for managing the lifecycle of all problems.”;
  8. lss-usdl:belongsToBusinessEntity :ExtCompany .
  9. :IncidentManager a lss-usdl:Role ;
  10. rdfs:label”Incident Manager”;
  11. rdfs:comment”The person who owns the results of the Incident Management service”;
  12. lss-usdl:belongsToBusinessEntity :ABCompany .
  13. :TechnicalStaff a lss-usdl:Role ;
  14. rdfs:label”Technical Staff”;
  15. rdfs:comment”Support technical staff”;
  16. lss-usdl:belongsToBusinessEntity :ABCCompany .
  17. :EndUser a lss-usdl:Role ;
  18. rdfs:label”End User”;
  19. rdfs:comment”The end users and employees of a company that experience difficulties with IT.” ;
  20. lss-usdl:belongsToBusinessEntity :ABCompany .

Listing 4.5 Modeling roles and business entities

Not all the roles defined were used in the examples of this chapter. The objective was to show how role modeling can be achieved. To structure and organize the many roles that can exist, the knowledge organization systems SKOS can be used to construct a classification schema or a taxonomy.

4.2.5 Goals

The concept of goal has been used in many domains such as business sciences and strategic planning. The objective is to provide a planning framework which links goals with interactions. It is intended to assist ITIL service owners in understanding the effects of interactions on services.

Each interaction has a one, or more, hasGoal predicate(s), indicating the goal(s) a specific interaction occurs. Listing 4.6 shows examples of several goals.

  1. :ReportIncident a lss-usdl:Goal ;
  2. rdfs:label “Report Incident”;
  3. rdfs:comment”A user, technical staff or system reports an incident regarding an IT service.”.
  4. :HandleIncident a lss-usdl:Goal ;
  5. rdfs:label”Handle Incident”;
  6. rdfs:comment”Execute several actions to deal with a reported incident.”.
  7. :RestoreNormalOperation a lss-usdl:Goal ;
  8. rdfs:label”Restore Operation”;
  9. rdfs:comment”Restore the normal service operation as quickly as possible.” .

Listing 4.6 Modeling the goals of interactions.

Since goals are targets for achievements, they should be written in such a way that they express the rationale for the interactions that exist and guides decisions at various levels within the enterprise. Here again, the SKOS can be used to organize goals using, e.g., structured controlled vocabularies.

4.2.6 Locations

The class lss-usdl:Location is concerned with the geographical location of the IM service interactions. Locations can be expressed simply as a list of the places where interactions occur, or they can take a more detailed form by describing how locations are related or detailing the facilities/IT that are available in each location.

Each interaction has a hasLocation predicate indicating where the interaction happens. For the IM service, we have identified two locations: the ServiceDesk Office and the UserOffice. The ServiceDeskOffice represents the location where a user or system can report an incident and the UserOffice location refers to the location where the company staff is working.

  1. :ServiceDeskOffice a lss-usdl:Location ;
  2. rdfs:label “Service Desk Office”.
  3. :UserOffice a lss-usdl:Location ;
  4. rdfs:label”User Office” .

Listing 4.7 Modeling locations within a service system.

The Listing 4.7 shows the definition of both locations. While these locations are concepts that only have a meaning for the company implementing the IM service, another approach to use geographical descriptions. This can be achieved by using, e.g., the GeoNames ontology, a data structure containing over 8.5 million geographical names. The information covers coordinates, administrative divisions, postal codes, amongst others. GeoNames can answer questions such as what are the coordinates for a location; which region or province does a location belong to; and what city or address is near a given GPS latitude / longitude.

4.2.7 Time

Each interaction uses a hasTime predicate to indicate when it occurs. The Time ontology is used for temporal reasoning. Typically, two time modeling options can be defined. The first one, used in this example, defines temporal relationships between interactions using constructs such as before or after.The second,uses time intervals of times point to define when an interaction can occur or occurs. Listing 4.8 exemplifies the use of the concept ProperInterval to describe the temporal dependencies between interactions.

  1. :IncidentIdentificationTime a time:ProperInterval;
  2. time:intervalAfter :IncidentCategorizationTime .
  3. :IncidentCategorizationTime a time:ProperInterval;
  4. time:intervalBefore :IncidentIdentificationTime;
  5. time:intervalAfter :IncidentPrioritizationTime .
  6. :IncidentPrioritizationTime a time:ProperInterval;
  7. time:intervalBefore :IncidentCategorization;
  8. time:intervalAfter :InitialDiagnosisTime .
  9. :InitialDiagnosisTime a time:ProperInterval;
  10. time:intervalBefore :IncidentPrioritizationTime;
  11. time:intervalAfter :InvestigationDiagnosisTime .
  12. time:intervalBefore :InitialDiagnosisTime;
  13. time:intervalAfter :ResolutionRecoveryTime;
  14. time:intervalEquals :scalationFirstTime .
  15. :ResolutionRecoveryTime a time:ProperInterval;
  16. time:intervalBefore :InvestigationDiagnosisTime;
  17. time:intervalAfter :IncidentClosureTime;
  18. time:intervalEquals :scalationSecondTime .
  19. :IncidentClosureTime a time:ProperInterval;
  20. time:intervalBefore :ResolutionRecoveryTime.
  21. :scalationFirstTime a time:TemporalEntity;
  22. rdfs:label “Scalation time for first level”;
  23. rdfs:comment”Need to define hasDurationDescription”.
  24. :scalationSecondTime a time:TemporalEntity;
  25. rdfs:label”Scalation time for second level”;
  26. rdfs:comment”Need to define hasDurationDescription” .

Listing 4.8 Modeling time within a service system.

4.2.8 Resources

Interactions can use the receivesResource, consumesResource, createsResource, or returnsResource predicate to indicate the resources received, consumed, created, or returned. For the IM service, we have defined that the interaction IncidentLogging consumes knowledge from the user in the form of ReportData and IncidentData and creates two new resources: IncidentID and IncidentRecord. Listing 4.9 defines the resource IncidentRecord.

  1. :IncidentRecord a lss-usdl:KnowledgeResource ;
  2. rdfs:label “Incident Record”;
  3. rdfs:comment”An Incident Record generated during the IncidentLogging” ;
  4. owl:sameAs dbpediar:Incident_report .
  5. :Severity a rdf:Property ;
  6. rdfs:domain :IncidentRecord ; 8 rdfs:range xsd:integer .

Listing 4.9 Modeling the resources associated with interactions.

Naturally, the IncidentRecord should include more fields, besides Severity, to reflect the complexity of records, which describe an incident. Our example is simple to convey the principle of resource and their descriptions.

4.2.9 Process

Each interaction belongs to a business process model (concept), which can be specified using the property belongsToProcess (see Listing 4.3). In turn, the process model can be associated with an implementation, which can be made using, e.g., the Business Process Modeling Notation (BPMN) or Event-driven Process Chain (EPC) notations.

  1. :ITServiceIncidentManagement a lss-usdl:Process ;
  2. rdfs:label “Incident Management Business Process Model” ;
  3. lss-usdl:hasBPMN bpmnrep:IM_BPMN .

Listing 4.10 Modeling the process to which interactions belong.

Listing 4.10 shows a process model ITServiceIncidentManagement created to exemplify the use of the property hasBPMN to associate an implementation with the model, which, in this case, can be accessed at bpmnrep:IM_BPMN. While LSS-USDL only includes one property to attach BPMN processes to a service system, this was done as a proof of concept and additional properties can be specified to relate interactions with other process modeling languages.


  1. Jan Van Bon, Arjen de Jong, and Axel Kolthof. Foundations of IT Service Management based on ITIL. Van Haren Publishing, 2007.
  2. Kerstin Gerke, Jorge Cardoso, and Alexander Claus. Measuring the compliance of processeswith reference models. In 17th International Conference on Cooperative Information Systems (CoopIS), Algarve, Portugal, 2009. Springer.
  3. Martin Hepp. Goodrelations: An ontology for describing products and services offers on theweb. In Knowledge Engineering: Practice and Patterns, pages 329–346. Springer, 2008.
  4. ITIL Service Operation. ITIL Series. Stationery Office, 2007.
  1. 2 Step-by-step modeling
  2. 2.1 Prefixes and external vocabularies
  3. 2.2 The Service System

Installing the LSS-UDSL Visual Editor

Cardoso et al. developed this web app in Ruby, using the Ruby on Rails framework – so if you don’t have Ruby installed in your computer, you need to install it. Follow this link for all the information on how to install Ruby on your platform.

This application is versioned in Git, so if you don’t have Git installed, you should also install it. Follow this link for all the information on how to install Git on your platform.

If you want to run this application on your computer and not on a production server, you also need to install the database SQLite, to store the information even when you exit the editor. Follow this link for the installation instructions. If you are configuring a production environment, then you should install PostgreSQL instead.

The first step to set up this app on your computer is to clone the Git repository. To do so, type the following in your terminal:

git clone

This will copy all the necessary files to the directory lss-usdl_editor. To go to that directory:

cd lss-usdl_editor

Now you need to install the required dependencies. If you don’t have the Bundler gem installed:

gem install bundler

Now to install all other required gems:

bundle install

In order to save data we need to have a database and the right schema. We use the SQLite database because it is great for lightweight usage. If you are setting up a production environment, then the database is PostgreSQL. The required commands to generate the database and schema are:

rake db:create
rake db:migrate

Initially, I received an error message – no Javascript runtime – solution:

If you have CentOS 6.x, and have enabled the EPEL repository, you can use yum to install node/npm:

sudo yum install npm

After the installation is complete, check to make sure node is setup properly:

$ node -v
# Returns v0.10.36

Set up the database again:

rake db:create
rake db:migrate

This process creates these tables:

  • users
  • service_systems
  • goals
  • process_entities
  • business_entities
  • roles
  • resources
  • locations
  • interactions
  • interactions_roles
  • goals_interactions
  • interactions_locations
  • interactions_processes
  • interactions_receives_resources

Now everything is set. To start the application:

cd lss-usdl_editor
rails server


=> Booting Thin
=> Rails 3.2.12 application starting in development on
=> Call with -d to detach
=> Ctrl-C to shutdown server
>> Thin web server (v1.5.1 codename Straight Razor)
>> Maximum connections set to 1024
>> Listening on, CTRL+C to stop

Useful links

  • Linked Service Systems for USDL: Open source repository of the LSS-USDL model.
  • USDL Incubator Group: LSS-USDL is part of the research for service systems by the USDL research group.
  • Linked USDL: Similar project, focusing on service descriptions for customers. The third use case found in LSS-USDL’s repository shows a service system modeled both in LSS-USDL and Linked USDL.
  • Linked USDL core: Repository for the core module of Linked USDL. The other modules may be found under the same Github profile.
  • Semantic Web: Technologies such as RDF are a core component of LSS-USDL.

Installing Rails

On CentOS, the default version of Ruby installed is 1.8.7. Some Ruby applications (like Rails) require Ruby version 1.9 and higher, so they cannot run properly on stock CentOS.

If you already installed ruby and ruby-devel packages with yum before, remove them first before upgrading Ruby.

sudo yum remove ruby ruby-devel

The Ruby Version Manager – RVM – is the simplest means of getting the latest Ruby interpreter (version 2.1.0) installed on a VPS running CentOS .

As the first step, we need some development tools – but even before that, I found I was missing an XML Parser – so let’s install that and then get the development tools:

perl -MCPAN -e 'install XML::Parser'
yum groupinstall -y development

To download and install RVM:

curl -L | bash -s stable

To download and install RVM, run the following (the gpg2 command is to address an authentication failure in the curl):

gpg2 --keyserver hkp:// --recv-keys D39DC0E3
curl -L | bash -s stable

Next, create a system environment using RVM shell script:

source /etc/profile.d/

To install Ruby 2.1.0 from source using RVM:

rvm reload
rvm install 2.1.0 

To see all the installed Ruby versions, use the following command:

rvm list rubies

(Here, I only see Version 2.1.0, but the default 1.8.7 is still lurking ’cause when I try installing Rails using yum instead of RVM it fails! – So I install Rails using RVM – expecting that this will suffice to bypass the CentOS fail!)

Set this Ruby version as the default:

rvm use 2.1.0 --default

… and install Rails (takes a good while):

gem install rails

Learn more about using RVM.

Installing GIT

I ran into a problematic interaction between Cpanel and the installation of GIT – so we need to disable the excludes:

yum --disableexcludes=main install git

Also turns out that I hadn’t associated a public key with my github account, so go do that now.

Focusing on a Unified Service Description Language for Linked Service Systems (LSS-UDSL)

In the interest of “doing something” with my study of service science, I’ve decided to close off (for now at least) my searching and re-searching the most promising approaches to designing, implementing, and evaluating various models of service, service systems, and service networks, and to focus on a family of models (expressing the “Unified Service Description Language”) developed by Jorge Cardoso and his associates in the past few years.

In 2014, Cardoso, Lopes and Poels developed a variant of the Unified Service Description Language that was suited to Linked Service Systems (LSS-USDL). The design of the LSS-USDL was the culmination of three principal efforts:

Basic Definitions

For an extended discussion of these definitions, see Linked Service System USDL (LSS-USDL) – Perspectives, definitions and objectives.

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.

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.

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.

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.

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.

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 contextualizes the scope of a service system model like the LSS-USDL. 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.

The LSS-USDL implements Linked Data and Semantic Web technologies. Let’s see how.

Next: x
Previous: Transparency of services

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.

Jorge Cardoso – *-USDL Models, Open Semantic Service Networks

Biographical Note

Jorge Cardoso is Associate Professor at the University of Coimbra (Portugal), and affiliated to the Information Systems Group. He is also Lead Architect for Cloud Management at Huawei’s European Research Center in Munich, Germany.

His current research involves the development of the next generation of Cloud Management Platforms (CPM), Cloud Automation solutions, Cloud Business Process Management (BPM), and High Performance BPM systems.

More information about his research on Cloud Computing, BPM, Semantic Web, Web Services, and Enterprise Systems at: LinkedIn, Google Scholar, DBLP.


Academic Advisor

*-USDL Related by Others