Ontology Based Personalized Service in E-markeplaces:
A Case Study in a Used Car Matching System
C.K. Lee1 and Dickson K.W. Chiu2, Senior Member, IEEE
1
Department of Computer Science and Engineering, The Hong Kong University of Science and Technology
2
Dickson Computer Systems, 7 Victory Avenue, Homantin, Hong Kong
email: [email protected], [email protected]
Abstract
In order to provide effective personalized recommendations, the understanding of products as well as the users’ preferences is crucial and this requires domainspecific knowledge. Recently, ontologies have been developed in various business domains with the recent maturing
of the Semantic Web technologies, which can be applied
for this purpose. In this paper, we present our enhanced
meta-model to address this problem. To demonstrate the
applicability and effectiveness, this paper present an application of the Semantic Web based technologies to a
Used Car Matching System (UCMS) in an e-marketplace
as a case study. We present the ontology for modeling
used cars with RDF (Resource Description Framework)
and RDF Schema, together with some sample coding and
information model to demonstrate the implementation.
1. Introduction
Recently, Semantic Web technologies [7][9] have been
maturing to make e-commerce interactions more flexible
and automated. The Semantic Web provides explicit
meaning to the information available on the Web for automated processing and information integration based on
the underlying ontology. Ontology defines the terms used
to present a domain of knowledge that is shared by people,
databases, and applications. In particular, ontology encodes knowledge possibly spanning different domains as
well as describes the relationships among them. Ontologies have also been developed in various business domains.
The trading of second-hand product is becoming more
and more popular over the web. However, searching are
often ineffective because matchmaking functions are still
preliminary and services supporting domain-specific
product knowledge are rare. This motivates our study on
the use of semantic web for such applications.
Based on the discoveries our earlier work [3] on using
ontology for the elicitation of negotiation requirements
and the formulation of efficient negotiation processes, we
adapt them to become the fundamental effective support
for the elicitation of trade requirements in e-marketplaces.
Ontology provides the key knowledge about the interrelationships among the issues and alternatives of the traders’ requirement so that object-oriented analysis of them
can be streamlined and possibly automated in an emarketplace.
In this paper, we illustrate the applicability of our
model semantic web based technology for the trading of
second-hand cars. The rest of this paper is organized as
follows. Section 2 discusses background and related work.
Section 3 presents a concept model of an e-marketplace
based on ontology. Section 4 introduces an overview of
the system. Section 5 presents some details of the application of Semantic Web technologies of the implementation.
Section 6 summarizes the paper with the advantage of our
approach and our future work direction.
2. Background and Related Work
Analysis by Forrester [10] estimates that 18% of global
exports will flow online by 2004 and that cross-border eMarketplace trade will surpass $400 billion. Despite technical challenges, e-Marketplaces have emerged to be important trading platforms in recent years. The popularity of
e-Marketplaces is largely attributed to their improvement
in economic efficiency, reduction in margins between
price and costs, and speeding up complicated business
deals. However, there are also drawbacks when online eMarketplace are implemented and used for business transaction. Obstacles such as boardroom conflicts, integration
hurdles, and unprofitable business models still have to be
overcome [10]. Due to its immaturity, e-Marketplaces are
often industry-specific with competitors joining forces to
aggregate their purchasing power operating both horizontally and vertically [14]. Because of cost, organizations in
all sizes are expected to purchase a significant amount in
order to gain benefit by adopting e-Marketplaces in their
procurement process. Organizations dedicated to it still
have to modify its business process in a number of areas
including changing internal procurement processes, integrating e-Marketplaces within internal systems, purchasing B2B applications, and paying e-Marketplace transaction fees.
On the other hand, although Semantic Web technologies are maturing, ontology standards are still forming [9].
Challenges remain for reusing available ontological information and researchers focus on information integration. In the past years, there are different standardized languages proposed. For example, the DARPA Agent
Markup Language (DAML) [6] is an ontology language
based upon the Resources Description Framework (RDF)
[17]. DAML-S was designed to serve as the basis for representing descriptions of inverses, unambiguous properties, unique properties, lists, restrictions, cardinalities,
pairwise disjoint lists, and data types. The Web Ontology
Language (OWL) [21] is an eXtended Markup Language
(XML) proposed by the World Wide Web Consortium
(W3C) for defining Web ontologies. OWL ontology includes descriptions of classes, properties, and their instances, as well as formal semantics for deriving logical
consequences in entailments. Edgington et al. [8] point out
that adopting ontology can facilitate knowledge sharing.
He et al. [12] have surveyed a large number of researches
on agent-mediated e-commerce and point out that semantic interaction and personalization are the main problem.
However, at the time of writing and as far as we know, no
other publications in major journals detail the applications
of ontology in e-marketplaces.
Cho [5] studies various requirements of negotiation
support in e-Marketplace and evaluates some popular eMarketplaces. Despite rapid automation of the other phases of e-commerce transactions, negotiations are often done
by using emails or traditional manual communication
technologies such as phones or face-to-face meeting, causing serious overhead costs. The work further provides a
framework for designing and evaluating a multidimensional auction model. However, these studies do not
cover different modes of negotiation comprehensively in
one complete framework nor negotiation based on econtracts. Yen et al. [19] propose an intelligent clearinghouse approach that supports both data and textual information about dynamic markets during negotiation, and
develops an agent-based prototype Virtual Property Agency. Negotiation support is mostly limited to simple bidding functions. There is a lack of general support for bargaining like the proposed mechanism in this paper.
Schoop and Quix [18] present the negotiation process as
the exchange of contracts between the parties in an eMarketplace. The contract contents are presented as extensible semi-structured documents. During the negotiation
process, the contract evolves over time until a final agreement has been reached or the negotiation is terminated. All
these works do not consider traders’ requirements elicitation or other fundamental mechanisms relating to the effectiveness of negotiation.
Yu and Mylopoulus [20] consider the dependencies of
business goals but not down to the practical details of
traders’ requirements elicitation. Phelps et al. [16] suggest
the use of ontology for agent-based negotiation with a
focus on the heuristics of bidding strategies of auctions
instead of negotiation plan for bargaining support. Lee
[13] points out the use of semantic value and ontology
servers with the help of context agents to avoid inconsistency in the exchange of offers during e-negotiation, but
not further for requirements elicitation. Ontology negotiation enables users to cooperate in performing an activity
based on different ontologies [2]. Modeled on the patterns
of successful human communication, ontology negotiation
consists of a series of interpretations and clarifications
intended to locate common vocabulary and assumptions
[1]. However, these studies concerned with how consensus
of ontologies can be arrived at. They do not consider further how an agreed ontology can help the requirements
elicitation as well as the formulation of matchmaking,
recommendation, and negotiation processes in general, as
our novel attempt in this paper.
3. E-marketplace Conceptual Model and our
Methodology
In this section, we extend the conceptual model of
Chiu et al. [3] for an e-marketplace and an overall process
model as a methodology to support all the main business
processes (instead of just negotiation), starting from traders’ requirement elicitation, to matchmaking, recommendation, and negotiation using ontology.
2..n
Negotiation
Trader
Ontology
n
Matchmaking
Auxiliary Concept
Base Concept
Recommendation
1..n
1..n
1..n
1..n
Task
1
1
1
evaluates
1..n
Offer
Accepted Offer
n
resolves
drives
1..n
Issue
1
maps to
formulates
1
Decision Plan
1
precedes
Concept n
n
1..n
n
1..n
n
indivisibly relates to
1..n
1..n
Alternative Value
Accepted Alternative Value
Figure 1. Conceptual Model of an ontology-based e-Marketplace
in UML Class Diagram
Figure 1 presents a conceptual model for an emarketplace in the Unified Modeling Language
(UML)[15] class diagram based on ontology. Traders are
involved in the three main business processes of an emarketplace, namely, matchmaking, recommendation, and
negotiation. Each process is made of up tasks, each of
which aims at resolving a requirement issue or a collection
of co-related issues. The elicitation and evaluation of these
issues is facilitated by mapping each of them to a set of
concepts and their relationships based on an agreed ontology. If an issue is mapped into exactly one concept in an
ontology, we call this concept a base concept. However, if
an issue can break down into several concepts according
to an ontology, we call these concepts auxiliary concepts.
In this way, the agreed ontology help the traders to elicit
their requirements before evaluating and making their decisions, that is, identify the inter-relationships among the
issues and concepts, as well as possible alternatives for the
issues (as explained in Section 4).
A decision plan can thus be formulated based on the
relationships across these concepts. The plan presents a
strategy to drive and organize various tasks in the emarketplace. The e-marketplace’s intelligent software
considers multiple offers and bids in a matchmaking task
or a recommendation task until results are found in is. On
the other hand, a task for e-Negotiation represents some
work that needs to be executed by a set of parties that can
be a negotiator, or even a program such as Negotiation
Support Systems (NSS) to resolve some specific issues.
Trader select agreed
relevant ontologies
for each
collection of
co-related
issue
[not consistent]
[consistent]
System maps issues
into ontology concepts
System derive
concept relations
System check consistency
of issues & concepts
Trader identify
issues
System identifies
alternatives
System formulate
decision plan
[need to identify
new issues]
Requirements
elicitation
phase
Requirements
elicitation
phase
[need to revise
tradeoff model]
[need to identify
new issues]
System creation of
agreement
[all issues are
resolved]
System supported
trader negotiation
[negotiation
[quit
target chosen]
negotiation] [accept offer]
Trader post (revised)
Trader product
preferences as offer
selection
[reject all matches/
recommendations]
System performs
recommendation
[match not found]
System performs
matchmaking
Trader specifies alternative
values of issues
Decision
phase
[match found]
[trader change requirements]
Decision
phase
Figure 2. Ontology Based e-Marketplace Process Model in
UML Activity Diagram
Figure 2 depicts (in the notation of UML activity diagram) the overall process model for an e-marketplace as
well as our proposed methodology for the elicitation of
traders’ requirements based on ontology. The overall emarketplace business process is driven by our conceptual
as described in the previous sub-section. Traders have to
participate in each constituting activity of the process,
which consists of two major phases: requirements elicitation phase and decision phase. The requirements elicitation phase is based on the most common and logical way
of analyzing the issues with ontology (as detailed in Section 4). We do not preclude other possible sequences for a
feasible decision plan formulation. In particular, decision
plans once elicited can be stored in a repository for reuse
and adaptation. That means, traders may just pick a decision plan from the repository and starts right away. Therefore, our approach is suitable for e-marketplaces of more
complicated B2B e-commerce, where semi-structured
decision making are often repeated and efficiency is also
important.
The decision phase is also heavily supported by the emarketplace, which first suggests matching offers, and
then if not found, recommend those near misses for selection or potential negotiation. Note that only through mutual concessions can the negotiation process reach an
agreement. This process eventually leads either to a successful creation of an agreement or the trader may insist in
posting the requirements as a new offer in the emarketplace for other traders, without accepting any existing ones. The following steps further elaborate on our
methodology. In Phase 1, the Requirement Elicitation
Phase, a trader has to determine the issues of requirements.
1. At the same time, the trader selects a commonly
agreed ontology from the e-marketplace’s ontology
to help the elicitation of requirements.
2. The requirements are related to the concepts in the
selected ontology.
3. The system checks all the dependencies of concepts
that constitute the requirements from the (refined)
ontology map. Mutually dependent clusters of concepts determine the indivisible groups of requirements that have to be considered together so that effective tradeoff can be evaluated.
4. The system checks the consistency of all the concepts, issues, and their dependencies [4].
5. For a consistent plan, the system can proceed to elicit
the possible alternatives; otherwise we have to reiterate from step 3.
6. According to the dependencies, the system can formulate a precedence graph of the requirements and
requirements groups. Based on the precedence graph,
an efficient decision plan can be determined.
In Phase 2, the Decision Phase, not only does the effective decision plan help systematic stepwise evaluation
in match-making (instead of considering an exponential
number of alternative combinations) and recommendation,
the progress of a negotiation can also be visualized and
exploited with the maximum possible concurrency.
7. The system searches for the matching offers based on
the trader’s preference and attempt to rank them for
the trader to choose. The trader may then either (i)
accept any matched offers or (ii) chance his reservation price and attempt a negotiation with those offers
in order to seek for a more favorable one.
8. If no matching offers are found, the system identifies
near misses and also attempts to rank them for the
trader to choose. The trader may (i) change his mind
to accept a near miss, or (ii) choose a near miss for
negotiation.
9. During negotiation, the system supports the user to
make and evaluate offers / counter-offers based on
the decision plan (from step 6) in a negotiation session as follows [3].
o Each negotiation cycle starts with the identification
of a set of interrelated requirement issues to be next
negotiated, according a negotiation plan based on
that from step 6.
o Each party will then prepare the reservation alternatives (reservation price) of these issues. After
8
4
5
9
Sell Agent (SA)
10
3
The system comprises two main applications. One is
for users who wanted to buy a car, the Buy Agent (BA).
The other one is for users who wanted to sell a car, the
Sell Agent (SA). The application requires a user to identify oneself upon the first time usage. The ID is stored in an
RDF file, with attributes like, name, phone number, address, email, and identity card number.
When a user submits a query to the BA, the application
would return a list of cars for sale, and the list could be
sorted and browsed sorted by year, price, location, and
availability, etc. Such information has been returned from
a web spider continuously searching the web for RDF files.
The SA would ask the user for more information about the
car to be sold and the information is store in another car
RDF file made available to the web. This car RDF file
contains the seller’s id and the details of the car such as
type, manufacturer, model, picture, price, and description.
To further support the understanding of car models, we
use RDF pointers to RDF files containing information
about the specific manufacturer and models, such as dealers, resellers, parts, prices, and so on. All the knowledge
recorded therefore helps effective matching the personalized recommendations.
Buy Agent (BA)
6
4. System Overview
4.1. UCMS System workflow
7
that, they may either make an offer to or wait for
some offers from counterparties.
o If a party is not satisfied with the (counter-) offer,
another counter-offer or a failure message will be
received.
o A negotiation cycle finishes successfully if an acceptance notification of previous (counter-) offer is
received.
o Finally, the negotiation process succeeds when all
issues have been successfully negotiated. An
agreement is successfully created when all issues
have been resolved.
o However, as the traders may relax their requirements during the negotiation process, some other
offers in the e-marketplace may satisfy one or both
of them and therefore cause them to quit the negotiation process. This is an extension to the approach
of Chiu et al. [3].
10. In step 7 to 9, the trader can always quit the process,
insist on a different requirement, post it to the emarketplace, and wait for some other traders’ responses instead.
Should new requirement issues arise in the decision
phase (say, due to incomplete specification), the trader can
repeat from step 2 to analyze the new issue and its relationships to the existing ones. In real-life, the formulation
of a decision plan may involve several iterations. This
reflects the traders may not be able to understand all the
inter-relationships among the issues in one shot.
Resource Detection
Agent, (RDA)
Purchase & Sell
order Directory
2
Resource
RDF + XML
1
Figure 3. UCMS workflow
Figure 3 further depicts the UCMS system workflow.
The Resource Detection Agent (RDA) is the programming
entity that looks up all the resources and through the Sell
Agent (SA) to build up the car to be sold list (Step 1-3).
The Buy Agent (BA) is the programming entity that
will be involved by the users who want to buy cars. The
BA will then transfer the requirements to the RDA and
store the information into the buy list. Then RDA will
return a subset of the sell list that matches the criteria
placed in the buy order back to the BA (Step 4, 5).
The BA will then ask the SA about further information
that the user would like to obtain (Step 6, 7). Negotiation
will be carried out between BA and SA (Step 8). If the
trade is successful, the BA will remove the buy requests
(Step 9). At the same time, the SA will also remove the
sell order from the purchase requests (Step 10).
4.2. Service model
Figure 4 shows an overview of the service model. It
should be noted that the UCMS mainly provides matchmaking services (i.e., the blue items in Figure 2). However, different topologies are possible and additional services
could be implemented or customized. Thus, this approach
is applicable to other business domains generally.
Car sell
Search car
Negotiate
Order car
Fulfillment
Provide car
information
Provide
contact
information
Provide
payment
information
Provide
shipment
information
Figure 4. UCMS service model
5. Application of Semantic Web Technologies
5.2. RDF XML Format Example
5.1. Ontology for UCMS
Figure 8 and 9 illustrate how user and car information
are coded into RDF files, respectively.
Figure 5 illustrates the car ontology, which features the
model of car. Thus, the car is fully described by the ontology and can be searched by its feature. To match the buy
requests (see Figure 6) and the sell requests (see Figure 7)
of used cars, we use OWL DL classification to relate the
specific domains, such as the color relation or the price
relation of the two domains. Also based on the classification, our framework provides a way to express the preferences between terms by using the priority property. So, by
this method, we can indicate which result to be considered
for the matching.
Mand
atory
Car
ry
dato
Man
Car Body
Man
dato Optional
ry
Transmission
Altern
y
da
tor
Pulls trailer
Alte
rna
tive
tive
Altern
ative
ry
Ma
n
dato
Red
ti
ative
Man
Color
a
ern
Alt ve
Engline
Alte
rna
Automatic
Manual
Electric
No. of seats
Alte
rna
Altern
ativ
tive
Blue
e
Alternative
5-seats
7-seats
Gasoline
Name
Peter
Pan
Phone
8109922355
May
Chan
…
8186655223
…
Vehicle
Important
Description
Priority
Description
Property
No. of seats
color
Price
Model number
Figure 6. Ontology of Buy Vehicle
UCMS
Vechicle for
sale
Seller
resource ID
Business car
Sport car
Family car
No. of seats
Made Year
color
Price
Model number
Figure 7. Ontology of Sell Vehicle
Identity
A8823560
[email protected]
K7749521
…
…
Figure 8. User information
Type
Light Goods
Vechicle
Model
Toyota
Picture
Mytoyota.jpg
Price
60k
Private Car
Honda
Hondacivic.jpg
35k
…
…
…
…
<?xml version="1.0"?>
Made Year
Email
[email protected]
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ucms_person="http://www.ust.csit600f/ucms_person#">
<rdf:Description
rdf:about="http://www.ust.csit600f/ucms_person/ Peter Pan ">
<ucms_person:phone number>810-9922355</ucms_person:phone number>
<ucms_person:address>No 1, Tai Ming Estate, TT, HK</ucms_person:address>
<ucms_person:email>[email protected]</ucms_person:email>
<ucms_person:identity>A8823560</ucms_person:identity>
</rdf:Description>
<rdf:Description
rdf:about="http://www.ust.csit600f/ucms_person/ May Chan">
<ucms_person:phone number>818-6655223</ucms_person:phone number>
<ucms_person:address>Room 8, Hall 1, UST, HK</ucms_person:address>
<ucms_person:email>[email protected]</ucms_person:email>
<ucms_person:identity>K7749521</ucms_person:identity>
</rdf:Description>
...
</rdf:RDF>
Figure 5. Ontology (car)
Buyer
resource ID
Address
No 1, Tai
Ming Estate,
TT, HK
Room 8, Hall
1, UST, HK
…
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ucms_car="http://www.ust.csit600f/ucms_car#">
<rdf:Description
rdf:about="http://www.ust.csit600f/ucms_car/<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ucms_car="http://www.ust.csit600f/ucms_car#">
<rdf:Description
rdf:about="http://www.ust.csit600f/ucms_car/Light Goods Vechicle">
<ucms_car:model>Toyota</ucms_car:model>
<ucms_car:picture>Mytoyota.jpg</ucms_car:picture>
<ucms_car:price>60k</ucms_car:price>
<ucms_car:remark>
<rdf:Bag>
<rdf:li>Auto</rdf:li>
<rdf:li>4 safety-bag</rdf:li>
<rdf:li> 8-seats</rdf:li>
</rdf:Bag>
</ucms_car:remark>
</rdf:Description>
<rdf:Description
rdf:about="http://www.ust.csit600f/ucms_car/Private Car">
<ucms_car:model>Honda</ucms_car:model>
<ucms_car:picture>Hondacivic.jpg</ucms_car:picture>
<ucms_car:price>35k</ucms_car:price>
<ucms_car:remark>
<rdf:Bag>
<rdf:li>Manual</rdf:li>
<rdf:li>V-tec engine</rdf:li>
</rdf:Bag>
Remark
Auto, 4 safety-bag, 8seats
Manual, V-tec
engine
…
Order Received
Begin
Enquiry
Received
Check
System
Config
Prepare
Quotation
Send
Quotation
Req
Extra
Info
System
Integrator
Prepare
Service
Deliver &
Install
Payment
Received
End
Request
Extra
Info
Sell Integrated System
</ucms_car:remark>
</rdf:Description>
...
</rdf:RDF>
Send
Extra Info
Begin
Order
Missing
Parts
Assemble
System
References
Test
Install
Software
[1]
Prepare Service
Figure 9. Car information
Begin
5.3. RDF Schema
Update
Catalog
[2]
End
Receive Part Info Updates
Figure 10 shows the schema about the resource of
“Toyota” and “Honda” is subclass of “car”.
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf= "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base= "http://www.ust.csit600f/ucms_car#">
<rdf:Description rdf:ID="car">
<rdf:type
rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>
<rdf:Description rdf:ID="toyota">
<rdf:type
rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#car"/>
</rdf:Description>
<rdf:Description rdf:ID="honda">
<rdf:type
rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#car"/>
</rdf:Description>
...
</rdf:RDF>
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Figure 10. RDF Schema
[10]
[11]
6. Discussion and Conclusion
[12]
The real power of the Semantic Web can only be realized when a large variety of services that collect Web content from diverse sources, process the information, and
exchange the result with other programs. The effectiveness
of software agents will increase exponentially as more
machine-readable web content and automated services and
other collaborating agents become available.
The Semantic Web is not just a tool for conducting individual tasks that we have discussed so far. In addition, if
properly designed, the Semantic Web can assist the evolution of human knowledge over the Internet as a whole.
Then, resources can be modeled and standardized to be
understood and utilized. In the Semantic Web, with well
defined ontology, it can provide semantic links between
and within resources to model. Thus, information and
knowledge can be standardized, processed, and exchange
effectively. This is particular useful for providing personalized recommendation, matching, and negotiations.
This paper is not aimed to describe all the details for
the implementation of the whole system, but a high-level
description the system workflow and approaches to utilize
ontology, the core of Semantic Web technologies, to help
business implementations. We are investigating other ontologies for assisting the implementations of different services in different e-business domains.
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
System
End
Bailin, S. C. and Lehmann, H. B., "Facilitating physician-patient
dialogue through ontology negotiation," Proceedings of the 16th
IEEE Symposium on Computer-Based Medical Systems 2003, 2627 June 2003, pp. 248 - 253.
Bailin, S. C. and Truszkowski, W., "Ontology negotiation between
scientific archives," In Proceedings of the Thirteenth International
Conference on Scientific and Statistical Database Management
2001, 18-20 July 2001, pp. 245 - 250.
Chiu, D. K. W., S. C. Cheung, P. C. K. Hung, and H.-f. Leung
(2005). Facilitating e-Negotiation Process with Semantic Web
Technologies. 38th Hawaii International Conference on System Sciences (CDROM).
Cheung, S. C., P. C. K. Hung and D. K. W. Chiu, “A Meta-model
for e-Contract Template Parameter Dependencies Facilitating eNegotiation,” In Proceedings of the 21st International Conference
on Conceptual Modeling (ER2002), Tampere, Finland, Springer
LNCS 2503, pp. 55-64 (2002).
Cho, S., “A Framework for the Evaluation of an Electronic Marketplace Design with Evolutionary Negotiation Support,” In Proceedings of the 34th Hawaii International Conference on System Sciences, pp. 1863-1872 (2001).
DARPA Agent Markup Language (DAML). (2004) Online:
http://www.daml.org/
Daconta, Michael C., Obrst, Leo J., Smith, Kevin T. The Semantic
Web: A Guide to the Future of XML, Web Services, and
Knowledge Management, John Wiley & Sons (2003).
Edgington, T., B. Choi, K. Henson, T.S. Raghu, and A. Vinze
(2004). Adopting ontology to facilitate knowledge sharing. Communications of the ACM, 47 (11), 103-109.
Fensel, D., McGuiness, D. L., Schulten, E., W. K. Ng, E. P. Lim and
G. Yan, "Ontologies and electronic commerce," IEEE Intelligent
Systems, Volume 16, Issue 1 , Jan-Feb 2001, pp. 8 - 14.
Forrester Research. http://www.forrester.com/ (2000, 2002)
Fraser, Niall M., “Ordinal Preference Representations,” In: Theory
and Decision 36 45-67 (1994)
He, M., N.R. Jennings, and H.-f. Leung (2003) On agent-mediated
electronic commerce. IEEE TKDE, 15(4), 985-1003.
Lee, M. R. "Context-dependent semantic values for E-negotiation,"
In Proceedings of the Second International Workshop on Advanced
Issues of E-Commerce and Web-Based Information Systems, 8-9
June 2000, pp. 41 - 47.
M2 Presswire. Research and Markets: eProcurement: Successful
Strategies for the eMarketplace” Coventry, 1 page. (Feb 19, 2003)
OMG, Object Management Group: Foreword UML specification
1.4. September (2001)
Phelps, S., Tamma, V., Wooldridge, M. and Dickinson, I. "Toward
open negotiation," IEEE Internet Computing, Volume 8, Issue 2,
March-April 2004, pp. 70 - 75.
Resource Description Framework (RDF). (2004) Online:
http://www.w3.org/RDF/
Schoop, M., Quix C., “DOC.COM: a framework for effective negotiation support in electronic marketplaces,” Computer Networks 37,
153-170 (2001)
Yen, J., J. Hui and T. Bui, “Intelligent Clearinghouse: Electronic
Marketplace with Computer Negotiation Supports,” Proceedings of
the 33th Hawaii International Conference on System Sciences, pp.
379-388 (2000).
Yu, E., Mylopoulus, J., “Using Goals, Rules, and Methods to Support Reasoning in Business Process Reengineering,” International
Journal of Intelligent Systems in Accounting, Finance and Management, John Wiley & Sons, 5 (1) 1-13 (1996)
Web-Ontology (WebOnt) Working Group. (2004) Online:
http://www.w3.org/2001/sw/WebOnt