AMS Radiocarbon Dating of Bone Samples from the Xinzhai Site in China

July 10, 2002 17:13 WSPC/173-IJITDM 00031

International Journal of Information Technology & Decision MakingVol. 1, No. 3 (2002) 491–510c© World Scientific Publishing Company

DEVELOPMENT OF AGENT-BASED E-COMMERCE SYSTEMS

USING SEMIOTIC APPROACH AND DEMO

TRANSACTION CONCEPT

JOSEPH BARJIS

Department of Computer Science, The University of ReadingP.O. Box 225, Whiteknights, Reading, RG6 6AY, United Kingdom

Tel: +44 118 931 6024, Fax: +44 118 975 [email protected]

http://is.twi.tudelft.nl/∼barjis

SAMUEL CHONG

School of Computing, Staffordshire UniversityStafford, Beaconside, ST18 0AD, England, UKTel: +44 1785 353509, Fax: +44 1785 353497

[email protected]

JAN L. G. DIETZ

Department of Information Systems & Software EngineeringDelft University of Technology, P.O. Box 356, 2600 AJ, Delft, The Netherlands

Tel.: +31 15 2785827, Fax: +31 15 [email protected]

KECHENG LIU

School of Computing, Staffordshire UniversityStafford, Beaconside, ST18 0AD, England, UKTel: +44 1785 353509, Fax: +44 1785 353497

[email protected]

As software agents get more sophisticated, it becomes difficult to understand and modelsuch systems. This paper contends that all developers bring to the task of development

some implicit or explicit assumptions of the agent communication pattern. This issue isnot readily addressed in current literature and represents a gap in knowledge. For thispurpose, a generic pattern of inter-agent communication is introduced and discussed inthis paper. For better understanding and modelling of agent-based e-commerce systems,the semiotic approach and the DEMO transaction concept are briefly introduced. It isshown that the semiotic approach offers a unifying framework for identifying the rolesof agents, the responsible human agents and the right/constraints associated with eachrole. The DEMO transaction concept is applied to model the communicative interactionbetween agents.

Keywords: Software agent; agent communication; Semiotics; DEMO methodology.

491

July 10, 2002 17:13 WSPC/173-IJITDM 00031

492 J. Barjis et al.

1. Introduction

Electronic commerce is emerging as one of the most exciting research areas in our

era. E-commerce systems are dynamic networks of interrelated transaction processes

between two or more trading agents.

Agent-based technology is emerging as a powerful paradigm for developing

e-commerce systems. In recent years, software agents have been introduced to

e-commerce. Software agents in e-commerce systems have some autonomy and the

ability to sense and react to their environment, as well as socially communicate and

cooperate with other software agents in order to accomplish their duties which are

delegated from the human agents. Software agents can potentially help the human

agents to perform some delegated tasks, such as searching for some products of in-

terest, negotiate with the supplier and even make payment on behalf of the human

agents. By looking at the business processes of agent-based e-commerce systems,

the following features are observed. First of all, it is a process between two agents,

supplier and customer (or customer and supplier, depending on who is the initia-

tor of the current deal). Secondly, it is observed that communication for a deal in

e-commerce involves the exchange of electronic transactions between these agents.

As the capabilities in software agents become more complex, it becomes more

difficult to model and design agent-based e-commerce systems. While the technolo-

gies for developing agents are maturing and advancing at an increasing rate, there

is a lack of methods that is based on sound and theoretically principle for modelling

such systems. In order to build a successful and effective agent-based e-commerce

system, one needs a proper study of the way in which agents communicate to

each other. Thus, the inter-agents communication perspective becomes an impor-

tant issue in the study of agent-based e-commerce systems. Although numerous

papers5,6,20 are dedicated to this issue, it is still a poorly understood one. For in-

stance, existing design methods such as the Agent Oriented Relationship modelling

method,18 Gaia Methodology for Agent Oriented Analysis and Design,20 Agent

Modelling Technique (AMT),12 Multiagent System Engineering (MaSE) method7

and the Agent Oriented Methodology (AOM)10 only excel in generating low-level

design diagrams and offer little guidance in helping the designers to study the inter-

agent communication. Therefore, an efficient, adequate and easily understandable

technique is needed to model agent-based e-commerce in order to improve the design

of the system.

This paper investigates e-commerce systems from the communication perspec-

tive based on the semiotic approach and the DEMO (Dynamic Essential Modelling

of Organization) modelling technique. DEMO is a modelling methodology mainly

considering a business system from the communication perspective.9 It emphasizes

a uniform communication pattern between agents, involved in a business deal. A so-

cial model of the business domain is obtained through the analysis of how meanings

and intentions can be conveyed by language (signs) and what aspects of language

need to be captured so that through the representation of data, the agent-based

July 10, 2002 17:13 WSPC/173-IJITDM 00031

Development of Agent-Based E-Commerce Systems 493

e-commerce system can function as an effective substitute for human communica-

tion. Through this model, the roles of agents and their potential behaviour (e.g.

buys, subscribes) can be identified. For this purpose, the authors consider that

the DEMO transaction concept and the semiotic approach can more properly and

adequately represent and model an agent-based e-commerce system.

2. Generic Communication Pattern for Agents in E-commerce

In order to study the complexities of the communication of agents so that an

effective agent-based e-commerce system can be developed, it is first necessary to

understand the generic communication pattern of the human agents. By doing this,

it can be ensured that agents engage in the same communication pattern as their

human agents so that the rights of the human agents will not be infringed. There-

fore, although the DEMO transaction concept was originally conceived to under-

stand human communication within an organization,9 it can also be easily adapted

for understanding inter-agent communication involved in agent-based e-commerce

systems. Hence, the inter-agent communication is referred to as electronic transac-

tion. A generic pattern of such electronic transaction is presented in Fig. 1(a). An

electronic transaction is carried through by two agents/parties (human or software

agents), mostly on an online basis. The one who starts the transaction and even-

tually accepts the results, is called the customer or initiator. The other one, who

actually performs the objective action, is called the supplier or executor. In order to

perform the objective action, the human agent may employ the help of a software

agent. In this respect, the software agent is also considered to be an executor on

behalf of the human agent at the IT layer. This interrelation is depicted in Fig. 1(a)

as two-layered presentation — social layer and IT layer. The same rule applies to

the initiator, who may also employ the help of a software agent to initiate a re-

quest on his behalf, in which case, the software agent is considered the initiator at

the IT layer. A transaction according to DEMO consists of three phases: the order

phase or O-phase, the execution phase or E-phase, and the result phase or R-phase

[represented as three discs in Fig. 1(b)].

The order phase (O) is an interaction between the initiator and the executor that

starts with the request of the initiator and ends with the promise by the executor.

The execution phase (E) starts with the promise and ends with the statement by the

executor that the objective action, leading to the agreed upon result, is executed.

The result phase (R) starts with the statement and ends with the acceptance by the

initiator of the result. The arrows between the social and IT layers represent the

delegation of duties and authorities to the software agents. The double-headed bold

arrow shows the use of signs between the agents (human or software) to perform a

business deal.

Analyzing the DEMO transaction concept mentioned above, one can conclude

that this transaction in e-commerce will have the following interpretation. As for

O-phase, it is an interaction between human agent and software agent representing

July 10, 2002 17:13 WSPC/173-IJITDM 00031


IT layer(

software agents)�

signs Begin Read If true Do Else Wait End

.. Begin Read If true Do Else Wait End

..Inter-layer interface depicting 'obligations' and 'expectations'

�Initiator

(�customer)� � Executor

(supplier)�

Social layer�

(human agents)�

signs

(a)

request promise� state accept

O

E RDEMO

�

Transaction

(b)

Fig. 1. (a) The two layered inter-agents communication structure; (b) the DEMO transactionpattern.

the delegation of duties to the software agent, thus making the software agent an

initiator on behalf of the human agent. As for E-phase, generally speaking, it takes

place in the IT layer and is performed solely by software agent on behalf of the

initiator human agent.

3. Semiotic Analysis for Identifying Communicating Roles

This phase starts with the Semantic Analysis method.2,6,17 It is important to note

that the signs used for communication by the human agents can be broken down

into a structure, which consists of the recipient of a message, the sender of the mes-

sage, the meaning of the message and the intention of the message (see Fig. 3). As

shown in Fig. 1, the software agents generate electronic signs that carry meaning

or intentions in order to change the social world of their human agents. In order

to understand how software agents use signs to communicate meanings and inten-

tions, it is first necessary to understand how the human agents use signs in the

same situation to get the same task done. Figure 2 shows a contextual diagram of

the business domain of QuickQuote. A more detailed description of the business

operation of QuickQuote can be found at http://www.quickquote.com/.

As a result of identifying the human agents and specifying the social world

that is created by their use of signs during semantic analysis, an ontological chart

is conceived (see Fig. 4). Readers can consult Chong & Liu5 and Liu14 for more

details regarding the steps in constructing the ontological chart.

July 10, 2002 17:13 WSPC/173-IJITDM 00031


Fig. 2. Context diagram of quickquote.

Sign

Recipient Sender Meaning Intention

Fig. 3. Structure of a sign.

Looking at the case study and its ontological chart, the roles, potential actions

of software agents and the responsible human agents can be identified. It should be

noted that the above ontological chart has to be read from left to right. Entities

that are on the right are dependent on the existence of the entities on their left

to exist. Any entity whose existence is dependent on the existence of other entities

is known as the dependant, while the parent entity of the dependant is known as

the antecedent. In this model, the entities in circles are usually the companies or

human agents that are responsible for the actions of their agent. The roles of the

software agents that are required in the business domain can be identified from

the semi-circles. Nodes that represent verbs reflect the potential actions that the

software agents can perform on behalf of its human agent. It is to be noted that the

action may evolve into a business transaction that involves two parties and creates

a new fact in the object world. The action “buys” leads to the existence of the

action “pays” if the action “buys” is satisfactorily completed. Therefore, a dotted

line with an “@” sign is used to indicate that the completion of the action “buys”

activates the action “pays”.

Some features of the ontological chart are worth noting. Firstly, one of the con-

tributions of the ontological chart is that it provides an understanding of which

July 10, 2002 17:13 WSPC/173-IJITDM 00031


Society�

person�

insurancecompany�

credit card�

company�

website�

owns�

address�

lives

searches

insurance

agent�

credit�

card�

licensee

QQ

e-mail�

address�

enquires�

@

register

licenser�

commission�

subscriber

pays�

commission�

payee�

payer�

payee

subscribes

customer�

policies�

buys�

buyer

#Policy_numbe�

r#Policy_type

�

#Effective_date#Effective_time

�

@

pays�@

Fig. 4. Ontological chart of quickquote.

human agents are responsible for the actions of the software agents. This under-

standing provides the basis to specify the social obligations that are incurred on

the responsible human agents as a result of the actions of the software agents. This

is important in a business deal especially, since it is important for the company

to fulfil any obligation incurred on them by the software agents. Customers will

definitely take their business elsewhere if obligations or promises are not kept. For

example, the insurance company is obliged to sell an insurance policy at a price

which the software agents have quoted to the customer. Secondly, one has to realize

that the existence of an action must be within the existence of its antecedent. Once

its antecedent ceases to exist, the lifetime of the dependant will also come to an

end. For example, no behaviour “buys” should be performed by any other software

agents when there are no customer. This understanding can be translated into im-

plementation to ensure that only the software agents that represent the appropriate

human agents have the proper authority to perform some sensitive tasks.

The ontological chart and its relation to DEMO concept can be explained in

the following manner. All possible transactions can be identified by analyzing the

potential actions in the figure (buy, pay, search, etc.). However, the action can only

be treated as a transaction if it creates a new fact in the object world, e.g. ‘buy’,

which causes the issue of a new insurance policy. In other words, a new insurance

policy is created.

Each potential transaction has a set of underlying rights and constraints that

are associated with the successful completion of the transaction. The transaction

July 10, 2002 17:13 WSPC/173-IJITDM 00031


“buys” for example is a complex action that includes a set of underlying rights

and constraints which are referred to as behavioural norms. Although the onto-

logical chart offers an understanding of what potential transactions are available,

the detailed rights and constraints associated with the realizations of each transac-

tion are not covered. For example, one of the constraints of the transaction “buys”

may be that the software agent is allowed to make payment only if the price of

the policy is less than $100. These complex actions which is built upon the rights

and constraints can be depicted in the form of behavioural norms of the human

agents.5,17 The concept of behavioural norms is not new in information systems

development. A prominent approach that employs the use of norms for identifying

the actions of the object system is the MEASUR research program.16 In Liu et al.13

authors also give an account of how behavioural norms can help in the modelling

and development of information systems.

Behavioural norms can be captured from the human agents by studying the

regularities of their actions. These norms can later be programmed and incorporated

into software agents for two purposes:

• To govern the actions of the software agents, which will ensure that the software

agents do not violate the rights of the human agents by behaving reasonably and

correctly.

• The norms can also act as trigger for the software agents to perform automatic ac-

tions, such as replying to an enquiry. Another type of trigger is reminder messages

that prompt some actions from the human agents (i.e. their social obligation).

In general, behavioural norms have the following structure:

IF <certain conditions> obliged/permitted/forbidden>

to perform <action/speech act>

There are three fundamental aspects of behavioural norms and they are ex-

pressed in the form of “a software agent is obliged, permitted or forbidden to be-

have in certain way”. In this process, the responsible human users (identified from

the ontological chart) are consulted. A permitted action or speech act is one which

is normative and can thus be performed legally by a software agent, an obligatory

action or speech act is one which must eventually be performed by a software agent

and a forbidden action or speech act is one which is non-normative and thus cannot

be preformed by a software agent. For the sake of simplicity and clarity, only some

of the behavioural norms underlying the action “buys” and “pays” are shown in

Fig. 5.

One of the weaknesses of the representation of behavioural norms in Fig. 5

is that they are subjected to misinterpretation as they are expressed in natural

language, that is, English.

July 10, 2002 17:13 WSPC/173-IJITDM 00031


Fig. 5. Behavioural norms of the actions “buys” and “pays”.

4. Interface Requirement Analysis

Software agent is a software entity that is constructed and controlled by means of

signs. A sign in this respect stands for something to somebody in some respect.1

The interface component of software agent is one good example of a computer-based

sign. Recently, semiotics has been identified by a variety of writers as a useful way

of understanding the computer interface because of the computer’s nature as a very

special kind of communication medium.1,8,19 Other writers such as Blakenberger

& Hahn,3 Familant & Detweiler,11 Reisner15 have also contributed to semiotics in

interface design (either explicitly or implicitly).

Authors Tim & Vile19 identified three phases based on semiotics which offer an

analytical framework to any would be interface developer:

• Contextual HCI semiotics analysis.

• Web interface semiotics analysis.

• Semiotic metaphor analysis.

The Contextual HCI semiotics is concerned with how meanings are interpreted

by the human agents with respect to the social and business context in which they

July 10, 2002 17:13 WSPC/173-IJITDM 00031


�

��

��

��

��

��

��

��

��

�

Fig. 6. Three phases of interface requirements analysis.

work in. Once the analysts are clear of the meanings of the signs in the specific busi-

ness context, the analysis enters into the web interface semiotics phase. This phase

is concerned with the most effective use of the means of communication including

the use of icons and indexes to reflect the meaning of the signs in that specific busi-

ness context. At the semiotic metaphor analysis, there may be question about the

consistency and the cohesiveness between the relationship of the metaphor used

to represent the sign types and the object it represents. These three phases are

illustrated in Fig. 6. Building upon Tim & Vile’s work,19 the link is established

between the semantic model and interface design.

4.1. Contextual HCI semiotics analysis

From a semiotic perspective, an interface is a sign system that is repeatedly in-

terpreted by a group of human agents. The human agents are actively seeking to

interpret the object represented by the sign. In order to help the human agents

interpret signs successfully, the social context in which the signs obtain their mean-

ings needs to be taken into consideration. The human agents’ culture and context

will influence the way in which they interpret signs from the interface. For exam-

ple, for a computer scientist, a class stands for an object differing from an entity in

relational databases. A class can be instantiated and will inherit the attributes of

its superclass. However, to a teacher, a class is a collection of students that he or

July 10, 2002 17:13 WSPC/173-IJITDM 00031


she teaches. In QQ case study, for example, the term “insurance agent” can mean

an entity which can receive commission from the QQ, entity which can subscribes

to QQ’s services and so on. The developers should not invent their own classifica-

tion scheme of the meaning of the term without involving the human agents and

understanding the business context under which the human agents work in.

The semantic model in Fig. 4 can complement this by offering a framework in

which the semiotic properties of a term and the situational context can be identified

and compared. From a computing perspective, the semantic model is useful because

it provides a framework that reconciles the perspective of the system held by both

the designer and the user. The human agent uses signs including verbal or day

to day speech. This includes the terms that are already identified in the semantic

model, such as policies, subscribes. These terms are interpreted by the human agents

within their specific business context in order to perform their tasks. However, these

meanings are sometimes difficult to capture on documents, as many of them are

tacit, learned, used and passed on at an unconscious level of thought. The concept

of norms can help establish the correct meaning of each term in a given business

context. Underlying each term, a set of perceptual or evaluative norms can be

identified, which when elicited from the human agent, reveal the meaning of that

term in that business context. Perceptual and evaluative norms have a structure

different to that of behaviour norms. In general, they have the following structure:

IF <certain conditions apply > THEN <agent>

Adopts <an attitude> Towards < some consequences or proposition>

The relationship between the term “products” and its underlying norm is illus-

trated in Fig. 7.

The elicitation of the perceptual or evaluative norms provides a mechanism

in which the meaning of the specialized terminology used by the human agent

can be captured. These could include jargons for day-to-day communication. For

instance, in order to build an effective interface, the analysts must ensure that the

QQ�

subscribes�

insuranceagentPerceptual norm: e.g. IFinsurance agentsubscribes to QQ,�

THEN �

insurance agentwill � recognise that there

�

will be a US$100subscription fees�

Fig. 7. Meanings of terms that can be identified from perceptual norms.

July 10, 2002 17:13 WSPC/173-IJITDM 00031


sign “products” must be interpreted, as perceived by human agent (customers), as

comprising a product description and price per quantity.

4.2. Web interface semiotic analysis

In order to achieve their business purposes, agent-based e-commerce systems must

be understandable to the human agents. In this phase, the analysts are primarily

concerned with how to represent the meaning of a term on a computer in the most

effective way. In order to understand the representation of term using signs, interest

is in the means of communication and all types of signs and signification including

languages, symbols, icons, pictures etc. According to Tim & Vile,19 any semiotic

element (sign, text or picture) at least has two planes, an expression in the so-called

“semiosic” plane and a content in the “mimetic” plane.

At the semiosic plane, interest is in the different sign types used for represent-

ing the meanings of the terms. A simple example is use to illustrate this point:

the messaging service of our mobile phones usually identifies who the senders

of the messages are. The senders are represented as the mobile phone numbers or

the WWW addresses that were used to send the message. Although mobile phone

numbers are unique, they do not provide sufficient information to identify who the

senders really are, considering the wide circle of friends and relatives that constitute

our social life. The messaging service may instead provide a mechanism in which

the names instead of the mobile phone numbers of the sender are sent to the recip-

ient. The names may not be unique, but they do provide sufficient information to

know who the senders really are. In other words, the sign chosen by the messaging

service to represent the senders (i.e. by mobile phone numbers) fail because they

do not relate to our daily sign system. Therefore, it is important to consider this

issue when choosing the appropriate signs (texts or pictures) for representing the

meanings that were identified in the previous phase.

Signs at the semiosic plane can be classified into three main categories: Icon,

Symbol and Index. Familant & Detweiler11 attempt to give a precise definition of

icons and the relation between an icon and the thing it represents. They first distin-

guish icons from other signs such as indexes (signs left by other signs), and symbols

whose expression only conforms to the signified object accidentally. Firstly, an icon

usually displays some characteristics of the signified. For example, the “Inbox” icon

shown in Fig. 8(a) displays an explicit relationship between the signifier and the

signified, i.e. an inbox that contains some incoming mail.

A symbol on the other hand, means the signifier and the signified have an arbi-

trary logical entailment and connection. The connection is fixed wholly by cultural

and social convention. For example, if it is to set up a modem, it will click on

the “control panel” symbol as shown in Fig. 8(b). However, there are no forces

that guarantee the relationship between the signifier and the signified. Under the

“control panel” symbol, there are other signs involved apart from modem, such as

accessibility options and keyboard. It just happened that the relationship between

July 10, 2002 17:13 WSPC/173-IJITDM 00031


� �

� � � � � �

�

� � �

� �

Fig. 8. Example of an icon (a), symbol (b) and an index (c).

“control panel” and “modem” is linked by chance without being planned and is

guaranteed only by a conventional rule. In other words, the “control panel” symbol

can stand for something else apart from modem. Conventional rules are socially

constructed, which means that every conventional rule is clearly understood by the

human agents involved. Another good example will be the name “John” which ap-

pears on your incoming e-mail. John is not unique and can stand for anyone else.

It could be your colleagues, ex-classmates etc. But John happens to refer to your

best friend who had replied to your queries from your e-mail two days ago.

In an index, the signifier and the signified are bounded in a cause-effect rela-

tionship. A thermometer for example is an example of an index. The sign on the

thermometer represents the effect of the temperature of the room. Indexes exist due

to the results of some effects, such as the effect of leaving a footprint on the beach,

which bears the sign that someone was there. In the World Wide Web, indexes are

commonly used to refer to other sites, through the effects of being guided where to

navigate in the global network, as shown in Fig. 8(c). Indexes, like icons, lead the

human agent to some specific object that they represent, but they differ in that the

navigational paths of indexes are clearly defined.

At this phase, the analysts may find it useful by asking themselves the following

questions:

• Are the conventional rules well understood? For example, it is not a good idea

to have a “car” sign to stand for engine parts such as valves, carburettor, and

alternator if the human agents are not experts in cars.

• Are there multiple relationships or any potential concepts that may be popu-

lated with the current concept? For example, when representing cars, there may

potentially be other signs to represent, such as steering wheel, safety belts etc.

• Is navigation to other points or specific sites an essential part of the interface?

In general, icons and indexes should be used liberally, but the excessive use of sym-

bols is discouraged. Icons should be used when an illustration of ideas is necessary,

use indexes (e.g. hyperlink) to point to a specific page or point, and symbols only

July 10, 2002 17:13 WSPC/173-IJITDM 00031


Table 1. Rules for choosing sign types.

Concept in Semantic Model Sign Type

Potential Behavior Index

Determiners Icon

Terms with Conventional Rule Symbol

when the conventional rules are socially understood, since symbols are vague in

nature.19

The choice of using different sign types depends on the users’ cultural and

social context, and one way of understanding this is by examining the semantic

model. This process can play a substantive role in furnishing the analysts with a

more detailed understanding of which categories of signs should be used to repre-

sent the meaning. As a rule of thumb (see Table 1), a potential behaviour (shown

as nodes in the semantic model) of the software agent can be represented as an

index (especially when a behaviour activates another set of behaviour), for example

as “buys” activates “pays”. The behaviour “buys” for example, can be an index

that will lead the customer/buyer to some site where the behaviour “pays” can

be performed (i.e. sending their credit card details). Icons on the other hand, can

be liberally used to represent determiners, since they usually bear an explicit and

straightforward relationship to the object they represent, such as “Policy type”.

Though symbol should be used sparingly, the semantic model reveals some terms

that have a clearly understood conventional rule. The term “policies” for example,

may stand for strategies, guidelines, documents, certificates and so on. However in

the specific context of QQ, policies is linked to some shared meaning through some

conventional rule. A symbol that can effectively represent this conventional rule can

be used.

At the mimetic plane, interest is in the meaning of the content of the web page

and the messages they communicate to the interpreter. Particularly, there is concern

about the types of message that are transmitted from the web page to the human

agent. For example, what kind of images of the organization are being portrayed

to the customers as a result of using signs or texts on the web interface? Is it able

to create a sense of trust and establish a good relationship with the customers

through the interfaces? Unless customers trust the site and have confidence in the

organization, they will definitely take their business elsewhere.19 It may be useful

for the analysts to ask themselves the following questions at this stage:

• Is the interface engendering trust and portraying a good image of the company?

• Are the texts or signs that are used clear?

• Do the texts contain any jargons?

• Are the signs or texts structured in a way that accounts for sight and hearing

impaired users?

• Is the placement of the company logos too large?

July 10, 2002 17:13 WSPC/173-IJITDM 00031


• Is the interface giving a message of authoritarianism? That is, does the use of icons

excludes certain groups, for example, by being religiously or culturally biased?

• Is the interface up-to-date?

• Are the navigation methods consistent?

• Is there any escape route provided? For example, are there any quit buttons?

4.3. Semiotic metaphor analysis

The designers should have by now identified the contextual issues that govern the

use of signs. The most effective way of representing the signs (i.e. using icon, symbol

or index) would have already been analyzed and studied. In this phase, the analysts

are interested in choosing a right metaphor for representing the sign, whether the

sign is to be shown as icon, symbol or index. This is an important activity, because

it forces the designers to question the validity and consistency of the interface

metaphors. For example, it is not a good idea to use a “piggy bank” metaphor to

represent the concept of the “save” action of your word processor. A “diskette”

metaphor may be a more appropriate one. Semiotic metaphor analysis consists of

four phases as shown in Fig. 9. Here, only a brief discussion is given on this phase.

A more detailed discussion is left for a future paper.

4.3.1. Candidate object generation

In this phase, the potential objects to be represented are singled out, e.g. a list

of verb, nouns, prepositions, etc. is produced. It is important to note that it is

impossible to list every single object in the semantic model and represent them

as icons. A more feasible way is to list the objects classified by categories and

represent them as symbols using metaphors. Potential objects are identified from

the semantic model.

4.3.2. Candidate metaphors generation

This phase is concerned with detailing the appropriate metaphor to represent the

object. A list of candidate metaphors that are chosen to represent the candidate

objects is generated in this phase.

Candidate metaphorgeneration�

Metaphor match/mismatch analysis

Develop mismatchstrategies�

Candidate objectgeneration�

Fig. 9. Four phases of semiotic metaphor analysis.

July 10, 2002 17:13 WSPC/173-IJITDM 00031


4.3.3. Metaphor match/mismatch analysis

This is an important phase in the analysis. Its main purpose is to identify some

of the mismatches that are likely to occur. Typically when this occurs, the human

will have difficulties understanding what the object represented by the metaphors

if the mismatches are not dealt with in the interface. It is in this phase that the

analyst, who already possesses an understanding of the sign and the signified, forms

an understanding of the relationship between them. This understanding is in the

mind of the analyst and is referred to as the interpretant in the semiosis process.

An important step to aid the understanding between the object and the metaphors

is to identify the match or mismatch between them.

4.3.4. Develop mismatch strategies

The final phase addresses the problems with metaphor mismatches and the course of

actions to be taken in order to help the human agents to deal with the mismatches.

Developing the right strategies help the human agents to understand what is and

what is not depicted in the metaphors. Carroll et al4 went to the extent of making

the claim that metaphor mismatches, if designed properly, can actually help the

human agents to gain a greater understanding of the object. Such strategies can

typically be handled by providing an index that links the metaphors to some addi-

tional notes about their actual characteristics that are not shown in the metaphors.

5. Interaction Model of QuickQuote

DEMO methodology comprises five types of models that together allow complete

understanding of organization and business processes within an organization.

The first model that is constructed in the DEMO analysis of an organization is

the Interaction Model. The Interaction Model is a “timeless” representation of the

transactional structure of an organization, that is, the Interaction Model does not

show the order in which the business transactions in an organization take place.

The focus of the Interaction Model is on the specification of (1) the types of

business transactions that take place between the organization under investigation

and its environment as well as in the organization, and (2) the initiating and exe-

cuting actors of these identified transaction types. This specification of the transac-

tional structure is, of course, performed parallel to the determination of the system

boundary.

5.1. The interaction diagram

The interaction diagram is the graphical representation that is used for representing

the DEMO Interaction Model. It provides symbols for all the aspects of the system

that are identified in the model. This means that transaction types, initiating and

executing actors as well as the system boundary are included in the model.

July 10, 2002 17:13 WSPC/173-IJITDM 00031


Looking at the description of the QuickQuote case study, introduced in Sec. 3,

one can easily identify all essential transactions that take place when performing

the mission of the organization. However, a plain description is still not enough to

identify the transaction exactly and easily. Therefore the use of semantic analysis

helps analysts to do this better. In this sense, the most helpful part of the semantic

analysis is the ontological chart (see Fig. 4).

Ontological chart helps to identify all roles, agents (actors) and actions. Usually

actions in the ontological chart are represented by verbs (e.g. buy, pay). These verbs

are the key to the identification of potential transactions. Once these transactions

are identified, the related initiators and executors can be identified in a straightfor-

ward way. For example, the verb “buy” in Fig. 4 indicates an action that creates a

new fact (a new policy is issued). Now looking at the chart, it is obvious that the

initiator of this transaction is an external actor “customer” and the executor is an

internal actor “insurance company”.

From this description and Fig. 4, it is understood that a customer, in or-

der to buy a policy, begins his search with the QQ that offers an appropriate

policy/company (this is first transaction in the process T1). After finding an ap-

propriate company matching customer’s requirements and wishes, the customer

applies to buy a policy (T2). In order for the insurance company to issue a new

policy, the customer has to pay for it (T3). Otherwise said, for completion of T2

one needs result of T3 and therefore T3 has to be completed during execution of

T2. Once a policy is paid and issued, according to arrangements between the insur-

ance company and the QQ, the insurance company has to pay commissions for each

issued policy arranged through the QQ (T4). Actually, this is the last transaction

in the process. All identified business transactions are represented in Table 2. This

table also contains information about the software agents involved.

The next step in DEMO methodology is to identify the relevant actors and to

determine their roles as initiator and executor of the transaction types. Once this

is done, all interaction relationships are determined. These are drawn as exhibited

in Fig. 10. Transaction types are represented by a symbol consisting of a disk

with a diamond behind it. The disk represents the “intersubject world part” of the

transaction, the diamond represents the “object world part”. Therefore, the disk

can also be considered as a bank that contains the intersubject world states, and

a diamond can be considered as a bank that contains the object world facts that

Table 2. Transaction types.

Transaction Type Software Agents(see Fig. 12) Result Fact Type (see Fig. 4)

T1 policy offering F1 policy P is offered buyer

T2 policy buying F2 policy P is bought buyer

T3 policy payment F3 policy P is paid buyer

T4 commission payment F4 the commission payer, payeefor policy P is paid

July 10, 2002 17:13 WSPC/173-IJITDM 00031


are created as the result of successfully completed transactions. Boxes represent

actors. A white box represents an elementary actor, i.e. an actor that is executor

of precisely one transaction type, and a grey box represents a composite actor, also

called system kernel. A transaction type is connected to its initiator by a plain line

and to its executor by a line with an “open” arrow point. The system boundary

is represented by a grey round angle. The diagram exhibits e.g. that actor A1 is

the executor of transaction type T1 and that (an elementary actor in) the system

kernel S1 is its initiator.

6. Process Model of QuickQuote

The diagram of Fig. 10 does not show how the identified transaction types are put

together to form the business process(es). To this end, another kind of diagram is

T1� A1�T1� A1�T1� A1�T1� A1�T1� A1�T1� A1�T1� A1�

S1�

T1�

Customer

A1 QQ�

T4�T4�T4�T4�T4�T4�T4�T4

T3�T3�T3�T3�T3�T3�T3�T3

T5�T5�T5�T5�T5�T5�T5�T2� A2 Insurance Company�

Fig. 10. Interaction model of the QQ case.

T2/O T2/E T2/R

T3

T1�

T4

Fig. 11. Process model of the QQ case.

July 10, 2002 17:13 WSPC/173-IJITDM 00031


developed, as shown in Fig. 11. It contains only the “intersubject world part” of

the transaction types, which are mostly split up into three phases O, E and R,

interconnected by plain lines. Small disks represent the initiation points of transac-

tions. They are connected by plain lines with arrowhead to the initiated transaction

types. These arrows thus represent the causal links between transaction types. For

example, Fig. 11 exhibits the structure of the business process, which consists of

transaction types T1, T2, T3 and T4. T1, T2 and T3 are initiated externally (rep-

resented by the single small disk). T3 is initiated during the execution phase of T2.

To represent this, the disk of phase E of T2 is stretched out in order to contain

the initiation disk for T3. The dotted lines with arrowheads represent conditional

links. For example, the dotted arrow from T3 to T2/E indicates that T3 has to be

completed before T2/E can be completed. This reflects the fact that one receives

insurance policy after having paid the policy fee.

7. Comparison with Other Methods

Existing methods have difficulties capturing the profound social relationship and

context between the software agents and the human agents. This paper there-

fore took a fundamental different approach in supporting the analysts to design

ABEC systems than that from existing methods. This section evaluates the pro-

posed method from the perspective of the functions that are not offered by existing

methods.

The Agent-Oriented-Relationship (AOR) method18 provides minimal support

to the analysis of the proposed system at the conceptual level. No useful techniques

or guidelines are given. It begins by modelling the proposed system as a collection

of entities, objects, events, actions etc. It is arguable that as a result, one has to

be preoccupied with substantial implementation details at a very early stage. For

instance, the analyst has to specify the one-to-one or one-to-many relationship be-

tween the entities. The DEON method supports the analysis right from the problem

statement and gradually working out the necessary requirements for the system.

The Gaia method20 is divided into an analysis and a design stage. The method,

however, do not facilitate the social obligations of the human agents to be expressed.

Substantial extension is required to incorporate this function in order to provide a

more realistic view of the business domain, where the human agents play a central

and essential role.

The AMT method20 captures the architectural aspects of the entire agent-based

system (external level) and the specific software agent design (internal level). It

makes one important assumption, that is, the types and roles of software agents

are known beforehand. Unlike the proposed method in this paper, it is not clear on

which basis these software agents are derived.

The MaSE method12 has one similarity with the our method, namely, it has a

design phase that aims to capture the basic types of software agents. However, the

design phase is contentious, since no guidelines are given to support the aim of the

July 10, 2002 17:13 WSPC/173-IJITDM 00031


identification of the types of software agents. In contrast, our method handles this

by offering a systematic and progressive way of analyzing and identifying the types

of software agents.

Like the DEON method, the AOM method7 provides a technique to iden-

tify the potential software agents and their behaviour patterns. Also, it places no

implementation assumptions or constraints on the analysts. Nevertheless, for the

AOM to be widely accepted for designing ABEC systems, major overhaul is needed

in order to incorporate the functionality of capturing the social obligations of the

human agents.

8. Conclusion

The semiotic method introduced in the paper is developed based on a sound theoret-

ical underpinnings and is an established method that have been applied successfully

in many real life case studies and applications. It provides a set of formal and pre-

scribed steps in carrying out an investigation of the business problems at hand,

which include identifying the responsible human agents, software agents and their

potential actions, and the behavioral norms which brings about the realization of

the potential actions. These features make it a valuable asset in understanding the

design requirements of the agent-based e-commerce system.

The DEMO provides a sound and well-tested modelling technique for under-

standing and describing business systems for the purpose of optimizing business

processes and designing information systems. It will prove to be a very useful tool

to understand e-commerce systems within its powerful framework.

Using the DEMO transaction concept allows analysts and designers of

e-commerce system to better understand the nature of communication in

e-commerce system. DEMO transaction concept distinguishes between intersub-

ject and object world. As a result, it helps to model two-layered communication in

e-commerce systems. These two layers are referred to as the social and IT layers.

References

1. P. B. Andersen, A Theory of Computer Semiotics (Cambridge University Press, USA,1997).

2. J. Barjis and J. Filipe, Simulation of organizational processes combining semanticanalysis and Petri nets, Proc. SCSC’2000, Vancouver, B.C. Canada, July 16–20, 2000.

3. S. Blakenberger and K. Hahn, Effects of icon design on human-computer interaction,Int. J. Man Mach. Stud. 35 (1991) 363–377.

4. J. M. Caroll, R. L. Mack and W. A. Kellogg, Interface metaphors and the users in-terface design, Handbook of Human-Computer Interaction, ed. M. Helander (Elsevier,Amsterdam, 1988) 67–85.

5. S. Chong and K. Liu, A semiotic approach to the design of agent-mediated e-commercesystems, Proc. IFIP WG 8.1 Int. Working Conf. ISCO-4, 1999.

6. S. Chong and K. Liu A semiotic approach for modelling and designing agent-basedinformation systems based on roles and norms, Proc. Int. Bi-Conf. Workshop Agt.-Oriented Inf. Syst. (AOIS′00), Stockholm (Sweden), Texas (USA), 2000.

July 10, 2002 17:13 WSPC/173-IJITDM 00031


7. S. A. DeLoach, Multiagent systems engineering: A methodology and language fordesigning agent systems, Proc. Int. Workshop on Agt.-Oriented Inf. Syst. (AOIS’99),Heidelberg, Germany, 14–15 June, 1999.

8. C. S. De Souza, The semiotic engineering of user interface languages, Int. J. ManMach. Stud. 39 (1993) 753–773.

9. J. L. G. Dietz, Understanding business processes on the basis of Habermas’ theory ofcommunicative action, Proc. AMCIS Conf., Milwaukee, USA, August 1999.

10. M. Elammari and W. Lalonde, An agent-oriented methodology: High-level and inter-mediate models, Proc. Int. Workshop Agt. Oriented Inf. Syst. (AOIS’99), Heidelberg,Germany, 14–15 June, 1999.

11. M. E. Familant and M. C. Detweiler, Iconic reference: Evolving perspective and anorganising framework, Int. J. Man Mach. Stud. 39 (1993) 705–728.

12. D. Kinny, M. Georgeff and A. Rao, A methodology and modelling technique forsystems of BDI agents, Agents Breaking Away: Proc. Seventh European Workshopon Modelling Autonomous Agents in a Multi-Agent World (MAAMAW’96), LectureNotes on Artificial Intelligence 1038, eds. W. van der Velde and J. Perram (Springer-Verlag, Heidelberg, Germany, 1996).

13. K. Liu, L. Sun, A. Dix and M. Narasipuram, Norm based agency for designing col-laborative information systems, Inf. Syst. J. 11 (2001) 229–247.

14. K. Liu, Semiotics in Information Systems Development (Cambridge University Press,UK, 2000).

15. P. Reisner, APT: A description of user interface inconsistency, Int. J. Man Mach.Stud. 39 (2000) 215–236.

16. R. Stamper, Social norms in requirements analysis- and out of MEASUR, Require-ments Engineering: Technical and Social Aspects, eds. M. Jirotka and J. Goguen(Academic Press, 1994).

17. R. Stamper, K. Liu, M. Hafkamp and Y. Ades, Understanding the roles of signs andnorms in organizations — A semiotic approach to information design, J. BehaviorInf. Tech., 2000.

18. K. Taveter and G. Wagner, Combining AOR diagrams and Ross business rules’diagram for enterprise modelling, Proc. Int. Bi-Conf. Workshop Agt. Oriented Inf.Syst. (AOIS’00), Stockholm (Sweden), Texas (USA), 2000.

19. F. Tim and A. Vile, Semiotics for e-commerce: Shared meanings and generativefutures, Proc. BIT’99 Conf., Manchester Metropolitan University, UK, 3–4 November,1999.

20. M. Wooldridge, N. R. Jennings and D. Kinny, The Gaia methodology for agent-oriented analysis and design, J. Autonomous Agts. Multi-Agt. Syst. 3, 3 (2000)285–312.

AMS Radiocarbon Dating of Bone Samples from the Xinzhai Site in China

Documents

Transcript of AMS Radiocarbon Dating of Bone Samples from the Xinzhai Site in China