TOWARDS A META MODEL FOR DESCRIBING

COMMUNICATION

How to address interoperability on a pragmatic level

Boriana Rukanova, Kees van Slooten, Robert A. Stegwee

School of Business, Public Administration and Technology, University of Twente, P.O.Box 217, 7500 AE Enschede,

The Netherlands

Keywords: business information systems, interoperability, pragmatics, standard

Abstract: The developments in the ICT led companies to strive to make parts of the business transaction electronic

and raised ag

ain the issue of interoperability. Although interoperability between computer systems has been

widely addressed in literature, the concept of interoperability between organizations is still to a large extent

unexplored. Standards are claimed to help achieving interoperability. However, experience with the

implementation of EDI standards shows that many EDI implementation projects led to technical solutions

with unclear business benefits. New standards are currently being developed, however their implementation

can also lead again to purely technical solution, if the social context is not taken sufficiently into account. In

this paper we address the problem on how to identify interoperability problems on a pragmatic level that can

occur between organizations that want to carry out business transactions electronically. We also point out

that, in order to identify interoperability problems on a pragmatic level, it is necessary to capture the

communication requirements of the business parties and to evaluate to what extent a standard is capable to

meet these requirements. To perform that evaluation we develop a meta model for describing

communication. The meta model is based on theory of speech-act and communicative actions. The use of

the meta model to identify interoperability problems on a pragmatic level is illustrated with an example.

1 INTRODUCTION

The developments in the area of ICT made possible

disparate information systems to exchange data

electronically. This raised the question of how to

achieve interoperability. The issue of

interoperability between software systems has

already been widely addressed (Goh et al., 1999;

Heiler, 1995; Wegner, 1996). Further, it is expected

that the use of standards can help in resolving the

interoperability problems. However, experience with

the implementation of EDI standards shows that

often the result is a technical interoperability

between software systems with unclear business

benefit (Covington, 1997; Huang, 1998). Other

standards are currently being developed. Examples

are RosettaNet, and HL7. However, there is a danger

that an implementation of such a standard could lead

again only to a technical solution, rather than

improving the way of doing business. This means

that more than technical interoperability between

computer systems is needed, but rather

interoperability between organizations (business

information systems) is to be achieved (Stegwee &

Rukanova, 2004).

To achieve interoperability between

rganizations, it is important to realize first, that an

organization is a combination of people and

technology. Second, each organization operates in

its own context. Thus, the organizations need to

define a shared communication context in order to

enter into business transactions together (Stamper,

1996; Vermeer, 2000).

If the business parties decide to use computers to

erform parts of the business transaction

electronically, then the relevant shared context needs

to be made explicit, formalized and embedded in the

computer systems. In case where standards are used

to formalize the relevant shared context, a standard

needs to be evaluated to what extent it is capable to

cover the relevant shared context (Rukanova et al.,

2003a). This check is important to indicate where

interoperability problems might arise. One

possibility to make the comparison between the

requirements of the communication context and the

375

Rukanova B., van Slooten K. and A. Stegwee R. (2004).

TOWARDS A META MODEL FOR DESCRIBING COMMUNICATION - How to address interoperability on a pragmatic level.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 375-382

DOI: 10.5220/0002636903750382

 SciTePress

capabilities of a standard is by using a meta model,

which captures elements of a business transaction

(Rukanova et al., 2003b).

To capture the context of a business transaction,

a number of views can be defined (Rukanova et al.,

2003c). These views can help to look at the business

transaction from different perspectives and provide a

holistic understanding of the context of a business

transaction. The analysis of the different views can

contribute to the identification of interoperability

problems that can occur, when different

organizations decide to do business transactions

electronically.

In this paper we will investigate only one of the

views: “the communicative acts view”, which is

concerned with how to describe the conversations

and the intentions in a business transaction. This

view is concerned with the pragmatics aspect in a

business transaction. The pragmatics underlines the

importance that it is not sufficient to understand

what is communicated, but also what is the intention

behind it, how you interpret the communicated

information and how you act upon it. This paper is

concerned with how to identify interoperability

problems on a pragmatic level.

To achieve interoperability on a pragmatic level,

it is necessary to be able to express and compare the

requirements of the business transaction (on a

pragmatic level) and the capability of the standard to

cover these requirements. In this paper we create a

meta model for describing conversations to help

make that comparison.

The remaining part of the paper is structured as

follows. In part two, a number of theoretical

constructs to describe communication are identified.

In part three these constructs are used as a basis for

defining a meta model for describing

communication. In part four we use the meta model

to evaluate the capabilities of a standard to cover the

business requirements (on a pragmatic level).

2 ELEMENTARY UNITS TO

DESCRIBE COMMUNICATION

As it was mentioned in the introduction, the main

concern in this paper is how to achieve

interoperability on pragmatic level, if organizations

want to use standards in order to carry out their

business transactions electronically. Thus, it is

necessary to identify key elements that can capture

communication requirements of a business

transaction and further to use these elements to

evaluate the extent to which a standard is capable of

capturing the communication requirements. As we

are currently interested in the pragmatic aspect of

communication, it means that the elements that we

need to identify have to address the problem of what

is communicated, and how is it interpreted. Further,

as we are interested in the whole business

transaction, we need to identify what communication

takes place during the entire transaction lifecycle.

2.1 E-message and Ae-message

The research done in the area of information systems

and language-action perspective can provide us with

substantial input to be able to identify key elements,

which describe communication. As this research

addresses communication in general, we can apply

some of the findings to describe communication

specific for business transactions. To define what is

communicated and what is the intention behind the

communicated information, we will make use of the

notions of elementary message (e-message) and

action elementary message (ae-message).

The notion of e-message is defined by Langefors

(Langefors, 1973). According to Langefors, an e-

message consists of four basic terms to give

information about the property of an object: the

identity of an object, the kind of property, the

specification of that property for that object, the

point in time at which the information is valid.

Further we add that an object can have multiple

properties. Thus each combination of object (id),

property, property value and time can result in an e-

message. If we want to describe the different

properties of an object at a given time, a number of

e-messages can be defined. This can be

schematically presented as illustrated in figure 1.

The ORM notation (Halpin, 1996) is used as a

means for representation of the models in this paper.

Object

(Id)

Has

Time

Property

(Value)

Figure 1: An object defined in terms of elements of e-

messages

Although using the elements of e-message is a

good starting point for describing communication, it

provides a limited view, as it implies a purely

descriptive approach toward information. (Goldkuhl

& Lyytinen, 1982; Winograd & Flores, 1986).

However, language can be used not only to describe

things, but also to perform actions (Austin, 1962;

Goldkuhl, 1995; Habermas, 1984; Searle, 1969). In

order to capture the intention behind the

communicated information, the notion of action

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

376

elementary message (ae-message) can be used

(Agerfalk, 1999, 2002; Goldkuhl & Agerfalk, 2002).

The notion of the ae-message is built upon the

notion of e-message, and extended to capture the

intention. An ae-message is composed of four

elements: the communicator, the interpretor, the

propositional content (the content that is

communicated), and the communicative function

(the intention behind the communicated information)

(see Figure 2).

Propositional

content

ae-

message

Has

communicator

Interpreter

Communicative

function

Has

Figure 2: Elements of an ae-message.

We will elaborate further on the concepts of

communicative function and the propositional

content. The propositional content consists of a

number of e-messages. The propositional content is

the content, which is communicated, that is

information about objects and their properties at a

certain time. (See Figure 3)

Propositional

content

Object

(Id)

Has

Time

Property

(Value)

Has

Figure 3: Elements of a propositional content.

There are relationships between the objects,

which are part of the prepositional content, however,

for simplicity reasons this relationship is not

explicitly represented in the model

The other concept included in the ae-message,

which deserves attention, is the communicative

function (synonyms are illocutionary acts and action

mode). The communicative function contains the

intention of the speech act. Different types of

communicative functions (illocutionary acts) can be

identified (see (Habermas, 1984; Searle, 1969)).

Examples of communicative functions are order and

promise. The main point that we want to make here

is to stress the importance of the communicative

function in capturing intentions behind the

communicated information. We will not go further

into describing the different types of communicative

functions. However, in part 2.2 of this paper, we will

come back to the concept of communicative

functions to explore their role in forming patterns of

conversations.

So far we have identified some elementary

constructs for describing communication. However,

although describing ae-messages is a big step in

describing communication, the speech acts theories

are criticized in two directions. The first one is that

they do not pay much attention to the content of

what is communicated (the propositional content)

(Schoop, 2003). The second one is that they focus

mainly on the individual speech acts, and not on the

whole conversation. This issue will be further

addressed in the next section.

2.2 Sequence of Utterances

The Speech-act approaches focus mainly on the

individual speech-acts rather than the whole

conversation, thus the speech-act theory cannot be

used to explain the organization of communication

(Goldkuhl, 2003). The research done by Winograd

and Flores (Winograd & Flores, 1986) can help in

addressing this problem, as the authors argue that the

main focus should not be on the individual speech-

acts, but the conversation, in which individual

speech acts are related to one another. Their key

contribution is in the identification of basic patterns

for describing conversations- the “conversation for

action” scheme (see figure 4).

Figure 4: The basic "Conversation for Action" Adopted

form Winograd and Flores, 1986, p. 65

The schema describes different states that a

conversation can take and how the states are altered

through the performance of speech acts. For

example, actor A can make a request to another

actor B. B can either promise to fulfil the request,

counter the request or reject it. Here we can see how

different communicative functions (e.g. request,

promise) can interplay to form a conversation.

Flores and Winograd have influenced a number of

researchers in the field of Language action

perspective. Based on the conversation for action

scheme, a number of communication patterns have

been derived. However, the derived patterns seem to

be rather prescriptive. The result of this is that, when

describing a real life situation, one might end up

TOWARDS A META MODEL FOR DESCRIBING COMMUNICATION: HOW TO ADDRESS INTEROPERABILITY

ON A PRAGMATIC LEVEL

377

with actually changing the requirements of the real-

life situation so that they can fit into the pre-defined

pattern. This however is undesirable. Thus, although

interaction patterns can be helpful in eliciting the

conversation requirements, their use should be done

with caution (Goldkuhl, 2003).

In the introduction we started with the problem

of how to identify interoperability problems (on a

pragmatic level) that can occur if companies decide

to do business transactions electronically by using

standards. So far, we have identified a number of

elements, which can help us to describe

conversations. This enables us to move to the next

step for addressing the interoperability on pragmatic

level: linking these elements in a meta model for

describing conversations.

3 A META MODEL FOR

DESCRIBING CONVERSATIONS

In the previous section we have identified a number

of concepts to describe a conversation. However,

these concepts alone provide a fragmented view of

elements of conversation. In this section, we link

these concepts into a meta model.

The meta model is presented in Figure 5 below.

ae-message

Propositional

content

Communicative

function

Communicator Interpreter

Object

(Id)

Property

(Value)

Time

Sequence of

utterances

Has

Is part of

Figure 5: A meta model for describing conversations

Although most of the concepts were already

introduced earlier, a brief description and

explanation of the meta model is provided below. A

key concept around which the meta model is built is

the ae-message. An action elementary message has a

communicator, an interpreter, a propositional

content, and a communication function. Further, an

ae-message is part of a conversation, and the

conversation can be described with sequence of

utterances. We consider the real life situation as a

starting point for identifying sequence of utterances.

Communication patterns (such as the “conversation

for action” scheme of Winograd and Flores) can be

used as a support tool to describe the sequence of

utterances, once they have been identified based on

the real-life situation. Although the scheme of

Winograd and Flores is very powerful in expressing

different possibilities that a conversation can follow,

there could be real-life situations, where this scheme

can turn to be limited. Thus, the Winograd and

Flores scheme, as well as any other patterns of

conversations (whenever available) should be used

with caution.

To overcome the critique that speech acts do not

focus on the content of what is communicated (see

2.1), the notion of propositional content is explicitly

includes in the model. The propositional content

contains information about objects, the properties of

objects, the values of the properties and the time the

value is valid.

In that way, the meta model captures information

about the content of the message that is

communicated, who is the communicator and the

interpreter of that message, what is the intention of

that message and how it forms part of a

conversation.

The main benefit from the meta model is that it

can be used to describe both the communication

requirements of a business transaction and the

capabilities of the standard in the same terms. When

both, the requirements of the business transaction

and the capabilities of the standard are expressed in

terms of the meta model, they can be easily

compared (see also (Rukanova et al., 2003a, b). A

mismatch between the two will mean that some of

the requirements of the business transaction cannot

be covered by the standard, which would signal

interoperability problems (on a pragmatic level). In

the section below we will illustrate the use of the

meta model.

4 THE META MODEL IN USE

In this section we will illustrate the use of the meta

model to identify whether interoperability on a

pragmatic level can be achieved. We will first

introduce a standard (the (HL7) standard will be

used for our example). Further we will describe a

simple business transaction, which needs to be

automated using the HL7 standard. We will translate

the requirements of the business transaction in terms

of the meta model. We will also translate the

capabilities of the standard in terms of the meta

model. Once expressed in the same terms, we will be

able compare the requirements of the business

transaction and the capability of the standard to meet

these requirements. A mismatch between the two

will mean that there could be interoperability

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

378

problems on a pragmatic level, which can hinder the

way of doing business. Due to space limits, in this

example we will not elaborate in full detail the

elements describing the propositional content.

However, such a description can be done and is

important part of the analysis.

4.1 The HL7 Standard

For this example we will look at the HL7 v.3

standard. HL7 is one of the leading Healthcare

standards for clinical data interchange. The standard

covers transactions in several areas, some of which

are accounting and billing, claims and

reimbursement, and diagnostic orders and

observations. For the purpose of this example we

will look at how the interactions are defined in the

HL7 standard and we will limit our analysis to the

interactions related to Laboratory observations.

Before going further we will provide some

background information about the HL7 v.3 standard.

In the basis of the HL7 v.3 is the HL7 Reference

Information Model (RIM). The RIM models, on a

very high abstract level, the major things of interest

in the healthcare domain. It consists of six major

classes, defines the attributes of these classes and the

relationships between them. The messages that are

exchanged in the clinical communication are derived

from the RIM. However, the link between the RIM

and the message that is actually exchanged is not

straightforward, but it requires intermediary steps.

As the concepts in the RIM are very general, a

procedure called cloning is defined. After this

procedure, a domain message information model is

defined (DMIM). This model is derived from the

RIM, and provides further restrictions on the defined

information (by for example restricting the attributes

of the classes). This domain message information

model is then used to create the Hierarchical

message description, which defines in full detail the

messages that are later exchanged in the interactions.

A central class in the RIM is the “Act”. The act

represents actions that are executed and must be

represented as the healthcare processes take place.

An example of Act is (Lab) Order. The information

provided above is important in order to understand

how interactions are defined in the HL7 standard.

In the HL7 v.3 Guide, an interaction is defined

as “ a unique association between a specific message

type (information), a particular trigger event, and the

application roles that send and receive a message

type. It is a unique, one-way transfer of

information.” From this definition we can derive,

that an interaction is uniquely defined using four

components: the sending application role (a system

component which sends a message), the receiving

application role (a system component, which

receives the message), the trigger event (the reason

to send a message), and the message type (what

message to send) (see Figure 6).

Message type

Interaction

Has

Sending role

Receiving

role

Trigger event

(mood, state-transition,

type)

Has

Figure 6: Description of the HL7 interactions

To better understand the interactions, as defined

in the HL7 standard, some further elaboration is

needed on the notion of a trigger event. According to

the HL7 v.3 Guide, “a trigger event is an explicit set

of conditions that initiate the transfer of information

between system components (application roles). It is

a real-world event such as the placing of a laboratory

order or drug order.” The trigger event is expressed

as a combination of mood, state-transition, and type.

The “mood” is a very important concept in the HL7

v.3 standard. It distinguishes between statements of

facts that the ordered service (act) has been

completed, or it specifies the intent to perform such

a service. Examples of moods as defined in the HL7

are “order” (an order of a service), “promise” (a

promise that the service will be performed), and

“event” (a statement that the service has been

performed). Another important attribute of act is act

status. The act status captures the defined state of an

act. Examples of act status are “active” (the act can

be performed or is performed), and “completed” (an

act that has terminated normally after all of its

constituents have been performed). A change in the

act status can lead to a state-transition (for example

an act status can become from “active” to

“completed”. The third element defining the event is

type. There are three types of events defined in the

HL7 standard: user request based, interaction based

and state-transition based trigger events. Within this

paper we will not go into describing these concepts

into full detail. However, it is important to say that

the combination of mood, state-transition, and type

can capture the intent behind the message.

Based on the analysis of the HL7 concerning lab

order, we found out that the HL7 trigger events

supports the following intentions: request to fulfil an

order, promise to fulfil the order, rejection to fulfil

the order, statement that the order has been fulfilled.

We will come back to these elements in the next

section.

TOWARDS A META MODEL FOR DESCRIBING COMMUNICATION: HOW TO ADDRESS INTEROPERABILITY

ON A PRAGMATIC LEVEL

379

4.2 Evaluation of the HL7 Standard

In section three of this paper we have presented a

meta model for describing conversations. In section

4.1. we have introduced a brief description of how

interactions are described in the HL7 standard. The

aim of this section is to express the capabilities of

the HL7 standard concerning Lab order in terms of

the meta model.

From the meta model for describing

conversations it can be said that an ae-message has

propositional content, communicator, interpreter,

and communicative function. The interactions

defined in the HL7 standard correspond to the ae-

messages defined in the meta model. The sending

role and the receiving role (as defined in HL7) can

be translated as communicator and interpreter in

terms of the meta model. The trigger event can be

translated as communicative function in terms of the

meta model and the hierarchical message description

can be seen as propositional content. Further, the

trigger events defined for Lab order in the HL7

standard support the following communicative

functions: request to fulfil an order, promise to fulfil

the order, rejection to fulfil the order, statement that

the order has been fulfilled. For illustrative purposes,

we can map these communicative functions to the

scheme of Winograd and Flores (see figure 4). Note,

we have first identified the interactions supported by

the standard and after that we check whether the

interactions can be mapped to the scheme of

Winograd and Flores. Further, for this example the

scheme provides a good visualization of the different

interactions. From the mapping we can see that the

HL7v.3 standard supports the individual interactions

request (1,2), promise (2,3), reject (2,8) and declare

(3,4) (see Figure 4).

Different elements of the propositional content

are covered in an HL7 message. In the HL7

message, information about objects of interest for

the transactions is captured. Examples of such

information is information about the patient (and

how one can identify a patient), or the about the

properties of a patient, such as name and the sex.

Further, the HL7 standard defines the reference

values for such properties. Although we will not be

able to further elaborate on the propositional content

due to limitations of space that we have for this

paper, such an analysis is important and can be done

in practice.

In the next section we describe a business

transaction, parts of which would need to be

automated using the HL7 standard.

4.3 Description of the Business

Transaction

For the purpose of this example, we use an

imaginary business transaction, which we describe

below. Let us imagine that a doctor sees a patient

and decides to order a lab tests for him. Thus, the

doctor has to enter into a business transaction with

the Lab. For the communication between the doctor

and the Lab there is an agreement to communicate in

the following way. The doctor orders a lab test. The

Lab either accepts to perform the lab test and

confirms the order, or rejects the order. Once the lab

test is performed, the Lab sends the Observation

result to the doctor and the doctor either does not

communicate back (in case that he does not have

objections to the test result), or asks for correction, if

he thinks that there is a mistake. Currently this

communication is paper-based. However, this way

of communication is time consuming and time is

critical in the Healthcare domain. Also, a double

entry of data is required.

To reduce the time for carrying out a transaction

and to avoid double entry of information, a decision

is made to automate the communication between the

doctor and the Lab. Further, the HL7 standard is

chosen to support the electronic communication.

4.4 Describing the business

transaction in terms of the meta

model

In this section we will translate the requirements of

the business transaction described in 4.3. in terms of

the meta model. We start with analysing the

elements of an ae-message again. If a message is

send from the doctor to the Lab, then the doctor can

be translated as a communicator in the ae-message

and the Lab as the interpreter of the ae-message. If

the Lab sends a message to the doctor, then the Lab

is the communicator of the ae-message and the

doctor is the interpreter. In case the transaction is

electronic, these roles can be played by the

applications used by the doctor and the interpreter.

The propositional content corresponds to the

content of the paper documents exchanged between

the Doctor and the Lab. The communicative

functions that are used in the communication

between the doctor and the Lab are: Ordering of a

lab test, acceptance to perform the lab test, rejection

to perform the test, statement that the test is

completed, questioning of the result of the test. To

visualize the communicative functions, we can again

map them to the scheme of Winograd and Flores.

This would result in the following interactions:

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

380

request (1,2), promise (2,3), reject (2,8), assert (3,4),

declare (4,3).

So far, we have expressed the requirements of

the business transaction and the characteristics of the

standard, both in terms of the meta model. This

enables us to compare the two, which will be done in

the next section.

4.5 Comparing the standard and the

requirements

Table 1 below provides a comparison of the

requirements of the business transaction and the

characteristics of the HL7 standard.

Table 1: Comparing the requirements of the business

transaction and the capabilities of the HL7 standard

Meta model

element

Requirement of

the Business

Transaction

HL7 Standard

Lab Orde

Specification of the

propositional

content

Required Capable to cover

(only for the

communicative

functions supported

by HL7)

Identification of the

communicator

Required Capable to cover

(identification of

the sending

application role)

Identification of the

Interpreter

Required Capable to cover

(identification of

the receiving

application role)

Communication

functions

Required:

Request (1,2),

promise (2,3),

reject (2,8),

assert (3,4),

declare (4,3).

Capable to cover:

Request (1-2),

promise (2,3),

reject (2,8),

assert (3,4),

Sequence of

utterances

Successful

completion

(1,2), (2,3), (3,4)

Failure

(1,2), (2,8)

Questioning the

outcome

(1,2), (2,3), (3,4),

(4,3)

Successful

completion

(1,2), (2,3), (3,4)

Failure

(1,2), (2,8)

From the analysis it is clear that the HL7

standard (concerning Lab orders) is a good standard

to cover the communication requirements between

the doctor and the Lab. It has the capability to

identify the communicator and the interpreter of a

message, as well as the content of the message and

the intention behind it. It can support both the

conversation that can lead to successful completion

of the business transaction as well as to failure. For

the interactions that are supported by the HL7

standard, the HL7 standard specifies in detail the

propositional content in terms of objects, properties,

and it defines the reference values that these

properties can have. Thus, we consider that the

propositional content defined in the HL7 standard

can cover the requirements of the business

transaction. However, as we mentioned earlier, we

will not go further in detail in elaborating the

propositional content.

However, the HL7 does not support situations

where the doctor can question the results of a lab

test, thus a conversation that can lead to questioning

of the outcome is not supported. Neither is the

propositional content for this type of interaction.

This can be a problem for achieving full

interoperability between the Doctor and the Lab,

unless additional measures to compensate for that

are undertaken.

The aim of this example was mainly to illustrate

how the meta model can be used. Although we

looked at a simple transaction, the principles of the

analysis can be applied to analyse very complex

situations. This can be done by first, identifying the

different parties that take part in a business

transaction. And second, by applying a separate

analysis of the conversations between each two

parties separately, as illustrated in the example.

5 CONCLUSIONS AND FURTHER

RESEARCH

In the introduction we stated that it is important to

explore the concept of interoperability, going

beyond interoperability between software systems.

We further addressed the issue of interoperability on

a pragmatic level between organizations, which

would like to do business transactions electronically

by using standards. We also pointed out that in order

to identify interoperability problems on a pragmatic

level, it is necessary to capture the communication

requirements of the business parties and to evaluate

to what extent a standard is capable to meet these

requirements. The contribution of this paper can be

seen in two main directions. It stresses the

importance to look beyond the interoperability

between software systems. Second, it addresses the

issue of identifying interoperability problems on a

pragmatic level and provides a meta model to help in

that problem identification. We also provided an

example on how the meta model can be used in

practice.

TOWARDS A META MODEL FOR DESCRIBING COMMUNICATION: HOW TO ADDRESS INTEROPERABILITY

ON A PRAGMATIC LEVEL

381

The example used in this paper describes a rather

simple transaction. The purpose of the example was

to illustrate how the meta model can be used.

However, the steps illustrated in this example can be

used to analyse very complex transactions.

The future research on this topic can continue in

two main directions. The first one is to empirically

test the usefulness of the meta model in real life

situations. The second one is to explore the concept

of interoperability between organizations, capturing

other aspects, apart form pragmatics.

REFERENCES

Agerfalk, P. J. (1999). Pragmatization of Information

Systems: A Theoretical and Methodological Outline,

Licentiate Thesis. Linkoping University.

Agerfalk, P. J. (2002). Messages are Signs of Action-

From Langefors to Speech Acts and Beyond. In

Proceedings of LAP'02, 80-100

Austin, J. L. (1962). How to do Things with Words,

Oxford University Press.

Covington, M. A. (1997). On Designing a Language for

Electronic Commerce. International Journal of

Electronic Commerce 1(4): pp. 31-48.

Goh, C. H., S. Bressan, et al. (1999). Contex Interchange:

New Features and Formalisms for the Intelligent

Integration of Information. ACM Transactions on

Information Systems 17(3): pp.270-292.

Goldkuhl, G. (1995). Information as Action and

Communication. The Infological Equation: Essay in

the Honour of B. Langefors: 63-79.

Goldkuhl, G. (2003). Conversational Analysis as a

Theoretical Foundation for Language Action

Perspective.In proceedings of LAP 2003, 51-69

Goldkuhl, G. and P. J. Agerfalk (2002). Actability: A Way

to Understand Information Systems Pragmatics. In Liu

K. Clarke, R., Andersen, P., Stamper, R. (eds.)

Coordination and Communication Using Signes.

Boston, Kluwer Academic Publishers.85-115

Goldkuhl, G. and K. Lyytinen (1982). A Language Action

View on Information Systems. In proceedings of the

Third International Conference on Information

Systems, Ann Arbor, MI.

Habermas, J. (1984). The Theory of Communicative Action

1. Reason and the Rationalization of Society.

Cambridge, Polity Press.

Halpin, T. (1996). Business Rules and Object Role

Modeling. Database Programming and Design

(October 1996).

Heiler, S. (1995). Semantic interoperability. ACM

Computing Servey 27(2).271-273

HL7 "http://www.hl7.org/."

Huang, K. (1998). Organizational Aspects of EDI: a

Norm-oriented Approach (PhD thesis).

Langefors, B. (1973). Theoretical analysis of Information

Systems, Studentlitteratur.

Rukanova, B. D., Slooten, C. v, Stegwee, R.A. (2003)a.

Beyond the Standard Development and the Standard

Adoption

. In proceedings of 8th EURAS Workshop on

Standardization, Germany., Mainz Publishers.

120-

138

Rukanova, B. D., Slooten, C. v, Stegwee, R.A. (2003)b.

Towards a Meta Model for Distributed Business

Transactions. In proceedings of CAiSE '03 Forum

Information Systems for a Connected Society.141-144

Rukanova, B. D., Slooten, C. v, Stegwee, R.A. (2003)c.

Capturing the Context of a Business Transaction. In

proceedings of 3rd International Interdisciplinary

Conference on Electronic Commerce"ECOM-03",

Gdansk, Poland. 135-141

Schoop, M. (2003). A Language-Action Approach to

Electronic Negotiations. In proceedings of LAP 2003,

143-160

Searle, J. R. (1969). Speech Acts. An Essay in the

Philosophy of Language. London, Cambridge

University Press.

Stamper, R. (1996). Organisational Semiotics. F. S. J. M.

(eds.). Information Systems: An Emerging Discipline.

London and New York, McGraw-Hill.

Stegwee, R.A., Rukanova, B.D. (2003). Identification of

Different Types of Standards for Domain-Specific

Interoperability. In: Proceedings of MIS Quarterly

Pre-Conference Workshop ICIS 2003. pp. 161- 170,

Retrieved January, 2004 from

http://www.si.umich.edu/misq-stds/proceedings/

Vermeer, B. (2000). How Important is Data Quality for

Evaluating the Impact of EDI on Global Supply Chain.

Proceedings of the 33 Hawaii International

Conference on System Science.

Wegner, P. (1996). "Interoperability." ACM Computing

Servey 28(1): 285-287.

Winograd, T. and F. Flores (1986). Understanding

Computers and Cognition: A New Foundation for

Design. Norwood, Ablex.

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

382