how ontologies can help in an e-marketplace dickson k. w. chiu senior member, ieee dickson computer...

How Ontologies can Help in an

e-Marketplace

Dickson K. W. CHIUSenior Member, IEEE

Dickson Computer SystemsHong Kong

[email protected], [email protected]

Poon, Joe Kit Man Lam, Wai ChunTse, Chi Yung

Sui, William Hi TaiPoon, Wing Sze

Department of Computer Science,

University of Hong Kong

Ontology for e-

Marketplace ECIS 2005- 2

IntroductionFunction Traditional e-marketplace problem Contributions of Ontology

Match-making

Match-making is often ineffective because of the rigid definition of products of limited attributes.

Shared and agreed ontology provides common, flexible, and extensible definitions of products and requirements for match-making and subsequent business processes

It is difficult to specify complex product requirements because the relationships among attributes and values are ignored.

Complicated requirements can be decomposed into simple concepts for streamlining the elicitation of options

User interactions are limited to mainly manually, which is time consuming.

Accessible by automated agents through Semantic Web specifications for more business opportunities

Recom-mendation

Recommendations are often only possible within the same category.

Ontology helps elicit alternatives for recommendation.

Pre-set formulae for every type of product are needed for evaluation.

Ontology help recommendation by evaluating offers in terms of flexible overall scaling

Cross-sale and grouping of buyers and sellers with similar requests are difficult.

Matching grouping of buyers and sellers as well as cross-sale possible by inference with the ontology.

Negotiation No implicit ordering of alternatives. Implicit ordering of alternatives is elicited via inheritance.

Manual negotiation or inadequate negotiation support cause inefficient process and ineffective recognition.

Machine understandable semantics facilitate negotiation and automatic configuration of products and services as specified.

Ontology for e-


Background of Research D.K.W. Chiu, S.C. Cheung, P.C.K. Hung, and H.F. Leung. Semantic

Web Technologies for e-Negotiation. HICSS38 D.K.W. Chiu, S.C. Cheung, P.C.K. Hung, S.Y.Y. Chiu* and K.K.

Chung*. Developing e-Negotiation Process Support with a Meta-modeling Approach in a Web Services Environment, Decision Support Systems, accepted. (*FYP students)

Peliminary Version at ICWS'03, June 2003 6th Pacific Asia Conference on Information Systems, Sept 2002

D.K.W. Chiu, S.C. Cheung, P.C.K. Hung, and H.F. Leung. Constraint-based Negotiation in a Multi-Agent Information System with Multiple Platform Support, HICSS37, Jan 2004.

S.C. Cheung, P.C.K. Hung and D.K.W. Chiu. On e-Negotiation of Unmatched Logrolling Views, HICSS36, Jan 2003.

S.C. Cheung, P.C.K. Hung and D.K.W. Chiu. A Meta-model for e-Contract Template Variable Dependencies Facilitating e-Negotiation, ER2002, Oct 2002

Ontology for e-


Motivation

Are there currently significant practical use of the Ontology from Semantic Web?

Match-making and beyond Software requirement engineering / negotiation Model and solve practical problems with CS and

technologies Cross-over multi-disciplinary research

Ontology for e-


Objectives How to elicit negotiation requirements? Semantic Web

=> Ontologies => help negotiators’ mutual understanding of issues, alternatives, and tradeoffs

Address semantic requirements of negotiation Reduce cost and improve effectiveness of negotiation

(avoid combinatorial explosion of issues) Development of an effective and efficient negotiation

plan Applications: e-Marketplace, Web-service

negotiation, agent negotiation, requirement negotiation…

Ontology for e-


e-Negotiation Portal at e-Marketplaces

Buyers

Supplierse-Marketplace

Aggregate requests from Buyers, contactpotential Suppliers,

match Suppliersand Buyers, exchange

bids and offers,generate e-Contract

Repository

Ontologies and Concepts

e-Negotiation dataAgreements- …

bids

bids

offers

offers

Ontology for e-


Semantic basede-Marketplace Conceptual Model

Accepted Alternative ValueAccepted Offer

Trader

Recommendation

Matchmaking

Negotiation

Offer

Auxiliary Concept

IssueTask1..n

1..n 1..n

1..n

1

1..n1

Decision Plan

11

Ontology

nn

Alternative Value1..n1..n

Concept

1..n

1..n

1..n

1..n

1..n

1

1

n

1..n

nn

Base Concept

n

n

2..n

1..n

1..n

1..n

1..n

1

evaluates

drives1

1

1

nformulates

indivisibly relates to

nn

precedesn

n

1..n

resolves1..n1

1..n

1maps to

Ontology for e-


Overall e-Negotiation Process Design Methodology

Trader select agreed relevant ontologies

Trader identify issues

System maps issues into ontology concepts

System derive concept relations

System creation of agreement

Trader post (revised) preferences as offer

Trader product selection

[reject all matches/recommendations]

[accept offer]

[need to identify new issues]

System performs recommendation

System supported trader negotiation

[all issues are resolved]

[quit negotiation]

[need to identify new issues]

[need to revise tradeoff model]

[negotiation target chosen]

System check consistency of issues & concepts

[not consistent]

System performs matchmaking

[match not found]

[match found]

Trader specifies alternative values of issues

[trader change requirements]

System identifies alternatives

[consistent]

System formulate decision plan

Requirements elicitation phase

Decision phase

for each collection of co-related

issue

Requirementselicitationphase

Decisionphase

Ontology for e-


Requirement Elicitation Methodology

1. Traders select agreed ontology.2. Traders relate requirements to concepts in the selected ontology.3. System checks dependencies of concepts that constitute all 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 (Cheung et al. 2002).

5. For a consistent plan, the system can proceed to elicit the possible alternatives; otherwise we have to re-iterate 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.

Ontology for e-


Decision Phase Methodology The system

searches for the matching offers based on the trader’s preference attempt to rank them for the trader to choose

Trader may accept any matched offers or change his reservation price and attempt a negotiation with those

offers in order to seek for a more favorable one. If no matching offers are found, the system identifies near

misses and also attempts to rank them for the trader to choose. Trader change his mind to accept a near miss

or choose a near miss for negotiation. During negotiation, the system supports the user to make and

evaluate offers / counter-offers based on the decision plan (from previous slide) in a negotiation session as follows (Chiu et al. 2005).

Should new requirement issues arise in the decision phase (say, due to incomplete specification), the trader can we can go back 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.

Ontology for e-


Sample Ontology (Clothing)

Quantity

PurpleRed

Discount

Total Amount

Refunding Policy

ColorSize

Appearance

Clothing

Unit Cost

Payee

Insured Amount Insurer Premium

{unordered} attributes: deposit, installment, pay-upon-del ivery, ...

{unordered} attributes: brick red, crimson, ...

{unordered} attriburtes: smal l, medium, large, extra-large

{unordered} attributes: l ight purple, magenta, ...

Delivery Date

Sale Order

**

Delivery

Shipping Cost

Payment Terms

Insurance

Ontology for e-


Understanding Requirements from Ontologies

Perform graph search algorithm on the semantic map

Key requirements are preliminary identified in the first round (e.g., unit price, quantity)

For each identified requirement issue, check if an issue can be mapped directly to a concept. If not, see if an issue can be refined into a set of more

specific concepts a cost is refined into constituent costs that sum up to

it. Incomplete Ontologies

Introduce new concepts into the ontology map Relate it with to existing ones

Ontology for e-


Understanding Requirements from Ontology (Cont)

Perform graph search algorithm on the semantic map

For each identified concept c, Examine every un-visited node n adjacent to c in the

ontology map. For each such node n, see if the new concept is

relevant to the negotiation problem. Repeat until no more related new concepts can be

identified. Only after successful deal do we need to

consider combining newly identified concepts back to specify a more concise agreement

Ontology for e-


Understanding Dependencies of Requirements from Ontologies

Functional dependency borrowed from fundamental relational database

concepts motivate this research The alternative for an issue is determined by the

alternatives(s) of other issue(s). cost of production depends on delivery date and

quantity. Computational dependency –

more obvious type of functional dependency hardwired computational formula E.g. insurance amount = percentage * cost of goods.

Ontology for e-


Understanding Dependencies of Requirement from Ontology

Requirement dependency (constraint satisfaction) Only after the determinant value is known can viable

alternatives be determined. E.g., whether a customer may pay by credit card,

bank draft, or remittance is evaluated according to the total amount.

Classification dependency A special type of requirement dependency in which

the classification of another issue is dependent on the outcome of an agreed issue.

Ontology for e-


Indivisible Requirement Components for Tradeoff Evaluation

Indivisible Components of Issues Cyclic dependencies among the concepts Tradeoff Evaluation

Determine Size

Determine Color

Determine Refund Policy

Determine Unit Cost, Quantity & Delivery Date

Determine Payment Terms

Determine Shipping Cost and Payee

Determine Insurance Premium, Insured Amount & Insurer

Determine Discount

Compute Total Amount

Ontology for e-


Understanding Possible Requirement Alternatives from Ontology

Alternative for requirement are often in discrete values cannot be expressed in numerical values not quantized in normal practices because of difficulties in

recognizing them, e.g., color for simplicity and convenience (size => S, M, L, XL)

The elicitation of options is streamlined when a complicated issue is decomposed into concepts(appearance => size + color + shapes)

Ontology provide explicit ordering of them (size => S < M < L < XL) implicit ordering

inheritance (“is-a”) hierarchies composition hierarchies

Ontology for e-


Exploring more trading opportunities

from Ontology

improving the accessibility of automated agents to match functional specification

Agents could represent buyers or sellers e-marketplace acts as “broker” considering the shared ontology attributes and

constraints mapping of cross-sale grouping buyers or sellers together for higher

market efficiencies

Ontology for e-


System Implementation Architecture

Multiplatform Support Subsystem

WAP Gateway

SMS Gateway

Internet Messenger

Web Server

e-Negotiation Executing Subsystem

e-Negotiation Session Manager

Ontology Generator

e-Negotiating Matching Subsystem

e-Negotiation Process Generator

Task Organizer

Issue Dependency Editor

issuedependency

taskdependency

Ontology Maintenance Subsystem

Ontology Editor

Search Engine

Criteria & Issues Editor

ontology

CriteriaIssue

bids & offers e-Negotiation process

ontologyIssue

ontology

e-Negotiation process

revised ontology, issues

existing ontology

e-Negotiation Data & Repository

MultiplatformDevices

Ontology for e-


OWL Listing<owl:Ontology rdf:about="#Clothing"> <rdfs:comment>Sample Clothing

Ontology</rdfs:comment> <owl:Class rdf:ID="Clothing" /> <owl:Class rdf:ID="Appearance" /> <owl:Class rdf:ID="Color"> <rdfs:subClassOf rdf:resource="#Appearance" /> ... </owl:Class> <owl:ObjectProperty rdf:ID="hasAppearance"> <rdfs:domain rdf:resource="#Clothing" /> <rdfs:range rdf:resource="#Appearance" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasColor"> <rdfs:subPropertyOf

rdf:resource="hasClothAppearance" /> <rdfs:range rdf:resource="#Color” /> ... </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="size">  <owl:Restriction> <owl:someValuesFrom

rdf:resource="#Appearance" /> </owl:Restriction> </owl:equivalentClass></owl:Class>…</owl:Ontology>

Ontology for e-


Conclusions Formulation of negotiation plan with maturing of

Semantic Web technologies Elicitation of negotiation issues, issue dependencies,

tradeoff, and alternatives Control the openness of issues Our algorithm verifies the completeness of elicited

negotiation requirements Negotiation processes are properly guided, recorded,

and managed For e-commerce activities are usually more structural

and repeatable (as opposed to political negotiations) Ontologies and plans are therefore reusable Negotiation automation with agents / integration with

EIS

Ontology for e-


Future Work

Formal models Elicitation of semantic distances enhancement of ontology-based matchmaking and

recommendation algorithms ontology-based cross-sale and up-sale grouping of buyers and sellers for combined

quantity deals mobile clients and constraint-based requirement

specification

how ontologies can help in an e-marketplace dickson k. w. chiu senior member, ieee dickson computer...

Documents

e marketplaceecis

enegotiation process

manual negotiation

emarketplace dickson

ontology help recommendation

constraintbased negotiation

semantic web technologies

chiu senior member