[mening gevraagd] opzet knowledgebase

[Verwijderd]

Ik zou graag, van de mensen die een interessante mening hebben, willen horen/lezen wat ze vinden van het volgende idee.

Ik wil een knowledgebase maken, daarbij worden documenten, een titel en steekwoorden ingevoerd. M'n datamodel wil ik zo maken dat er een tabel is met de link naar de documenten, de titel en de gebruiker. Verder wil ik een tabel met de ingevoerde steekwoorden en een koppeltabel tussen de steekwoorden en de documententabel.

Ik wil nu dat als er een nieuw document ingevoerd wordt, de volgende handelingen uitgevoerd worden.
- Het document met gegevens invoeren

- Check of er steekwoorden in de tabel steekwoorden aanwezig zijn die lijken op de ingevoerde steekwoorden (met behulp van Lievenhstein's Distance).

- Als de afstand te klein is, een melding geven ("weet je zeker dat dit een nieuw steekwoord is?")

- Als er nieuwe steekwoorden zijn, deze invoeren en in de koppeltabel deze koppelen aan het document. Als er geen nieuwe zijn, deze niet invoeren maar wel koppelen.

Denken jullie dat dit een snelle, nauwkeurige methode zal zijn om in te gaan zoeken? Of is dit datamodel gewoon niet handig. Suggesties zijn welkom!

[EfBe]

Nou ik zou, mocht je de mogelijk hebben, fijn met Index server/ms search gaan werken. Je kunt dan bv je documenten in originele staat op harddisk bewaren en toch full text search met de leuke zaken van dien gebruiken zonder veel werk. Indexeren gaat automatisch en text, word, excel etc documenten worden gewoon geindexeerd. Je kunt direct queries afvuren op indexserver vanuit webpages, en dan de full text search capaciteiten benutten dus bv 'near' gebruiken, rankings etc. Dit alles kost nauwelijks code (1 pagina) en je hebt het zo opgezet, plus het vereist geen onderhoud, en je kunt wanneer je de code klaar hebt meteen beginnen met zoeken, zonder dat mensen eerst alle documenten gaan invoeren.

[xtra]

Dit model kan werken, afhankelijk van de discipline van degenen die de documenten invoeren. Zeker als het een grote groep is waarvoor het geen 'core-business' is heb ik hier slechte ervaringen mee.

Steekwoorden zijn een prima manier om te zoeken. Denk wel aan synoniemen. Als de één het steekwoord 'computer' invult en een ander gebruikt 'pc', dan gaat het mis. Een soort vertaaltabel (die dezelfde kan zijn als je tabel met steekwoorden) kan er voor zorgen dat 'pc' automatisch 'computer' wordt. Een soort aanvulling op je Lievenhstein's Distance dus. (Daar kon ik overigens niets over vinden.)

[Verwijderd]

xtra schreef op 24 April 2003 @ 11:57:
Dit model kan werken, afhankelijk van de discipline van degenen die de documenten invoeren. Zeker als het een grote groep is waarvoor het geen 'core-business' is heb ik hier slechte ervaringen mee.

Het is een groep van ongeveer 4 a 5 systeembeheerders... Groot is de groep dus niet

Steekwoorden zijn een prima manier om te zoeken. Denk wel aan synoniemen. Als de één het steekwoord 'computer' invult en een ander gebruikt 'pc', dan gaat het mis. Een soort vertaaltabel (die dezelfde kan zijn als je tabel met steekwoorden) kan er voor zorgen dat 'pc' automatisch 'computer' wordt. Een soort aanvulling op je Lievenhstein's Distance dus. (Daar kon ik overigens niets over vinden.)

Da's lastig, zijn hier misschien standaard lijsten voor?

[sebas]

Ik weet niet hoeveel knowledge deze 4 a 5 mensen hebben, maar dat moet wel heel veel zijn voordat je echt indices nodig gaat hebben. Tot een paar megabyte grote databases is een Fulltextsearch prima te doen. En van 4 a 5 mensen verwacht je niet zoveel queries dat load echt een probleem gaat worden.

Ik zou sowieso ook voor een al bestaande searchengine gaan. Er komt gewoon een hoop bij kijken, en wat je uiteindelijk doet is het wiel opnieuw uitvinden, waarschijnlijk niet beter maar way tijdsintensiever dan als je gewoon htdig of iets dergelijks pakt en de tijd die je spaart in gebruiksvriendelijkheid stopt. Bij het ontwerp van je database hou je dan rekening met de integratie van een searchengine. (Er was een mooi postgresql search engine, maar ik ben de naam even kwijt.)

Het invoeren van steekwoorden is zeker nuttig, maar het vergt inderdaad een hoop discipline om het goed in te voeren. En met jouw oplossing is een supermooi document waarvan gewoon de keywords niet kloppen of laks zijn gekozen gewoon verloren in de database. Zou jammer zijn toch? Als je zelf met een search gaat beginnen, dan zou ik er in ieder geval goed opletten wat er echt ingevoerd wordt, en dat dat bruikbaar is voor de search, bijvoorbeeld inderdaad het verschil pc <> computer d.m.v. een vertalingstabel ... Dit zijn dus allemaal dingen waar enorm veel tijd in gaat zitten, naast het ontwerpen van de indices zelf, de queryparser (je wilt wel AND / AND NOT / OR en dat allemaal met haakjes, he) ...

[Verwijderd]

Wat is Lievenhstein's Distance. Heb je daar wat meer info over of wat bronnen (urls)

[Verwijderd]

Verwijderd schreef op 24 April 2003 @ 14:43:
Wat is Lievenhstein's Distance. Heb je daar wat meer info over of wat bronnen (urls)

http://www.merriampark.com/ld.htm
http://www.powerbasic.com...s/Forum7/HTML/001026.html
ook leuk:
http://elj.warwick.ac.uk/jilt/artifint/97_2noor/default.htm

[Verwijderd]

sebas schreef op 24 april 2003 @ 14:16:
Ik weet niet hoeveel knowledge deze 4 a 5 mensen hebben, maar dat moet wel heel veel zijn voordat je echt indices nodig gaat hebben. Tot een paar megabyte grote databases is een Fulltextsearch prima te doen. En van 4 a 5 mensen verwacht je niet zoveel queries dat load echt een probleem gaat worden.

Ik zou sowieso ook voor een al bestaande searchengine gaan. Er komt gewoon een hoop bij kijken, en wat je uiteindelijk doet is het wiel opnieuw uitvinden, waarschijnlijk niet beter maar way tijdsintensiever dan als je gewoon htdig of iets dergelijks pakt en de tijd die je spaart in gebruiksvriendelijkheid stopt. Bij het ontwerp van je database hou je dan rekening met de integratie van een searchengine. (Er was een mooi postgresql search engine, maar ik ben de naam even kwijt.)

Het invoeren van steekwoorden is zeker nuttig, maar het vergt inderdaad een hoop discipline om het goed in te voeren. En met jouw oplossing is een supermooi document waarvan gewoon de keywords niet kloppen of laks zijn gekozen gewoon verloren in de database. Zou jammer zijn toch? Als je zelf met een search gaat beginnen, dan zou ik er in ieder geval goed opletten wat er echt ingevoerd wordt, en dat dat bruikbaar is voor de search, bijvoorbeeld inderdaad het verschil pc <> computer d.m.v. een vertalingstabel ... Dit zijn dus allemaal dingen waar enorm veel tijd in gaat zitten, naast het ontwerpen van de indices zelf, de queryparser (je wilt wel AND / AND NOT / OR en dat allemaal met haakjes, he) ...

Heb je misschien nog id'en over paketten die samenwerken met MS Sql server?

[sebas]

Nee, helaas niet. Ik ben redelijk open source gericht, daarmee zou ik je wel kunnen helpen.
(Een goed alternatief voor MS SQL server is misschien postgresql, hiervoor is al een redelijk goede windows port, die van de zomer stable wordt, in mijn ogen goed genoeg om erop te ontwikkelen. Qua mogelijkheden zal PostGres niet op MS SQL achterlopen, dit weet ik echter niet uit gebrek aan ervaring met De serverproducten van Microsoft. Ik neem ook aan dat je niet zelf kunt bepalen welke database je gebruikt ...)

[Verwijderd]

sebas schreef op 24 April 2003 @ 16:38:
Nee, helaas niet. Ik ben redelijk open source gericht, daarmee zou ik je wel kunnen helpen.
(Een goed alternatief voor MS SQL server is misschien postgresql, hiervoor is al een redelijk goede windows port, die van de zomer stable wordt, in mijn ogen goed genoeg om erop te ontwikkelen. Qua mogelijkheden zal PostGres niet op MS SQL achterlopen, dit weet ik echter niet uit gebrek aan ervaring met De serverproducten van Microsoft. Ik neem ook aan dat je niet zelf kunt bepalen welke database je gebruikt ...)

Ik ben jammer (?) genoeg gebonden aan MS SQL server.

Ik denk dat ik dan toch ga voor de manier die ik me bedacht heb. Ik niet super veel tijd om het te bouwen, maar ik denk dat ik in de beschikbare tijd een heel leuk stukje software kan maken.

Maar mochten er mensen zijn die nog andere id'en hebben, shoot!

[Verwijderd]

http://www.microsoft.com/sharepoint/teamservices/default.asp

[Verwijderd]

Verwijderd schreef op 24 April 2003 @ 21:45:
http://www.microsoft.com/sharepoint/teamservices/default.asp

Ben ik bekend mee, zal er eens over nadenken...

Weet jij hoe het ook alweer zit met de licentiekosten voor Team services, Sharepoint portal is niet te betalen. Teamservices viel mee toch?

[EfBe]

Verwijderd schreef op 24 April 2003 @ 16:48:
Ik ben jammer (?) genoeg gebonden aan MS SQL server.
Ik denk dat ik dan toch ga voor de manier die ik me bedacht heb. Ik niet super veel tijd om het te bouwen, maar ik denk dat ik in de beschikbare tijd een heel leuk stukje software kan maken.
Maar mochten er mensen zijn die nog andere id'en hebben, shoot!

Je wilt dus niet gebruik maken van indexserver en full text search dat al meegeleverd wordt met elke win2k server? Dan hoef je nl. nauwelijks iets te doen, het is juist daarvoor gebouwd.

Tenzij mensen de documenten uberhaupt niet intikken in word, maar 'ergens in'. Ook dan zou ik full text search van sqlserver gebruiken. Het opzetten kost je 1 minuut en je hebt er geen kind aan, je hoeft geen keywords e.d. op te slaan, zoekmachine achtige logica te implementeren, je zoekt gewoon met keywords die ingegeven worden door de gebruiker in de textvelden waar de artikelen instaan (dus platte tekst). Zo'n zoekquery is 1 simpele SELECT.

[xtra]

Hulpmiddelen als Index Server en full text search zijn ideaal om een grote verzameling documenten zonder structuur te doorzoeken, maar niet in alle gevallen handig.
De topicstarter heeft niet aangegeven hoe groot de doelgroep is van zijn knowledge base. Als dit een grote is zoals klanten op internet of een hoop medewerkers in een bedrijf kan het zinvol zijn toch steekwoorden toe te voegen. Mits goed bijgehouden kun je hiermee de bezoeker sneller naar het juiste document sturen.
Uiteraard kun je ook een combinatie maken van steekwoorden en full text. Als (makkelijker te onderhouden) alternatief kun je documenten ook in een bepaalde rubriek plaatsen.

[Verwijderd]

EfBe schreef op 25 April 2003 @ 09:07:
[...]

Je wilt dus niet gebruik maken van indexserver en full text search dat al meegeleverd wordt met elke win2k server? Dan hoef je nl. nauwelijks iets te doen, het is juist daarvoor gebouwd.

Tenzij mensen de documenten uberhaupt niet intikken in word, maar 'ergens in'. Ook dan zou ik full text search van sqlserver gebruiken. Het opzetten kost je 1 minuut en je hebt er geen kind aan, je hoeft geen keywords e.d. op te slaan, zoekmachine achtige logica te implementeren, je zoekt gewoon met keywords die ingegeven worden door de gebruiker in de textvelden waar de artikelen instaan (dus platte tekst). Zo'n zoekquery is 1 simpele SELECT.

Ik zal nog eens gaan kijken naar info over index server...

[Verwijderd]

xtra schreef op 25 april 2003 @ 09:42:
De topicstarter heeft niet aangegeven hoe groot de doelgroep is van zijn knowledge base. Als dit een grote is zoals klanten op internet of een hoop medewerkers in een bedrijf kan het zinvol zijn toch steekwoorden toe te voegen.

Verwijderd schreef op 24 april 2003 @ 12:52:
[...]

Het is een groep van ongeveer 4 a 5 systeembeheerders... Groot is de groep dus niet

[Croga]

Het is jammer dat je gebonden bent aan MS. Lotus Notes/Domino is ideaal geschikt voor dit soort toepassingen, aangezien je niet gebonden bent aan enige tabellen, en dus je steekwoorden niet in een link-tabel aan je documenten hoeft te koppelen. Daarnaast is de FT search van Domino vermaard om zijn nauwkeurigheid en snelheid.

In dit geval zou ik inderdaad gaan voor de MS search op je standaard schijf, daar heb je verder geen sql databases bij nodig. Nadeel is wel dat zoeken in niet-MS documenten minder nauwkeurig gaat gebeuren, en dat je geen steekwoorden aan, bijvoorbeeld, PDF bestanden kunt hangen....

[henkleerssen]

als je eens in bent voor iets nieuws.. en goeie, snelle server wilt gaan hebben op basis van keywords moet je eens kijken op http://www.goendymion.com.
Vriend van me heeft die search engine bedacht (vroeger Znow). Probeer maar eens de search engine eens uit daar.. is ook gekoppeld aan documenten enzo..
Maar ik ben bang dat jij als klant buiten de scope valt.. ze azen op grote ondernemingen die veel documenten hebben .. om op een logische en nieuwe wijze te indexeren.. dussum.. kijk maar eens

[EfBe]

xtra schreef op 25 April 2003 @ 09:42:
Hulpmiddelen als Index Server en full text search zijn ideaal om een grote verzameling documenten zonder structuur te doorzoeken, maar niet in alle gevallen handig.
De topicstarter heeft niet aangegeven hoe groot de doelgroep is van zijn knowledge base. Als dit een grote is zoals klanten op internet of een hoop medewerkers in een bedrijf kan het zinvol zijn toch steekwoorden toe te voegen. Mits goed bijgehouden kun je hiermee de bezoeker sneller naar het juiste document sturen.
Uiteraard kun je ook een combinatie maken van steekwoorden en full text. Als (makkelijker te onderhouden) alternatief kun je documenten ook in een bepaalde rubriek plaatsen.

Ik zie niet waarom een klein groepje niet geschikt is voor index server. Immers: je wilt een service bieden, en die heb je met bestaande tools in een handomdraai gebouwd. Die service is echt hetzelfde voor 4 man als voor 400 man.

Keywords toevoegen is een onnodig iets, want die staan al in je tekst en dus vind je die al met full text search, dat bv ook 'near', or en and verstaat, wildcards etc. Door de ranking die je terugkrijgt kun je zelf bepalen hoe je die resultset weergeeft en de zoeker kan dan snel een toegang hebben tot de documenten. Als je extra keywords opneemt in het document, bv als sectie onderaan zoals MS doet in de KB, dan kun je die keywords ook nog gebruiken in je zoekquery. Het voordeel is ook dat degene die het artikel schrijft meteen tijdens het schrijven die keywords kan toevoegen, zonder dat deze later moeten worden bedacht.

Zelf gaan lopen knoeien met een eigengebouwde zoekengine die documenten harvest of waarvan het succes afhangt van de bereidwilligheid van de invoerder om keywords op te hoesten lijken me niet succesvol wanneer je de tools die dat al voor je doen wel succesvol zijn.

Sterker: als je de worddocs in een directory tree plaatst, je zet indexserver aan het werk op die directory kun je direct vanuit explorer al gaan zoeken, zonder 1 regel code.

[EfBe]

Croga schreef op 25 april 2003 @ 10:15:
In dit geval zou ik inderdaad gaan voor de MS search op je standaard schijf, daar heb je verder geen sql databases bij nodig. Nadeel is wel dat zoeken in niet-MS documenten minder nauwkeurig gaat gebeuren, en dat je geen steekwoorden aan, bijvoorbeeld, PDF bestanden kunt hangen....

Je kunt com objects installeren die indexering van andere typen documenten mogelijk maakt.

[xtra]

EfBe schreef op 25 april 2003 @ 10:18:
[...]

Ik zie niet waarom een klein groepje niet geschikt is voor index server. Immers: je wilt een service bieden, en die heb je met bestaande tools in een handomdraai gebouwd. Die service is echt hetzelfde voor 4 man als voor 400 man.

Ik wel Hoe je informatie succesvol ontsluit is sterk afhankelijk van je doelgroep en van de mensen die informatie plaatsen. Naast de omvang van deze groep is het een belangrijk verschil of het een bijkomende taak is of 'core business'.
Dit baseer ik op ervaring die ik in verschillende situaties en organisaties heb opgedaan.

Keywords toevoegen is een onnodig iets, want die staan al in je tekst en dus vind je die al met full text search, dat bv ook 'near', or en and verstaat, wildcards etc.
(...)

Afhankelijk van je doelgroep wil je verschillende zoekmogelijkheden aanbieden. Een softwareontwikkelaar kan prima uit de voeten met OR en AND. Bij een jurist of milieudeskundige wil je wellicht een ander mechanisme.

Als je extra keywords opneemt in het document, bv als sectie onderaan zoals MS doet in de KB, dan kun je die keywords ook nog gebruiken in je zoekquery. Het voordeel is ook dat degene die het artikel schrijft meteen tijdens het schrijven die keywords kan toevoegen, zonder dat deze later moeten worden bedacht.

Ook dit is in veel gevallen een prima manier om steekwoorden toe te voegen. Nu gebruikt MS wel speciale steekwoorden die je moet kennen: WINNT, MSSQL etc. (Even als voorbeeld. Ik weet niet of dit de juiste zijn.)

Zelf gaan lopen knoeien met een eigengebouwde zoekengine die documenten harvest of waarvan het succes afhangt van de bereidwilligheid van de invoerder om keywords op te hoesten lijken me niet succesvol wanneer je de tools die dat al voor je doen wel succesvol zijn.

Zeker niet doen. Op mijn werk heerst een cultuur van alles zelf doen. Ik roep al tijden dat ik producten van 'de plank' wil omdat die vaak beter zijn.
Maar ik denk ook dat een search engine als IS, maar ook 'slimme' als Autonomy niet in alle gevallen even goed voldoen. Dit is afhankelijk van de toepassing.

Sterker: als je de worddocs in een directory tree plaatst, je zet indexserver aan het werk op die directory kun je direct vanuit explorer al gaan zoeken, zonder 1 regel code.

Begrijp me niet verkeerd. Ik wil niet de ultieme oplossing aandragen. Daarvoor ken ik de situatie niet genoeg. (Eigenlijk helemaal niet.) Ik wil alleen wat overwegingen meegeven om een juiste keuze te kunnen maken.

[Verwijderd]

Ben ik bekend mee, zal er eens over nadenken...

Weet jij hoe het ook alweer zit met de licentiekosten voor Team services, Sharepoint portal is niet te betalen. Teamservices viel mee toch?

1 Frontpage Server License, verder niets.

http://www.microsoft.com/...ices/howtobuy/default.asp

Overigens maakt Team Services, net als zijn grote broer SharePoint, volgens mij ook gewoon gebruik van Indexing Services van Windows, maar bij Team Services krijg je veel meer 'out of the box'.

Je zou ook nog een paar maanden kunnen wachten op de nieuwe versie van TS die als uitbreiding op Windows 2003 uit zal komen.

[EfBe]

Zit TS niet standaard in win2k3? In de RC1 van Win2k3 zat wel een sharepoint achtig iets.

[xtra]

Verwijderd schreef op 25 April 2003 @ 10:08:
[...]


[...]

Dat geeft nog niet expliciet antwoord op de vraag hoeveel mensen de documenten gaan raadplegen. Als dat diezelfde 4 á 5 mensen zijn dan zou ik inderdaad niet veel verder kijken dan iets als IS.

[EfBe]

xtra schreef op 25 April 2003 @ 10:52:
Ik wel Hoe je informatie succesvol ontsluit is sterk afhankelijk van je doelgroep en van de mensen die informatie plaatsen. Naast de omvang van deze groep is het een belangrijk verschil of het een bijkomende taak is of 'core business'.
Dit baseer ik op ervaring die ik in verschillende situaties en organisaties heb opgedaan.

Ja dat klopt wel, maar is grotendeels een GUI kwestie: heb ik een fancy querybuilder of een textbox.

Afhankelijk van je doelgroep wil je verschillende zoekmogelijkheden aanbieden. Een softwareontwikkelaar kan prima uit de voeten met OR en AND. Bij een jurist of milieudeskundige wil je wellicht een ander mechanisme.

Nogmaals: dat is een gui kwestie en niet een kwestie van de onderliggende engine die het voor je opzoekt. Wat achter die gui zit zal de user boeien, en als je de elementen beschikbaar hebt om te bouwen wat je moet aanbieden als functionaliteit, waarom zou je dan de meest moeilijke weg kiezen: zelf bouwen ?

Ik heb voor onze forummodule van ons CMS ook sqlserver's full text search gebruikt. Kost nauwelijks code en levert zeer goede performance en functionaliteit. Ga dat zelf maar eens bouwen, 10 tegen 1 dat je met veel moeite dezelfde functionaliteit haalt en dat tegen veel regels code en dus hoge kosten. Hoe je die functionaliteit dan aanbiedt hangt, zoals je zegt, van de doelgroep af, echter dat is puur het aanbieden, niet de engine's functionaliteit: die moet artikelen zoeken op basis van de wensen van de zoeker.

Zeker niet doen. Op mijn werk heerst een cultuur van alles zelf doen. Ik roep al tijden dat ik producten van 'de plank' wil omdat die vaak beter zijn.
Maar ik denk ook dat een search engine als IS, maar ook 'slimme' als Autonomy niet in alle gevallen even goed voldoen. Dit is afhankelijk van de toepassing.

Het Not Invented Here (NIH) syndrome is diepgeworteld bij veel 'developers' inderdaad. Geen een zoekmachine is zaligmakend, maar je kunt een heel eind komen en het kost echt veel moeite om een goede zoekmachine te maken. Vraag dat maar aan de boys van Parse

Begrijp me niet verkeerd. Ik wil niet de ultieme oplossing aandragen. Daarvoor ken ik de situatie niet genoeg. (Eigenlijk helemaal niet.) Ik wil alleen wat overwegingen meegeven om een juiste keuze te kunnen maken.

Wat een keuze zou kunnen zijn om NIET voor een searchengine als IS te kiezen is dat je bv een blader systeem wilt. Dus een soort rubricering waar je doorheen bladert en dan de artikelen kunt zien al naar gelang je een rubriek aanklikt, ala yahoo. Dan heb je dus een eigen systeem nodig.

Dit soort dingen wordt echter vaak verzocht door mensen die niet snappen hoe gebruikers denken (ookal zijn het vaak zelf gebruikers) : je klikt en bladert je veelal het schompes op zoek naar iets, terwijl bij het intikken van een paar keywords je direct voorgeschoteld krijgt wat je wilt.

[Verwijderd]

EfBe schreef op 25 April 2003 @ 11:03:
Zit TS niet standaard in win2k3? In de RC1 van Win2k3 zat wel een sharepoint achtig iets.

Voorzover ik weet (ga hem dit weekend pas testen dus ik kan nog niet uit ervaring spreken) is TS eruit gehaald en wordt deze in een van meerdere geplande 'updates' van Win2k3 gestopt, zo gaan ze blijkbaar een aantal extra 'services' gespreid introduceren.

[Verwijderd]

Verwijderd schreef op 25 april 2003 @ 13:32:
[...]


Voorzover ik weet (ga hem dit weekend pas testen dus ik kan nog niet uit ervaring spreken) is TS eruit gehaald en wordt deze in een van meerdere geplande 'updates' van Win2k3 gestopt, zo gaan ze blijkbaar een aantal extra 'services' gespreid introduceren.

Ik heb hem al twee weken draaien en het zit er idd in als ik me niet vergis... 'k Heb nog niet echt tijd gehad om de leuke features te proberen...

edit:
nu ik beter kijk zie ik het niet zitten...

[ Voor 9% gewijzigd door Verwijderd op 25-04-2003 16:29 ]