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.

Evolution and Overview of Linked USDL

Cardoso, J and C Pedrinaci – Evolution and overview of Linked USDL – 2015


Linked USDL (Unified Service Description Language)[15] was developed for describing business and software services using computer-readable and computer understandable specifications to make them tradable on the web/Internet [6]. Linked USDL takes the form of a reference vocabulary 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; GoodRelation is used to mainly 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 description 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 the Internet of Services.

Services and service systems, such as cloud services and digital government services, are showing increasing interests from both academia and industry.

Among the many aspects which still require to be studied, such as service innovation, design, analytics, optimization, and economics, service description is one of the most pressing and critical components since it is a keystone supporting a web of tradable services.

While several service description languages have been developed over the past 10 years to model software-based service descriptions, such as WSDL, OWL-S, SAWSDL, e3service, and e3value ontologies, a language that also covers business and interaction aspects is missing. This paper summarizes our efforts to create USDL and, more recently, Linked USDL, a family of languages providing a comprehensive view on services to be used by providers, brokers, and consumers when searching, evaluating, and selecting services.


The initial main driving organization behind the first two versions of USDL was SAP Research. The two initial versions of USDL (versions 1.0 and 2.0) started to be developed in 2007 and were ready in 2009. They were built using XML Schema. Later, in 2011, based on the experience gained from the first developments, a W3C Incubator group was created and USDL was extended leading to version 3.0. In 2012, version 4.0 was created and renamed to Linked USDL since its development followed Linked Data principles.

Currently, Linked USDL is the version most often used to develop infrastructures and applications to manage services. The objective is to shift from a closed solution to a language which enabled the large scale, open, adaptable, and extensible description of services using a decentralized management. The use of Linked Data enabled USDL to inherit many distinctive aspects such as unique service addresses on the web via the use of URIs and the description data about services is published in a computer-readable and -understandable format.

The rationale behind the use of Linked Data is the requirement that USDL descriptions should be shared between interested parties and linked to other descriptions, standards, and vocabularies. Linked Data technologies are particularly suitable for supporting and promoting this level of web-scale interlinking. Globalization truly happens only when people, devices, processes, and services are all connected into a global network.

Versions 1.0, 2.0, and 3.0 of USDL have been discontinued and are no longer supported. Linked USDL introduces many changes and follows a different philosophy when compared to its predecessors. While the core and pricing models for Linked USDL are finalized, work on developing and aligning several modules of the specification (e.g. legal, security, and service level) with various use cases (e.g., higher education, cloud computing, and human-based services) is still in progress. The modular approach followed, separating the different service aspects into independent vocabularies, has proved to be efficient, flexible, and easy to be processed by service delivery platforms.

The evolution of USDL and Linked USDL

Figure 1. The evolution of USDL and Linked USDL.

Linked USDL Family

Linked USDL is segmented into modules that together form the Linked USDL family. The objective of this division is to reduce the overall complexity of service modeling by enabling providers to only use the modules needed. Currently, five modules exist but they have different maturity levels. The modules identified with one star (*) have been developed only as a proof of concept. The modules identified with two stars (**) have passed the proof-of-concept stage and are being finalized. The modules identified with three stars (***) are ready and have been validated.

  • usdl-core (***). The core module covers concepts central to a service description. It includes operational aspects, such as interaction points that occur during provisioning, and the description of the business entities involved.
  • usdl-price (***). The pricing module provides a range of concepts which are needed to adequately describe price structures in the service industry.
  • usdl-agreement (**). The service level module gathers functional and nonfunctional information on the quality of the service provided, e.g., availability, reliability, and response time.
  • usdl-sec (*). This module aims at describing the main security properties of a service. Service providers can use this specification to describe the security features of their services.
  • usdl-ipr (*). This module captures the usage rights of a service, which are often associated with the concept of copyright.

The usdl-agreement module is being reconstructed with the objective to align it with the WS-Agreement specification. Customers and providers can use usdl-agreement to create service level agreements to, afterwards, monitor whether the actual service delivery complies with the service level agreed terms. In case of violations, penalties or compensations can be directly derived.

Linked USDL Core can be regarded as the center of the Linked USDL family since it ties together all aspects of service descriptions distributed across the USDL modules. Figure 2 shows the conceptual diagram of the core module.

Classes are represented with an oval, while properties with an edge. Linked USDL Core has 12 classes and 13 properties (the reader is referred to [15] to understand the purpose of using external vocabularies such as GoodRelations, SKOS, and MSM).

Other modules are being developed as proofs of concept. For example, Linked Service System USDL (LSS USDL) provides modeling constructs to capture the concepts of a service system. While Linked USDL looks into the external description of a service, i.e., a service is seen as a black box, LSS USDL looks inside the ’box’ to describe its elements.

Standardization Efforts

Service standards are expected to drive the industrialization of the service market, to increase transparency and access, to lead to higher trading of services across countries, and to contribute to a new level of service innovation by aggregation or composition. Linked USDL fills the gap by proposing a specification language which enables the unified formalization of business and technical aspects.

Linked USDL Core Schema

Figure 2. Linked USDL Core Schema.

See Modeling Example

The class usdl:Service provides the entry point for the description.

  • Associating a service model with the service.
  • Specifying the business entities participating during service provisioning.
  • Enumerating the interaction points provided by the service.

The class usdl:ServiceModel is used to create groupings of services that share a number of characteristics.

The class usdl:EntityInvolvement captures the usdl:BusinessEntities involved in the service delivery and the usdl:Role they play.

Linked USDL provides a reference taxonomy of basic business roles that cover the most typical ones encountered during service modeling such as regulator, intermediary, producer, and consumer. The prefix usdl-br identifies the taxonomy usdl-business-roles[1] which defines the default roles available.

The description include the ISIC (International Standard Industrial Classification of All Economic Activities) code and the NAICS (North American Industry Classification System) code, legal name, tax ID number, and country where the company is located.

An interaction point (usdl:InteractionPoint) represents an actual step in performing the operations made available by a service. On a personal level, an interaction point can model that consumer and provider meet in person to exchange service parameters or resources involved in the service delivery (e.g., documents that are processed by the provider). On a technical level, this can translate into calling a web service operation. An interaction point can be initiated by the consumer or the provider.

Interaction points define four main pieces of information:

  • The communication channels that customers or applications can use to interact with a service.
  • The entities that are involved during the interaction.
  • The resources that are needed for an interaction.
  • The resources that are generated from an interaction.

Communication channels are additionally characterized by their interaction type. Linked USDL provides two reference taxonomies covering the main modes (e.g., automated, semi-automated, and manual) and the interaction space (e.g., on-site and remote).

The specification describes how customers can ask for information to use the service. This can be done by using traditional mail, a telephone, or email. All the communication channels require a manual (usdl-it:manual) and remote (usdl-it:remote) interaction. This means that humans, not software applications, will be involved in the interaction.

The example also indicates the role of the two entities that will interact; both will be participants. This information is represented using the class usdl:EntityInteraction which links interaction points to business entity types (e.g., provider, intermediary, and consumer), and the role they play within the interaction (e.g., initiator, mediator, and receiver). The interaction point receives (usdl:receives) and yields (usdl:yields) resources. Receives is the input required and yields corresponds to the outcome yielded by an interaction point. The example shows that the interaction point ip Advertise receives an dbpedia:Advertising and yields a dbpedia:Contract. Naturally, other computer-processable data sources such as can be used.

We may specify a fully automated interaction which does not require human intervention. Linked USDL covers the most widely used human-based communication channels (e.g., email, phone, and mail) by means of vCard (a standard for electronic contact details), and application-driven channels (e.g., SOAP and REST Web services) by relying on the Minimal Service Model (MSM).

A usdl:ServiceOffering is an offering made by a gr:BusinessEntity of one or more usdl:Service to customers. An offering usually associates a price, legal terms of use, and service level agreements with a service. In other words, it makes a service a tradable entity. A service offering may have limited validity over geographical regions or time. The offering adds various pieces of information such as temporal validity, eligible regions, and accepted payment methods.

See Related Work:

  • WSDL – describing technical aspects of web services using syntax
  • OWL-S, SAWSDL and WSMO – descriptions languages to provide semantics
  • e3 family of ontologies
  • GoodRelations



  1. H Akkermans, Z Baida, J Gordijn, N Pen˜a, et al. Value Webs: Ontology-Based Bundling of Real-World Services. IEEE Intelligent Systems, 19(4):57–66, 2004.
  2. Mika¨el Barbero, Fr´ed´eric Jouault, Jeff Gray, and Jean B´ezivin. A practical approach to model extension. In MDA – Foundations and Applications. Springer, 2007.
  3. Alister Barros and Daniel Oberle. Handbook of Service Description: USDL and Its Methods. Springer, 2012.
  4. Christian Bizer, Tom Heath, and Tim Berners-Lee. Linked data – the story so far. International Journal on Semantic Web and Information Systems, 4(2):1–22, 2009.
  5. The standardisation environment for cloud computing. Technical report, Germany Federal Ministry of Economics and Technology, Feb. 2012.
  6. Cardoso, A. Barros, N. May, and U. Kylau. Towards a unified service description language for the internet of services: Requirements and first developments. In IEEE International Conference on Services Computing (SCC), pages 602 –609, July 2010.
  7. Jorge Cardoso, Matthias Winkler, and Konrad Voigt. A service description language for the internet of services. In Symp. on Services Science (ISSS’09), 2009.
  8. Anne Geraci. IEEE Standard Computer Dictionary: Compilation of IEEE Standard Computer Glossaries. IEEE Press, 1991.
  9. Jaap Gordijn, Eric Yu, and Bas van der Raadt. e-service design using i* and e3value modeling. IEEE Software, 23:26–33, 2006.
  10. Martin Hepp. GoodRelations: An Ontology for Describing Products and Services Offers on the Web. In Knowledge Engineering: Practice and Patterns. Springer, 2008.
  11. Kopecky, T. Vitvar, C. Bournez, and J. Farrell. SAWSDL: Semantic Annotations for WSDL and XML Schema. Internet Computing, IEEE, 11(6):60 –67, 2007.
  12. Maurizio Lenzerini. Data integration: A theoretical perspective. In of the 21st symposium on principles of database systems, pages 233–246. ACM, 2002.
  13. Martin, M. Burstein, J. Hobbs, O. Lassila, D. McDermott, et al. OWL-S: Semantic markup for web services. W3C Member submission, 22:2007–04, 2004.
  14. Paskin. Toward unique identifiers. Proceedings of the IEEE, 87(7):1208–1227, July 1999.
  15. Carlos Pedrinaci, Jorge Cardoso, and Torsten Leidig. Linked USDL: A vocabulary for web-scale service trading. In 11th Ext. Semantic Web Conference, Greece, 2014. 16. Carlos Pedrinaci, John Domingue, and Amit Sheth. Handbook on Semantic Web Technologies, volume Semantic Web Applications, chapter Semantic Web Services. Springer, 2010.

Linked USDL – Introduction

After Pedrinaci, C, J Cardoso, and T Leidig – Linked USDL – A vocabulary for web-scale service trading – 2014


The importance of real-world services, that is business activities of a mostly intangible nature (e.g., life insurance, consulting), has grown over the last 50 years to dominate economic activity [1]. Because of their intangible nature, services can often be bundled, adapted, and traded in an automated manner. In an attempt to exploit the Web as a service trading platform a number of service marketplaces have emerged, ranging from purely technical registries like UDDI [2], to business-oriented marketplaces such as Google Helpouts. Technical registries have for the most part focused on the computer science aspects of services which is limiting as it ignores fundamental characteristics of services including the economic, social, and business contexts [3]. Business-oriented marketplaces on the other hand have focussed on providing silos that offer limited search and comparison capabilities through an essentially human-oriented storefront [4]. As a result, common and essential economic activities in the service sector such as the generation of customised offerings, the creation and trading of possibly cross-domain and multi-provider service bundles, or simply the communication between customer and provider remain largely manual activities [4].

Supporting the trading of services over the Web in an open, scalable, and automated manner enabling the opportunistic engagement of multiple crossdomain providers requires a shared means for capturing and reasoning upon the economic, social, and technical aspects governing service exchanges [1,3,4]. The Unified Service Description Language (USDL) is the most comprehensive attempt in this direction but it has received limited adoption due to its complexity, while it also exhibited limitations with respect to the level of extensibility and automation supported. In this paper we present Linked USDL, a new vocabulary which builds upon the results and experience gained with USDL combined with prior research on Semantic Web Services, business ontologies, and Linked Data to better support Web-scale automated service trading. We present the methodology and main decisions adopted for transforming the complex USDL specification into a network of vocabularies that is anchored on simplicity as well as on vocabulary and data reuse. The resulting vocabulary is thoroughly evaluated in terms of domain coverage, suitability for purpose, and its current level of adoption.

Related Work

Service Science aims to reach a better understanding of services, service networks, value co-creation and service innovation, to name a few of the main research topics [1]. These efforts, which encompass several disciplines, are geared towards establishing solid foundations for advancing our ability to design, create, and analyse service systems with both business and societal purposes in mind.

Relevant work in Computer Science includes service-oriented systems, which approach the development of complex applications by integrating networked software components called Web services [2]. This area has been prolific in terms of both tooling and specifications including a number of approaches for describing technical services semantically, e.g., OWL-S, SAWSDL, and WSMO [5,6]. Although (semantic) Web services work provides advanced support for discovering or composing technical services, it disregards the fundamental socio-economic context of real-world services (e.g., value chains and offerings), and does not cover the widespread manual services (e.g., consulting) [3]. Complementary work on Workflow and Business Process Management has focussed on the operationalisation of the processes within enterprises [2,3,5], which has more recently also incorporated human activities [7]. This work is, however, centred on a procedural view on how activities are carried out within an organisation which is orthogonal to the business characteristics of the services offered (e.g., speed of internet connection offered) which are essential to service trading.

The most notable effort able to represent and reason about business models, services, and value networks is the e3 family of ontologies which includes the e3service and e3value ontologies [3,8]. This research has, however, not been much concerned with the computational and operational perspectives covering for instance the actual interaction with services. Likewise, the technical issues related to enabling a Web-scale deployment and adoption of these solutions were not core to this work. GoodRelations [9] (GR) on the contrary is a popular vocabulary for describing semantically products and offerings. Although GR originally aimed to support both services and products, it is mostly centred on products to the detriment of its coverage for modelling services, leaving aside for instance the coverage of modes of interaction, or the support for value chains.

USDL [4,10] is, to date, the most comprehensive approach to supporting the description of services for automated processing. USDL consists of 9 modules modelled in eCore capturing services, interaction interfaces, pricing models, service level agreements, and related legal issues. Despite its comprehensive support, this effort underestimated the need for such an all encompassing model to be widely open, highly flexible and extensible, and yet simple in nature [11]. On the one hand, the rather centralised and controlled nature of the approach led to an overly complex model hard to grasp and apply. On the other hand, eCore exhibited technical limitations towards its extensibility and its use as a lingua franca on the Web where Linked Data and light semantics are currently considered a more adequate technology.

Requirements Analysis

Informed by research carried out on services, including the related work covered earlier, we have elicited a number of requirements that Linked USDL and any other language or vocabulary with such an ambitious purpose should address. This includes notably coverage requirements, which we shall cover first. We also present additional criteria that we identified during the standardisation activities of USDL as potential issues and limitations for its Web-scale adoption [11].

Description Requirements

One of the essential difficulties when dealing with services beyond mere technical interfaces, is the fact that they are at the intersection of many diverse disciplines that range from technical aspects, to operational ones, socio-economic concerns, or even legal issues. Being able to move across each of these domains is essential to support the trading of services online. We detail the main dimensions next.

Functionality Services are business activities that normally take place through (possibly technology mediated) interactions between stakeholders, resulting in benefits to the actors involved. Fundamental to the notion of service is therefore its functionality in terms of what it does, requires, and provides. Given the highly diverse nature of services this should cover the entire spectrum from fully automated provisioning (e.g., Spotify) to those essentially manual (e.g., car repair service). Depending on the stakeholder, the level of abstraction could vary from a detailed operational view (provider), to a high-level one for customers.

Agents and Networks Services delivery engages several stakeholders in (possibly ephemeral) ad-hoc business networks, e.g., banks often engage in partnerships with insurances to provide accounts with integrated travel insurance. The modelling of services should seamlessly support both the emergence and analysis of such networks in order to enable the dynamic co-creation of value through Web-wide service trading. Important aspects to be covered are thus the agents involved in a certain network and the role(s) they play.

Service Relationships Thanks to their intangible nature, services can be combined, repurposed, and adapted to better fulfil customer needs. Services are often related to other services and products. For instance, services can often be enhanced with others, or there can be variations over established types. Services are often bundled, i.e., aggregated and offered jointly in packages like broadband and TV services. And in the case of automated services, services may be composed according to specific data and control flow to achieve a complex objective out of simpler components.

Operational and Delivery The delivery of services is often subject to restrictions or conditions. These may range from geographical concerns (e.g., the insured individual should live in the UK), temporal availability, legal issues, variable pricing, and so on. From a service provider operational perspective, there may well be limitations due to the resources required, e.g., staffing, that need to be tracked as they determine the costs and the capacity for providing a service.

Consumption Services are most often accessed or “consumed” through interactions by means of designated communication channels. For example, making an insurance claim may require the customer to phone the insurance company, or fill up a form online. These communication channels may vary during the service delivery process (e.g., initially claim by phone and check the progress online), and there may exist restrictions on how interactions should take place. For instance a car repair service may require you to bring the car to the garage whereas in other cases the service may take care of sending a mechanic within some geographical boundaries.

Language Requirements

In addition to the aforementioned coverage requirements, research in the area has highlighted further requirements that the language should meet. First and foremost given the complexity of the domain and the fact that the aim is to maximise to the extent possible the level of automation that can be achieved during the life-cycle of services, the modelling of services needs to rely on a conceptual model with formal foundations that can enable automated processing [3, 10]. Nonetheless the language should be modular and extensible in order to be able to accommodate different domains and the many facets of services while minimising the complexity for users and tool developers.

Our subsequent work on standardisation highlighted that although necessary, these requirements did not appear to be sufficient for Web-scale adoption:

An Open Solution To support the engagement of any business entity across any domain the technological approach should be open. It should be open so as to allow anybody to engage and trade services online, as well as towards its evolution in order to cater for new requirements, accommodate new ways of doing business, or support new domains.

A Web-based solution A scenario like the one envisaged requires an approach that can support the engagement of millions of service providers and consumers in exposing, locating, interpreting, and contracting services. This necessarily calls for highly interoperable and scalable solutions in terms of data sharing, data processing, and communication protocols.

Promoting uptake While providing an open solution is likely to have a positive impact on technology take up, adoption will largely be determined by the simplicity with which any business entity could adopt a solution based on these technologies and the compatibility with existing legacy systems.

Linked USDL Vocabulary

Driven by the aforementioned requirements and informed by the drawbacks exhibited by USDL we worked on Linked USDL focussing essentially on reducing the complexity underlying USDL and fostering its wider adoption through the use of Web-centric technologies that are more amenable to extension, modification, and automation at large scale.

Design Decisions

First, due to the success, scale, growth, and current adoption of the Web for worldwide telecommunication and electronic commerce we believe that any technology hoping to enable service trading online should necessarily embrace and build upon the Web principles and technologies [12]. Notably Linked USDL should also embrace principles like i) the establishment of global identifiers, e.g., by using URIs to identify services and providers; ii) the use of links to other resources on the Web to enrich a particular datum with reusable and externally provided information, e.g., pointing to complementary services; iii) the use of HTTP as a simple uniform protocol for supporting interactions; and iv) the decoupling between resources and their representation. Doing so brings a technology stack that has proven to support large scale, efficient, multi-party interactions, as well as it directly provides an integration point with open, standard technologies that are already widely used and supported.

Second, to enable effective interactions at the business level, we need to provide standards that go beyond data transportation and syntactic representation [1].

To this end, Linked USDL embraces the use of formal ontology representation languages to capture the semantics of services such that they are amenable to automated reasoning. Linked USDL goes one step forward in the adoption of Web technologies to embrace the emerging standard approach for data sharing online, namely Linked Data [13]. Adopting these principles enables Linked USDL to capture, share, and interlink data about services of highly heterogeneous nature and domains, in an open, scalable, and uniform manner. Linked Data principles promote and support reuse which in turn helps to reduce the data modelling overhead (e.g., by reusing conceptual models and existing data sets), and maximise the compatibility with existing tooling. Both aspects are major challenges earlier versions of USDL faced which this work aims to alleviate.

Design Methodology

Following common Knowledge Engineering best practices [14], we aimed at creating a modular solution based on well-designed, widely adopted vocabularies that did not introduce substantial ontological commitments away from the core topics of interest. Thus, considerable effort was devoted to identifying and evaluating reusable ontologies.

First, we identified the main topics to be covered given the original USDL specification and determined some core terms characterising each of these topics. Informed by the topics and terms identified, we carried out both a manual and semi-automated search to determine potentially relevant reusable ontologies. On the one hand, we performed a state of the art analysis to identify ontologies that were relevant for the modelling of services, see [11] and Section 2. On the other hand, we used Swoogle [15], Watson [16], LOD Stats [17], and the Linked Open Vocabularies (LOV) engines to search for ontologies covering the main terms identified. For each of the queries asked, we kept the top 10 results. The resulting list was eventually enriched with widely-used general purpose vocabularies such as Dublin Core (DC) and Simple Knowledge Organisation Scheme (SKOS).

Second, for each of the vocabularies identified, we used both LOD Stats and LOV to figure out the number of datasets using these terms, the number of instances of the main concepts of interest present in datasets on the Web, and the number of times the vocabulary is reused elsewhere. The search for reusable ontologies provided us pointers to existing vocabularies of potential interest together with indications regarding their use and popularity. Table 1 shows the results obtained for the vocabularies for which there was at least one instance found on the Web[1]. Indeed, the statistics should not be taken as an exact value of the overall use of these vocabularies (e.g., GR is used more frequently than what is reflected by this analysis), but rather as a relative indication. Indeed we also took into account the properties defined by these vocabularies which are in some cases (e.g., DC Terms) the main constructs reused.

The design of Linked USDL was driven by these statistics, and a manual assessment of the quality, coverage, and potential alignments of the vocabularies.

Topic Vocabulary # Datasets # Instances LOV Reuse
Service GR 6 45 146 0 6
MSM 2 0 41,368 0 0
OSLC 2 0 2 0 0
COGS N/A 5 N/A 0 3
Offering GR 6 8 824 656 4
Location vCard (v3 & v4) 5 0 + 2 3,684 3,686 + 3 0 + 2
WGS84 11 1 3,204 1,7651 1
AKT Signage 18 0 11,789 0 0
DC Terms 1 9 39 39 6 1 5 1
Business Entities 2 4 1,570,778 1,570,778 3
FOAF 60 135 14,613 14,557 29
GR 1 N/A 3,918 N/A N/A
W3C Org. 1,050 11 2 1,050 2
Time W3C Time 9 N/A 236,433 N/A N/A

Table 1. Top Vocabularies per Topic.


Informed by the aforementioned analysis, Linked USDL, which is publicly available together with further examples in GitHub, builds upon a family of complementary networked vocabularies that provide good coverage of necessary aspects and are widely used on the Web for capturing their particular domains. In particular Linked USDL builds upon:

  • DC Terms to cover general purpose metadata such as the creator of a certain description, its date of creation or modification, etc.
  • The vocabulary has been modelled mostly using RDF/RDFS constructs and we have limited the inclusion of abstract foundational concepts, so as to attain a model that is simple enough for its adoption online. The reader is referred to [19] for indications on how this model could be mapped to a foundational ontology.
  • SKOS providing low-cost support for capturing knowledge organisation systems (e.g., classifications and thesauri) in RDF.
  • Time Ontology (Time) for covering basic temporal relations. The ontology allows us to capture temporal relationships such as before and during.
  • vCard vocabulary a vCard 4 compatible vocabulary to support providing location and contact information for people and organisations.
  • Minimal Service Model (MSM) [18] to provide coverage for automated service-based interactions including Remote Procedure Call solutions (e.g., WSDL services) and RESTful services.
  • GR [9] to provide core coverage for services, business entities, offerings, and products.

Linked USDL Core Schema
Figure 1. Linked USDL Core Schema.

As the core and initial module of a set of vocabularies for supporting service trading online Linked USDL Core, see Figure 1, aims to cover four essential aspects: offerings, services, the business entities involved in the delivery chain, and the actual interaction points allowing consumers to contract or trigger the benefits of contracted services.

Linked USDL extends GR which is nowadays the de facto standard vocabulary for publishing semantic descriptions for products. It is worth noting that although services are accommodated within GR, their coverage is rather basic at this stage. Extending GR enables linking services and products descriptions which is particularly useful since many products are often sold in combination with a service, e.g., a repair or replace service. Additionally, it also ensures that an initial alignment with the increasingly popular vocabulary is in place, for GR is already largely aligned to it.

Core Concepts

The most important concepts provided by Linked USDL are:

Service is a refinement of gr:ProductOrService and subsumes all classes describing service types. Examples of subclasses of Service could be “internet provisioning service” and “insurance service”. Instances of Service may define i) prototypical services part of a portfolio, e.g., “BT unlimited broadband service”, as covered by ServiceModel, ii) one-of services custom tailored for a potential customer, or iii) actually contracted services, e.g., “your concrete life insurance provided by AXA”, as covered by gr:ServiceIndividual.

ServiceModel is a refinement of gr:ProductOrServiceModel which specifies common characteristics (e.g., download speed) of a family of services. ServiceModel thus defines families of Services sharing common characteristics, e.g., “BT unlimited broadband services share the characteristic of supporting unlimited download”. An actual service instance shares the properties of its service model. This is a feature that requires non-standard reasoning which specific implementations should take care of.

ServiceIndividual is a subclass of gr:Individual and Service. Instances of ServiceIndividual are actual services that are creating value to a network of business entities. For instance, “your concrete life insurance provided by AXA” is a ServiceIndividual which is providing value to yourself and AXA.

ServiceOffering is a subclass of gr:Offering and represents essentially offerings by a business entity including at least one Service. ServiceOffering may have limited validity over geographical regions or time.

EntityInvolvement is introduced in Linked USDL in order to enable capturing service value networks. In a nutshell, Entity Involvement allows capturing a ternary relationship expressing that a business entity, e.g., “AXA”, is involved in a service, e.g., “basic life insurance” playing a business role, e.g., “provider”. Linked USDL provides a reference SKOS taxonomy of basic business roles that covers the most typical ones encountered such as regulator and intermediary.

InteractionPoint link services to interactions that may be possible or required between the members of a service value network and the service during its life cycle. This allows answering questions such as “what is the sequence of interactions I may expect if I want to make an insurance claim and what communication channels are available to that end?”.

CommunicationChannel is the class of all different communication channels that business entities could use for communication. Linked USDL covers the most widely used channels by means of 2 vocabularies: vCard (e.g., email, phone), and MSM (e.g., Web services, and RESTful services). Communication channels are additionally characterised by their interaction type. Linked USDL provides 2 reference SKOS taxonomies covering the main modes (e.g., automated) and the interaction space (e.g., on-site).

EntityInteraction links interaction points to business entities or types (e.g., provider), and the role they play within the interaction (e.g., initiator). EntityInteraction allows expressing things like “to make a claim, the consumer should first contact the insurance provider and provide the policy number”.

Classifications Classifications or taxonomies of entities are most often used when describing services to capture, for instance, service types, business entity roles, e.g., “provider”, as well as interaction related issues, e.g., “manual vs automated”. We also expect that classifications will be needed in forthcoming modules addressing strategic issues or the internals of delivery chains.

This could be approached directly using subclassing which is directly supported by RDFS. However, the use of a hierarchy of classes establishes strict relationships which may not adequately match existing organisation schemes. For this reason, in Linked USDL we have accommodated the use of SKOS, which enables capturing classification schemes and taxonomies. Indeed, this mechanism does not prevent users from providing their own domain-specific categorisations through subsumption if they wish to. This approach thus enriches Linked USDL with a powerful, yet flexible and extensible means for creating categorisations.

The current version of Linked USDL includes three SKOS schemes with reference categorisations for BusinessRoles, InteractionRoles, and InteractionTypes, see Figure 1. These schemes have been, however, kept as separate modules so that different schemes can be used if necessary.


Coverage Evaluation

Ontologies are often evaluated by comparing them to a gold standard ontology [20]. In our case, we have done such an evaluation by comparing the resulting model to USDL, the most comprehensive model available for describing services. Doing so allows us to get a clear indication of the overall coverage of the domain, and to identify as well the main deviations from USDL.

A fundamental goal of this work is providing a conceptual model that would be easy to grasp, populate, process, and ultimately be adopted for Web-scale use. Thus, out of the 9 modules of USDL we have essentially deferred covering the following modules: Service, Legal, Service Level, and Pricing. Nonetheless, for every module we have checked the coverage of the main concepts defined in order to get an indication of both module-specific and the overall coverage of Linked USDL. [The results of this analysis are summarised in Table 2 of the original paper].

This analysis shows that thanks to integrating an reusing existing vocabularies we have managed to cover the vast majority of USDL, by providing a vocabulary consisting of 12 concepts and 3 complementary SKOS categorisations. In particular, from an original specification with 125 concepts we cover 74%, if we limit ourselves to the specific modules we targeted, and 60% overall, which shall contribute towards reducing the overhead related to understanding and adopting Linked USDL. It is worth noting that out of the concepts not explicitly covered several are sometimes redundant (e.g., Condition is subclassed in many modules), or were seldom properly understood and used (e.g., Functions, Phases of interactions, Service Level Agreements).

Suitability for Tasks and Applications

Given that Linked USDL does not cover all concepts present in USDL it is worth assessing the impact of such decisions. [Again, see Table 2 in the original article]. In qualitative terms, the decisions adopted are such that Linked USDL does not currently provide support for capturing how providers deliver services in terms of resources needed, complex internal workflows, or strategic decisions (e.g., targeted markets). The reason for this is two-fold. First, such aspects are often not automated and when they are, providers already have mechanisms in place to this end. Second, these are private concerns that are orthogonal to the trading of services. Similarly, Linked USDL does not currently include support for conceptualising complex agreements including legal requirements and guarantees as these were barely used or understood by users. Finally, we have opted for a simple mechanism for capturing prices and have deferred to a separate module the modelling of more complex dynamic pricing that are less often used and usually remain private to the provider.

Despite these changes, Linked USDL provides advanced support for modelling, comparing, discovering, and trading services and service bundles. It provides means for tracking and reasoning about the involvement of entities within delivery chains which informs the trading and comparison of services as well as it enables the tracing and analysis of service value networks. It provides advanced support for automating the interactions between actors during the life-cycle of services. Additionally it includes support for capturing service offerings, for combining services and products (e.g., a car often comes with a warranty), and for applying temporal reasoning, which were not previously available. Finally, and most importantly, these activities can be achieved with a greater level of automation benefitting from automated reasoning and they can be performed on a Webscale across Web-sites and service providers thanks to capturing and sharing the semantics of services as Linked Data.

Empirically, the suitability of the language for supporting the automation of key tasks has been evaluated by two main means. On the one hand, we have reused and developed tools that provide support for these tasks, and, on the other hand, we are continuously applying Linked USDL in a number of domains. In terms of reuse, thanks to the adoption of existing Linked Data vocabularies,

Linked USDL benefits from general purpose tooling, e.g., SPARQL engines and RDF stores, but also from vocabulary-specific solutions. This notably concerns existing advanced machinery for discovering, composing, and invoking technical services (i.e., RESTful and WSDL services) described in terms of MSM [18].

Additionally, general purpose infrastructure has been developed specifically for Linked USDL. A Web-based Linked USDL editor is currently available to help providers to easily generate Linked USDL descriptions. There is also an advanced multi-party dynamic and open service marketplace developed in the context of the FI-WARE project, able to gather, combine, and exploit rich service descriptions from distributed providers to help match offer and demand. Notably the marketplace supports consumers in searching for service offerings, comparing them, and contracting them.

Finally, from the perspective of its suitability for supporting service trading across domains, Linked USDL is currently being applied in a variety of domains. For instance, in the field of Software as a Service we have explored the use of Linked USDL in conjunction with TOSCA[21]. Linked USDL was used to formalise, structure, and simplify the discovery and selection of services of the Web-based customer relationship management (CRM) platform SugarCRM, while TOSCA supported the automated deployment and management of the services.

Additionally this work helped us evaluate the extensibility of Linked USDL by integrating it with complementary third party specifications such as TOSCA. In the FI-WARE project Linked USDL is used to support a service infrastructure supporting service ecosystems in the cloud covering both the technical and business perspectives. The FINEST project aims to support the transport and logistics (T&L) ecosystem, in which many service providers collaborate in order to transport goods over what is referred to as a “chain of legs”. Therein Linked USDL is being exploited in the planning of chains of legs to support searching and matching transport service offerings in a transparent, distributed, and multi-party manner.

Across the diverse domains where Linked USDL is being applied (see list of projects next), it has proven to be a valuable resource as a means to provide shared and globally accessible service descriptions integrating both technical and business aspects. The genericity, modularity, and extensibility of the approach has enabled extending the vocabulary with dedicated domain-specific vocabularies in the areas of SaaS and T&L, while generic software infrastructure was easily reused across domains.

Vocabulary Adoption and Use

When evaluating ontologies and vocabularies, one aspect that is often taken into account is their adoption and use. This evaluation may be carried over the ontology itself and/or over the different ontologies that are imported. The former gives an indication of the acceptance and adoption of the ontology in its entirety whereas the latter provides a more granular assessment over the reused ontologies. In this section we mainly address the latter but also provide preliminary indications of the overall adoption of Linked USDL.

The methodology that was followed was centred on the reuse of widely adopted vocabularies. Table 1 presented earlier shows the main vocabularies that were identified through search engines, together with core indicators of their use on the Web. These figures highlight that Linked USDL is based on vocabularies that are the most used in their respective domains of interest. Only two exceptions exist, AKT Signage which was not adopted for it was not dereferenceable, and which is indirectly aligned via GR. This approach in turn reduces the potential overhead one would incur when using Linked USDL: frequently reused vocabularies are likely to have greater acceptance and support by people and existing systems.

Additionally, the availability of datasets with instances in terms of the vocabularies reused guarantees that new descriptions could reuse and link to existing resources, e.g., allowing the reuse of descriptions of companies. Doing so provides clear benefits from the perspective of data acquisition which was one of the main concerns Linked USDL was trying to address. Additionally, by linking to existing instances the data provided is enriched which may in turn enable further advanced processing as well as it may increase the discoverability of services.

Providing a substantial account of the adoption of Linked USDL would require a reasonable wait from its first release, which coincides with this publication. Nonetheless, Linked USDL is currently already in use within more than 10 research projects, namely FI-WARE, FINEST, Value4Cloud, Deutsche Digitale Bibliothek, MSEE, FIspace, FITMAN, FI-CONTENT, ENVIROFI, OUTSMART, SMARTAGRIFOOD, IoT-A, Broker@Cloud, and GEYSERS. These projects are using Linked USDL as the core vocabulary for describing services, contributing to validate the suitability, genericity, and extensibility of Linked USDL for different domains. This also highlights that despite its youth, Linked USDL is already witnessing a promising adoption.


Despite the importance of services in developed economies, the widespread adoption of world-wide electronic commerce over the Web, most service trading is still essentially carried out via traditional and often manual communication means. A fundamental reason for this is the difficulty for capturing the abundant information and knowledge governing services and their related transactions in a way amenable to computer automation. Out of the wealth of work around services, USDL is the most comprehensive solution proposed thus far for enabling (semi)automated service trading. Yet, work on its standardisation highlighted a number of limitations for Web-scale service trading.

We have presented Linked USDL, the next evolution of USDL centred on fostering its wider adoption and better automation support through the (re)use of Linked Data. Linked USDL has been developed following a methodology centred on maximising the reuse of existing vocabularies and datasets and minimising the complexity. The resulting vocabulary has been evaluated in terms of domain coverage, suitability for purpose, and vocabulary adoption.

Despite the good evaluation results obtained, Linked USDL is to be regarded as one step towards enabling Web-scale service trading, albeit a fundamental one. Further work is required for covering aspects such as complex dynamic pricing models and agreements which are common in certain domains such as Cloud services. Additionally, from the tooling perspective, developing advanced mechanisms able to support steps such as the negotiation between service providers and consumers, or the bundling of services would also be necessary. We expect in this last regard to take inspiration and adapt solutions developed for the e3 family of ontologies.

[1] These statistics were last retrieved in November 2013.

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


  1. Chesbrough, H., Spohrer, J.: A research manifesto for services science. Communications of the ACM 49(7) (July 2006) 35.
  2. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F.: Service-Oriented Computing: State of the Art and Research Challenges. Computer 40(11) (2007) 38–45.
  3. Akkermans, H., Baida, Z., Gordijn, J., Peña, N., Altuna, A., Laresgoiti, I.: Value Webs: Ontology-Based Bundling of Real-World Services. IEEE Intelligent Systems 19(4) (2004) 57–66.
  4. Cardoso, J., Barros, A., May, N., Kylau, U.: Towards a Unified Service Description Language for the Internet of Services: Requirements and First Developments. IEEE International Conference on Services Computing (SCC) (2010) 602–609.
  5. Cardoso, J., Sheth, A.: Semantic e-workflow composition. Journal of Intelligent Information Systems (JIIS) 21(3) (2003) 191–225.
  6. Pedrinaci, C., Domingue, J., Sheth, A.: Semantic Web Services. In: Handbook on Semantic Web Technologies. Volume Semantic Web Applications. Springer (2010) 7. Oppenheim, D.V., Varshney, L.R., Chee, Y.M.: Work as a service. In: ICSOC’11: Proceedings of the 9th international conference on Service-Oriented Computing, Springer-Verlag (2011).
  7. Gordijn, J., Yu, E., van der Raadt, B.: e-service design using i* and e3value modeling. IEEE Software 23 (2006) 26–33.
  8. Hepp, M.: GoodRelations: An Ontology for Describing Products and Services Offers on the Web. In: Knowledge Engineering: Practice and Patterns. Springer (2008) 329–346.
  9. Oberle, D., Barros, A., Kylau, U., Heinzl, S.: A unified description language for human to automated services. Information Systems (2012).
  10. Kadner, K., Oberle, D., Schaeffler, M., Horch, A., Kintz, M., Barton, L., Leidig, T., Pedrinaci, C., Domingue, J., Romanelli, M., Trapero, R., Kutsikos, K.: Unified Service Description Language XG Final Report. Technical report (2011).
  11. Jacobs, I., Walsh, N.: Architecture of the World Wide Web, Volume One. W3C Recommendation (2004).
  12. Bizer, C., Heath, T., Berners-Lee, T.: Linked Data – The Story So Far. International Journal on Semantic Web and Information Systems (IJSWIS) (2009).
  13. Suarez-Figueroa, M.C., Gómez-Perez, A., Motta, E., Gangemi, A., eds.: Ontology Engineering in a Networked World. Springer (2011).
  14. Ding, L., Finin, T., Joshi, A., Pan, R., Cost, R.S., Peng, Y., Reddivari, P., Doshi, V.C., Sachs, J.: Swoogle: A Search and Metadata Engine for the Semantic Web. In: CIKM ’04: Thirteenth ACM international conference on Information and Knowledge Management. (2004).
  15. d’Aquin, M., Motta, E.: Watson, more than a Semantic Web search engine. Semantic Web 2(1) (2011) 55–63.
  16. Auer, S., Demter, J., Martin, M., Lehmann, J.: LODStats — an extensible framework for high-performance dataset analytics. In: EKAW’12: Proc. of the 18th international conference on Knowledge Engineering and Knowledge Management, Springer (2012).
  17. Pedrinaci, C., Domingue, J.: Toward the Next Wave of Services: Linked Services for the Web of Data. Journal of Universal Computer Science 16(13) (2010) 1694–1719.
  18. Ferrario, R., Guarino, N., Janiesch, C., Kiemes, T., Oberle, D., Probst, F.: Towards an ontological foundation of services science: The general service model. Wirtschaftsinformatik (February 2011) 16–18.
  19. Sabou, M., Fernandez, M.: Ontology (network) evaluation. In Suarez-Figueroa, M.C., Gómez-Perez, A., Motta, E., Gangemi, A., eds.: Ontology Engineering in a Networked World. Springer (2012) 193–212.
  20. Cardoso, J., Binz, T., Breitenbücher, U., Kopp, O., Leymann, F.: Cloud Computing Automation: Integrating USDL and TOSCA. In: 25th Conf. on Advanced Inf. Systems Engineering (CAiSE 2013). Volume 7908 of LNCS., Springer (2013) 1–16.

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