[php/sql] regular expression in database

[Verwijderd]

Ik ben bezig om een database aan te legen waarmee vragen mee beantwoord kunnen worden. Voor een groot deel kan je de vragen structuur standardiseren maar niet altijd.

Nu wil ik dus een standaard vraag opslaan in de database.

Bijvoorbeeld: Waarom verkopen jullie niets van X

Waar X staat kan dus van alles ingevuld zijn. Is het mogelijk om een query te schrijven of om data zo op te slaan dat je met een regular expression toch het juiste record krijgt?

Het voorbeeld hierboven is overigens niet leidend, ik heb meerdere vragen die het zelfde zijn op merknaam/bandnaam/productnaam etc na.

[D-Raven]

Waarom sla je de vraag dan niet apart op ten opzichte van het merk/product/band naam.

Dan kun je simpelweg query's op koppeltabellen uitvoeren om het gewenste resultaat te krijgen.

Maargoed, je kunt natuurlijk ook met LIKE aan de slag. Als je LIKE '%waarde' gebruikt dan heb je in feite al een EndsWith operator.

[TeeDee]

D-Raven schreef op woensdag 29 augustus 2007 @ 17:00:
Waarom sla je de vraag dan niet apart op ten opzichte van het merk/product/band naam.

Dat is nog wenselijker ook. Wat als de product/merk/band naam aangepast wordt?

Waarom handel je dit niet gewoon af in php met een simpele replace?

Je kan dit opslaan in de db: Waarom verkopen jullie niets van {productname}

En dan {productname} in php vervangen.

[Verwijderd]

het punt is dat ik honderden varianten kan krijgen, alle verschillend op 1 word of term (bestaande uit meerdere woorden). en dit per vraag type. dus dit kan vrij snel oplopen. daarbij weet ik niet van te voren hoe de structuur van de vraag is.

Met LIKE benader ik de database met een (half) open vraag. Omdat ik redelijk wat vragen kan verwachten met vergelijkbare opbouw, zoals wat is, hoe komt, waarom dit, is het in stukken hakken en kijken naar de beste match mogelijk maar slordig. Zeker gezien de vragen over het algemeen niet erg lang zijn.

Ik zou het liefst dus de query anderom willen benaderen. De vraag opslaan met een makering op de plek van het open woord/term en dan hieraan de vraag met het woord/term aan matchen.
zodoende hoef ik maar 1 keer de structuur op te slaan om toch alle vergelijkbare vragen te beantwoorden.

Wat je met de koppeltabellen bedoelt als oplossing moet je me even uitleggen. Hoe zou je de database structureren?

[Verwijderd]

TeeDee schreef op woensdag 29 augustus 2007 @ 17:11:
[...]

Dat is nog wenselijker ook. Wat als de product/merk/band naam aangepast wordt?

Waarom handel je dit niet gewoon af in php met een simpele replace?

Je kan dit opslaan in de db: Waarom verkopen jullie niets van {productname}

En dan {productname} in php vervangen.

Nou zoiest heb ik dus ook in gedachten. Alleen hoe match ik "waarom verkopen jullie niets van blaat" aan "Waarom verkopen jullie niets van {productname}".
Om de str_replace te gebruiken moet ik weten om welk woord/term het gaat. En das nou het punt dat weet ik niet.

[Creepy]

Wat wil je nu selecteren en hoe?
Als je vragen gaat ophalen dan moet je toch een productnaam hebben? Als je een productnaam hebt dan kan je toch een standaard vraag ophalen en het juiste productnaam invullen?

Maar zoals al hierboven aangegeven: beter is het om alle vragen per product gewoon te te slaan.

Een koppel tabel is een tabel die gebruikt wordt op een n:m relatie in een database vast te kunnen leggen. Als je eens wilt zoeken hoe normalisatie in z'n werk gaat dan kom je geheid die term tegen (al dan niet in een iets andere vorm ).

[_js_]

In veel databases kun je gewoon een pattern in een tabel opslaan en met LIKE matchen

Als je een tabel hebt met een kolom genaam pattern, met daarin onder andere de waarde 'abc%', dan kun je dus meestal wel
SELECT ... FROM tabel WHERE 'abcdef' LIKE tabel.pattern
doen en de gewenste rijen terugkrijgen.

[FragFrog]

Wat wellicht een optie is voor jou is als je MySQL gebruikt is om met match against te gaan werken en strings in je database opslaan (alhoewel andere databases ongetwijfeld ook een dergelijke zoekmethode hebben).

Ruim een half jaar geleden ben ik me daar eens mee bezig gaan houden, het resultaat staat op http://fai.fragfrog.nl. In een database sla ik vragen en antwoorden op, aan elkaar gekoppeld met ID's een een score voor relevantie (met MySQL's match against in full_text_mode kun je een score krijgen die aangeeft hoe goed je zoekstring lijkt op een bepaald record). Gestelde vragen worden gekoppeld aan hun best matchende antwoord (waarbij gebruikers ook zelf aan kunnen geven of een match goed of slecht is) en dankzij query expansion worden ook antwoorden die op gelijksoortige vragen gegeven zijn terugkomen. Bij compleet onbekende zinnen wordt in de learning mode gevraagd een antwoord in te vullen, zodat gebruikers zelf meehelpen de database te vergroten (wat helaas gruwelijk misbruikt wordt momenteel gezien een aantal infantiele antwoorden, maar daar verzin ik nog wel een keer wat op ). Daarnaast zijn er een aantal 'fallback' searches en speciale modes (zo zal {time} in een antwoord altijd de huidige tijd weergeven omdat het bij het ophalen vervangen wordt) die bijvoorbeeld een 100% match geven als een zin al letterlijk eens is voorgekomen.

Het voordeel van een dergelijk systeem is dat je in principe heel dynamisch zoeken toe kan staan - een vraag als 'waar bevinden jullie je?' kan zo bijvoorbeeld ook beantwoord worden als je alleen een antwoord voor 'waar zijn jullie te vinden?' hebt opgeslagen. Hierin schuilt natuurlijk ook weer het nadeel: je 'net' wordt zo wel snel groot en mensen kunnen resultaten terugkrijgen waar ze niet naar op zoek waren.

Als je echt zeker wilt dat productsearches altijd relevante informatie teruggeven zou je eigenlijk een tabel moeten maken met alle productnamen en iets van een ID waar hun info-pagina gevonden kan worden en een match against doen versus die tabel - alle woorden in een zin die niet in je tabel staan leveren dan automatisch een score 0 op en de rest zou al op relevantie gesorteerd moeten zijn. Hou er dan alleen wel rekening mee dat woorden van minder dan 4 karakters standaard niet eens gevonden zullen worden.

[ACM]

Verwijderd schreef op woensdag 29 augustus 2007 @ 16:48:
Is het mogelijk om een query te schrijven of om data zo op te slaan dat je met een regular expression toch het juiste record krijgt?

Zowel in MySQL als PostgreSQL kan je gewoon met een regexp matchen, andere databases kunnen het vast ook wel. Met een regexp stukken tekst uit een veld halen is wat lastiger, sterker nog ik weet eigenlijk niet eens of dat wel kan.

Maar belangrijker is domweg wat je nou eigenlijk probeert te bereiken, er bestaat een grote kans dat je geen regexps nodig hebt, maar met je huidige uitleg is dat mijns inziens nog steeds niet duidelijk. Heb je concrete voorbeelden van data en het soort match dat je er op moet doen en waarom twee verschillende stukken data aan dezelfde query moeten voldoen?

[Verwijderd]

ACM schreef op donderdag 30 augustus 2007 @ 09:21:
[...]

Zowel in MySQL als PostgreSQL kan je gewoon met een regexp matchen, andere databases kunnen het vast ook wel. Met een regexp stukken tekst uit een veld halen is wat lastiger, sterker nog ik weet eigenlijk niet eens of dat wel kan.

Maar belangrijker is domweg wat je nou eigenlijk probeert te bereiken, er bestaat een grote kans dat je geen regexps nodig hebt, maar met je huidige uitleg is dat mijns inziens nog steeds niet duidelijk. Heb je concrete voorbeelden van data en het soort match dat je er op moet doen en waarom twee verschillende stukken data aan dezelfde query moeten voldoen?

Het doel is om een openvraag en antwoord systeem te krijgen. Waar mensen in hun eigen woorden een vraag kunnen stellen en hier een passend antwoord op kunnen geven. Ik heb het op dit moment zo opgezet dat de binnenkomende vragen gekoppelt worden aan een antwoord. Maar veel vragen zijn in structuur het zelfde op 1 word of term na. ondanks deze afwijkende term is het antwoord wat ze dienen te zien het zelfde.

Nu kan ik iedere vraag gaan koppelen maar dat zal de database enorm doen groeien. Niet dat dat persé erg is maar ik wil weten of er niet een schonere manier is om dit te doen zonder dat ik hiermee de kanspercentage voor een hit omlaag haalt.

Ik kan geen database van termen/namen gebruiken wanneer de vraagstelling iets is van "waarom verkopen jullie niets van X". Omdat X werkelijk van alles kan zijn.

Mijn uiteindelijke doel is dus om te zorgen dat X waar die ook in een vraag mag voorkomen resulteerd in een goed resultaat doormiddel van een soort syntax waarmee ik de structuur van de vraag in de database koppelt aan het antwoord.

Voorbeeld:

Wanneer komt Dimmu Borgir weer op voorraad
Wanneer komt Queen weer op voorraad
Wanneer komt die CD weer op voorraad

Op deze vragen kan een algemeen antwoord worden gegeven. De vraag kan echter qua term (bold) weer anders zijn. Mijn idee is dus de structuur op te slaan als:
wanneer komt {term} weer op voorraad

Om vervolgens in staat te zijn de vragen hieraan te matchen.

[Janoz]

Tja, ik denk dat je een beetje teveel hooi op je vork genomen hebt. Een natural language search engine is wel ietsje meer dan enkel een lijst met mogelijke vragen opstellen. Wat dacht je bijvoorbeeld van
Wanneer komt die cd weer op vooraad?
Wanneer komt die cd weer?
Wanneer hebben jullie weer die cd?
Wanneer hebben jullie die cd weer?
Wanneer hebben jullie die cd weer op vooraad?
Komt die cd binnenkort weer?
Is die cd leverbaar?
Wanneer is die cd weer leverbaar?
Kan ik die cd bestellen?
Wanneer kan ik die cd weer bestellen?
Wat is de levertijd van die cd?

Als ik jou was zou ik nu naar de opdrachtgever communiceren dat de natural search niet mogelijk is. Gezien je beperkte ervaring op dit gebied gaat dit waarschijnlijk nauwlijks werken. Als je toch echt door wilt zetten, ga dan op internet eens op zoek naar wat literatuur omtrend dit onderwerp.

[Verwijderd]

Janoz schreef op donderdag 30 augustus 2007 @ 10:55:
Tja, ik denk dat je een beetje teveel hooi op je vork genomen hebt. Een natural language search engine is wel ietsje meer dan enkel een lijst met mogelijke vragen opstellen. Wat dacht je bijvoorbeeld van
Wanneer komt die cd weer op vooraad?
Wanneer komt die cd weer?
Wanneer hebben jullie weer die cd?
Wanneer hebben jullie die cd weer?
Wanneer hebben jullie die cd weer op vooraad?
Komt die cd binnenkort weer?
Is die cd leverbaar?
Wanneer is die cd weer leverbaar?
Kan ik die cd bestellen?
Wanneer kan ik die cd weer bestellen?
Wat is de levertijd van die cd?

Als ik jou was zou ik nu naar de opdrachtgever communiceren dat de natural search niet mogelijk is. Gezien je beperkte ervaring op dit gebied gaat dit waarschijnlijk nauwlijks werken. Als je toch echt door wilt zetten, ga dan op internet eens op zoek naar wat literatuur omtrend dit onderwerp.

Of het teveel hooi op mijn vork is weet ik niet. De materie is nieuw voor me, maar je moet ergens beginnen. Als je refferenties heb waar ik het één en ander kan vinden dan zou ik hetr erg waarderen.

[Janoz]

Heb je überhaupt de term 'natural language search' al eens door google gehaald?

[Verwijderd]

Janoz schreef op donderdag 30 augustus 2007 @ 11:14:
Heb je überhaupt de term 'natural language search' al eens door google gehaald?

ja en 112,000,000 hits. Naar mijn ervaring weten tweakers vaak goeie duidelijke sites te vinden die niet persé in de top 100 van google staan.

Dus even hier vragen is vaak een stuk efficienter dan door honderden pagina's heen te kruipen.

Maar aan jouw reactie te zien weet je er dus geen.

[TeeDee]

Verwijderd schreef op donderdag 30 augustus 2007 @ 11:47:
[...]
Maar aan jouw reactie te zien weet je er dus geen.

Goede, relevante informatie opzoeken is ook iets wat je moet leren.

Google (jouw topic staat er ook tussen, dus mocht je een nette, mooie oplossing hebben, dan hebben andere mensen er ook wat aan!)

Edit:

Voorbeeld:

Wanneer komt Dimmu Borgir weer op voorraad
Wanneer komt Queen weer op voorraad
Wanneer komt die CD weer op voorraad

Op deze vragen kan een algemeen antwoord worden gegeven. De vraag kan echter qua term (bold) weer anders zijn. Mijn idee is dus de structuur op te slaan als:
wanneer komt {term} weer op voorraad

Om vervolgens in staat te zijn de vragen hieraan te matchen.

Op basis van bovesntaand voorbeeld vraag ik me af of je niet te ingewikkeld aan het denken bent.

{term} kan je imo prima in PHP vervangen met de gegevens binnen de bold tags. Die gegevens kan je gewoon uit je database, session, url parameter rukken.

[ Voor 40% gewijzigd door TeeDee op 30-08-2007 12:07 ]

[Janoz]

Ik weet inderdaad geen pagina waarop even simpel wordt uitgelegd hoe je natural language search kunt implementeren, maar ik denk dat dat komt omdat dit niet simpel uit te leggen is. Ik had gehoopt dat je uit die resultaten van google zelf de conclusie kon trekken dat deze materie niet iets is waar je je in een paar dagen even in inleest. De computer natural language laten begrijpen, zelfs binnen een erg beperkt domein, zijn dingen die onderdeel zijn van eem Master Thesis of PhD opdracht.

[Verwijderd]

Ik heb nergens iets gezegd van tijdsdruk of iets dergelijks. Mijn vraag was of het mogelijk was en hoe dit te bereiken. Ik ben niet opzoek naar een quickfix als ik die impressie hebt gegeven dan is dit mijn schuld. Ik ben opzoek naar de technologie en daar kan ik de nodige tijd in steken.

[Verwijderd]

TeeDee schreef op donderdag 30 augustus 2007 @ 11:58:
[...]

Goede, relevante informatie opzoeken is ook iets wat je moet leren.

Google (jouw topic staat er ook tussen, dus mocht je een nette, mooie oplossing hebben, dan hebben andere mensen er ook wat aan!)

Edit:


[...]

Op basis van bovesntaand voorbeeld vraag ik me af of je niet te ingewikkeld aan het denken bent.

{term} kan je imo prima in PHP vervangen met de gegevens binnen de bold tags. Die gegevens kan je gewoon uit je database, session, url parameter rukken.

Ik denk dat je gelijk hebt met het te moeilijk (of te mooi) denken. Ben nu bezig om de meest voorkomende structuren in een array te laden en deze vragen te breken op de {term}.
Vervolgens de voorkant en de achterkant vergelijken met de vraag.

dit zal in principe moeten resulteren in macht.

[P.O. Box]

kun je niet beter andersom denken... en wat algemene zoekwoorden in je tabel opnemen die in de vraag voor moeten komen om tot een bepaald antwoord te komen?

dus bijvoorbeeld:

Wanneer hebben jullie die CD op voorraad?

en dan in de database bij het antwoord een veld maken met "wanneer, voorraad" (of een koppeltabel)... als alle woorden (in dit geval wanneer en voorraad) voorkomen in de vraag dan tover je het antwoord voor. Of de antwoorden waar de meeste trefwoorden raak zijn toon je.
dan nog moet je heel goed nadenken over je trefwoorden, maar lijkt het me wel eenvoudiger te implementeren, en meer trefzekerheid op te leveren...

[Verwijderd]

Edwardvb schreef op donderdag 30 augustus 2007 @ 12:56:
kun je niet beter andersom denken... en wat algemene zoekwoorden in je tabel opnemen die in de vraag voor moeten komen om tot een bepaald antwoord te komen?

dus bijvoorbeeld:

Wanneer hebben jullie die CD op voorraad?

en dan in de database bij het antwoord een veld maken met "wanneer, voorraad" (of een koppeltabel)... als alle woorden (in dit geval wanneer en voorraad) voorkomen in de vraag dan tover je het antwoord voor. Of de antwoorden waar de meeste trefwoorden raak zijn toon je.
dan nog moet je heel goed nadenken over je trefwoorden, maar lijkt het me wel eenvoudiger te implementeren, en meer trefzekerheid op te leveren...

Op dit ogenblik werkt het systeem op de volgende wijze:

1. het systeem kijkt of de vraag 1 op 1 voorkomt in de database.
2. indien geen resultaat wordt er gekeken naar de woroden in de vraag en of deze terugkomen in de tekst.

ik heb net een scriptje gemaakt waarmee ik denk het gross te kunnen ondervangen.

code:

$q_array[] = "Wanneer komt {break} weer op voorraad";
$q_array[] = "Wanneer komt {break} weer";
$q_array[] = "Wanneer hebben jullie weer {break}";
$q_array[] = "Wanneer hebben jullie {break} weer";
$q_array[] = "Wanneer hebben jullie {break} weer op vooraad";
$q_array[] = "Komt {break} binnenkort weer";
$q_array[] = "Is {break} leverbaar";
$q_array[] = "Wanneer is {break} weer leverbaar";
$q_array[] = "Kan ik {break} bestellen";
$q_array[] = "Wanneer kan ik {break} weer bestellen";
$q_array[] = "Wat is de levertijd van {break}";


print_r($q_array);
echo "<br /><br />----------------------------------<br /><br />";

$q = "Wanneer komt die cd van queen weer op voorraad";

foreach($q_array as $key => $val)
    {
    $break = explode("{break}", $val);
    $i=0;
    foreach($break as $breakkey => $breakval)
        {
        if(!empty($breakval))
            {
            if(stristr($q, $breakval))
                {
                echo "$breakval [$key]<br />";
                $i++;
                }
            }
        }
    $point[$key] = $i;
    }

print_r($point);

It's not pretty but it does the trick.