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

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.

Business-models and models of service systems

After Cardoso, J, R Lopes, and G Poels – “The LSS-USDL Model” in Service Systems: Concepts, modeling, and programming (2014).


In Chapter 2, we studied four theories that provided a comprehensive view of service. This chapter starts by complementing the study made by looking into business model conceptualizations to create an evaluation framework that will help in identifying a set of concepts to be used for the creation of a service system model.

Related research has proposed several business model conceptualizations. We briefly present eight of these proposals that are relevant to our research as they define concepts that pertain to both external and internal views of service systems. We do not explain these conceptualizations in detail, but merely list concepts relevant to a service system model. It should be noted that these proposals are unrelated to the service theories reviewed in the previous section, hence, both types of related work will be used in the next section to derive the most common service system concepts.


Alt and Zimmermann [4] distinguished six generic elements as a comprehensive framework to develop business models: Mission, Structure, Processes, Revenues, Legal issues and Technology. Published in 2001, this is the earliest proposal in our study, but as we can see by analyzing Table 1 it already mentions most of the generic concepts that newer models used the most. This indicates that it had an impact in the field.

Table 3.1 Service model evaluation framework

Table 1 Service model evaluation framework.

Petrovic et al. [5] divided a business model into seven sub-models: Value model, Resource model, Production model, Customer relations model (it was further divided into Distribution model, Marketing model and Service model), Revenue model, Capital model, and Market model. The naming of this model’s elements hints at a lower level description for each of them. However, the authors do not identify any further characteristics.

Kaner and Karni [6, 7] proposed CAIOPHYKE, a service model based on 9 major classes: Customers, Goals, Inputs, Outputs, Processes, Human enablers, Physical enablers, Information enablers, and Environment. Each of these major classes can be further described by main classes, which can then be further described by their respective minor classes. This model was developed based on a study with 150 student projects that covered around 100 service domains [8]. This is one of the most comprehensive models found in the literature. However, it features a high level of complexity without a proper formalization, which prevents from creating an abstraction to handle complexity.

In e3service [9, 10], Kinderen and Gordijn focused on satisfying consumer needs and displaying the various value offerings from different services for an easier comparison. Therefore, the elements of this model are different from other approaches. This model is a valuable contribution to the state of the art as it is represented by a machine-readable ontology, the level of formality we envision for our model. However, its scope is customer-oriented, while we seek a manager-oriented approach that provides a view on how a service system operates.

Spohrer and Maglio [11] defined a service as value co-creation and list ten related foundational concepts: Ecology, Entities, Interactions, Outcomes, Value proposition based interactions, Governance mechanism based interactions, Stakeholders, Measures, Resources, Access rights and Questions [11]. Table 3.1 shows that it is one of the most complete models of our study.

Osterwalder and Pigneur [12] propose the Business Model Canvas, a high level graphical tool for business modeling. The model uses the concepts Value proposition, Customer segments, Channels, Customer relationships, Key activities, Key resources, Key partners, Cost structure, and Revenue Streams. This model and its tool are very simple and easy to understand and enjoy some popularity.

Fielt [13] extended the Business Model Canvas by addressing its strongest limitations: the lack of partnering (c.f. [14]) and co-creation (c.f. [15]) concepts. This increased the complexity of the original model. However, Table 1 shows that this new model only contributes to one more element of the common concepts, so there is a risk that this increase in complexity might not be beneficial.

Zolnowski et al. [16] tried to tackle the issue of lack of elements of the original Business Model Canvas to describe co-creation. This proposed approach focuses on a redistribution of the elements and their connections, rather than changing them as seen in Fielt’s approach. Hence, this model shares the same concepts as the original Business Model Canvas, but their organization changes ([16] p.158).


Comparing the related work reviewed in the previous chapter and section, it is possible to identify common concepts for describing service systems and, thus, derive a service evaluation framework of the most frequent and relevant concepts. The most common concepts identified are:

  • Goals
  • Stakeholders
  • Processes
  • Inputs
  • Outputs
  • Resources
  • Measures
  • Legal
  • Financial

Goals are one of the most used concepts in the studied models. There is no doubt that this is a critical element for a service model, not only because of its wide acceptance among the studied approaches, but also because it states the objectives of the service system and its value proposition to consumers.

Stakeholders are one of the most important concepts of a service, since it is conditioned by the people and organizations involved. This concept is used by almost all the studied approaches due to its importance. In most service models, there is an attribute for service customers. In the Business Model Canvas from Osterwalder [12] and the two studied improved approaches there is also an attribute for service partners [12, 13, 16]. Spohrer and Maglio [11] propose additional attributes which specialize stakeholders into authorities and competitors.

Processes are, along with Goals, a concept that all studied approaches share. This concept is of utmost importance when describing services from an internal organization, because corporations must have a strong knowledge of the processes needed for their services, to identify bottlenecks, and other issues.

Inputs are described in a small set of service models. Spohrer and Maglio [11] refer to them using the concept of Ecology. Fielt [13], when extending the Business Model Canvas, adds Partner activities and Customer activities, which act as an input for the service. Karni and Kaner’s CAIOPHYKE model [7] features the major class Inputs.

Outputs are also described in a small set of service models. Spohrer and Maglio [11] refer to them using the concept of Outcomes. e3service [10] features outputs in the classes Consequence, Benefit, and Value derivation. Karni and Kaner [7] feature the major class Outputs.

Resources are described in most service description models, being absent just in e3service. Alt and Zimmermann’s approach [4] is the only model that does a partial description of this concept, focusing only on technology.

Measures refer to how the company can know its services’ performance receive feedback of their operations. Only a small number of models were found in the literature that addressed this concept, as shown in Table 1.

Legal is the concept for the legal aspects of a service or business. It has a surprisingly low presence in the literature. Exceptions are Alt and Zimmermann [4] who propose Legal issues as one of their six generic elements of a business model; Karni and Kaner [7] use the main class Legal factors in the major class Environment; and Spohrer and Maglio identify Governance mechanism based interactions and Access rights [11].

Financial is the concept for the financial aspects of a service. This concept is used in most of the studied approaches. Hence, it is also an important concept for developing a comprehensive service model and evaluation framework.


  1. Stephen Vargo and Robert Lusch. Evolving to a new marketing dominant logic for marketing.Journal of Marketing, 68(1):1–17, 2004.
  2. Scott Sampson and Craig Froehle. Foundations and implications of a proposed unified services theory. Production and Operations Management, 15(2):329–343, 2006.
  3. Steven Alter. Work system theory: Overview of core concepts, extensions, and challenges for the future. Journal of the Association for Information Systems, 14(2), 2013.
  4. Rainer Alt and Hans-Dieter Zimmermann. Preface: introduction to special section – business models. Electronic Markets, 11(1):3–9, 2001.
  5. Otto Petrovic, Christian Kittl, and Ryan Teksten. Developing business models for e-business. Available at SSRN 1658505, 2001.
  6. Maya Kaner and Reuven Karni. Design of service systems using a knowledge-based approach.Knowledge and Process Management, 14(4):260–274, 2007.
  7. Reuven Karni and Maya Kaner. An engineering tool for the conceptual design of service systems. Advances in Services Innovations, pages 65–83, 2007.
  8. Teaching innovative conceptual design. Technological Forecasting and Social Change, 64(2):225–240, 2000.
  9. Sybren Kinderen and Jaap Gordijn. e3service: An ontological approach for deriving multi-supplier IT-service bundles from consumer needs. In Proceedings of the 41st annual Hawaii international conference on system sciences, 2008.
  10. Reasoning about substitute choices and preference ordering in e-services. In Advanced Information Systems Engineering, pages 390–404. Springer, 2008.
  11. Jim Spohrer and Paul Maglio. Service science: Toward a smarter planet. Introduction to service engineering, pages 3–30, 2009.
  12. Alexander Osterwalder and Yves Pigneur. Business model generation: a handbook for visionaries, game changers, and challengers. Wiley, 2010.
  13. Erwin Fielt. An Extended Business Model Canvas for Co-Creation and Partnering, 2010.
  14. Erwin Fielt. To what extent is the Business Model Canvas constraining? A Co-Creation Canvas example. html, 2010
  15. Erwin Fielt. Alternative business model canvasses: A Partnering Canvas example. http://, 2010
  16. 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.
  1. 1 Service System Evaluation Framework
  2. 1.1 Business Model Conceptualizations of Service Systems
  3. 1.2 Evaluation Framework

Establishing and Specifying the REA model as a Domain Ontology for Business

Original specification of the REA Ontology – McCarthy, Geerts et al at University of Michigan

Transitional efforts to formalize REA Ontology using UML Diagrams – Poels, Paemeleire, Gailly et al at Ghent University

Formalization of the REA Enterprise Ontology using OWL and the UML Profile of OWL – Poels, Gailly et al at Ghent University


The REA Ontology is an “event ontology” (Allen, GN and ST March, 2006) that focuses on events occurring within the realm of a company, their participating agents, affected resources, and regulating policies. REA can be used as a reference for modeling a single business cycle (e.g. sales-collection) or a chain of business cycles, connected through resource flows. Applications supported by REA-driven modeling include the design of accounting and operations management systems, auditing and internal control, and conceptual data modeling. REA has been used in a number of international standardization efforts for e-collaboration systems. For instance, REA was the basis for the business process ontology in the UMM business process and information model construction methodology, the ECIMF system interoperability enabling methodology, and the Open-EDI business transaction ontology which is part of the ISO/IEC 15944-4 standard. REA has further been proposed as a theoretical basis for the reference models that underlie ERP systems.

The Project

Frederik Gailly and Geert Poels (Ghent University) set out with two goals:

  1. To establish the REA ontology as a domain ontology – specifically a domain ontology for business, using a semiotic framework (Stamper et al, 2000; Burton-Jones et al , 2005). Within this framework, the authors sought assistance with their evaluation of the ontology’s syntactic quality specifically from Welty et al (1999) and Lassila and McGuiness (2001), and with their evaluation of the ontology’s social quality from Guarino (1998) and Uschold and Jasper (1999).
  2. To enhance the specification of the REA ontology using both a formal language representation (the Web Ontology Language or OWL) and a graphical representation (the Unified Modeling Language or UML Profile for OWL) .

We will leave it largely up to the readers to familiarize themselves with the details of how the authors achieved their goal of establishing the REA ontology as a domain ontology for business. We simply present the semiotic framework (Burton-Jones et al , 2005) in Table 1 and highlight the authors’ evaluation of the REA ontology against this framework in Table 2. Finally, we note that the authors define business as “the activity of providing goods and services involving financial, commercial and industrial aspects”.

Metric Attribute Description
Syntactic quality Lawfulness Correctness of syntax
Richness Breadth of syntax used
Semantic quality Interpretability Meaningfulness of terms
Consistency Consistency of meaning of terms
Clarity Average number of word senses
Pragmatic quality Comprehensiveness Number of classes and properties
Accuracy Accuracy of information
Relevance Relevance of information for a task
Social quality Authority Extent to which other ontologies rely on it
History Number of times ontology has been used

Table 1. Metrics  for evaluating ontologies (Burton-Jones, A et al, 2005)

Metric Attribute REA evaluation
Syntactic quality Lawfulness
  • The REA ontology has a semantically rich internal structure (say) that is not limited to the IS-A relations as found in a typical thesaurus, and that defines axioms that allow for semantic reasoning.
  • However, many details of the REA ontology internal structure and underlying logic are not explicitly specified (e.g., disjointness of concepts).
Semantic quality Interpretability
  • The authors don’t evaluate the semantic quality of the REA ontology because of their focus on the applicability of the ontology.
Pragmatic and
Social quality
  • Both the pragmatic and social qualities of the REA ontology are evaluated largely in terms of the ontology’s applications and the extent to which the ontology is useful for users and their agents, irrespective of syntax and semantics.
  • The REA ontology supports a wide range of applications and users:
    • education in accounting and business
    • model-driven systems and software design
    • supply chain and e-collaboration
    • knowledge representation and retrieval
Social quality Authority

Table 2. Evaluation of the REA ontology.

The authors’ evaluation of the syntactic quality of the REA ontology as a domain ontology for business highlighted the following deficiencies:

  • the REA ontology was a somewhat incoherent mix of textual and graphical elements that spoke to its relative immaturity
  • while some researchers (Bialecki 2001; Chou 2006; Geerts 2004) had taken steps to represent the REA ontology in a machine-readable format, none of these formalizations was widely known or generally accepted
  • like Geerts and McCarthy (1999), the authors recognized the importance of better specifying the REA ontology

Again, we will leave it largely up to the readers to familiar themselves with the details of how the authors enhance the specification of the REA ontology. The main principles of their approach included:

  • the authors apply formal procedures – the METHONTOLOGY framework (Fernandez-Lopez et al. 1997; G6mez-Perez and Rojas 1999) and the Operational Data Model (OMG, 2006) – to re-engineer the existing REA ontology
  • Three main activities are identified in this re-engineering process (Figures 2 and 3):
    • reverse engineering – the conceptualization of the REA ontology is recovered from whatever representation formats are available (e.g. text, tables, modeling diagrams)
    • re-structuring – the recovered conceptualization of the REA ontology is re-designed and expressed in a graphical representation with well-defined syntax and semantics (like the UML Profile for OWL) 1
    • forward engineering – the re-designed conceptualization is transformed into a re-engineered, formal language representation (like OWL)


A Business Domain Ontology Re-engineering Methodology - Process, Activities and Artifacts

Figure 2. A Business Domain Ontology Re-engineering Methodology – Process, Activities and Artifacts.


REA Ontology Transformation and Tools

Figure 3. The recovery, re-design, and formalization of the REA domain ontology for business.

With this overview of the methodology used by Geerts, Laurier and Poels to re-engineer the REA ontology in 2007 – 2008, we can turn to the resulting graphical representation (UML Profile of OWL) and formal language representation (OWL) of the REA domain ontology for business.

Next: Graphical representation of the REA domain ontology for business (UML Profile for OWL)




  1. Using UML in the re-design of the REA ontology capitalizes on the familiarity of many end-users  in the business domain with this technology.

Jim Amsden – Service oriented architecture Modeling Language (SoaML)

Jim Amsden is Senior Technical Staff Member, IBM. His papers provide a nice introduction to SoaML – a technology I’ll be using to visualize a vocabulary of Government Services derived from

Modeling with SoaML (2010)

Using SoaML Services Architecture (2012)

Integrating BPMN and SoaML (2014)