DEMO Engine
Pedro Matos de Carvalho, Carlos Mendes and Miguel Mira da Silva
Instituto Superior Técnico, Universidade Técnica de Lisboa, Avenida Rovisco Pais, Lisboa, Portugal
Keywords: Enterprise Ontology, DEMO, Service Fulfilment, Service Quality, Communications’ Gap.
Abstract: The service sector is the biggest of the world economy. It leads the creation of value in organizations.
However, the service sector presents quality gaps that reduce customers' satisfaction and revenues. The
fourth gap of service quality states that there is a difference between the service delivered and the
communication acts involved in that delivery. In this research we proposed an approach based on Enterprise
Ontology (EO) theory to mitigate this gap. Our proposal also includes the development of a software
system, based on Design & Engineering Methodology for Organizations (DEMO) and Service Level
Agreements (SLA), the DEMO Engine. This research was conducted using the Design Science Research
Methodology (DSRM). The demonstration of our proposal is done using an artificial example of a use of the
DEMO Engine in a Travel Agency. The evaluation was made with feedback collected from 47 academic
and by using the 4 Österle principles.
1 INTRODUCTION
The services industry has grown exponentially in the
last decades. Throughout the years the service sector
has become the number one driver to obtain value in
the economy (Central Intelligence Agency, 2011).
These services comprise many daily activities,
which include telecommunication, mass media,
financial, franchising, health care or even tourism.
The importance of the service sector can be inferred
by looking at the world’s GDP – 63.4% is related to
services – and workforce – 42.4% of world’s
population work in the service sector (Central
Intelligence Agency, 2011; International Monetary
Fund, 2012). Also, the top 20 of the most successful
companies are directly or indirectly related to
services (Forbes, 2012), whether in their main
business focus or related to after-sale services, such
as warranties, repairing, etc.
With this impact on the world’s economy, it is
imperative to ensure that each and every service is
done accordingly and satisfies customers’
expectations. Achieving customer satisfaction will
be dependent on service quality, and this quality will
be the major competitive advantage towards other
services (Henry Chesbrough, 2006).
In order to control quality, several frameworks
and tools were developed to ensure principles that
could guarantee service quality. Information
Technology Infrastructure Library (ITIL) and
Capability Maturity Model Integration (CMMI) are
examples of said frameworks that try to bring out
these principles. Nevertheless, ITIL and CMMI are
based upon best practices, which are not necessarily
the best options due to their lack of theoretical
background on implementation options. Other
approaches from the Web Services community also
fail to comprise this factor.
In this research we used the Enterprise Ontology
(EO) and the corresponding methodology Design &
Engineering Methodology for Organizations
(DEMO) (Dietz, 2006) as a mean to reduce the
service quality gaps and, thus, achieve higher levels
of service quality. Our proposal is based on previous
works done in the area of Service Level Agreements
(SLA) definition (Mendes and Mira da Silva, 2012;
Almeida, 2012) that tackled the first three gaps.
Now, we continue the research by also tackling gap
number four of service quality. This gap is a result
of the difference between the service produced and
the service communicated to the customers. This
way our solution tackles all the gaps identified by
(A. Parasuraman, 1985). At first EO might not seem
related to services but another research in the field
brought these two areas closer since they defined the
service concept using EO terms (Albani et al., 2009).
To validate this research we demonstrated our
proposal using a fictional example of a Travel
445
Matos de Carvalho P., Mendes C. and Mira da Silva M..
DEMO Engine.
DOI: 10.5220/0004649604450452
In Proceedings of the International Conference on Knowledge Engineering and Ontology Development (SSEO-2013), pages 445-452
ISBN: 978-989-8565-81-5
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
Agency. We then evaluated the impact of the
application of the system and we collected feedback
from 47 academics that granted us with valuable,
precise and concise feedback.
In this research we used Design Science
Research Methodology (DSRM) (Hevner et al.,
2004; Peffers et al., 2008).
The paper is structured as follows. We start by
describing the service quality gaps problem (Section
2). Then, we present a system that can be seen as
similar to our approach (Section 3). Afterwards, we
introduce the DEMO-based solution to specify the
services quality (Section 4). In Section 5, we
describe the demonstration of our proposal using a
fictional example. In Section 6, we explain the
evaluation process. Finally, we present our
conclusions (Section 7).
2 PROBLEM
This section corresponds both to the problem
identification & motivation phase and to the
objectives definition phase of DSRM.
Service quality is closely related to increased
market share and return of investment, but quality is
difficult to be measured and to be assured (A.
Parasuraman, 1985). Nevertheless, in order to be
successful, organizations need to obtain this quality
to gain a competitive advantage. If organizations
cannot measure quality, they cannot know if they
already provide services with quality or what is
needed to be done to improve.
Service quality has five gaps that can be used to
assess where the customers’ expectations of quality
are being corrupted. These gaps serve as a guideline
for organizations to know what, where and how to
tackle the lack of service quality. This gaps were
designed by (A. Parasuraman, 1985):
Gap 1: The difference between the customer’s
service expectation and the provider’s perception
of that expectation;
Gap 2: The service specification as used by the
service provider differs from the expected service
as perceived by the customer;
Gap 3: The difference between the specified
service and the delivery of that service;
Gap 4: The gap between the service delivered
and the external communication to customers of
that service;
Gap 5: The global difference between the
customers' expected service and the perceived
service they receive.
Our main focus, gap number 4, can be caused by
sales overpromising, ineffective management of
customers' expectations or inadequate horizontal
communication. An example of this gap can be a
customer not being informed when a bug he/she
reported was repaired. We only focus on gap number
4 since the previous researches that supports our
work (Ferreira, 2010; Almeida, 2012; Mendes,
2013) have already tackled gaps 1, 2 and 3.
This gap 4 presents five communication
challenges: Service Intangibility, Management of
Service Promises, Management of Customer
Expectations, Customer Education and Internal
Marketing Communications.
There are several solutions that contributed to
closing the gaps, but none solved the problem
completely. Most of these solutions are function-
oriented solutions and these are not sufficient
because they lack an appropriate deep understanding
of enterprises and enterprises networks. Functional
knowledge is appropriate and sufficient for the use
and control of enterprises, but in order to change
them, knowledge about their construction and
operation is needed (Dietz and Albani, 2011).
We can summarize our research problem as
“Does a system that register all the coordination
acts involved in the service exchange diminishes
the gap between the service delivery and the
related communication? “.
Even though the result of this research question
might seem trivial, there is no research that actually
proves the result. Therefore, answering this question
appears to be a pertinent and innovative research.
Notice that with this system we only intend to tackle
the communications with the customer inside gap
number four. For example, defining the marketing
plan of an organization is not the purpose of this
research and can be seen as a limitation.
3 RELATED WORK
In a recent research (van Kervel, 2012) was designed
a modeling language for DEMO that uses extensible
markup language (XML) representations to capture
DEMO models, called DEMO modeling language
(DMOL).
The purpose of the DEMO processor is to be
able to offer a full decomposition of transactions,
disagreements patterns inclusion, concatenated and
parallel transactions identification, further detail
required in the action rules specification and
negative policy enforcement.
KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment
446
The processor takes use of definitions such as
business transaction model (BST) and enterprise
dynamic systems control (EDSC). BST are
specifications on how all actors co-operate and
communicate to an optimal production in an
enterprise. EDSC consists in a set of concepts
designed to enforce control of the enterprise in the
run-time business transactions.
With this is mind we can see that the DEMO
processor can be a great contribution to the creation
of an enterprise information system (EIS), an
information system driven by DEMO models.
Models used in this processor can later be read,
written, destroyed, constructed or executed using a
DEMO processor.
To create a DMOL model the users starts by
entering the desired DEMO models one by one in
the DEMO processor. After this the DEMO
processor tries to validate the models in a cyclic
process, every failure in validation is communicated
to the relevant stakeholders and they can edit the
model. A successful validation translates into a
renderization and storage of the model in DMOL. It
is important to refer that in every step the original
model can be parsed and rebuild.
This DEMO processor contributes to assess the
quality of DEMO models and re-engineering them,
if needed, before implementing them in real world
organizations. All the models that go through the
DEMO processor are assured with a formal rigor,
the absence of anomalies and guaranteed ontological
completeness.
In section 6 we will compare this DEMO
Processor with the proposal we present in this
research. The greatest fault of this processor is that it
focus primarily on modelling instead of execution
and has no quality component, essential to tackle our
research problem.
4 PROPOSAL
This section corresponds to the design and
development step of DSRM.
Our proposal is the creation of a system that
combines knowledge from EO, DEMO, Generic
Service Specification Framework (GSSF) and
DEMO-based SLAs in order to mitigate gap 4 of
service quality.
Not only we propose to register all coordination
acts and production facts involved in a service
exchange, the c-facts and p-facts should be available
to any actor that participates in the service delivery
and at any given moment. This way providers and
customers have more sense of control and
responsibility, since they get all the information they
need, whenever they need.
We intend to achieve 4c-ness in our proposal:
coherency, comprehensiveness, consistency and
conciseness (Dietz, 2006). We do not focus on the
essential characteristic of EO because we opted for
supporting ontological, infological and datalogical
services.
Furthermore, we intend to tackle the gap 4
communication challenges in the following way:
Service Intangibility: To create a simple service
catalogue that can be understood by the customer
using both GSSF (Terlouw and Albani, 2011) and
DEMO-based SLA (Mendes and Mira da Silva,
2012). Both the customer and the provider will be
active in the creation of the catalogue;
Management of Service Promises: DEMO roles
ensure that employees have a promise
jurisdiction. Also, customers will perceive the
“DEMO brand” and know what to expect of the
service. Customers will perceive DEMO and
know that patterns are the same in every
execution, making it harder for the providers to
overpromise without the customers noticing it;
Management of Customer Expectations: The
arguments of the DEMO SLA (such as bonus or
price) ensure that customers know what they are
paying for and what they can receive for a poor
service performance. Also, the initiator/executor
relationship clarifies which actors are
participating in the service. The customer knows
at which step is the execution and has a constant
feedback that allows him manage his
expectations;
Customer Education: Both the customer and the
provider responsibilities are stated in the DEMO-
based SLA. Customers can add custom
services/SLA to the provider’s catalogue to better
match their needs. Additionally, the DEMO
transaction patterns do not change from execution
to execution so the customer always knows about
the existing choices, they perceive what they have
to do, how and when;
Internal Marketing Communications: Make all
services, DEMO-based SLA and acts are visible
to all employees to increase communication
inside the organization. Even service executions
are always visible so that we can know which
state they are in.
DEMOEngine
447
5 DEMONSTRATION
This section corresponds to the demonstration phase
of DSRM. In order to demonstrate our proposal, we
have implemented a web-based prototype. The
prototype was developed using the SCRUM
methodology (Schwaber, 1995).
During the prototype development, the prototype
was used by two researchers to request services
between them. These two researchers provided
weekly feedback that was included in the prototype
features. The prototype includes the following
features:
Service Catalog Management: create, read,
update and delete services and SLAs. The
services can be specified using the GSSF
(Terlouw and Albani, 2011) and the SLAs using
the DEMO-based SLAs (Mendes and Mira da
Silva, 2012). This management is done in
collaboration with the providers and the clients;
Organization Resources Management:
connection between an organization’s resources
and the actor roles of a DEMO model. In other
words, the prototype allows us to define who are
the people that can implement certain actor roles
and, consequently, execute the respective
services;
Service execution Management: execution of
services according to the EO transaction patterns;
Notification Management: configure the
notifications by user, having the opportunity to
select the frequency of the e-mails. When the
SLAs have performance targets to be fulfilled,
calendar appointments are included in the e-mails;
Information exchange Management: every act
and every service execution is registered and
visible to the interested actors.
To better present these features we will use a
fictional example of a Travel Agency, where we
have James (the customer) who is requesting a “Trip
Advisory” service and John (the provider) who
answers James’s request.
James starts by looking at the Travel Agency
service catalogue and he notices a service that might
correspond to his needs, “Trip Advisory” (top of
Fig. 1). James then proceeds to click on the request
button and he is prompted with a pop-up to select
which allows him to select the service characteristics
(bottom of Fig. 1). He fills in information about the
context of the service (why he is requesting it) on
the “Execution Notes” field, he selects John as the
service provider and opts for the SLA associated
with the service. James now knows that his request
must be answered in the next 5 hours (response date)
and finalized over the course of the next 10 hours
(resolution date).
Now is the turn of John to deal with the request.
John receives an e-mail saying he has a request to
answer and, after agreeing with the options that
James requested, he promises the service directly
from the e-mail. Making this promise John agrees
with the SLA and agrees to deliver the “Trip
Figure 1: Trip Advisory Request (Catalogue on the top and pop-up on bottom).
KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment
448
Advisory” service in 10 hours. With this promise
John has fulfilled the first performance target of the
Trip Advisory’s SLA chosen, the response time.
Important to notice that after the promise, both
actors (James and John) receive an e-mail with the
coordination fact produced and also a Google
Calendar notification with the resolution time of the
Trip Advisory as deadline.
After the promise being done, John has to execute
the service. This execution is not the focus of
DEMO and therefore we do not intend to model it.
Nevertheless, one can think of the execution as John
looking up in his brochures for several beach resorts
and attaching those brochures to the service
execution of the DEMO Engine.
When John states that the “Trip Advisory has
been supplied”, James faces a problem. There is no
information about Brazil in the brochures, and a
close friend of him told him Brazil was a great place
to visit. James feels compelled to reject the service
and he justifies the reject with his concern.
John receives the reject from James and now has
to analyse it carefully. If he aborts the transaction
(making a c-act “stop”) he will possibly disappoint a
customer and damage the company’s image. On the
other hand, if he fulfills James proposition (re-
executing the service and performing the c-act state)
he will need to work more, work that is directly
unpaid.
John, being a good employee and caring about the
customers, decides to look for brochures of Brazil.
After selecting the according ones he attaches them
to the “Trip Advisory” service execution. After the
state fact is made, John fulfills the second
performance target of the SLA, the resolution date.
Finally James has to reach a final verdict, or he is
fully satisfied with the “Trip Advisory” performed
by John or he rejects it again. After reviewing the
new brochures, James feels satisfied with the
opinions he receives and has decided to spend two
weeks on a resort in Rio de Janeiro, Brazil.
If we look to Fig. 2 we can see the execution
evolution from James (left side) and John (right
side) point of view. We can see in this picture the
difference that happens in the interface between acts,
with the objective of facilitating the communication
so we can address our research problem.
James now feels that he needs to book a hotel in
Rio de Janeiro, but he wants to do the booking using
the Travel Agency. Nevertheless, after looking at
their catalogue, James sees that there is no “Hotel
Booking” service. So he proceeds to request a
custom service to the Travel Agency specifying the
features he wants. We can see James’ request in Fig.
3.
James opts not to fill in the SLA attributes to
specify the response date, the resolution date, the
penalty and the bonus of the service. This means that
the execution must be best-effort (ASAP). After
clicking request, John will receive notification of
this custom service. Now this service execution
flows the EO pattern according to the choices both
actors take. If the service is promised by John, the
service will be added to the service catalogue so that
any customer can request it, further enabling co-
creation.
6 EVALUATION
This section corresponds to the evaluation phase of
Figure 2: Trip Advisory Execution (left - client view, right - provider view).
DEMOEngine
449
Figure 3: Hotel Booking.
DSRM and in order to explain the evaluation, we
use the framework proposed in (Pries-Heje et al.,
2004). This framework identifies what is actually
evaluated, how it is evaluated and when the
evaluation takes place.
We evaluated the artifact evaluated is the
proposed system elaborated in Section 4 (a design
product), the results achieved by creating a
prototype and the feedback collected among
academics.
We did an artificial evaluation using the Travel
Agency example. We also used feedback given from
the academic community and a comparison between
our proposal and the DEMO Processor (van Kervel,
2012).
The evaluation was made ex post, that is, we first
constructed the prototype and only afterwards
proceeded with gathering feedback among
academics.
In order to evaluate the system we propose, we
compared it with the related work (the DEMO
Processor) (van Kervel, 2012).
Both approaches are based on EO and DEMO,
but nevertheless have different objectives. While our
proposal focus on the execution of any kind of
service using DEMO patterns, the DEMO Processor
has a bigger concern on creating and compiling the
correct DEMO models of an organization.
In DEMO Engine the models can be taken from
real use of the system instead of prior defined.
Furthermore, the knowledge of the organization
required to use both solutions is very different.
While in DEMO Engine anyone can specify services
and request them using knowledge from SLM, to use
the DEMO processor we need to know how the
organization works.
Being focused in the execution of services, the
DEMO Engine supports the notion of service
quality (from DEMO-based SLA), determinant to
tackle the gap number four. DEMO Processor lacks
this support.
Another big difference that stands out is that the
DEMO Engine only allows independent transaction,
or better, composed transactions are not actually
linked, there is no formal representation of it. The
DEMO Processor enables this linkage, therefore
allowing transaction and services with high
complexity.
Finally we can sum the difference of these
systems with the relation with their goals. The
DEMO Engine being focused on improving
communications between actors, has a special
concern with service quality and allowing interactive
communication with an intuitive interface, while
also using EO transactions. On the other hand,
DEMO processor focus on creating Information
Systems compliant with EO, therefore focusing
more on creating and compiling models.
We also gathered feedback from 47 academics to
better evaluate our proposal, this feedback was given
in interviews, presentations and workshops. All
feedback was collected after a presentation of this
research.
The first evaluation took place in a DEMO
workshop held in Lisbon by the DEMO Portuguese
community with a professor representing the
Japanese DEMO Community. There were 12
workshop attendees including Portuguese and
Japanese academics (professors and researchers).
The feedback collected had two major concerns.
The first is related to the interactiveness of the EO
patterns, increasing communication quality, helping
co-creation and a real representation of the
organization. The second is related to the potential
KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment
450
of data mining with real data from organizations,
especially concerning what are the best services for
an organization, which bring more value and which
do not.
The second live evaluation occurred in Lisbon in
a workshop held with students and professors from
the Virginia Commonwealth University (VCU).
There were 30 people attending. The audience was
characterized by being students of a Fast Track
Executive MS Information Systems in VCU.
This feedback collected was mostly related to the
importance of the topic, the relevance of the research
problem and motivation to keep pursuing the
mitigation of gap number four of service quality.
The third evaluation was made in a DEMO
Workshop, held in Lisbon, with a representative of
the Switzerland DEMO Community.
With this workshop we collected important
feedback that allowed us answer the Österle
principles. This feedback was especially concerned
about the connection between our proposed system,
the DEMO Engine, and the DEMO Processor.
As a final evaluation with academics we
interviewed a Portuguese academic that has access
to the DEMO Processor and could provide us with
important and concise feedback over the two
systems.
The most positive feedback we receive was
regarding the Management of Service Promises:
Service Standardization. According to him, our
proposal makes use of the EO patterns and that
reduces the communication mismatch in service
delivery. Also the Management of Customer
Expectations was considered as a major impact of
the DEMO Engine, especially because of the
DEMO-based SLA, Act visibility and clarification
of who participates in the service execution. The
factor that least improved with DEMO Engine was
the Service Intangibility: Service Perception. This
was mostly due to the lack of service context in the
system.
To conclude the evaluation we present how the
Four Principles from (Österle et al., 2011) were
accomplished in our research. The Abstraction
because the artifact we propose can be applied to all
types of services, ontological, infological or
datalogical. The Originality because the combine
usage of DEMO and SLA to tackle service quality
gaps was used in recent researches (Mendes, 2013)
but not to the gap number four. Also, using EO
patterns and oblige customers to explicit every
coordination act they make is a novel approach to
service management. The Justification because the
artifact is justified by all the evaluations and
feedback we gathered. Benefit because the DEMO
Engine artifact provides a way to reduce the
difference between the service delivery and the
communication involving that delivery, therefore
increasing the service quality.
7 CONCLUSIONS
The service sector is the largest economy sector and
is the driver for value creation in modern
organizations. With so many new services being
created quality becomes a distinct factor between
them. However quality in services is difficult to
measure and control. Nevertheless, it was created a
model to better understand the challenges services
faced. This model decomposed service quality in
five gaps. The gaps model was the first step towards
determining how to achieve quality services.
This research is focused on reducing the
difference between the expectations and perceptions
of customers when requesting services. We take off
from work done tackling other service quality gaps
(Ferreira, 2010; Almeida, 2012; Mendes, 2013) and
focus on the difference between the service delivery
and the communication of that delivery.
We intended to evaluate the impact of using the
communication patterns of EO to close this gap. For
that purpose, we developed a system that enables
transparency, readiness and easiness in
communication between the customer and the
service provider. We intend with this system address
the communication challenges of gap 4: Service
Intangibility, Management of Service Promises,
Management of Customers Expectations, Customer
Education and Internal Marketing Communications.
This research was done using DSRM. We
developed an artifact (the DEMO Engine) using a
software prototype that enables an overall better
service exchange between the customer and the
provider, and enabling co-creation. In order to
specify the contract of each service, we use SLA
knowledge (Mendes and Mira da Silva, 2012) and
service specification (Terlouw and Albani, 2011).
To better demonstrate the functionalities and
capabilities of the DEMO Engine, we demonstrated
the system using a fictional example of a service
request to a Travel Agency. The evaluation of this
research was done by applying the Österle principles
and gathering feedback from academics.
The first major contribution that this work
intends to pursue is the creation of an engine that
can enable an organization to have its Information
System based on DEMO, managing services with
DEMOEngine
451
4c-ness, while also simplifying the EO concepts to
make then usable for a wider range of people.
The second contribution is the enabling of
service co-creation based on EO. This was possible
by using dynamically defined services and SLA that
are negotiated over the course of an execution of an
EO transaction pattern.
The last major contribution that this research
pursues, is how to address the service
communication challenges of service quality gap
number 4 in EO terms.
As for future work there is the possibility of
creating processes based on DEMO to better
represent the real-world. Currently we only have
transactions associated to the DEMO Engine.
Also an important addition would be the
integration with present day systems to provide more
useful information and making it practical to use.
ACKNOWLEDGEMENTS
The authors would like to thank to all the
interviewees that had shared their time and
knowledge, to organizations for providing contacts,
and to everyone who help in the research, write and
review process.
REFERENCES
A. Parasuraman, V. Z. (1985). A Conceptual Model of
Service Quality and its Implication for Future
Research. Journal of Marketing.
Albani, A., Terlouw, L., Hardjosumarto, G., & Dietz, J.
(2009). Enterprise Ontology Based Service Definition.
4th International Workshop on Value Modelling and
Business, Amesterdam, The Netherlands.
Almeida, M. (2012). Specifying Customers Expectations
using DEMO-based SLAs. Lisbon: MSc Thesis -
Instituto Superior Técnico.
Central Intelligence Agency. (2011). The World Factbook.
Washington, DC: Central Intelligence Agency.
Dietz, J. (2006). Enterprise Ontology - Theory and
Methodology. Delft: Springer.
Dietz, J., & Albani, A. (2011). Enterprise Ontology Based
Development of Information Systems. International
Journal of Internet and Enterprise Management, 7(1),
41-63.
Ferreira, J. (2010). Implementação de Gestão de Serviços
de Informática. Lisbon: MSc Thesis - Instituto
Superior Técnico.
Forbes. (2012). The Forbes Global 2000. Retrieved
December 2012, from
http://www.forbes.com/global2000/list/
Henry Chesbrough, J. S. (2006). A Research Manifesto for
Services Science. Communications of the ACM, 49(7),
35-40.
Hevner, A., March, S. T., Park, J., & Ram, S. (2004).
Design Science in Information Systems Research. MIS
Quarterly.
International Monetary Fund. (2012). World Economic
Outlook Database. Retrieved December 2012, from
http://www.imf.org/external/pubs/ft/weo/2012/02/weo
data/index.aspx
Mendes, C. (2013). A Method Based on DEMO for
Managing Service Quality. Lisbon: PhD Thesis,
Instituto Superior Técnico.
Mendes, C., & Mira da Silva, M. (2012). DEMO-Based
Service Level Agreements. Exploring Services
Science, 103, 227-242.
Österle, H., Becker, J., Frank, U., Hess, T., Karagiannis,
D., Krcmar, H., . . . Sinz, E. (2011). Memorandum on
Design-Oriented Information Systems Research.
European Journal on Information Systems, 20, 7-10.
Peffers, K., Tuure, T., Rothenberger, M., & Chatterjee, S.
(2008). A Design Science Research Methodology.
Journal of Management Information Systems, 45-77.
Pries-Heje, J., Baskerville, R., & Venable, J. (2004).
Strategies for Design Science Research Evaluation.
16th European Conference on Information Systems
(ECIS), pp. 255-266.
Schwaber, K. (1995). Proceedings of the Workshop on
Business Object Design and Implementation at the
10th Annual Conference on Object-Oriented
Programming Systems, Languages, and Applications .
Terlouw, L., & Albani, A. (2011). An Enterprise
Ontology-Based Approach to Service Specification.
IEEE Transactions on Services Computing, 99, 1939-
1374.
van Kervel, S. a. (2012). Enterprise Ontology Driven
Software Engineering. ICSOFT'12, 205-210.
KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment
452
