Agent-based E-commerce System Maria Ganzha Marcin Paprzycki http: //agentlab. swps. edu. pl
Agent-based E-commerce System 1. Introduction
Assumptions l Modelling a distributed marketplace Internet l e-buyers visit e-shops with a desire to purchase products l buyers negotiate prices with sellers l clients decide which store to buy from l “wholesalers” provide products for e-shops l Utilizing software agents for all e-commerce functions l develop complete system skeleton all agent functions and agent interactions implemented
Use case of the system
What's different (1) l Multiple items of a product placed for sale one after another series of price negotiations l Multiple items sold price negotiations are organized differently “discrete process” l Buyer Agents (BA) “collected” and released in groups to participate in negotiations l while negotiation takes place BA’s communicate only with the Seller Agent (Se. A) l meanwhile next group of BA’s is collected (as they arrive) and will participate in the next negotiation
What's different (2) Multiple subsequent auctions (involving items of the same product) take place price negotiation mechanism can change l Model of a complete e-commerce system l l actions that take place before negotiations l actions that take place after negotiations l product logistics l Clients choose shop from which to make a purchase “airline reservation” model
Agent-based E-commerce System 2. Ontologies and their utilization
Ontology of products (1) l Product taxonomy inspired by the Global Products Classification (GPC) standards l shoes l cameras l Product skeleton l created by sub-classing the base ontology l shoes of the same style and brand l Product variation l instance of a product skeleton l shoes of given style and brand of a particular size and colour
Ontology of products l Instance
Ontology of products (2) : Product a owl: Class. : Clothing rdfs: sub. Class. Of : Product. : Shoes rdfs: sub. Class. Of : Clothing. : Shoes. With. Laces rdfs: sub. Class. Of : Shoes. : Athletic. Shoes rdfs: sub. Class. Of : Shoes. : has. Price a owl: Object. Property ; rdfs: domain : Product ; rdfs: range : Price. : has. Brand a owl: Datatype. Property ; rdfs: domain : Product ; rdfs: range xsd: string. : has. Color a owl: Object. Property ; rdfs: domain : Product ; rdfs: range : Color. : has. Size a owl: Object. Property ; rdfs: domain : Product ; rdfs: range : Size.
Ontology of product – instance (1) @prefix cc: <http: //www. ibspan. waw. pl/ecap/product/clothing-catalog. owl#> @prefix prod: <http: //www. ibspan. waw. pl/ecap/product. owl#>. @prefix : <http: //www. ibspan. waw. pl/ecap/db/cic/products. owl#>. : Product 1165510834375 a cc: Protective. Lower. Body. Wear. Brick, a prod: Product. Entity ; cc: has. Consumer. Lifestage cc: Unclassified ; cc: has. Gender cc: Female ; cc: has. If. Disposable cc: Yes ; cc: has. Safety. Features cc: Cold. Resistant ; cc: has. Type. Of. Material cc: Combination ; cc: has. Type. Of. Protective. Lower. Body. Wear cc: Protective. Knee. Pads
Ontology of product – instance (2) @prefix avc: <http: //www. ibspan. waw. pl/ecap/product/audio-visual-catalog. owl#>. @prefix prod: <http: //www. ibspan. waw. pl/ecap/product. owl#>. @prefix : <http: //www. ibspan. waw. pl/ecap/db/cic/products. owl#>. : Product 1165506706750 a avc: Televisions_Hand_Held. Brick, prod: Product. Entity ; avc: has. Colour. Format avc: Black_White ; avc: has. Type. Of. Televisions avc: Plasma ; avc: has. If. With. Radio avc: Yes ; avc: has. Screen. Size avc: _2. 5 Inch.
Ontology of products l Instance
Product registration (1) l SA registers sold products with the CIC using ACL REQUEST messages l message content specified using FIPA Semantic Language (FIPA SL) l FIPA SL term representing an action has the form: (action Agent Action) l Specifically: l Agent = the agent performing the action l Action = the action which is [to be] performed
Product registration (2) l Agent = CIC (agent-identifier : name cic@ibspan. waw. pl : addresses http: //www. ibspan. waw. pl: 9999) l Action = register set of products sold by a SA (Add-Product-Shop (Entry : product (set PD 1. . . PDn) : shop Shop : gatekeeper Gatekeeper)) l PDi = product descriptions in OWL (Lite) ontology instance (Product. Description : language "owl" : description OWL-EXPRESSION )
Product registration (3) Products that are sold have to be registered with the CIC l Product ID l l extension of product ontology to specify that a given shop sells a given product l shop identified by its Gatekeeper Agent (GA) : GA-1 a : gatekeeper. Agent; : name ga 509@ibspan. waw. pl ; : addresses http: //www. ibspan. waw. pl: 9999 ; : shop 767 ; : sells : Product 4094094049.
Usage scenario l System is running for some time l SA’s have registered their products with the CIC l stored in a Jena repository l middleware over a database to manage stored in the system instances of ontologies l CA’s know where the CIC is l CA’s have interacted with some SA’s l SA’s have interacted with some CA’s l Scenario what happens when user wants to buy a pair of athletic shoes l assumption user interacts with its CA through a web-based interface
Processing User Request l A query-string (URL extension) representing user request reaches the CA l Example: ? product. Class=Athletic. Shoes &has. Color=Black. Color&prize: of. Currency=EUR &prize: value: left. Bound=25&prize: value: right. Bound=50 &size: value 1=36&size: value 1=37 l CA translates query-string into a SPARQL query l SPARQL rather than RDQL because SPARQL is more expressive than RDQL l SPARQL is about to obtain standardization l JENA already includes working SPARQL module l SPARQL query engine is better tested l
SPARQL Query example PREFIX my: <http: //jacs. ibspan. waw. pl/ontology#> SELECT ? product, ? gateway { ? gateway : sells ? product; } { ? product, rdfs: sub. Class. Of my: Athletic. Shoe ; my: has. Color my: Black. Color ; my: has. Prize ? prize ; my: has. Size ? size } { ? prize, my: of. Currency my: EUR ; my: value ? prize. Value } { ? size my: value ? size. Value }, FILTER ((? size. Value = “ 36. 0” || ? size. Value = “ 37. 0”) && (? prize. Value >= “ 25. 0” && ? prize. Value <= “ 50. 0”))
CIC result set and what next? CA packs the SPARQL query into an ACL QUERY-REF message send to CIC agent l CIC returns a (possibly empty) set of answers packed in an ACL INFORM message containing expressions like this: l (set (sequence PD 1 GA 1). . . (sequence PDn GAn)) CA evaluates this list based on “trust/image” l Based on results of evaluation CA will interact with selected e-shops l
Before Negotiation
Before Price Negotiations l CA asks the GA about admission rules l GA checks CA-trust + product availability and responds l no more product l go away we do not trust you l BA’s have to come l CA creates and sends a BA l BA’s created locally RESULT BA skeleton is “in” l GA provides BA with negotiation “details” l BA requests strategy (for THAT negotiation) l RESULT BA is ready and informs the GA l
Modular Agents
Negotiation and After l GA manages a pool of Se. As l when the time comes, it releases the list of BAs to a free and appropriately configured Se. A for negotiation l When negotiation is finished l Se. A informs winning BA and SA (via GA) l SA (via SDA) determines for how long to reserve the product for the winner BA/CA l depending on BA/CA “image/trust” l SA informs the BA about the reservation conditions l BA informs its CA about results on negotiation
Decision Time l CA receives ACL INFORM messages from its BAs l inform about winning or loosing negotiations l come completely asynchronous l varying time of reservation l CA utilizes multicriterial analysis to decide l to make purchase utilizing an available offer l to try for a better price l to abandon purchase
Agent-based E-commerce System 3. Trust in the system
Trust and Image trust – standard conceptualization a peer’s belief in another peer’s capabilities, honesty and reliability based on its own direct experiences trust – in our system fulfilment of a contract product matching our order delivery time reliability of the buyer image – involves „perceptions” given shop is „cheap” or „expensive” And I could afford to buy at your shop But your prices are too high for me. . . I trust you. I believe in your responsibility. I also trust you. I believe in your honesty. Maria. Merchant Paweł. Client Costin. Client
Trust in the System
Client Trust l Most processes that can visibly change trust in a given store take place during Sale finalization l involves, among others, payment and delivery of products
Initial Trust Sequence Diagram
Shop Trust l Most of process which can visibly change trust take place during After-negotiation period: l SA create reservation l BA: confirm purchase reject purchase (? time? ) no answer/answer after deadline
Modelling Trust of the Shop in Client x after n-th interaction event performed by the Client. Trust adjustment of n-th interaction event; impact of an interaction event on trust change.
Effect of α Brave client “I want to buy new shoes and I'm gonna try to negotiate with Maria's and Marcin's shops. ” Maciej. Client T Tn(Maria)=0 Tn(Marcin)=0 Careful merchant “You must be really obnoxious to make me angry, but as soon you managed to do it, I won't change my opinion about you so fast. ” Maria. Merchant Radical merchant α=0. 1 Tn(Maciej)=0 “I can be really mad, when you make me angry, but I also forget about negative behaviours quickly. Marcin. Merchant α=0. 8 Tn(Maciej)=0
TA(e) – How Can It Look Like l Reservation time is tres, no-penalty time is tnop, reservation cancellation time is tcant 1. BA has finalized purchase at time t [0, tres] TA(e) =1 2. BA has cancelled reservation at time tcan [0, tnop] TA(e) = 0 3. BA has cancelled reservation at time tcan (tnop, tres]. Let us assume that the maximum penalty for cancellation at time tcan = tres is γ, where 0 ≤ γ ≤ α, and the TA(e) is linear function, then TA(e) = a* tcan + b, where a = γ / (tres – tnop) and b = –γ tnop /(tres – tnop) 4. if BA has not responded in time t ≤ tres, then TA(e) = –α tnop -γ tres
Comments Trust value as a part of CA's strategy l it will buy one item, while has multiple reservations l which to reject imediately? l which can expire? l where not to send agent back to negotiations? l etc. l knowing that over time good and bad behaviors are being forgotten and the incoming agent is treated as „unknown”
Agent-based E-commerce System 4. Price negotiations
Price Negotiation Overview l BJP framework l negotiation “participants” l host negotiation “manager” l buyer(s) l seller(s) l negotiation process has phases: l proposal submission l agreement formation l Our system l admission to negotiations – Gatekeeper agent (GA) – not a part of negotiations l rules for admission to negotiations – outside of the host
Negotiation Host Structured Into Subagents
Negotiation Rules l Enforce specific negotiation mechanism l for checking the validity of negotiation proposals – Proposal. Validator l for protocol enforcement – Proposal. Enforcer l for updating the negotiation status and informing participants – Information. Updater l for agreement formation – Agreement. Maker l for controlling the negotiation termination – Negotiation. Terminator
English Auction l single-item l first-price l open-cry l ascending auctions l single seller and many buyers l time limit for ending the auction l seller reservation price simple, well-known, !uninteresting!
Posting Rule IF There is a valid proposal Pr submitted by a participant with role ‘Buyer’ on product A AND There is an active proposal submitted by a participant with role ‘Seller’ on product A THEN Proposal Pr is posted
JESS represented rule
Dutch Auction l Single item Dutch auction l Seller begins with a high asking price which is lowered until buyer is willing to accept the price, or a predetermined minimum price is reached (no sale) l Multiple-item Dutch auction? ?
Dutch Auction Scenario (1) l Participants: l Negotiation Host (“location” where the negotiations takes place) l Single Seller Agent (Se. A) l Multiple Buyer Agents (BA)s l N units of product P are to be sold l Initial bid posted on the Blackboard
Dutch Auction Scenario (2) l Se. A subsequently reduces the price l One of BAs (e. g. BA 5) responds with an ACL message informing that it is ready to purchase M, M ≤ N, units of P at a price equal to the current bid l then number of available units is reduced by M and BA 5 is removed from negotiations (each BA is allowed to submit at most one successful bid) l Process continues until (1) all N units are sold, or (2) minimal price of the Se. A is reached, or (3) time of inactivity is over
Seller Rules l Seller is allowed to shout a new price when one of the following conditions holds: l it is the first shout l one of Buyers submitted a bid that was successful l no successful bids were received and at least Tm time units elapsed since the last shout
Improvement-Seller Rule IF participant with role ‘Seller’ has posted proposal Pr and value of last offer posted by ‘Seller’ is B and minimum decrement is H and X(Pr) ≤ B − H THEN proposal Pr is active
Experiments l JADE agent environment l JAVA Expert System Shell (JESS) l up to 20 machines in a single network l homogeneous environment (Windows or Linux) l heterogeneous environment (Windows + Linux) l system is being re-implemented, so next slides represent “what was” (IT WORKED)
Agent-based E-commerce System 6. Logistics
Logistics SDA controls supply and demand information l SDA sends product level prediction for a time -period (i. e. weekly prediction for 5 weeks) l WA analyses the status of the warehouse and decides how many to buy l Order (if necessary) is send to the Logistics Agent (LA) l LA utilizes a pool for Ordering Agents to process and order l
Use Case of Logistics
END of Agent-based E-commerce System
Скачать презентацию Agent-based E-commerce System Maria Ganzha Marcin Paprzycki http
e62011025ad82875caee8bfa585e0a11.ppt