"Vraag en aanbod" - matching

[Rony Rabijns]

De opbouw :

- Twee tabellen : tabel "Vraag" en tabel "Aanbod".

- Beide tabellen hebben dezelfde velden

- De velden worden ingevuld op basis van waardelijsten

 

De bedoeling :

Checken (liefst relationeel) welke vraag met welk aanbod overeenkomt en andersom.

 

Het probleem :

Je kan dat "keihard" doen en een "eenvoudige" relatie bouwen, maar dan is de kans relatief groot dat er geen aanbod is dat voldoet aan een vraag.

 

Daarom formuleer ik de vraag nu iets anders :

Ik wil weten welke vraag het meest overeenkomt met welk aanbod en andersom.

 

Door het probleem zo te formuleren moet je ook gaan werken met gewichten. Bepaalde velden wegen in een matching zwaarder door dan anderen. En niet noodzakelijk alle velden moeten overeenkomen.

 

Ik heb al wat paden uitgetest. Sommigen zijn succesvol maar te langzaam, met sommigen geraak ik er niet uit.

 

Is er van jullie iemand die al met iets gelijkaardigs in aanraking is gekomen ? Zo ja dan hoor ik het graag.

[vbaren]

Rony,

 

Ik heb laatst via Rene (rgaros) iets gehoord over de Soundex procedure. Hiermee zou je gelijk klinkende woorden met elkaar kunnen vergelijken.

 

Wellicht leest hij het ook en kan hij je hierover meer vertellen.

 

Bart

[Joris Aarts]

Dag Rony,

 

begrijp ik het goed? Iemand zoekt een 'trui' en iemand anders heeft een 'pull' in de aanbieding en die moet je kunnen matchen? Je zou dat kunnen doen via een synoniemenlijst waarbij je aan elk synoniem een ranking meegeeft. Misschien een 'leermodule' integreren zodat je de rankings bij het gebruik nog kan bijsturen.

Als het over matching gaat van meerdere velden dan zou je een puntenwaarde aan elk veld kunnen toekennen en op basis daarvan rankings maken.

Veel groeten,

Joris

[Jeroen Aarts]

Mja, en op basis van de operatoren die je in FMP7 in relaties kan gebruiken kan je je ranking perfect relationeel vertalen.

 

Jeroen

[Rony Rabijns]

... de Soundex procedure. Hiermee zou je gelijk klinkende woorden met elkaar kunnen vergelijken.

 

Ik ben wel benieuwd. Hoewel "gelijk klinkende woorden" of "synoniemen" niet echt iets te maken hebben met het probleem dat zich hier bij mij stelt. (zie lager)

 

Iemand zoekt een 'trui' en iemand anders heeft een 'pull' in de aanbieding en die moet je kunnen matchen? Je zou dat kunnen doen via een synoniemenlijst waarbij je aan elk synoniem een ranking meegeeft. Misschien een 'leermodule' integreren zodat je de rankings bij het gebruik nog kan bijsturen.

Als het over matching gaat van meerdere velden dan zou je een puntenwaarde aan elk veld kunnen toekennen en op basis daarvan rankings maken.

 

 

Mja, en op basis van de operatoren die je in FMP7 in relaties kan gebruiken kan je je ranking perfect relationeel vertalen.

 

Joris en Jeroen,

 

Ik zal een voorbeeld geven waarbij je je waarschijnlijk wel iets kan voorstellen :

 

Tabel vraag :

Een man zoekt een vrouw zonder kinderen tussen 30 en 40 jaar.

 

Tabel aanbod :

1. Een vrouw zonder kinderen tussen 30 en 40 jaar.

2. Een vrouw zonder kinderen tussen 25 en 30 jaar.

3. Een vrouw zonder kinderen tussen 40 en 50 jaar.

4. Een vrouw met één kind tussen 30 en 40 jaar.

5. Een man zonder kinderen tussen 30 en 40 jaar.

 

 

De ingevulde data komt in beide gevallen uit waardelijsten en kan dus NIET vrij ingevuld worden. Met andere woorden, we weten welke data we kunnen verwachten in de records. Synoniemen zijn dus niet van toepassing.

 

Wat betreft de matching :

 

Aanbod 1 voldoet perfect. Deze match kan je ook relationeel perfect bepalen want voor ieder veld is de inhoud gelijk in vraag en aanbod.

Aanbod 2 zou kunnen voldoen maar scoort minder dan aanbod 1. Misschien is de man wel te overhalen toch met de vrouw in zee te gaan, ondanks de iets jongere leeftijd.

Hetzelfde geldt voor aanbod 3.

Aanbod 4 : een aantal criteria voldoen aan de vraag, behalve het aantal kinderen. Dus ook dit aanbod komt in aanmerking maar scoort geen 100%. De score wordt bepaald door de waarde die de man hecht aan het aantal kinderen.

Aanbod 5 voldoet absoluut niet omdat de eerste eis van de man is : een vrouw.

4 mei 2005 aangepast door Gast

[JeanWM]

Rony,

 

uit het gegeven voorbeeld meen ik een vergelijking met ons QA systeem te zien.

 

Ik gebruik een soort van 'wegingsformule' voor ieder item.

Aan de hand daarvan worden de items getoond die binnen de eerste 25% vallen, als er zijn....

...of er wordt een ranking gegeven. Daarna bepalen we wat er dient te gebeuren aan de hand van de ranking....

 

Komt dat in de buurt....?

[Rony Rabijns]

Komt dat in de buurt....?

 

Hé Jean,

Zo moet je het inderdaad zien.

Welke technieken heb jij hierin verwerkt ?

[JeanWM]

Welke technieken heb jij hierin verwerkt ?

 

Als je hiermee FM technieken wil zeggen: ik denk dat uiteindelijk veel aan bod gekomen is, vermits er ook een verwerking in zit met binomialen om 'waarschijnlijkheden' te berekenen zoals een 'gewone', een cumulatieve en verschillende in functie van ingegeven waarden.

Hiervoor gebruikten we enerzijds gewone (nu ja 'gewone') berekeningen, of berekeningen via scripts. en, indien mijn geheugen nog goed is, zit er ergens nog een Poisson berekening in verwerkt.

De waarschijnlijkheidsberekening wordt oa gebruikt om te beoordelen of een gegeven antwoord wel binnen 'het normale' zit.

Zoals je 'man' keuze in je voorbeeld, maar dat is dan wel zeer voor de hand liggend. Ik vermoed dat bepaalde antwoorden dat soms niet zullen zijn (verschillende antwoorden uit verschillende lijsten met elkaar vergelijken, waar sommige antwoorden (op zich) eigenlijk dezelfde moeten zijn....)

 

Waar ik aan dacht is eigenlijk de opvolging/beoordeling/verwerking van NCR's (Non Conformity Reports) in een kwaliteitssysteem.

Ik wil wel verder in detail gaan of forum, vermits er enkele zaken nogal 'gevoelig' liggen....(zoiets als jouw kok en restaurant vgl)

 

Maar hier toch een klein voorbeeld:

 

Er wordt een beoordeling gemaakt op 3 niveaus:

1. de waarschijnlijkheid van het optreden (W)

2. de ernst (E)

3. de kans op ontdekken (D)

 

1. krijgt een cijfer (bv van 1 tot 5)

1. zo goed als nul

2. zwak

3. ...

4. ....

5. .....

 

2. krijgt ook een cijfer

1. geen

2. klein

3. ...

4. ....

5. .....

 

3. evenzo

1. bijna zeker

2. ...

3. ....

4. .....

5. .......

 

De criticiteit is een vermenigvuldiging van waarschijnlijkheid, ernst en detectie. C = W x E x D

 

 

 

Aan de hand van die waardes ga je verder bouwen.

Zaak is in het begin een goede/juiste bepaling te maken van het resultaat (weging) van de uitkomst.

Ik heb die in een valuelist gepropt en met (Middle;enz) elke afzonderlijke waarde (die volgens je eerste bepaling bijna altijd op dezelfde plaats in de lijst zal staan) een 'gevolg' gegeven.

Moeilijker, maar niet onmogelijk, wordt het als die waardes van plaats kunnen verschillen, niet altijd het meest voor de hand liggende als eerste mogelijke keuze. Maar dat kun je 'achter de schermen' opvangen...

 

Je zou dus gelijke items uit de 'vraag' kunnen laten vergelijken met de vaste waardes uit ieder mogelijk antwoord.

Om snelheidsverlies tegen te gaan heb ik, waar mogelijk, de berekeningen op veldniveau gedaan.

Andere moest ik scripten en via gerelateerde bestanden gaan (FM5), wat op termijn wat vertraging geeft. Maar dat was meer omdat het geheel vervat zit in een volledig QA systeem met 32+ bestanden.

 

Dus..

 

Ik wil weten welke vraag het meest overeenkomt met welk aanbod en andersom.

 

Dan vrees ik dat je een 'waarschijnlijkheidstheorie' zult moeten inbouwen...

[Rony Rabijns]

... vermits er enkele zaken nogal 'gevoelig' liggen....(zoiets als jouw kok en restaurant vgl)

 

Dank Jean,

Daar heb ik dan ook alle begrip voor.

 

Jouw (dankbare) bijdrage werpt weer een ander licht op de zaak. Op dit ogenblik kan ik (nog) niet oordelen of jouw oplossing niet te complex is voor het probleem waar ik nu mee worstel.

 

Ik heb een werkende oplossing die voldoet aan de wensen van de klant, maar ben nu vooral op zoek naar alternatieven en andere invalshoeken. Ik vind mijn huidige oplossing te traag (dateert uit FM 4, en we leven nu in het FM7-era). Bovendien reageert ze niet adequaat genoeg in de huidige omstandigheden.

 

Mijn droom is om bij ingave van een aanbod, in een portaal onmiddellijk alle matches te zien, gesorteerd op "waarschijnlijkheid" (cq score). En vice versa.

Maar of dat dit kan met Filemaker ... Daar ben ik nog niet uit.

[Jeroen Aarts]

Beste Rony,

 

In zijn meest eenvoudige vorm zie ik het zo:

 

Elke vraagpartij op de 'markt' kan een aantal voorkeuren opgeven m.b.t. de kenmerken (verdeeld in vaste categorieën volgens jouw commentaar) van het verhandelde 'goed'. Deze voorkeuren worden uitgedrukt op een schaal (bv. van 0 [geen interesse] tot 10 [perfecte match]). Zo kan ikzelve bv. opgeven dat een alleenstaande vrouw tussen 25 en 30 met kinderen een score 10 krijgt en een vrouw tussen 30 en 40 een score 8.

 

Indien het niet wenselijk is dat de vragers zelf de ranking maken, moet je naar een complexere methodiek gaan om je ranking automatisch te laten genereren. In de post van Jean wordt verwezen naar een bv. de binomiale verdeling, waarbij je in jouw model een endogene verklaring krijgt van wat verklaard zou moeten worden (je wil de match obv een categorie tot stand brengen naar aanleiding van een statistische verdeling van bestaande matches). Hoe de ranking ook tot stand komt, eenmaal je die hebt is de verdere implementatie m.i. vrij eenvoudig

 

De voorkeuren worden bijgehouden in een rankingtabel (tR) die per record een veld bevat die de id van de vraagpartij bevat, een veld voor de categorie (bv. 'alleenstaande man zonder kinderen tussen 30 en 40') en een veld voor de score op de schaal. Via de relatie tussen de tabel die het aanbod bevat (tA) en tR op basis van het categorieveld in tR en tA, kan je op je layout obv tA een portal maken waarin de matches aflopend zijn gesorteerd op score. Via een exra 'hop' naar de relatie tussen tR en tabel die de vraagpartijen bevat (tV) kan je de relatie leggen tussen vrager en aanbieder. Eventueel kan je nog een veld toevoegen in tA die een minimum-match op de schaal (bv. tenminste 5) normeert, waarbij je de relatie tussen tA en tR op basis van categorie kunt uitbreiden met de opgave dat het veld 'score' in tR tenminste gelijk moet zijn aan de waarde in het globaalveld in tA.

 

Mijn excuses indien dit niets aan het antwoord op je vraag toevoegt

 

 

 

Jeroen

[JeanWM]

Het wordt ook wat tricky indien je nog een 'interne' controle van de antwoorden nodig hebt.

 

Indien een man een vrouw zoekt en aangeeft dat kinderen geen probleem zijn (in vraaglijst 1) en in vraaglijst 3 is het antwoord 'ik hou eigenlijk niet van kinderen', zit je met een onwaarschijnlijkheid....

 

die minder erg zal zijn dan:

'ik hou van kinderen' maar 'ik wil geen kinderen', (om welke reden dan ook)

 

Dan moet je bijna een weging op een weging gaan uitvoeren, of vooraf elke onwaarschijnlijkheid bepalen (wat misschien makkelijker is).

 

Dat is oa de reden waarom ik in mijn toepassing de binomiale verwerkt heb....en waarom het goed is dat vader soms eens langskomt met zijn luisterend oor...

[Rony Rabijns]

Tijd brengt raad en vooral overleg met de klant brengt raad

 

Eerst en vooral wil ik iedereen danken die heeft willen meedenken en meegedacht heeft.

 

Samengevat :

De hoofdeis blijft dat alles relationeel moet opgelost worden aangezien de vragende partij of de aanbiedende partij vaak fysisch aanwezig zijn bij de ingave en onmiddellijk moeten kunnen zien op basis van haar selecties, wat de eventuele matches zijn. Op die manier kan de vraag onmiddellijk bijgestuurd worden zodanig dat er "altijd" een resultaat is. De aanbieder daarentegen ziet onmiddellijk of er kandidaten zijn.

 

Daar bovenop komt nog dat deze applicatie gelijktijdig op het internet en lokaal zal draaien. De ingave voor de internetgebruiker moet dus zeer eenvoudig en rechtlijnig zijn. Geen ingewikkelde dingen dus met gewichten en voorkeuren ingeven.

 

Vandaar dat we zijn gekomen tot onderstaande oplossing : simpel, functioneel en interactief. (zie screenshot)

[Bonte]

Ook maar een bijdrage leveren, nog niet alles in detail gelezen maar bij mij was dit m'n eerste gedacht.

 

De variabele criteria van de persoon waar je een 'perfect match' voor zoekt in globale velden plaatsen via een script.

 

Alle andere personen moeten een relatie hebben met die globale variabele velden. bv 3 vaste gegevens zoals man/vrouw en 6 variabele. Dan een berekend veld die de variabele relaties samentelt bv 4 van de 6 hebben een werkende relatie met de globalen dus krijgt die het cijfer 'match 4'.

 

Dan via een script zoeken naar de 3 vaste gegevens en naar alle 'match 4' en hoger. Het zoekresultaat uiteraard sorteren van hoog naar laag.

[Rony Rabijns]

Ook maar een bijdrage leveren, nog niet alles in detail gelezen maar bij mij was dit m'n eerste gedacht.

 

Bedankt Bonte voor het willen meedenken.

 

Maar ... jouw oplossing is gescript en dat "mocht" niet.

Het moest en zou relationeel zijn.

[Bonte]

Ook maar een bijdrage leveren, nog niet alles in detail gelezen maar bij mij was dit m'n eerste gedacht.

 

Bedankt Bonte voor het willen meedenken.

 

Maar ... jouw oplossing is gescript en dat "mocht" niet.

Het moest en zou relationeel zijn.

 

Oeps, nu ja het kan ook zonder scripten. De inhoud van de vaste voorwaarden plaats je in 1 berekend relationeel veld, in het portaal van die relatie sorteer je de resultaten dan gewoon de match-resultaten van hoog naar laag.

 

(edit) probleem is natuurlijk wel dat er maar 1 gebruiker kan zijn dus toch geen goede oplossing.

[Koen Van Hulle]

Hier een mogelijke oplossing die volledig relationeel is. Ik weet wel niet wat de snelheid zal zijn bij grote hoeveelheden data.

 

De volgende spelregels heb ik gehanteerd:

als alle voorwaarden overeenkomen: 100%

als geslacht en leeftijd overeenkomt maar niet kinderen: 75%

als geslacht en kinderen overeenkomt maar niet leeftijd: 50%

als enkel geslacht overeenkomt: 25%

 

Groeten,

 

Koen

matching.zip

[Rony Rabijns]

Dank Koen.

Ik vind het sterk dat zowel de relationele opbouw als de layout quasi identiek is aan die van mij. Kan jij hier binnenkijken ?

Ik vind de oplossing van je "rating" goed gevonden. Dat opent zeker perspectieven.

Je opmerking over de snelheid is ook een bedenking van mij. De tijd zal hier raad brengen. Hoe dan ook, het blijft sneller dan de gescripte oplossing die ik tot nu toe hanteerde.

[Koen Van Hulle]

Had je geen schermafdruk gepost?

 

Koen