Zoekfunctie Tweakers

[Verdi48]

Deze site bevat een mega hoeveelheid onderwerpen, topics, reviews en honderden forumreacties, dus lekker veel informatie over electronics, PC en aanverwante artikelen. Daarin makkelijk kunnen vinden wat je zoekt is dan wel prettig.

Het zal wel aan mij liggen, maar ik kan niet echt enthousiast worden over het zoeken in tweakers. Ik probeer ook op dit forum altijd eerst te zoeken naar wat al geschreven is over een onderwerp waar ik belangstelling voor heb. Voordat ik ga vragen of zelf schrijven. In de praktijk betekent dit dat ik vaak niet vind wat ik weten wil, er soms meer bij toeval toch op stuit en anders al snel uitwijk naar een andere site.

Dat kan toch niet de bedoeling zijn. Ik weet goed genoeg hoe ik met de zoek operators AND, OR etc. om moet gaan. Toch is mijn zoekresultaat zelden direct goed.

Als voorbeeld: Ik wil een WLAN Radio ook wel internet radio aanschaffen. Die termen in de "GoT Search" geeft honderden hits, maar niet wat ik echt zoek. Na lang spitten vond ik vrij veel over de Freecom MusicPal. Maar er zijn er veel meer, is daar nog zo weinig over geschreven, of zoek ik zo slecht. ?

Graag wat advies

[wimpie007]

Ben ik met je eens, erger ik me ook aan

Als ik Bv zoek op het grote samsung topic vind ik allemaal oude delen met andere zaken erbij en niet eens op volgorde

[Jazzper]

Idem hier. Komt volgens mij omdat er geen ranking systeem zit anders dan een orderlijkheid op datum

[KneppaH]

Als ik iets zoek krijg ik eerst altijd een aantal pagina's met topics uit 2001 en 2002. Hetzelfde als ik een bepaald topic (meestal gewoon uit 2009) probeer terug te vinden.
Zelfs als ik de topictitel bijna exact hetzelfde in de search intyp krijg ik eerst oude topics uit 2002 voor m'n kiezen op de eerste pagina met resultaten

[ Voor 5% gewijzigd door KneppaH op 26-03-2009 01:26 ]

[Kixtart]

Er zit wel een soort ranking in dmv gebruikte woorden. Wanneer jouw zoektermen vaak gebruikt zijn in een topic komt deze bij 'relevantie' hoger te staan. Het enige waar ik zelf soms problemen mee heb is de autocorrectie. Stel ik typ cmoputer dan zal de zoekfunctie in sommige gevallen dit automatisch vervangen door computer (bij deze zoekterm niet) en vaak merk je dit niet automatisch op. Dit is volgens mij op te lossen door "zoekterm" te gebruiken (quotes dus), maar dan moet dit dus al opgevallen zijn.

Ander probleem voor mij is dat de 'grote' topics vaak niet gevonden worden omdat als het goed is niet gelet wordt wanneer deze het laatst actief is geweest maar wanneer dit topic aangemaakt is.

edit:
In het eerste geval bedoel ik de stemming van de search (Omega search manual #stemming).

[ Voor 10% gewijzigd door Kixtart op 26-03-2009 01:33 ]

[Henk007]

Je kunt ook een externe zoekmachine laten zoeken, dit werkt soms best goed. De truc is om in de zoekregel site:gathering.tweakers.net toe te voegen.
voorbeeldje

[Kixtart]

Henk007 schreef op donderdag 26 maart 2009 @ 01:33:
Je kunt ook een externe zoekmachine laten zoeken, dit werkt soms best goed. De truc is om in de zoekregel site:gathering.tweakers.net toe te voegen.
voorbeeldje

note: kan alleen bij topics waar je niet ingelogd voor hoeft te zijn.

[Jejking]

Da's nogal logisch... posts binnen de HK en SG zijn nowai terug te vinden door Google omdat het een afgeschermd deel van de site is.

[RobIII]

Jejking schreef op donderdag 26 maart 2009 @ 01:41:
Da's nogal logisch... posts binnen de HK en SG zijn nowai terug te vinden door Google omdat het een afgeschermd deel van de site is.

Daarom kaart 'ie het ook aan

[ACM]

Verdi48 schreef op woensdag 25 maart 2009 @ 17:12:
Het zal wel aan mij liggen, maar ik kan niet echt enthousiast worden over het zoeken in tweakers. Ik probeer ook op dit forum altijd eerst te zoeken naar wat al geschreven is over een onderwerp waar ik belangstelling voor heb. Voordat ik ga vragen of zelf schrijven. In de praktijk betekent dit dat ik vaak niet vind wat ik weten wil, er soms meer bij toeval toch op stuit en anders al snel uitwijk naar een andere site.

Het specifieke voorbeeld dat je geeft is eigenlijk een heel erg lastig voorbeeld om goed te krijgen. Want wat bedoel je als je "internet radio" zegt? Zo'n apparaat dat zelf een internetverbinding kan maken via je wlan en dat afspeelt? Of een van de vele streaming online diensten... Bij wlan radio wordt het nog lastiger, want radio is uiteraard ook een term die op de netwerkconstructie van wlan slaat

Zoals je ook bij google kan checken leveren die termen ook daar niet heel erg relevante resultaten op voor jouw zoekopdracht. Ik ben bang dat we met dit specifieke voorbeeld tegen de beperkingen van termbased searches aanlopen, maar zelfs zogenaamde "semantische" zoekmachines zullen hier moeite mee hebben.

Maar er zijn er veel meer, is daar nog zo weinig over geschreven, of zoek ik zo slecht. ?

De termen zelf zijn al jaren redelijk populair natuurlijk, maar met het doel dat jij er nu bij had komen ze een stuk minder vaak voor...

Graag wat advies

Voor een lijst van producten kan je wellicht beter eerst in de pricewatch wat rondneuzen. Hoewel de internet radio's dusdanig zeldzaam zijn dat ze nog geen eigen categorie hebben gekregen en je bij de "mediaspelers" dan wat moet klooien met het uitzetten van de videoformaten (in de zijkant allemaal bij de niet-optie aanzetten) en missen we zo te zien de netwerkverbinding als invoer- en keuzeoptie. Bovendien moet je dan weten dat ze daar staan en niet bij de "mp3 spelers".

Heb je nog andere voorbeelden van resultaten die niet bij je zoekopdrachten pastten?

[TERW_DAN]

KneppaH schreef op donderdag 26 maart 2009 @ 01:25:
Als ik iets zoek krijg ik eerst altijd een aantal pagina's met topics uit 2001 en 2002. Hetzelfde als ik een bepaald topic (meestal gewoon uit 2009) probeer terug te vinden.
Zelfs als ik de topictitel bijna exact hetzelfde in de search intyp krijg ik eerst oude topics uit 2002 voor m'n kiezen op de eerste pagina met resultaten

Daarom kun je ook selecteren op datum topicstart en datum laatste reactie. Dit scheelt al HEEL veel is mijn ervaring.

[ACM]

wimpie007 schreef op woensdag 25 maart 2009 @ 17:13:
Als ik Bv zoek op het grote samsung topic vind ik allemaal oude delen met andere zaken erbij en niet eens op volgorde

Meestal vinden mensen een volgorde op relevantie beter. Maar dat hangt uiteraard van de zoekopdracht af. Verder gaan de meeste zoekmachines er van uit dat de termen niet semantisch bij elkaar horen, hoewel de grote jongens die daar echt tijd en geld aan kunnen besteden (zoals Google) daar uiteraard wel moeite in steken om dat toch als zodanig te herkennen.

Maar je kan uiteraard de volgorde aanpassen naar op- of aflopend de topicstarttijd of laatste-reactietijd en als je alleen de open versie van een groot topic wilt kan je natuurlijk ook nog bij de "Soort topic" alleen voor 'Open' kiezen. Maar ook hier geldt dat Google het niet noemenswaardig beter doet dan je bij ons kan bereiken. Het is hierbij helaas wel zo dat je wel wat beter moet weten hoe onze zoekmachine werkt om het eruit te halen.

Maar ik neem aan dat je in dit geval zocht naar een bepaald specifiek type samsung product, dus de naam daarvan bij de zoekopdracht toevoegen zal het allicht nog wat beter aan laten sluiten (en misschien dat de google resultaten dan wel beter zijn dan de onze).

Jazzper schreef op donderdag 26 maart 2009 @ 01:16:
Idem hier. Komt volgens mij omdat er geen ranking systeem zit anders dan een orderlijkheid op datum

Vanaf het moment dat we deze zoekmachine gebruiken (eind 2002 ergens) wordt al standaard op de relevantie gesorteerd. Dat die relevantie niet per se voor jou goed is begrijp ik uiteraard.

Kixtart schreef op donderdag 26 maart 2009 @ 01:27:
Het enige waar ik zelf soms problemen mee heb is de autocorrectie.

Nou, dat hebben we niet. Ik denk er wel over om het aan te bieden zodra omega het ondersteunt (in de vorm van tips dan overigens)
Wat je waarschijnlijk bedoeld is de 'stemming', het vertalen van woorden naar hun woordstam. En dat kan je inderdaad voorkomen, zodra je er last van hebt, door de term tussen "" te plaatsen. Dus bomen -> bom, maar "bomen" -> bomen. Hier hebben we zelfs een klein voordeel tov google, want vziw kan je het daar niet omzeilen

Ander probleem voor mij is dat de 'grote' topics vaak niet gevonden worden omdat als het goed is niet gelet wordt wanneer deze het laatst actief is geweest maar wanneer dit topic aangemaakt is.

Dat is dan toevallig iets waar ik op korte termijn naar wil kijken

Henk007 schreef op donderdag 26 maart 2009 @ 01:33:
Je kunt ook een externe zoekmachine laten zoeken, dit werkt soms best goed. De truc is om in de zoekregel site:gathering.tweakers.net toe te voegen.
voorbeeldje

Klopt. Overigens schrijf jij hier internetradio aan elkaar, wat voor google niet helemaal een andere opdracht is, maar voor onze zoekmachine wel. En in dit geval waarschijnlijk ook een betere zoekterm is voor de topicstarter

We zijn ons er van bewust dat de zoekmachine lang niet elke opdracht tot een succesvol einde weet te brengen. Helaas zie ik ook niet echt oplossingen om er iets aan te doen.

KneppaH schreef op donderdag 26 maart 2009 @ 01:25:
Als ik iets zoek krijg ik eerst altijd een aantal pagina's met topics uit 2001 en 2002. Hetzelfde als ik een bepaald topic (meestal gewoon uit 2009) probeer terug te vinden.
Zelfs als ik de topictitel bijna exact hetzelfde in de search intyp krijg ik eerst oude topics uit 2002 voor m'n kiezen op de eerste pagina met resultaten

We zijn zoals gezegd aan het kijken om in ieder geval het datumbereikfilter aan te passen zodat je (ook) naar de laatste-reactietijd kan kijken en ik overweeg uberhaupt om standaard alleen topics van maximaal 3 of 4 jaar oud te tonen, aangezien de oudere vaak wel hoog scoren maar meestal niet bijster relevant meer zijn. Uiteraard kan dat filter wel uitgezet worden dan.

Als er nog meer voorbeelden van slechte resultaten bij goede termen zijn hoor ik ze graag

[ Voor 5% gewijzigd door ACM op 26-03-2009 08:25 ]

[Verdi48]

ACM schreef op donderdag 26 maart 2009 @ 08:06:
[...]

Voor een lijst van producten kan je wellicht beter eerst in de pricewatch wat rondneuzen. Hoewel de internet radio's dusdanig zeldzaam zijn dat ze nog geen eigen categorie hebben gekregen en je bij de "mediaspelers" dan wat moet klooien met het uitzetten van de videoformaten (in de zijkant allemaal bij de niet-optie aanzetten) en missen we zo te zien de netwerkverbinding als invoer- en keuzeoptie. Bovendien moet je dan weten dat ze daar staan en niet bij de "mp3 spelers".

Heb je nog andere voorbeelden van resultaten die niet bij je zoekopdrachten pasten?

Thanks voor de reacties.

Ben in ieder geval blij dat ik niet de enige ben die moeite heeft met zoeken in Tweakers. Ik had al ontdekt dat de tweeledige betekenis van "internetradio" het zoeken bemoeilijkt. De niet instelbare voorkeur volgorde (datum) vind ik ook niet handig. Ook zoeken op mij bekende merknamen van Wlan radio's, ook binnen pricewatch geeft maar een magere score.

Grappig dat je internetradio's zeldzaam betiteld, kijk eens op het Duitse Ebay, daar vind ik al snel 20 merken en types. Dus misschien toch tijd voor een aparte rubriek. Juist in de "begin" fase van zo'n product heb je behoefte aan 1e reviews en ervaringen. Daar waardeer ik tweakers juist voor.

Nog even een misschien heel domme vraag, waar zit op deze site de uitlog knop ?

[RobIII]

Verdi48 schreef op donderdag 26 maart 2009 @ 11:48:

Nog even een misschien heel domme vraag, waar zit op deze site de uitlog knop ?

My TNet menu -> uitloggen

[ Voor 77% gewijzigd door RobIII op 26-03-2009 11:50 ]

[Erkens]

Verdi48 schreef op donderdag 26 maart 2009 @ 11:48:
Nog even een misschien heel domme vraag, waar zit op deze site de uitlog knop ?

In het "My Tnet"-menu

[Verwijderd]

ACM schreef op donderdag 26 maart 2009 @ 08:24:
[...]

We zijn zoals gezegd aan het kijken om in ieder geval het datumbereikfilter aan te passen zodat je (ook) naar de laatste-reactietijd kan kijken en ik overweeg uberhaupt om standaard alleen topics van maximaal 3 of 4 jaar oud te tonen, aangezien de oudere vaak wel hoog scoren maar meestal niet bijster relevant meer zijn. Uiteraard kan dat filter wel uitgezet worden dan.

Als er nog meer voorbeelden van slechte resultaten bij goede termen zijn hoor ik ze graag

Is het raar als ik zo'n beetje standaard in de geavanceerde optie de periode op een jaar zet? In ICT gerelateerd spul gaan dingen zo hard dat alles van > jaar oud meestal al niet relevant meer is

Of ouderdom gaan gebruiken als vermenigvuldigingsfactor voor relevante?

[ Voor 4% gewijzigd door Verwijderd op 26-03-2009 12:07 ]

[Verdi48]

RobIII schreef op donderdag 26 maart 2009 @ 11:50:
[...]
My TNet menu -> uitloggen

ROBIII en Erkens Bedankt voor snelle reactie

Verdi

[Verwijderd]

Kan er niet een test worden gedaan met een soort ranking systeem?

Als bijvoorbeeld na een zoekopdracht een topic wordt aangeklikt in de zoekresultaten dat er een teller +1 doet ofzo bij het topic voor de zoekfunctie. In de zin van mogelijk zinvol resultaat. En dat er een mogelijkheid komt voor de zoeker te sorteren op deze relevantie.

[Jejking]

Ja, maar definieer het woord ''zinvol'' dan eens. Wat de een zoekt, is niet hetzelfde als dat van de ander.

[Atomsk]

Wat andere kritiekpunten:

Het is niet mogelijk om op meerdere zoektermen te zoeken binnen berichten ipv binnen topics (behalve de start post met de "START:" operator). Wanneer ik nu zoek naar "gforce and geweldig" krijg ik tig topics waar ergens de woorden "gforce" en "geweldig" in staan, maar niet noodzakelijkerwijs in hetzelfde bericht. Dit zou op te lossen zijn met een NEAR operator of "MESS:"(message).

Soms vraag ik me af of UserX wel eens iets heeft gezegd over nietmachines. Dat kan ik wel invullen bij de search, maar ook dan krijg je bergen ruis van topics waar UserX in gepost heeft, maar iemand anders iets over nietmachines zei.

Het is verwarrend (en overbodig) dat je zowel operators kan gebruiken (AND, OR) én dat er ook nog een dropdown list onder het zoekvak staat (Welke trefwoorden:) waar je hetzelfde kunt opgeven. Het lijkt me veel handiger dat de standaardmethode gewoon "AND" is en dat je dit kunt aanpassen door er OR tussen te zetten waar je dat wilt.

Een aparte advanced search waar je regex kunt gebruiken zou natuurlijk nog beter zijn.

[Tukk]

Atomsk schreef op donderdag 26 maart 2009 @ 13:36:
Wat andere kritiekpunten:

Het is niet mogelijk om op meerdere zoektermen te zoeken binnen berichten ipv binnen topics (behalve de start post met de "START:" operator). Wanneer ik nu zoek naar "gforce and geweldig" krijg ik tig topics waar ergens de woorden "gforce" en "geweldig" in staan, maar niet noodzakelijkerwijs in hetzelfde bericht. Dit zou op te lossen zijn met een NEAR operator of "MESS:"(message).

Soms vraag ik me af of UserX wel eens iets heeft gezegd over nietmachines. Dat kan ik wel invullen bij de search, maar ook dan krijg je bergen ruis van topics waar UserX in gepost heeft, maar iemand anders iets over nietmachines zei.

Het is verwarrend (en overbodig) dat je zowel operators kan gebruiken (AND, OR) én dat er ook nog een dropdown list onder het zoekvak staat (Welke trefwoorden:) waar je hetzelfde kunt opgeven. Het lijkt me veel handiger dat de standaardmethode gewoon "AND" is en dat je dit kunt aanpassen door er OR tussen te zetten waar je dat wilt.

Een aparte advanced search waar je regex kunt gebruiken zou natuurlijk nog beter zijn.

Qft!

Wat ik mis zijn berichten als resultaten. Ik wil zoeken in berichten, niet in threads, ik wil dan ook alleen de berichten die voldoen aan mijn zoektocht als resultaat terug krijgen. Dit lijkt op wat Atomsk vraagt.

* Tukk vraagt zich af waarom de search al die jaren niet op de schop is gegaan. Topics als dit zie ik al meer dan 5 jaar voorbij komen.

[ Voor 4% gewijzigd door Tukk op 26-03-2009 13:46 ]

[Verwijderd]

Jejking schreef op donderdag 26 maart 2009 @ 12:30:
Ja, maar definieer het woord ''zinvol'' dan eens. Wat de een zoekt, is niet hetzelfde als dat van de ander.

Zal wel een paar weken of maanden duren voordat een dergelijk systeem redelijke resultaten heeft/geeft. Maar als een massa een bepaald topic interessant genoeg vind om op te klikken ongeacht de zoekopdracht lijkt mij dat het topic meer waarde heeft dan 1 waar niet zoveel op is geklikt en lager in de resultaten komt te staan. Dat is het idee erachter.

[DennusB]

Tukk schreef op donderdag 26 maart 2009 @ 13:45:
[...]

* Tukk vraagt zich af waarom de search al die jaren niet op de schop is gegaan. Topics als dit zie ik al meer dan 5 jaar voorbij komen.

Het zal wel gewoon veel tijd kosten dat helemaal om te gooien...
Toch hoop ik dat ze er snel iets aan gaan doen.

Elk modje wordt boos als je niet goed 'zoekt' op GoT, maarja, je kan hier ook bijna niet goed zoeken op deze manier

[Hooglander1]

Voorbeeldje van waar het mijns inziens wel eens raar gaat

http://gathering.tweakers...earchtimeout]=30#hitstart]

ff selecteren en kopieren dus.

2e hit wil je eigenlijk niet hebben, maar die komt altijd bovenaan opduiken. Terwijl je eigenlijk de 10e hit wil hebben.

[ Voor 6% gewijzigd door Hooglander1 op 26-03-2009 16:58 ]

[Jejking]

Verwijderd schreef op donderdag 26 maart 2009 @ 16:51:
[...]

Zal wel een paar weken of maanden duren voordat een dergelijk systeem redelijke resultaten heeft/geeft. Maar als een massa een bepaald topic interessant genoeg vind om op te klikken ongeacht de zoekopdracht lijkt mij dat het topic meer waarde heeft dan 1 waar niet zoveel op is geklikt en lager in de resultaten komt te staan. Dat is het idee erachter.

Ah... de altijd mooie Wet van de Grote Aantallen. Als je er een nieuwe search tegenaan gooit zou het kunnen werken, maar niet op deze manier in ieder geval.

[ACM]

Atomsk schreef op donderdag 26 maart 2009 @ 13:36:
Wat andere kritiekpunten:

Het is niet mogelijk om op meerdere zoektermen te zoeken binnen berichten ipv binnen topics (behalve de start post met de "START:" operator). Wanneer ik nu zoek naar "gforce and geweldig" krijg ik tig topics waar ergens de woorden "gforce" en "geweldig" in staan, maar niet noodzakelijkerwijs in hetzelfde bericht. Dit zou op te lossen zijn met een NEAR operator of "MESS:"(message).

Near is er. Dat kan je gebruiken met gforce NEAR geweldig en dan mag gforce niet meer dan 10 woorden van geweldig af staan. Je kan dat aanpassen naar NEAR/6 om er 6 woorden van te maken, wat de max is weet ik eigenlijk niet.
Helaas zorgt het opvragen van de positionele data ervoor dat het allemaal een stuk langer duurt.

Soms vraag ik me af of UserX wel eens iets heeft gezegd over nietmachines. Dat kan ik wel invullen bij de search, maar ook dan krijg je bergen ruis van topics waar UserX in gepost heeft, maar iemand anders iets over nietmachines zei.

Daarvoor zullen de losse berichten geindexeerd moeten worden. Onze huidige zoekomgeving ondersteund geen dubbellaags structuur (topics die losse berichten bevatten) en van de korte blikken die ik op andere omgevingen heb geworpen kreeg ik niet de indruk dat zoiets gebruikelijk is om te ondersteunen.

Wel overweeg ik om nadat we een nieuwe server hiervoor hebben aangeschaft (8GB ram is ondertussen veel te weinig voor deze database) om daar een tweede database naast te gaan draaien, met berichten los geindexeerd. Dan kan je dus kiezen of je in hele topics, of slechts in losse berichten wilt zoeken.

We gaan wat mij betreft niet de boel omgooien om alleen de losse berichten om te gooien. De berichten-only optie biedt m.i. niet alleen voordelen

Het is verwarrend (en overbodig) dat je zowel operators kan gebruiken (AND, OR) én dat er ook nog een dropdown list onder het zoekvak staat (Welke trefwoorden:) waar je hetzelfde kunt opgeven. Het lijkt me veel handiger dat de standaardmethode gewoon "AND" is en dat je dit kunt aanpassen door er OR tussen te zetten waar je dat wilt.

Dat is de standaard operator. Aangezien vrijwel niemand de moeite neemt om zelf met AND's en OR's te strooien denk ik niet dat het verstandig is die te verwijderen. Overigens is het wel zo dat resultaten die aan meer van de opgegeven termen voldoen over het algemeen ook een hogere relevantie hebben. Dus de topresultaten bij OR en AND zouden redelijk hetzelfde moeten zijn.

Een aparte advanced search waar je regex kunt gebruiken zou natuurlijk nog beter zijn.

Mja, maar dat wordt dan door heel weinig mensen gebruikt, dus dat is al gauw zonde van de moeite

Tukk schreef op donderdag 26 maart 2009 @ 13:45:
Wat ik mis zijn berichten als resultaten. Ik wil zoeken in berichten, niet in threads, ik wil dan ook alleen de berichten die voldoen aan mijn zoektocht als resultaat terug krijgen. Dit lijkt op wat Atomsk vraagt.

Weet je zeker dat je altijd in losse berichten wilt zoeken? Dat lijkt me namelijk sterk.

Het splitsen naar berichten zorgt er bijvoorbeeld voor dat topics die over een bepaald onderwerp gaan ineens niet per se meer bovenaan komen te staan in de resultaten, omdat het topic als geheel wel heel goed zou hebben gescoord, maar de individuele reacties niet. Ik kan me wel voorstellen dat je af en toe op berichtniveau wilt zoeken, zoals met de voorbeelden van Atomsk.

* Tukk vraagt zich af waarom de search al die jaren niet op de schop is gegaan. Topics als dit zie ik al meer dan 5 jaar voorbij komen.

Ik heb ze ook geregeld gezien. En op de schop gooien is gewoon niet haalbaar. Er zijn nauwelijks alternatieve methoden, zeker niet die enigszins betaalbaar in te zetten zijn. En voor zover ik weet zijn er maar weinig verbeteringsideeen aangedragen die geen keerzijde hebben of verschrikkelijk lastig te implementeren zijn.
Daarbij zitten we met een zoekdatabase van 26GB die minstens een halve dag kost om opnieuw te genereren op een vlotte idle server (en we hebben geen idle servers in ons rack ). Daardoor is vooral de impact van een wijziging op de kwaliteit van de zoekresultaten niet "even" te testen.

[ACM]

Hooglander1 schreef op donderdag 26 maart 2009 @ 16:57:
Voorbeeldje van waar het mijns inziens wel eens raar gaat

Ik kan hem wel verklaren, hoewel ik met je eens ben dat dat 10e topic idd beter is. Het komt o.a. doordat bij het 2-berichts topic er letterlijk "tue" in de titel staat, en woorden in titels (en topicstart) wegen zwaarder. Bovendien is dat een vrij kort topic, waardoor de relatieve dichtheid van de woorden tue, laptop en 2005 er een stuk beter in zit.

Verwijderd schreef op donderdag 26 maart 2009 @ 16:51:
Zal wel een paar weken of maanden duren voordat een dergelijk systeem redelijke resultaten heeft/geeft. Maar als een massa een bepaald topic interessant genoeg vind om op te klikken ongeacht de zoekopdracht lijkt mij dat het topic meer waarde heeft dan 1 waar niet zoveel op is geklikt en lager in de resultaten komt te staan. Dat is het idee erachter.

Dan is een algemeen rating-systeem voor topics wellicht nuttiger. Maar het blijft lastig om relevantie voor een specifieke zoekopdracht met een algemene interesse te combineren. Afgezien daarvan heeft ons zoeksysteem geen mogelijkheden tot verwerking van dergelijke zoekkwaliteit/resultaatfeedback. Dat is een van die dingen die ons heel veel tijd en/of geld zal kosten om te bouwen...

Verwijderd schreef op donderdag 26 maart 2009 @ 12:06:
Of ouderdom gaan gebruiken als vermenigvuldigingsfactor voor relevante?

De ouderdom zou ik inderdaad graag mee kunnen wegen, maar helaas biedt omega/xapian daar in de stabiele versie geen ondersteuning voor. Gelukkig is het wel in ontwikkeling, maar of dat betekent dat wij het ook nog dit jaar in kunnen zetten weet ik niet.

[Tukk]

ACM schreef op donderdag 26 maart 2009 @ 17:03:

Weet je zeker dat je altijd in losse berichten wilt zoeken? Dat lijkt me namelijk sterk.

Nee, natuurlijk wil ik de keuze tussen thread of post kunnen hebben

Het splitsen naar berichten zorgt er bijvoorbeeld voor dat topics die over een bepaald onderwerp gaan ineens niet per se meer bovenaan komen te staan in de resultaten, omdat het topic als geheel wel heel goed zou hebben gescoord, maar de individuele reacties niet. Ik kan me wel voorstellen dat je af en toe op berichtniveau wilt zoeken, zoals met de voorbeelden van Atomsk.

Second that

[...]

Ik heb ze ook geregeld gezien. En op de schop gooien is gewoon niet haalbaar. Er zijn nauwelijks alternatieve methoden, zeker niet die enigszins betaalbaar in te zetten zijn. En voor zover ik weet zijn er maar weinig verbeteringsideeen aangedragen die geen keerzijde hebben of verschrikkelijk lastig te implementeren zijn.
Daarbij zitten we met een zoekdatabase van 26GB die minstens een halve dag kost om opnieuw te genereren op een vlotte idle server (en we hebben geen idle servers in ons rack ). Daardoor is vooral de impact van een wijziging op de kwaliteit van de zoekresultaten niet "even" te testen.

Mogelijk ben ik een verwende gebruiker door google, ms-search en dergelijke, maar ook simpelere/goedkopere zoekmachines als vinden.nl zoeken door grotere aantallen data en komen snel met antwoorden. Correct me if I'm wrong, maar 26Gb ia tch niet zo heel veel?
( ik weet het wel, vele gebruikers/zoekers * 26Gb is wel heel veel)...

[Atomsk]

ACM schreef op donderdag 26 maart 2009 @ 17:03:
[...]

Near is er. Dat kan je gebruiken met gforce NEAR geweldig en dan mag gforce niet meer dan 10 woorden van geweldig af staan. Je kan dat aanpassen naar NEAR/6 om er 6 woorden van te maken, wat de max is weet ik eigenlijk niet.
Helaas zorgt het opvragen van de positionele data ervoor dat het allemaal een stuk langer duurt.

Ja, ik zie het nu ook, staat wat verstop in de manual. Knopjes ernaast dan om "NEAR" en XOR in te voegen zou het dan wel compleet maken.

[...]

Dat is de standaard operator. Aangezien vrijwel niemand de moeite neemt om zelf met AND's en OR's te strooien denk ik niet dat het verstandig is die te verwijderen, wel zou een default op AND nuttig kunnen zijn omdat men doorgaans bewust meerdere termen in tikt en men dat ondertussen ook bij Google en de anderen gewend is. Overigens is het wel zo dat resultaten die aan meer van de opgegeven termen voldoen over het algemeen ook een hogere relevantie hebben. Dus de topresultaten bij OR en AND zouden redelijk hetzelfde moeten zijn.

Google geeft meer relevantie aan resultaten waarbij de zoektermen dichter bij elkaar staan, maar dat zal wel een te zware belasting geven voor deze database.

Opzich kan het uitklaplijstje in het zoekscherm wel blijven, maar dan zou er ook een optie "exacte woordcombinatie" bijmoeten IMO. Dit is een vrij standaard zoekoptie. Verder zou ik er "Zoeken op" voorzetten ipv "welke trefwoorden". Ik blijf het echter toch wat verwarrend vinden omdat er zo tegelijktijd een geavanceerde en simpele search wordt geboden, waarbij niet meteen duidelijk is wat er dominant is: de operatoren of het uitklapmenu.

Meerdere invulvelden zoals bij http://www.google.nl/advanced_search? zou ook nog kunnen.

[Palomar]

Ik vind de zoekfunctie op zich wel goed werken. Alleen heb ik meestal totaal geen behoefte aan oude topics en standaard zoek ik dan ook in een tijdsperiode van 500 tot 0 dagen geleden oid. Dan krijg ik meestal gewoon iets waar ik wat aan heb. Als ik dit niet doe krijg ik meestal topics uit 2002 e.d. bovenin en daar heb je in 90% van de gevallen niks aan omdat info van een paar jaar oud in de ICT-wereld gewoon ontzettend achterhaald is. Kan iig weinig nuttige doeleinden bedenken, behalve als je specifiek op zoek bent naar hulp over windows 95 of Quake 3. Oude resultaten zijn zelfs 'gevaarlijk', omdat je misschien tips gaat opvolgen over een probleem (bug oid) dat al lang gefixt is en je met zo'n tip alleen maar schade aanricht.

Misschien dat dit ook standaard wel ingesteld kan worden en dan een knop naast de resultaten met 'toon oudere topics'.

[edit] lees dat dit al een keer aangekaart is in dit topic

[ Voor 24% gewijzigd door Palomar op 26-03-2009 18:04 ]

[ACM]

Tukk schreef op donderdag 26 maart 2009 @ 17:25:
Mogelijk ben ik een verwende gebruiker door google, ms-search en dergelijke, maar ook simpelere/goedkopere zoekmachines als vinden.nl zoeken door grotere aantallen data en komen snel met antwoorden.

Vinden.nl is dan ook een "metazoekmachine" die weer de zoekresultaten van Google en diverse anderen opzoeken. Dus als die achterliggende zoekmachines snel zijn (en dat zijn ze), dan is vinden.nl ook snel

Correct me if I'm wrong, maar 26Gb ia tch niet zo heel veel?
( ik weet het wel, vele gebruikers/zoekers * 26Gb is wel heel veel)...

Voor een zoekmachine voor een enkele site is het vrij veel hoor En het gaat inderdaad om het toegangspatroon. Maar het is hoedanook genoeg data om er niet zomaar "even iets" in te kunnen wijzigen of "even" een kopietje van te maken. En als we dus de berichten apart indexeren komt er nog eens minstens 26GB bij.

Atomsk schreef op donderdag 26 maart 2009 @ 17:51:
Ja, ik zie het nu ook, staat wat verstop in de manual. Knopjes ernaast dan om "NEAR" en XOR in te voegen zou het dan wel compleet maken.

Ook voor die knopjes geldt natuurlijk dat "men" ze niet zoveel zal gebruiken en het toevoegen daarvan dus eerder meer dan minder verwarring teweeg brengt.

Opzich kan het uitklaplijstje in het zoekscherm wel blijven, maar dan zou er ook een optie "exacte woordcombinatie" bijmoeten IMO. Dit is een vrij standaard zoekoptie. Verder zou ik er "Zoeken op" voorzetten ipv "welke trefwoorden".

Ik heb er in de testomgeving "Zoeken op" van gemaakt. Een "Exacte woordcombinatie"-optie is voor ons niet echt handig met zo'n default operator te verwerken, dus dat laat ik weg, dat moet je dan maar alsnog bereiken met de " of '.

Ik blijf het echter toch wat verwarrend vinden omdat er zo tegelijktijd een geavanceerde en simpele search wordt geboden, waarbij niet meteen duidelijk is wat er dominant is: de operatoren of het uitklapmenu.

Deze opmerking snap ik niet?

Meerdere invulvelden zoals bij http://www.google.nl/advanced_search? zou ook nog kunnen.

Die vind ik toch ook niet heel erg duidelijk. We hebben juist expres de boel zonder refresh in een formulier zitten, maar verbergen wel de meeste ongebruikte opties onder een enkele muisklik.

[ACM]

Voor de liefhebbers heb ik er nu dit alvast van gemaakt:


Belangrijkste verandering dus de mogelijkheid om een topicstartjaar te kiezen (en de laatste vier jaar standaard geselecteerd) en de mogelijkheid om naast topicstartdatum ook op de datum van de laatste reactie te filteren (en een datum op te geven ipv een aantal dagen). Die twee opties overlappen uiteraard wel wat, dus misschien dat het nog iets anders aangepakt moet worden. Maar ik ga liever niet met allemaal extra datumvelden knoeien in het simpele deel, terwijl ik wel graag wil aangeven dat het datumbereik beperkt is...

[ Voor 6% gewijzigd door ACM op 26-03-2009 20:59 ]

[Kixtart]

En bij de quicksearch is het dan ook standaard de laatste 4 jaar? Zit er wel handig uit in elk geval

[Palomar]

ACM schreef op donderdag 26 maart 2009 @ 20:58:
Voor de liefhebbers heb ik er nu dit alvast van gemaakt:
[afbeelding]

Belangrijkste verandering dus de mogelijkheid om een topicstartjaar te kiezen (en de laatste vier jaar standaard geselecteerd) en de mogelijkheid om naast topicstartdatum ook op de datum van de laatste reactie te filteren (en een datum op te geven ipv een aantal dagen). Die twee opties overlappen uiteraard wel wat, dus misschien dat het nog iets anders aangepakt moet worden. Maar ik ga liever niet met allemaal extra datumvelden knoeien in het simpele deel, terwijl ik wel graag wil aangeven dat het datumbereik beperkt is...

Ziet er goed uit Misschien dat 2 datumkeuzes ook wel voldoen. Standaard alleen laatste 4 jaar en als optie kun je kiezen om in alle jaren te zoeken.

Denk nl. dat weinig mensen specifiek op 1 jaar gaan zoeken. Alleen het onderscheid oud-nieuw is belangrijk.

[Verwijderd]

De search is inderdaad super brak in mijn ervaring. Waar ik me ook nog steeds aan erger is dat je na een zoekactie niet kunt sorteren op de kolommen. Dus: Frm Topic Topicstarter Replies Laatste post zijn niet aan te klikken om daar op te sorteren NA de zoekactie. Maar daar zal helaas wel weer geen devtijd voor zijn.

Ook onhandig is dat je niet direct doorgelinked kan worden naar de post waar die woorden in voorkomen, zoeken op wow paladin update in de search bijv krijg je 100 grote WoW-topics die je daarna NOG een keer mag gaan lopen doorzoeken.

Ik wil zowel op postniveau als op topicniveau die woorden kunnen doorzoeken.
En als ik op postniveau zoek, direct naar die betreffende post waar die woorden in voorkomen een link hebben.

[ Voor 42% gewijzigd door Verwijderd op 26-03-2009 23:12 ]

[André]

Misschien moet Tweakers.net eens naar de GSA kijken. Ik heb even lopen spelen met een CSE, maar dat biedt weinig extra's boven het site: commando in Google.

Nadeel van de GSA is dat hij aardig aan de prijs is. Voordeel is dat je Google algoritmes op je database aan kunt sluiten.

[ Voor 4% gewijzigd door André op 26-03-2009 23:08 ]

[crisp]

Verwijderd schreef op donderdag 26 maart 2009 @ 23:01:
[...]Waar ik me ook nog steeds aan erger is dat je na een zoekactie niet kunt sorteren op de kolommen. Dus: Frm Topic Topicstarter Replies Laatste post zijn niet aan te klikken om daar op te sorteren NA de zoekactie.

Het is imo ook weinig zinnig om resultaten te sorteren op forum, topictitel of topicstarter. De eerste en derde zijn ook typische filters en geen sorteringen. Op laatste post kunnen sorteren is dan wel weer nuttig als je eerste search op datum topicstart was. Ik weet niet of aantal replies ueberhaupt een sorteringsoptie zou kunnen zijn; volgens mij slaan we dat niet op in de search-db.

Maar daar zal helaas wel weer geen devtijd voor zijn.

Tsja, tijd is sowieso altijd schaars dus moeten we altijd prioriteiten stellen, en onze prioriteiten hoeven natuurlijk niet de jouwe te zijn...

Ook onhandig is dat je niet direct doorgelinked kan worden naar de post waar die woorden in voorkomen, zoeken op wow paladin update in de search bijv krijg je 100 grote WoW-topics die je daarna NOG een keer mag gaan lopen doorzoeken.

Klikken op het linkje "Alleen berichten met trefwoorden tonen" onder het resultaat van het betreffende topic?

[Verwijderd]

crisp schreef op donderdag 26 maart 2009 @ 23:18:
[...]

Het is imo ook weinig zinnig om resultaten te sorteren op forum, topictitel of topicstarter. De eerste en derde zijn ook typische filters en geen sorteringen. Op laatste post kunnen sorteren is dan wel weer nuttig als je eerste search op datum topicstart was. Ik weet niet of aantal replies ueberhaupt een sorteringsoptie zou kunnen zijn; volgens mij slaan we dat niet op in de search-db.

Ja, maar ik vind het wel handig dat ik dan niet opnieuw een query/filter hoef in te voeren. Zoals op het aantal replies als mn eerste standaard search een andere was.

Klikken op het linkje "Alleen berichten met trefwoorden tonen" onder het resultaat van het betreffende topic?

super nooit opgevallen

Maar als ik zeg maar op 3 woorden zoek en al het andere default, zoekt hij dan ook of die 3 woorden in het topic voorkomen of zoekt hij direct enkel op de posts waar die drie woorden in voorkomen? Stel ik zoek bijvoorbeeld op android update software. En 1 post bevat: Er is weer nieuwe Android software uit! En post 2 bevat: Ja de update v2 was al bekend (bijv). Vind ik het topic dan ook standaard ook al bevat geen enkele post die 3 woorden maar die 3 staan wel in het topic...?

[ Voor 22% gewijzigd door Verwijderd op 26-03-2009 23:36 ]

[Atomsk]

ACM schreef op donderdag 26 maart 2009 @ 20:49:

Deze opmerking snap ik niet?

Ik bedoel dat het in tegenstrijdig is wanneer je bijv "groen OR rood" invult, terwijl de uitklaplijst op "alle trefwoorden" staat. De aanwezigheid van een operator gaat blijkbaar boven de uitklaplijst, maar helemaal intuïtief lijkt het me ook niet.

[...]

Die vind ik toch ook niet heel erg duidelijk. We hebben juist expres de boel zonder refresh in een formulier zitten, maar verbergen wel de meeste ongebruikte opties onder een enkele muisklik.

Mja, ik zie momenteel ook niet ff wat beters.

[ Voor 3% gewijzigd door Atomsk op 27-03-2009 00:27 ]

[ACM]

André schreef op donderdag 26 maart 2009 @ 23:06:
Nadeel van de GSA is dat hij aardig aan de prijs is. Voordeel is dat je Google algoritmes op je database aan kunt sluiten.

We zitten nu als we op topicbasis blijven op 1.3M documenten, dus dat is dan een stuk boven de 10k euro (dat is waar de GSA mini stopt met 300k documenten) en ik vermoed dat we daar niet zomaar een budget voor vinden. Als we op messagebasis willen kunnen indexeren, dan wordt het nog erger, want dan zitten we op 24M "documenten" en dan wil google blijkbaar dat je een compleet rack volgooit met die GSA's
Dat is ook gelijk het nadeel met zo'n beetje alle betaalde zoekmachines, je betaald doorgaans per hoeveelheid documenten en een miljoen documenten is doorgaans niet erg goedkoop...

Een ander probleem met GSA waar ik zo snel niet een oplossing voor zie is dat we niet willen dat gebruikers in elk forum kunnen zoeken, maar vaak is het niet erg duidelijk of dat uberhaupt op te bouwen is. Vooralsnog heb ik de indruk dat we qua algoritme er dan wellicht op vooruit gaan, maar qua flexibiliteit op inleveren.

[ACM]

Het filteren op jaarbasis (standaard 2006 t/m 2009) en de mogelijkheid om te filteren op laatste reactietijd ipv uitsluitend de topicstart zitten nu in de zoekmachine.

[Dancing_Animal]

Bij mij doet de search het, in ieder geval sinds gister, helemaal niet meer

[Palomar]

ACM schreef op zondag 29 maart 2009 @ 11:08:
Het filteren op jaarbasis (standaard 2006 t/m 2009) en de mogelijkheid om te filteren op laatste reactietijd ipv uitsluitend de topicstart zitten nu in de zoekmachine.

Ah stuk beter zo

Misschien nog een ideetje om het veld 'Zoek in tijdsperiode' de ingestelde 'Topic gestart in:' te laten overrulen. Je krijgt nu nl. geen resultaten als je zoekt op topics tussen bijv. 2001 en 2003. Moet je eerst handmatig die vinkjes bovenin aanzetten.

[ACM]

Palomar schreef op zondag 29 maart 2009 @ 11:56:
Misschien nog een ideetje om het veld 'Zoek in tijdsperiode' de ingestelde 'Topic gestart in:' te laten overrulen. Je krijgt nu nl. geen resultaten als je zoekt op topics tussen bijv. 2001 en 2003. Moet je eerst handmatig die vinkjes bovenin aanzetten.

Dat is nog wel een aardige optie idd.

[ACM]

Dancing_Animal schreef op zondag 29 maart 2009 @ 11:11:
Bij mij doet de search het, in ieder geval sinds gister, helemaal niet meer

Met wat voor zoekopdracht test je dat?

[bombadil]

Het mooiste vind ik altijd als je allemaal topics krijgt die snel gesloten zijn met een verwijzing om "de search te gebruiken". Eigenlijk zouden die helemaal niet meer omhoog moeten komen. Kan daar bij het slotje niet een "niet indexeren"tag bij oid?

[ACM]

bombadil schreef op zondag 29 maart 2009 @ 12:33:
Het mooiste vind ik altijd als je allemaal topics krijgt die snel gesloten zijn met een verwijzing om "de search te gebruiken". Eigenlijk zouden die helemaal niet meer omhoog moeten komen. Kan daar bij het slotje niet een "niet indexeren"tag bij oid?

Daar is sowieso de "snel gesloten topics ook tonen" voor bedoeld (wat standaard uit staat), dat is een vlag dat als een topic binnen 4 uur gesloten werd dat ie dan niet getoond wordt. De grens van 4 uur is een beetje arbitrair gekozen, maar er waren niet heel veel meer topics die bijvoorbeeld niet in 4, maar wel in 8 uur gesloten waren.

Verder geven mods en gebruikers geregeld tips voor andere zoektermen in dergelijke topics. Als je die niet zelf bedacht had kan het zelfs nuttig zijn om zo'n verwijzing te vinden.

[Dancing_Animal]

ACM schreef op zondag 29 maart 2009 @ 12:26:
[...]

Met wat voor zoekopdracht test je dat?

Ik deed dat met gta ds en dan verder niks selecteren. Nu doet ie het wel weer. Tres strangé.

[PowerFlower]

Sorry voor de kick, maar probeer net iets te vinden op GoT en erger me rot aan de zoekfunctie... Ik weet er ook wel "iets" van af (ik heb dit geschreven ) dus ga dan meteen zitten bedenken hoe het wél kan. Iig,

ACM schreef op vrijdag 27 maart 2009 @ 08:09:
Dat is ook gelijk het nadeel met zo'n beetje alle betaalde zoekmachines, je betaald doorgaans per hoeveelheid documenten en een miljoen documenten is doorgaans niet erg goedkoop...

Dat klopt, maar er zijn een stuk goedkopere alternatieven, en ik denk dat Apache Solr (op basis van Lucene) een stuk nuttiger zou zijn dan een GSA voor deze site. Omega heb ik nooit echt serieus bekeken als engine, te beperkt...

Een ander probleem met GSA waar ik zo snel niet een oplossing voor zie is dat we niet willen dat gebruikers in elk forum kunnen zoeken, maar vaak is het niet erg duidelijk of dat uberhaupt op te bouwen is. Vooralsnog heb ik de indruk dat we qua algoritme er dan wellicht op vooruit gaan, maar qua flexibiliteit op inleveren.

Dat is idd één van de vele redenen dat een GSA hier niet geschikt zou zijn. (Hoewel het zeker wel te doen is, maar dat kost meer moeite dan het waard is).

Overigens is een bekend misverstand dat de algoritmes van Google zo goed zijn dat je die ook voor sitesearch zou willen hebben. Een simpel voorbeeld: hoe goed werkt Google's fameuze PageRanking binnen GoT? Dat is gebaseerd op een soort "wisdom of crowds", m.a.w. waar iedereen naar linkt, moet wel de meest relevante pagina zijn. Da's leuk voor het web als geheel, maar binnen GoT heb je aan zo'n algoritme natuurlijk helemaal nix

Qua interface zouden jullie eens moeten kijken naar de "facetted search" die inmiddels in enterprise search gemeengoed geworden is. (In Nederland zeg ik dan altijd: kijk eens naar hoe je op Funda je criteria bijelkaar kunt klikken als voorbeeld). Er is genoeg metadata (poster, topic, datum, etc.) om daar hele zinnige dingen mee te kunnen doen.

Qua onderliggende techniek ligt het voor de hand het te zoeken in iets dat goed aansluit bij jullie dev omgeving. "Iets dat goed aansluit" is voor mij vanaf de zijlijn wat moeilijk te zeggen, maar als random voorbeeld, Thunderstone is gewoon in een soort SQL aan te spreken. Ander voorbeeld is dan weer Solr, waarbij je zelf redelijk wat moet klussen, maar dan wordt het wel precies zoals je het wil. (Of gebruik desnoods het al weer wat meer kant-en-klaar en in een PHP omgeving geïntegreerde eZ Find). Etc...

[ACM]

PowerFlower schreef op donderdag 30 april 2009 @ 19:03:
Dat klopt, maar er zijn een stuk goedkopere alternatieven, en ik denk dat Apache Solr (op basis van Lucene) een stuk nuttiger zou zijn dan een GSA voor deze site. Omega heb ik nooit echt serieus bekeken als engine, te beperkt...

Wat ik tot nu toe op de xapian mailinglist zie zodra Xapian met Lucene wordt vergeleken, is dat het daadwerkelijk zoeken in Xapian/Omega sneller en beter relevante resultaten oplevert. Solr biedt op zich een interessante extra laag om Lucene, maar is in de basis natuurlijk niet zo heel veel meer dan Lucene.

Qua interface zouden jullie eens moeten kijken naar de "facetted search" die inmiddels in enterprise search gemeengoed geworden is. (In Nederland zeg ik dan altijd: kijk eens naar hoe je op Funda je criteria bijelkaar kunt klikken als voorbeeld). Er is genoeg metadata (poster, topic, datum, etc.) om daar hele zinnige dingen mee te kunnen doen.

Wat die enteprises tegelijk ook gemeen hebben is dat ze gestructureerde data hebben, zeker je Funda-voorbeeld is natuurlijk sterk gestructureerd. Op de "genoeg metadata" die jij noemt kan je al lang zoeken/filteren, het enige wat je niet krijgt is een overzicht van de populairste versies van elke variant en hoeveel resultaten daar onder vallen.
Maar eerlijk gezegd betwijfel ik of het wel zo zinnig is om specifiek voor die zaken erg veel moeite te doen. Dan heb ik liever (automatische) clustering van documenten zodat de boel samengepakt kan worden en je eenvoudig groepen van vergelijkbare documenten kan krijgen.

Qua onderliggende techniek ligt het voor de hand het te zoeken in iets dat goed aansluit bij jullie dev omgeving. "Iets dat goed aansluit" is voor mij vanaf de zijlijn wat moeilijk te zeggen, maar als random voorbeeld, Thunderstone is gewoon in een soort SQL aan te spreken. Ander voorbeeld is dan weer Solr, waarbij je zelf redelijk wat moet klussen, maar dan wordt het wel precies zoals je het wil. (Of gebruik desnoods het al weer wat meer kant-en-klaar en in een PHP omgeving geïntegreerde eZ Find). Etc...

Ik zie niet echt een reden heel veel tijd te steken in een omgeving die in de basis hetzelfde werkt als we nu al hebben en waardoor de structurele problemen dus eigenlijk helemaal niet opgelost worden. Tenzij het duidelijk grote voordelen biedt, Thunderstone's Texis heeft bijvoorbeeld als nadeel dat het niet bepaald gratis is.
Als ik dat verkeerd zie hoor ik het natuurlijk graag.

[Puch-Maxi]

Ik moet ook bekennen dat ik af en toe gewoon google gebruik om GOT te doorzoeken

[PowerFlower]

ACM schreef op vrijdag 01 mei 2009 @ 09:50:
Wat ik tot nu toe op de xapian mailinglist zie zodra Xapian met Lucene wordt vergeleken, is dat het daadwerkelijk zoeken in Xapian/Omega sneller en beter relevante resultaten oplevert. Solr biedt op zich een interessante extra laag om Lucene, maar is in de basis natuurlijk niet zo heel veel meer dan Lucene.

Ik ga me komende maand nog maar eens in Xapian/Omega verdiepen dan, de meeste mensen die ik ken zijn er niet echt weg van maar ik wil altijd van de hoed en de rand weten

Wat die enteprises tegelijk ook gemeen hebben is dat ze gestructureerde data hebben, zeker je Funda-voorbeeld is natuurlijk sterk gestructureerd. Op de "genoeg metadata" die jij noemt kan je al lang zoeken/filteren, het enige wat je niet krijgt is een overzicht van de populairste versies van elke variant en hoeveel resultaten daar onder vallen.

Het gaat ook meer om de interface dan hoe je dat voorelkaar krijgt - de reden dat dat goed werkt is voornamelijk dat je makkelijk verfijningen aan kunt klikken (en dat je te zien krijgt hoeveel resultaten je dan nog overhoudt). Het is een vrij intuitieve manier om een query samen te stellen, een query die de meeste gebruikers niet zelfstandig in een of andere syntax voorelkaar zouden krijgen.

Maar eerlijk gezegd betwijfel ik of het wel zo zinnig is om specifiek voor die zaken erg veel moeite te doen. Dan heb ik liever (automatische) clustering van documenten zodat de boel samengepakt kan worden en je eenvoudig groepen van vergelijkbare documenten kan krijgen.

Daar heb ik nog geen goed werkende open source voorbeelden van gezien, dus dan zit je al vrij snel vast aan een commercieel systeem.

Ik zie niet echt een reden heel veel tijd te steken in een omgeving die in de basis hetzelfde werkt als we nu al hebben en waardoor de structurele problemen dus eigenlijk helemaal niet opgelost worden.

Ik denk dat de grootste slag die je kunt maken hem in de interface zit. En dat zou dus ook al bovenop Omega kunnen, als jullie daar beter mee uit de voeten kunnen.

Tenzij het duidelijk grote voordelen biedt, Thunderstone's Texis heeft bijvoorbeeld als nadeel dat het niet bepaald gratis is.
Als ik dat verkeerd zie hoor ik het natuurlijk graag.

Thunderstone's Webinator (gebaseerd op Texis) varieert van $700 - $5800 dus is niet echt heel erg duur. Dat is dan wel voor max 200,000 docs, maar geeft een indicatie. Bovendien denk ik dat er makkelijk een sponsor deal met ze te sluiten zou zijn

Maar het was maar een voorbeeld. Punt is meer dat er best veel (betaalbare) systemen zijn die specifiek sterk zijn in bepaalde functionaliteit (en die beter en goedkoper zijn dan Google). Het hangt er alleen enorm van af wat je zou willen doen.

"Zelfbouw" op basis van Omega (of Lucene) is vaak verleidelijk, zeker voor een devver (hoe moeilijk kan het zijn?) maar is in de praktijk vaak een nogal tegenvallende klus (omdat het toch best wel lastig is). Het kan dus de moeite zijn bepaalde functionaliteit OTTB te hebben. Dat is ook typisch het voordeel van bijv. Solr boven sec Lucene (er zit al een heleboel in wat misschien niet al te lastig lijkt, maar waar je zo een paar maanden mee aan de slag bent om het zelf te doen).

Voordeel van GoT is dat je geen echt lastige dingen hoeft te doen (het enige punt van zorg is security, maar voor de rest hoef je geen exotische documenttypes te indexeren of connectors voor een vreemde repository te bouwen/aan te schaffen).

Het gaat puur om performance (database off-loading), features (facetted search wordt al snel een CPU hog als je het niet al te handig doet, onzinnig voorbeeld maar als je bedenkt dat je zoiets in SQL zou moeten doen kun je je denk ik wel voorstellen dat een search engine daar ook specifiek goed in moet zijn), en interface. Als je dat allemaal zelf moet doen, is het de moeite niet. Maar er zijn dus alternatieven, alleen is het voor mij vanaf de zijlijn wat lastig te bedenken wat het handigste zou zijn Dus ik laat maar wat ballonnetjes op. (Hope it helps).

* PowerFlower gaat even in Xapian/Omega duiken.

[ACM]

PowerFlower schreef op maandag 04 mei 2009 @ 12:06:
Ik ga me komende maand nog maar eens in Xapian/Omega verdiepen dan, de meeste mensen die ik ken zijn er niet echt weg van maar ik wil altijd van de hoed en de rand weten

Een groot nadeel is dat je moet zoeken naar documentatie en een beginpunt, oftewel hetzelfde manco van veel OS projecten.

Het gaat ook meer om de interface dan hoe je dat voorelkaar krijgt - de reden dat dat goed werkt is voornamelijk dat je makkelijk verfijningen aan kunt klikken (en dat je te zien krijgt hoeveel resultaten je dan nog overhoudt). Het is een vrij intuitieve manier om een query samen te stellen, een query die de meeste gebruikers niet zelfstandig in een of andere syntax voorelkaar zouden krijgen.

Dat snap ik, maar voor het forum wordt het pas echt behulpzaam als je nuttige beperkende criteria krijgt. De meeste mensen die informatie zoeken maakt het niet uit wie het schreef, maar wellicht wel wat voor additionele termen er bij passen.

Daar heb ik nog geen goed werkende open source voorbeelden van gezien, dus dan zit je al vrij snel vast aan een commercieel systeem.

Ik ook niet Als je daar op zoekt krijg je vooral onderzoeksverhalen van mensen die het nauwelijks in de praktijk hebben toegepast of in ieder geval geen bruikbare omgeving hebben achtergelaten.

Ik denk dat de grootste slag die je kunt maken hem in de interface zit. En dat zou dus ook al bovenop Omega kunnen, als jullie daar beter mee uit de voeten kunnen.

Van omega weten we in ieder geval hoe het werkt en dat het de load die wij er op leggen aan kan. Puur als keyword-omgeving werkt het vrij goed, hoewel wat sturing van de relevantie met bijvoorbeeld de leeftijd van een topic nog wel nuttig zou zijn.

Dat is dan wel voor max 200,000 docs, maar geeft een indicatie.

Nouja, als wij alle topics willen indexeren komen we op 1,3 miljoen documenten en zes keer $700 is niet zo veel, maar zes keer $5800 wel... Als we alle reacties los willen nemen zitten we zelfs op dik in de 20 miljoen. De meeste van de commerciele omgevingen worden rap duurder boven een "beperkt" aantal documenten of hebben niet eens een prijsvermelding voor meer dan 1 miljoen en de echt geavanceerde systemen gaan er doorgaans van uit dat je documenten enorm veel waarde hebben en dat je dus zeer diep in de buidel wilt tasten om het doorzoekbaar te maken.

Maar het was maar een voorbeeld. Punt is meer dat er best veel (betaalbare) systemen zijn die specifiek sterk zijn in bepaalde functionaliteit (en die beter en goedkoper zijn dan Google). Het hangt er alleen enorm van af wat je zou willen doen.

Ze moeten dan dus vooral beter zijn in "meer dan een keyword retrieval engine", want dat doet Xapian vziw vrij goed, maar tegelijkertijd wel met dik een miljoen documenten overweg kunnen.

"Zelfbouw" op basis van Omega (of Lucene) is vaak verleidelijk, zeker voor een devver (hoe moeilijk kan het zijn?) maar is in de praktijk vaak een nogal tegenvallende klus (omdat het toch best wel lastig is). Het kan dus de moeite zijn bepaalde functionaliteit OTTB te hebben. Dat is ook typisch het voordeel van bijv. Solr boven sec Lucene (er zit al een heleboel in wat misschien niet al te lastig lijkt, maar waar je zo een paar maanden mee aan de slag bent om het zelf te doen).

Dat ben ik helemaal met je eens. Daarnaast missen we zelf nog wel een stukje document retrieval theorie, waardoor bepaalde zaken sowieso al minder kwaliteit zullen hebben.

Het gaat puur om performance (database off-loading), features (facetted search wordt al snel een CPU hog als je het niet al te handig doet, onzinnig voorbeeld maar als je bedenkt dat je zoiets in SQL zou moeten doen kun je je denk ik wel voorstellen dat een search engine daar ook specifiek goed in moet zijn), en interface. Als je dat allemaal zelf moet doen, is het de moeite niet. Maar er zijn dus alternatieven, alleen is het voor mij vanaf de zijlijn wat lastig te bedenken wat het handigste zou zijn Dus ik laat maar wat ballonnetjes op. (Hope it helps).

De schaalgrootte, het feit dat relevantie bij ons verwatert met de leeftijd en dat er nagenoeg geen structuur in de tekst zit zijn de grootste punten inderdaad. En daarbij inderdaad nog het puntje security, wat we bij Xapian opgelost hebben door boolean-queries op de achtergrond toe te voegen.
Als je gerichter vragen wilt stellen is het waarschijnlijk handiger deze discussie naar e-mail te verhuizen. We zijn altijd benieuwd naar betere oplossingen, maar het moet dan niet alleen een ander systeem worden, vooral ook beter