270 likes | 480 Views
Matchmaking in P2P e-Marketplaces: Concept, Algorithm and Use Case. Manish Joshi joshmanish@gmail.com Virendra C. Bhavsar bhavsar@unb.ca Harold Boley harold.boley@nrc-cnrc.gc.ca. Objectives. To discuss challenges in automated matchmaking;
E N D
Matchmaking in P2P e-Marketplaces: Concept, Algorithm and Use Case Manish Joshi joshmanish@gmail.com Virendra C. Bhavsar bhavsar@unb.ca Harold Boley harold.boley@nrc-cnrc.gc.ca
Objectives To discuss challenges in automated matchmaking; To discuss multifaceted nature of participants’ expectations and interests (formalized as constraints); To discuss soft and hard constraints; To define compromise match with the help of examples;
Objectives (cont…) To communicate how various matchmaking systems handles compromise matches; To describe our system that can represent different types of constraints and effectively deals with compromise match situations; To demonstrate the results of our matchmaking system with home rental use case data obtained from an existing e-marketplace.
Participant specifies expectations in natural language Multifaceted nature of constraints Hard/Soft Constraints – Willingness to compromise on facet value. Range Value – facet values are provided as a range. Preferential – a particular facet may have preference over others. Multi Value – more than one values associate to facets. Hidden Cost – a value of a facet contains hidden cost. General Challenges in Automated Matchmaking
Matching result are expected to be ranked in various categories Matchmaking results vary based upon approach to the missing facet in the counterpart profile. (symmetric / non symmetric matchmaking) Scalability issue Domain Independence General Challenges in Automated Matchmaking (cont…)
Reflect the relative flexibility of participants regarding the fulfillment of a constraint. A soft constraint A participant proceeds with a match even if the facet value described by his/her constraint is not satisfied by the facet value of the corresponding constraint of the counterpart profile. Example A constraint description `Smoking is not allowed, but can smoke in balcony', represents a soft constraint. This constraint can be matched with a constraint that allows smoking as well as that does not allow smoking. A participant does not compromise with an offer/request specified as a hard constraint. Example A constraint specification provided by a buyer as `house rent must be 500' indicates a hard constraint. Soft and Hard Constraints
Soft constraint matches with counterpart's facet value irrespective of his/her own facet value. A pair of constraints from two profiles have a compromise match if, 1. either one or both of the constraints in a comparison are soft constraints, and 2. the values of the facets of both the corresponding constraints do not match. In such a case, either one or both participants compromise with the mismatching value mentioned in the counterpart constraint. Hence we refer to it as a ‘compromise match'. Compromise Match
Problem Statement An automated matchmaking system must provide the facility to specify the hard as well as soft constraint As soft constraints lead to compromise matches, an automated matchmaking system must evaluate its effect while generating matchmaking results. Moreover, results must be categorized into appropriate categories. Very few systems support the incorporation of hard and soft constraints . No working system takes account the effect of Compromise match. Our proposed system solves the above mentioned problems
Proposed KRM We represent a participant profile as a set of constraints and each constraint is a quadruple represented as <attribute, description, flexibility, priority>. Attribute (a) represents the facet of a constraint. For a constraint ‘need 4 bedrooms’, an attribute is ‘bedroom’. sample attributes – area, laundry, pets-allowed, smoking etc. Flexibility (f) indicates whether a constraint is a hard or a soft constraint. Value ‘yes’ indicate a soft constraint and a ‘no’ value of flexibility indicates a hard constraint
Proposed KRM (cont…) Description (d) represents a set of values assigned to an attribute of a constraint. For above constraint, description of an attribute ‘bedroom’ is {4}. Descriptions may include – Downtown, coin operated, allowed, no, 500, 3, 4, apartment etc. Range value constraints are represented as {num1 … num2} where num1 and num2 are real numbers. Description as a set of values represents different values of a multi value constraint.
Proposed KRM (cont…) Priority (p) describes relative priority of soft constraints among other soft constraints. For example, consider a participant’s apartment profile with rent facet preferred to facets area, type, pet-allowed. This profile can succeed in spite of low constraint satisfactions for the other facets as long as the rent constraint is highly satisfied.
Profile Representation Tenant Profile: I am a mature student looking for an affordable shared or single apartment on the south side of Fredericton for September. Finishing up my last year at UNB, I smoke but can adjust with non-smoking apartment.rent – 400 to 450. Please contact if anything is available, thanks! Constraints are represented as a set of nodes <type, {apartment, shared}, No, 1> <rent, {400…450}, Yes, 1> <area, {South side}, No, 1> <smoke, {allowed}, Yes, 1> <available, {Sept-01}, No, 1> Constraints are represented as a set of quadruples
Implementation - GUI With the help of a GUI, participant profiles are transformed in the proposed KR Model.
Implementation - Algorithm The similarity value is a function of attribute, description, flexibility and priority values of all constraints from both profiles. For any two profiles Px and Py, where Px has m constraints and Py has n constraints, a similarity value is given by, S(Ci, Cj) is an intermediate similarity value, which is calculated for each pair of constraints of the two profiles.
Implementation – Compromise Match LP-4 Vs TP-2 and LP-4 Vs TP-3 have compromise matches. LP-4 Vs TP-2: Only one participant is ready to compromise. LP-4 Vs TP-3: Both the participants are ready to compromise. LP-4 Vs TP-3 shall have more similarity value than the similarity value obtained for LP-4 Vs TP-2. • LP-4 • <bedrooms,{2},No,1> <lease,{year},No,1> • <laundry, {yes}, No, 1> <rent, {700}, Yes, 1> • <type,{apartment},No, 1> • TP-2TP-3 • <bedrooms, {2}, No, 1> <kids,{yes}, No, 1> laundry,{yes}, Yes, 1> <pets,{yes}, No, 1> • <pets,{yes}, No, 1> <rent, {600}, No, 1> <rent, {500}, Yes, 1> • <type,{apartment}, Yes,1> <type,{apartment}, Yes,1> Both Rent constraints are not soft Both Rent constraints are soft
Implementation – Compromise Match Similarity value in case of compromise match is influenced by the count (compromise count) of participants (one or both) willing to compromise. We propose compromise count factors \alpha and \beta to reduce intermediate similarity value in case of compromise match. When only one participant is willing to compromise in a compromise match then \alpha is used to reduce the intermediate similarity value. When both the participants are willing to compromise in a compromise match then \beta is used to reduce the intermediate similarity value. <
Exact: All constraints of profile Px are present in profile Py and have exact matches. 2. Potential: Some of the constraints from profile Px are not present in profile Py. However, all the remaining constraints of profile Px and Py have exact matching constraints. 3. Compromise: At least one compromise match exists between the constraints of profile of Px and profile Py. (a) Compromise(both): A compromise match with compromise count factor two. (b) Compromise(one): A compromise match with compromise count factor one. Implementation – Result Matchmaking Categories
Matchmaking Result The sample matchmaking results obtained for a Landlord’s profile when matched with Tenants’ profiles.
Features System can represent all types of constraints. Participant can indicate flexibility of constraints. System can identify compromise matches and accordingly reduces the intermediate similarity value. Matchmaking result is automatically categorized into appropriate categories proposed.
Conclusions We explicitly defined compromise match and a mechanism is put in place to determine similarity value even for compromise matches. A matchmaking system developed for house rental domain that has more features as compare to earlier matchmaking systems.
Implementation – Matchmaking Let’s see how similarity values are calculated when P-1 is compared with few other profiles. P-1: <bedrooms,{4}, No, 1> <laundry,{yes}, No, 1> <lease,{1-year}, No, 1> <rent, {1700}, No, 1> <type,{apartment},No,1> The attributes bedrooms, rent and type are hard constraints and description values of these two profiles mismatch. Hence the Similarity Value: 0.0 Mismatch of 3 Hard constraints P-8 : <available,{Sept-1}, No, 1> <bedrooms,{1}, No, 1> <rent, {100-400}, No, 1> <type,{bachelor, room}, No,1> Some attributes like bedrooms, laundry, lease from P-1 are not present in P-13 and attribute pets from P-13 is missing in P-1. But rent and type are soft constraint in one profile (P-13). Similarity Value: 0.9412 Two Compromised match - soft constraints P-13 : <pets, {yes}, No, 1> <rent, {0},Yes, 1> <type,{room}, Yes, 1>
Implementation – Matchmaking P-1: <bedrooms,{4}, No, 1> <laundry,{yes}, No, 1> <lease,{1-year}, No, 1> <rent, {1700}, No, 1> <type,{apartment},No,1> The attributes bedrooms and type are hard constraints and description values of these two profiles mismatch. Mismatch of 2 Hard constraints and two compromised matches (laundry and rent). Similarity Value: 0.397635 P-14 : <area,{downtown},No, 1> <available, {Sept-1}, No,1> <bedrooms,{2}, No, 1> <kids, {no}, No, 1> <laundry,{yes},No, 1> <pets,{yes}, No, 1> <rent, {800}, Yes, 1> <type,{apartment},No,1> The attributes bedrooms and rent are hard constraints and description values of these two profiles mismatch. Mismatch of 2 Hard constraints but only one compromised match (type). Similarity Value:0.1396 Hence similarity value of this match is less than P1 Vs P14. P-11: <bedrooms,{ 2}, No, 1> <kids,{yes}, No, 1> <pets, {yes}, No, 1> <rent, {500}, No, 1> <type,{apartment},Yes,1>
Implementation – Matchmaking Results A customized matchmaking algorithm generates a list of matching profiles from other group. Matchmaking Results – Similarity value – profile 1 Vs. profile 13 is -->0.9412 Similarity value - profile 1 Vs. profile 14 is -->0.397635 Similarity value - profile 1 Vs. profile 11 is -->0.1396 Similarity value - profile 2 Vs. profile 12 is -->0.985 Similarity value - profile 2 Vs. profile 8 is -->0.9652 Similarity value - profile 3 Vs. profile 14 is -->0.4315 Similarity value - profile 4 Vs. profile 14 is -->0.9506 Similarity value - profile 4 Vs. profile 13 is -->0.946 Similarity value - profile 4 Vs. profile 11 is -->0.4703 Similarity value - profile 5 Vs. profile 9 is -->0.995 Similarity value - profile 5 Vs. profile 13 is -->0.9751 Similarity value - profile 5 Vs. profile 8 is -->0.9702 Similarity value - profile 5 Vs. profile 11 is -->0.9653 Similarity value - profile 6 Vs. profile 13 is -->0.93639 Similarity value - profile 6 Vs. profile 11 is -->0.4268
References [1] Baader, F., Calvanese, D., Mcguinness, D. et al. 2003. The Description Logic Handbook: Theory, Implementation and Applications. Cambridge University Press, Cambridge, MA. [2] Bhavsar, V. C., Boley, H. and Yang, L. 2004. A Weighted-Tree Similarity Algorithm for Multi-Agent Systems in e-Business Environments. Computational Intelligence 20, 584-602. [3] Islam, M. R., Islam M. Z. and Nazia, L. 2008. A Tree-based Approach to Matchmaking Algorithms for Resource Discovery. International Journal of Network Management. [4] Kuokka, D. and Harada, L. 1996. Integrating Information via Matchmaking. Journal of Intelligent Information Systems 6, 261-279. [5] Joshi, Manish R., Bhavsar, V. C. and Boley, Harold. 2008. A Comparative Study of Features of Web-based Matchmaking Systems. Technical Report, Faculty of Computer Science, UNB, 2008. [6] Li, L. and Horrocks, I. 2004. A Software Framework for Matchmaking Based on Semantic Web Technology. International Journal of Electronic Commerce8, 39-60. [7] Mohaghegh, S. and Razzazi, M. R. 2004. An Ontology Driven Matchmaking Process. World Automation Congress 16, 248-253. [8] Noia, T. Di., Sciascio, E. Di., Donini, F. M. and Mongiello, M. 2004. A System for Principled Matchmaking in an Electronic Marketplace. International Journal of Electronic Commerce 8, 9-37. [9] Ragone, A., Straccia, U., Noia, T. Di. et al. 2007. Vague Knowledge Bases for Matchmaking in P2P E-Marketplaces. In proceedings of the ESWC. [10] Bassiliades, Nick., Antoniou, G., Vlahavas, I. 2004. A Defeasible Logic Reasoner for the Semantic Web, In Rules and Rule Markup Languages for the Semantic Web 3323/2004, 49-64. [11] Subrahmanian, V. S., Bonatti, P., Dix, J. et al. 2000. Heterogeneous Agent Systems. MIT Press. [12] Sycara, K., Widoff, S., Klusch, M. and Lu, J. 2002. Larks: Dynamic Matchmaking among Heterogeneous Software Agents in Cyberspace. Autonomous Agents and Multi-Agent Systems 5, 173-203. [13] Veit, D., Müller J. P. and Weinhardt, C. 2002. Multidimensional Matchmaking for Electronic Markets. International Journal of Applied Artificial Intelligence 16, 853-869.