<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Towards a Common Ontology for Business Models</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Birger Andersson</string-name>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Maria Bergholtz</string-name>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Ananda Edirisuriya</string-name>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Tharaka Ilayperuma</string-name>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Paul Johannesson</string-name>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Bertrand Grégoire</string-name>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Michael Schmitt</string-name>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Eric Dubois</string-name>
          <email>eric.dubois@tudor.lu</email>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Sven Abels</string-name>
          <email>abels@wi-ol.de</email>
          <xref ref-type="aff" rid="aff4">4</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Axel Hahn</string-name>
          <email>hahn@offis.de</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Jaap Gordijn</string-name>
          <email>gordijn@cs.vu.nl</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Hans Weigand</string-name>
          <email>H.Weigand@uvt.nl</email>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Benkt Wangler</string-name>
          <email>benkt.wangler@his.se</email>
          <xref ref-type="aff" rid="aff5">5</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Computer Science Vrije Universiteit</institution>
          ,
          <addr-line>Amsterdam</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Dept. of Informatic Science, University Oldenburg</institution>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Public Research Centre Henri Tudor Luxembourg bertrand.gregoire</institution>
        </aff>
        <aff id="aff3">
          <label>3</label>
          <institution>Royal Institute of Technology Department of Computer and Systems Sciences</institution>
          ,
          <country country="SE">Sweden</country>
        </aff>
        <aff id="aff4">
          <label>4</label>
          <institution>University of Oldenburg, Business Information Systems Department of Computing Science</institution>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff5">
          <label>5</label>
          <institution>University of Skövde, School of Humanities and Informatics</institution>
          ,
          <country country="SE">Sweden</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>To create an understanding of enterprises and the ways they do business, a starting point could be to identify the main actors and the values transferred between them. Business models are created in order to make clear who the business actors are in a business case and to make their relations explicit. The relations are formulated in terms of values exchanged between the actors. The purpose of the work reported in this paper is to create a better understanding of business models by identifying basic notions used in such models. It does so by constructing a common ontology based on three established business model ontologies: e3-value, REA, and BMO. By means of a careful analysis of these ontologies a conceptual schema is created that defines the common concepts. An example is worked out that explains how the common ontology should be understood.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1 Introduction</title>
      <p>It is widely accepted that when modelling enterprises and the ways they do
business, a starting point could be to identify the main actors and the values
transferred between them. This can be performed in terms of business models.
Business models are created in order to make clear who the business actors are in a
business case and to make their relations explicit. Relations in a business model are
formulated in terms of values exchanged between the actors.</p>
      <p>A business model is different from a process model, as a process model captures
other kinds of relations between actors than those of a business model. For instance, a
process model may contain information about time ordering between activities or
flows of goods between actors.</p>
      <p>The purpose of this paper is to identify the basic notions of business models by
constructing a common business model ontology based on three established
ontologies: e3-value, REA, and BMO. An ontology is an explicit, shared specification
of a conceptualization and one use of ontologies is to define a Universe of Discourse
[ibrow00]. In this paper the Universe of Discourse is business modelling. The
rationale for creating such a common ontology is mainly theoretical, as it shows the
commonalities and relationships between these ontologies and also highlights the
differences between, such as differences in naming practice, abstraction level, and
business rule semantics. Another benefit is that opportunities for extensions and
revisions of the established ontologies are discovered and can be considered.
Examples of novel business modeling concepts defined in the common ontology are
rights, custody and evidence documents, all of which are introduced in order to refine
the, from a business modeling point of view, central analysis of value transfers
between actors.</p>
      <p>This paper is structured as follows. As we aim to produce a common ontology,
based on three ontologies, we briefly present their salient features in Section 2.
Section 3 presents the common ontology with explanations. Section 4 discusses some
open issues and suggests future work
2 Salient features of e3-value, REA and BMO</p>
      <p>The common ontology presented in this paper is based on three established
business model ontologies: e3-value, REA, and BMO. These ontologies were
originally developed for different and specific purposes, but there has also been recent
work on expanding their applicability. REA was originally intended as a basis for
accounting information systems [McCarthy82] and focused on representing increases
and decreases of value in an organisation. However, REA has been extended to form
a foundation for enterprise information systems architectures [Hruby06], and it has
also been applied to e-commerce frameworks [UMM03]. e3-value focuses on
modelling value networks of cooperating business partners and provides mechanisms
for profitability analysis that help in determining whether a certain value network is
sustainable [Gordijn04]. Extensions of e3-value have been suggested that incorporate
process related aspects as well as risk management [Bergholtz05] and [Weigand06].
BMO differs from the two other ontologies by being much wider in scope. In addition
to modelling exchanges of resources, BMO also addresses internal capabilities and
resource planning. Furthermore, BMO incorporates marketing aspects describing
value propositions as well as marketing channels [Osterwalder05].</p>
      <sec id="sec-1-1">
        <title>2.1 The REA Ontology</title>
        <p>The REA (Resource-Event-Actor) ontology was formulated originally in
[McCarthy82] and developed further in a series of papers, e.g. [Geerts99]. Its
conceptual origins can be traced back to traditional business accounting where the
needs are to manage businesses through a technique called double-entry bookkeeping.
This technique records every business transaction as a double entry (a credit and a
debit) in a balanced ledger.</p>
        <p>The core concepts in the REA ontology are Resource, Event, and Actor and the
intuition behind the ontology is that every business transaction can be described as an
event where two actors exchange resources. To get a resource an agent has to give up
some other resource. For example, in a purchase a buying agent has to give up money
to receive some goods. The amount of money available to the agent is decreased,
while the amount of goods is increased. There are two events taking place here: one
where the amount of money is decreased and another where the amount of good is
increased. This repetition of events is called a duality. A corresponding change of
availability of resources takes place at the seller's side. Here the amount of money is
increased while the amount of goods is decreased. An exchange is when an agent
receives economic resources from another agent and gives resources back to that
agent; and vice versa. A conversion is when an agent consumes resources to produce
other resources [Hruby06]. Events fulfill the commitments of actors. A commitment is
defined as being "an agreement to execute an event in a well-defined future that will
result in either an increase or a decrease of resources" available to an agent. Thus,
events "happen" because there exists commitments between actors, and the duality
relation between events exists because of a relation called reciprocity between
commitments. Which commitment is related to which is established through an
agreement.</p>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>2.2 The e3-value Ontology</title>
      <p>The e3-value ontology [Gordijn00] aims at identifying exchange of value objects
between the business actors. It also supports profitability analysis of the business
model created. The basic concepts in e3-value are actors, value objects, value ports,
value interfaces, value activities and value exchanges. An actor is an economically
independent entity. An actor is often, but not necessarily, a legal entity. Examples:
enterprises, end-consumers. A value object is something that is of economic value for
at least one actor. Examples: cars, Internet access, stream of music. A value port is
used by an actor to provide or receive value objects to or from other actors. A value
port has a direction, in (e.g., receive goods) or out (e.g., make a payment) indicating
whether a value object flows into or out of the actor. A value interface consists of in
and out ports that belong to the same actor. Value interfaces are used to model
economic reciprocity. A value exchange is a pair of value ports of opposite directions
belonging to different actors. It represents one or more potential trades of value
objects between these value ports. A value activity is an operation that could be
carried out in an economically profitable way for at least one actor.</p>
      <sec id="sec-2-1">
        <title>2.3 The Business Model Ontology</title>
        <p>The Business Model Ontology (BMO) was originally proposed in [Osterwalder04]
to provide an ontology that allows to accurately describing the business model of a
firm. The BMO takes the perspective of a single enterprise, highlighting its
environment and concerns for facing a particular customer’s demands. It consists of
nine core concepts: (i) Value Proposition that is an overall view of a company's
bundle of products and services that are of value to the customer. (ii) Target Customer
that is a segment of customers that a company wants to offer value to. (iii)
Distribution Channel that is a means of getting in touch with the customer. (iv)
Relationship that the kind of link a company establishes between itself and the
customer. (v) Value Configuration that describes the arrangement of activities and
resources that are necessary to create value for the customer. (vi) Capability that is the
ability to execute a repeatable pattern of actions that is necessary in order to create
value for the customer. (vii) Partnership that is a voluntarily initiated cooperative
agreement between two or more companies in order to create value for the customer.
(viii) Cost Structure that is the representation in money of all the means employed in
the business model. (ix) Revenue Model that describes the way a company makes
money through a variety of revenue flows.</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>3 A Common Ontology</title>
      <p>In this section, we introduce ontology for business models. This common ontology
is constructed using the concepts of e3-value, REA and BMO as inputs to an analysis
and subsequent synthesis. The method used in constructing the common ontology has
been to survey all concepts, tabulate them and carry out an analysis to establish
similarities and differences [Rosemann02, Wohed05].</p>
      <p>We have aimed at including all of the concepts in REA and e3-value except for a
small number of peripheral concepts, i.e. concepts that occur in only one of the
ontologies and are not central for the issue of value transfers. For BMO, we have
covered only a small part of the ontology, as BMO is wider in scope than the other
two ontologies and also goes into issues of internal organizational capabilities and
resource planning. We have also introduced a small number of concepts that do not
have any direct correspondences in the original ontologies. This has been done mainly
in order to analyse the notions of value transfer and resource.</p>
      <p>As the three original ontologies include concepts on the operational level as well as
the knowledge level, the common ontology has to include both these levels. As
described in [Fowler97], the operational level models concrete, tangible individuals in
a domain. The knowledge level, on the other hand, models information structures that
characterise categories of individuals at the operational level. For example, the
ontology distinguishes between Resource types (categories of resources like car
models) and Resources (specific, tangible things like concrete cars). Almost all
classes on the operational level have a corresponding class on the knowledge level.</p>
      <p>The following paragraphs contains the concepts in the common ontology and their
meanings are given informally. The concepts from the original ontologies are mapped
on the concepts of the common ontology using the definitions given in their
specifications, for a more extensive comparative analysis on the commonalities and
differences between the investigated ontologies, see [Andersson06c].</p>
      <sec id="sec-3-1">
        <title>Actor</title>
        <p>An Actor is someone who is able to participate in events (event defined below).</p>
      </sec>
      <sec id="sec-3-2">
        <title>Resource, Feature, and Right</title>
        <p>A Resource is an object that is regarded as valuable by some actors. An actor views
a resource as valuable because she can use it for producing other resources, for
trading it with other actors, or for deriving some consumer experience. Essentially
any object can be a resource. However, it is possible to identify some typical
categories of resources like goods, information, and services. A resource may have
properties and associations to other objects, like the weight of a pizza or the number
of shops accepting a credit card. Such properties and associations are modelled by
means of the class Feature.</p>
        <p>Resources are furthermore related to rights. A Right on a resource means that an
actor is entitled to use that resource in some way. An example is the ownership of a
book, which means that an actor is entitled to read the book, give it to someone else,
or even destroy it. Another example of a right is borrowing a book, which gives the
actor the right to read it, but not to give it away or destroy it or use it in any other
way. Fig. 1 shows the main classes: Resource, Feature and Right that are described in
this section together with their relationships to other classes.</p>
      </sec>
      <sec id="sec-3-3">
        <title>Event, Transfer, and Conversion</title>
        <p>An Event changes a feature or a right of a resource. An event is associated to
exactly one actor representing the perspective from which the event is viewed. This
means that each event can be seen as either an increment or decrement event from the
actor’s perspective. An increment event changes a feature or a right of a resource in
such a way that the resource becomes more valuable for the actor, while a decrement
event causes a change that decreases the value of the resource. In order to model
increments and decrements, an attribute stockflow of the class Event is introduced that
can take one of the values in {use, consume, produce, give, take}. This corresponds to
the stockflow relationship in REA [McCarthy82].</p>
        <p>The class Event has two subclasses, Transfer and Conversion [Hruby06]. A transfer
means that a right is transferred from one actor to another (for a more detailed
analysis, see the next subsection). If the actor of the event receives the right to the
resource, the event is a take event (represented by the stockflow attribute). If the actor
gives up the right to the resource, the event is a give event. Similarly, a conversion
event changes some feature of a resource. If this change means that a new resource is
created or the value of an existing resource is increased, the event is a produce event.
If the resource is completely consumed and no longer exists after the event, it is called
a consume event. If the resource is used but continues to exist also after the event, it is
called a use event. Use, consume, and give are decrement events, while produce and
take are increment events. Fig. 2 shows the events, transfers, conversions and their
relationships to other classes such as exchanges, interfaces, transactions, etc.
Rights, Custody and Evidence Documents - Three components of a Transfer
A Transfer from A to B can be viewed as consisting of three components:
− transferring rights on a resource from A to B
− giving custody of the resource to B
− transferring an evidence document (documenting the transferred right) from A
to B</p>
        <p>The second component of a Transfer is transferring the custody of the resource
being exchanged from one actor to another. An actor has the Custody of a resource if
he has immediate charge and control of the resource, typically physical access of the
resource. If an actor has the custody of a resource, this does not mean that she has any
rights on the resource. For example, a distributor may have the custody of some
goods, but he is not allowed to use the goods in any way. Providing custody of a
resource is essential in a value exchange, as the buyer is typically unable to exercise
the rights she gets unless she has custody of the resource. In the common ontology,
custody is modeled by means of the custody attribute of a Transfer.</p>
        <p>A Transfer may also include the transfer of some evidence document that certifies
that the buyer has certain rights on a resource. A typical example of an evidence
document is a movie ticket that certifies that its owner has the right to watch a movie.
While the first component, the transfer of right, always is included in a Transfer, the
last two components are optional. For example, when buying a piece of land, the
buyer is typically not given the custody of that resource. Clearly, evidence documents
are not always provided in a value exchange. Furthermore, the provision of custody
and evidence documents may be so trivial that it is not of interest to make them
explicit. A related approach may be found in [Kartseva06] where the legal and
economic aspects of a value object are presented. That approach, however, highlights
the transfer of rights only, and does not go to into the details of transfer of custody
and evidence documents in addition to the transfer of rights.</p>
        <p>EVENT TYPE
increment/decrement
1
0..*
0..*</p>
        <p>has_actor type</p>
        <p>TRANSFER TYPE
1
range</p>
        <p>1
0..*</p>
        <p>ACTOR TYPE
RESOURCE TYPE</p>
        <p>1
1</p>
        <p>0..*</p>
        <p>RESOURCE
EVIDENCE DOCUMENT
0..1
CONVERSION</p>
        <p>0..*</p>
      </sec>
      <sec id="sec-3-4">
        <title>Process, Interface, Exchange, Transaction, and Transformation</title>
        <p>A Process is a set of Event types including increment as well as decrement event
types, i.e. a process specifies how to group together a number of transfer and
conversion event types. This means that a process, as defined here, only describes the
changes of rights and features of resources; it does not specify temporal or
communicative aspects. These aspects are certainly relevant for processes in general,
but they are outside the scope of business models. The notion of a process is quite
general, as it may contain any event types. It is, therefore, useful to identify a number
of specialised processes, and the ontology distinguishes between interfaces,
exchanges, transactions, and transformations. An Interface is a process consisting of
transfer event types all associated to the same actor type. An interface specifies that
an actor (type) is prepared to trade according to the transfer event types of the
interface. An Exchange is a process consisting of a pair of one give transfer event
type and one take transfer event type associated to two different actor types. An
exchange specifies that one actor (type) is prepared to give a resource to another actor
(type) who takes it. A Transaction is a process consisting of a number of exchanges,
or more precisely, the transfer event types included in the exchanges. A transaction
specifies that two actor (types) are prepared to trade with each other according to the
1..*</p>
        <p>VALUE PROPOSITION
0..*
1
RESOURCE TYPE</p>
        <p>VALUE ACTIVITY
1..*</p>
        <p>1..*</p>
        <p>EVENT TYPE
increment/decrement
TRANSFER TYPE
1..*
refers_to
TRANSFORMATION
1</p>
        <p>EXCHANGE</p>
        <p>1..*
TRANSACTION
1</p>
        <p>FEATURE
0..* INTERFACE</p>
        <p>PROCESS
transfer event types of the exchange. A Transformation is a set of conversion event
types all associated to the same actor type. A transformation specifies that some
resource is produced while other resources are consumed or used.</p>
      </sec>
      <sec id="sec-3-5">
        <title>Value Proposition</title>
        <p>A Value proposition consists of a resource type and a number of features and
processes containing decrement event types associated to that resource type. A value
proposition does not only specify a resource type offered by an organisation but also
arguments why the customer should buy that resource type. These arguments can
consist of references to features of the resource, such as the freshness or nutritional
content of a pizza. Another kind of an argument is references to processes where the
resource is used or consumed in order to produce or improve other resources. For
example, an argument for buying a kitchen machine is that it can be used to produce
freshly squeezed orange juice.</p>
      </sec>
      <sec id="sec-3-6">
        <title>Commitment, Contract, and Agreement</title>
        <p>A Commitment is an obligation to carry out a give Transfer within an Exchange in
the future. A Contract is a collection of Commitments. An Agreement is an
arrangement between two Actors that specifies in advance the conditions under which
they will trade. The Fig. 3 given below relates the commitment to exchange, contract
and agreement.</p>
        <p>1
fulfills</p>
        <p>0..*
COMITTMENT
1..*
1</p>
        <p>CONTRACT</p>
        <p>AGREEMENT</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>4 Pawnshop Example</title>
      <p>In this section, we introduce an example that illustrates most of the concepts in the
common ontology.</p>
      <p>Fig. 4 and Fig. 5 show high-level models of the pawnshop business case based on
the graphical notation of e3-value. The gray rectangles models actors, the rounded
rectangles model interfaces, the triangles models value ports, and the lines model
value transfers (see also sect. 2.2).</p>
      <p>The business idea behind a pawnshop is to lend money to borrowers on a
shortterm basis accepting goods as collateral. A pawnshop and a borrower can make
business according to two different Transactions. The first is that the borrower gets a
time limited right to use the money and pays an interest; this is the case where the
borrower returns the money and gets the collateral back. The second Transaction is
that the borrower gets ownership of the money and the pawnshop gets ownership of
goods, i.e. the collateral; this is the case where the borrower does not return they
money and the pawnshop takes the collateral. While the model in Fig. 4 shows the
rights transferred between agents, it does not include changes in custody. A more
detailed model with changes in custody and taking evidence documents into account
is given in Fig. 5 (this model deviates from e3-value by distinguishing between
different types of transfers). The goods are transferred to the shop that then has the
custody of the goods while the borrower gets money and a receipt. If the customer
does not come back to the shop before a set date, present his receipt and pays to get
his goods back, then the ownership of the goods is transferred to the shop. The shop is
then free to sell the goods.</p>
      <p>The top arrow in the upper value interface represents the transfer of custody
(logistic flow) of goods from the borrower to pawnshop and in return the borrower
receives two rights from the pawnshop: ownership of money and the right to claim the
goods back later (represented via the documentary evidence, a receipt). Notice that in
this interface the customer gives up custody of the good and the pawnshop receives
the same custody, however it does not get the right to use the good. The pawnshop
has in fact an obligation to keep the good safe in case the borrower claims it back.
There are no restrictions on what a customer can do with the receipt. He may sell it or
give it away as he pleases since he has not given up his ownership of the goods but
only custody of it. A buyer of the receipt will buy the ownership rights of the goods
and may approach the pawnshop and claim the custody on the goods.</p>
      <p>The middle value interface represents the return of the money from borrower to
pawnshop and the transfer of goods back from pawnshop to customer This is
represented by three transfers: one transfer of rights from borrower to pawnshop
(meaning ownership right of money), one transfer of custody of goods from
pawnshop to borrower (a logistic flow of goods), and the receipt being returned to the
pawnshop (a logistic flow of documentary evidence without any transfer of rights).</p>
      <p>The lower interface models the situation where the ownership right of the good is
transferred from customer to pawnshop condition that the customer did not pay back
in time, i.e. it is a transfer of right (ownership of good) from customer to pawnshop.</p>
    </sec>
    <sec id="sec-5">
      <title>5 Summary and Concluding Remarks</title>
      <p>In this paper we have presented a common ontology based on three business
ontologies – the e3-value, REA and BMO. We constructed the common ontology
primarily in order to gain a better understanding of the original ontologies. The work
has shown that there is a considerable overlap between them but that there are also
differences, some obvious and some subtle.</p>
      <p>When constructing the common ontology we focused on concepts that mainly
concern communications and exchanges of values between business actors and,
therefore, some concepts of the originals were not included in the common ontology.
We have modelled a number of business scenarios using the common ontology and
by doing so discovered differences between concepts in the original ontologies that at
first might have been seen as identical. An example is that Economic resource in REA
and Value object in e3-value might seem identical to each other. However, they are
different as can be seen by analysing what is happening in an Economic event. In an
Economic event, something is transferred from one agent to another agent, but what is
transferred is not an Economic resource, but the control of an Economic resource. For
example, one Economic event may transfer the ownership of a car, while another
Economic event lends the car. These Economic events concern the same Economic
resource but transfer different rights on that resource. This motivates the introduction
of Rights in the common ontology – in a Transfer, the right to a resource is
transferred from one agent to another. In e3-value, a Value exchange transfers a Value
object from one agent to another. Therefore, Value object is mapped to the
combination of Right and Resource in the common ontology Similarly, the concept of
a Transfer gave rise to the issue of what is transferred. To address this question, we
analysed the concept into three sub-concepts; Custody, Documentary evidence and
Right transfer and thereby extended the common ontology with concepts not present
in the originals. One item for future research is to address more in detail those issues.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [Andersson06]: Andersson,
          <string-name>
            <given-names>B.</given-names>
            ,
            <surname>Bergholtz</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Edirisuriya</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            ,
            <surname>Ilayperuma</surname>
          </string-name>
          ,
          <string-name>
            <given-names>I.</given-names>
            ,
            <surname>Johannesson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            ,
            <surname>Grégoire</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            ,
            <surname>Schmitt</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Dubois</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            ,
            <surname>Abels</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            ,
            <surname>Hahn</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            ,
            <surname>Gordijn</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            ,
            <surname>Weigand</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            ,
            <surname>Wangler</surname>
          </string-name>
          ,
          <string-name>
            <surname>B.</surname>
          </string-name>
          , “
          <article-title>Towards a Reference Ontology for Business Models”, submitted to the 25th International Conference on Conceptual Modeling (ER2006) 2006</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <surname>[Bergholtz04]: Bergholtz</surname>
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jayaweera</surname>
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Johannesson</surname>
            <given-names>P.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Wohed</surname>
            <given-names>P.</given-names>
          </string-name>
          , “
          <article-title>A pattern and dependency based approach to the design of process models”</article-title>
          ,
          <source>Proc. 23nd International Conference on Conceptual Modeling (ER</source>
          <year>2004</year>
          ), Shanghai-China, Springer, LNCS,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [Bergholtz05]: Bergholtz,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Grégoire</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            ,
            <surname>Johannesson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            ,
            <surname>Schmitt</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Wohed</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            and
            <surname>Zdravkovic</surname>
          </string-name>
          <string-name>
            <surname>J.</surname>
          </string-name>
          , “
          <article-title>Integrated Methodology for linking business and process models with risk mitigation”</article-title>
          ,
          <source>REBNITA 05.</source>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [Fowler97]
          <string-name>
            <surname>Fowler</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>Analysis</given-names>
            <surname>Patterns</surname>
          </string-name>
          .
          <source>Reusable Object Models. ISBN: 0-201-89542-0</source>
          . Addison-Wesley,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [Geerts99]: Geerts,
          <string-name>
            <given-names>G.</given-names>
            and
            <surname>McCarthy</surname>
          </string-name>
          ,
          <string-name>
            <surname>W. E.</surname>
          </string-name>
          ,
          <article-title>An Accounting Object Infrastructure For Knowledge-Based Enterprise Models</article-title>
          .
          <source>IEEE Intelligent Systems &amp; Their Applications (July-August</source>
          <year>1999</year>
          ), pp.
          <fpage>89</fpage>
          -
          <lpage>94</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [Gordijn00]: Gordijn J.,
          <string-name>
            <surname>Akkermans</surname>
            <given-names>J.M.</given-names>
          </string-name>
          and
          <string-name>
            <surname>Vliet J.C. van</surname>
          </string-name>
          , “
          <article-title>Business Modeling is not Process Modeling”, Conceptual Modeling for E-Business and the Web</article-title>
          ,
          <source>LNCS 1921</source>
          , Springer-Verlag pp.
          <fpage>40</fpage>
          -
          <lpage>51</lpage>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [Gordijn04]: Gordijn,
          <string-name>
            <surname>J.</surname>
          </string-name>
          <article-title>"e-Business Model Ontologies", book chapter contribution to "eBusiness Modelling Using the e3value Ontology"</article-title>
          ,
          <source>Wendy Curry (editor)</source>
          , pp.
          <fpage>98</fpage>
          -
          <lpage>128</lpage>
          , Elsevier Butterworth-Heinemann, UK,
          <year>2004</year>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [Hruby06]: Hruby,
          <string-name>
            <given-names>P.</given-names>
            ,
            <surname>Model-Driven Design Using Business Patterns</surname>
          </string-name>
          .
          <article-title>Forthcoming book</article-title>
          .
          <source>ISBN: 3-540-30154-2</source>
          . Springer Verlag 2006.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [ibrow00]. ibrow.
          <article-title>Meta-Data and UPML</article-title>
          . UPML v.
          <volume>2</volume>
          .0.
          <string-name>
            <surname>Omelayenko</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Crubézy</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fensel</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ding</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Motta</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Musen</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          <year>www</year>
          .cs.vu.nl/~upml/upml2.0.pdf.
          <source>Accessed</source>
          <year>2006</year>
          -
          <volume>04</volume>
          -01 [Kartseva06]: Vera Kartseva, Jaap Gordijn,
          <string-name>
            <surname>Yao-Hua</surname>
            <given-names>Tan</given-names>
          </string-name>
          ,
          <article-title>"Inter-Organisational Controls as Value Objects in Network Organisations"</article-title>
          ,
          <source>proceedings of CAISE</source>
          <year>2006</year>
          ,
          <year>Luxembourg 2006</year>
          [McCarthy82]
          <string-name>
            <surname>: McCarthy W. E.</surname>
          </string-name>
          , “
          <article-title>The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment”</article-title>
          ,
          <source>The Accounting Review</source>
          <year>1982</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [Osterwalder04]: Osterwalder,
          <string-name>
            <surname>A.</surname>
          </string-name>
          ,
          <article-title>The Business Model Ontology. A Proposition in a Design Science Approach</article-title>
          .
          <source>PhD-Thesis</source>
          . University of Lausanne,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [Osterwalder05]: Alexander Osterwalder, Yves Pigneur &amp;
          <article-title>Christopher Tucci, Clarifying Business Models: Origins, present and Future of the Concept, CAIS</article-title>
          , Vol.
          <volume>15</volume>
          , p.
          <fpage>751</fpage>
          -
          <lpage>775</lpage>
          .
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [Rosemann02]: Rosemann,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Green</surname>
          </string-name>
          ,
          <string-name>
            <surname>P.</surname>
          </string-name>
          ,
          <article-title>Developing a meta model for the Bunge-WandWeber ontological constructs</article-title>
          .
          <source>Information Systems</source>
          ,
          <volume>27</volume>
          (
          <issue>2</issue>
          ), pp.
          <fpage>75</fpage>
          -
          <lpage>91</lpage>
          .
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [UMM03]
          <article-title>: “UN/CEFACT Modeling Methodology (UMM) User Guide”</article-title>
          , http://www.unece.org/cefact/umm/ .
          <source>Accessed November</source>
          ,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [Weigand06]
          <string-name>
            <surname>Weigand</surname>
            ,
            <given-names>H. P.</given-names>
          </string-name>
          <string-name>
            <surname>Johannesson</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          <string-name>
            <surname>Andersson</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          <string-name>
            <surname>Bergholtz</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Edirisuriya</surname>
          </string-name>
          , Th. Ilayperuma, “
          <article-title>On the Notion of Value Object”, accepted for publication in the proceedings of CAiSE'06</article-title>
          . LNCS, Springer Verlag,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [Wohed05]
          <string-name>
            <surname>Wohed</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Andersson</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <article-title>Reconciliation of two Business Modelling Frameworks</article-title>
          .
          <source>In The 17th Conference on Advanced Information Systems Engineering (CAiSE '05)</source>
          , Porto, Portugal,
          <fpage>13</fpage>
          -
          <lpage>17</lpage>
          June,
          <year>2005</year>
          ,
          <string-name>
            <given-names>CAiSE</given-names>
            <surname>Forum</surname>
          </string-name>
          , Short Paper Proceedings.
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>