Ministerie van Verkeer en Waterstaat. jklmnopq. Meetkundige Dienst

Ministerie van Verkeer en Waterstaat

jklmnopq Meetkundige Dienst

1

jklmnopq


Meetkundige Dienst

2



Trendrapportage Zoektechnologieën ten behoeve van WADI juli 2003

AGI-IBS-2003-33

1

jklmnopq


Meetkundige Dienst

2



Trendrapportage Zoektechnologieën ten behoeve van WADI juli 2003

AGI-IBS-2003-33

Vincent Buller ICT Strategie en Beleid (IBS) Meetkundige Dienst, Rijkswaterstaat

3

Inhoudsopgave .............................................................................................

1

Samenvatting

6

2 2.1 2.2 2.3 2.4 2.5 2.6

Projectbeschrijving Introductie Vraagstelling Projectafbakening Bronverantwoording Betrokkenen Het product Trendanalyse

8 8 8 8 8 9 9

3 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.4 3.5 3.5.1 3.5.2 3.5.3 3.6

WADI en DONAR Introductie Natte meetgegevens DONAR Systeemconcepten Selecteren in DONAR Analyse en Verwerkingsfuncties Waterbase (Plus) WADI Achtergrond en doelstelling Opzet Datamanagementsysteem Gegevensstandaarden Toepassing zoektechnologie

10 10 10 10 10 11 12 12 13 13 14 16 16

4 4.1 4.2 4.2.1 4.2.2 4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 4.3.8 4.3.9 4.4 4.5

Zoeken als nieuw paradigma Introductie Zoeken als manier van informatieontsluiting Toegang tot informatie Zoeken in plaats van ordenen? Zoeken vs. Selecteren De anatomie van zoektechnologie Overzicht van de anatomie De Spider Semantische structuren De Index Het User Interface Programmatisch interface Drie-lagen model Security Personificatie “Zoeken” in relatie tot andere ICT gebieden Zoektechnologie en WADI

17 17 18 18 19 20 21 21 22 22 23 24 27 27 28 29 29 31

5 5.1 5.2 5.3 5.4 5.4.1 5.4.2

Internet en Enterprise Zoekmachines Introductie Gartner Enterprise Search Magic Quadrant De Enterprise Search markt Produkten en produktontwikkeling Autonomy Verity

33 33 33 34 36 36 37

4

5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.5 5.6

Inktomi Google-in-a-box KennisBrowser en AquaBrowser, Medialab Collexis.com Convera Retrievalware Content Management en Kennismanagement Overzicht

40 42 42 43 44 44 45

6 6.1 6.2 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.4 6.5

Database technologie Introductie Databases en XML XML en de grote drie Oracle Microsoft SQL Server IBM DB2 What's in Store for XML DBs Text queries Databases en zoeken

46 46 46 46 47 47 48 48 49 49

7 7.1 7.2 7.3 7.4 7.5 7.6 7.7

XML Middleware en Information Integration Introductie IBM Information Integrator (eXperanto) OpenLink Software BEA Liquid Data MetaMatrix Nimble Technology EII en zoeken

50 50 50 52 52 52 52 53

8 8.1 8.2 8.3 8.4 8.5 8.6 8.7

Standaardisatie Introductie XML XML Query SQLX RDF en Topic Maps RDF en Topic Map query talen Samenvatting

54 54 54 55 55 55 57 58

9 9.1 9.2 9.3 9.4

“Zoeken” bij Rijkswaterstaat Introductie Project KM, RIKZ VenW Intranet AVV

59 59 59 60 60

10 10.1 10.2 10.3 10.4 10.5 10.6

Conclusies Ontwikkelingen in zoektechnologie Zoektechnologie en informatie integratie WADI en zoektechnologie WADI en de omgeving Zoektechnologie voor het verzamelen van gegevens Evaluatiecriteria zoekmachines

61 61 62 62 64 64 65

11 11.1 11.2 11.3 11.4 11.5

Referenties Rijkswaterstaat Butler Group Gartner Overige referenties Achtergrondinformatie

66 66 66 67 68 68

5

1 Samenvatting Dit trendrapport is het resultaat van een studie naar de relatie tussen zoektechnologie als methode voor de ontsluiting van tekstuele informatie en het opvragen van informatie uit gestructureerde (relationele) databases. Deze vraag is relevant voor het WADI project omdat werd gehoopt dat zoektechnologie kon helpen bij het vereenvoudigen van de toegang tot de database met natte meetgegevens. De resultaten van dit onderzoek zijn derhalve ook van belang voor andere database-projecten met een wens tot betere toegankelijkheid voor diverse typen gebruikers, en zelfs voor projecten die zich richten op “traditionele” toepassing van zoektechnologie voor bijvoorbeeld een internet, intranet of kennismanagement toepassing. Zoektechnologie is functioneel te onderscheiden in een aantal relatief onafhankelijke modules. Begrip van dit model is essentieel bij de beoordeling van de bruikbaarheid van specifieke technologie op een bepaald probleem: elk momenteel verkrijgbaar (zoek)product heeft sterkere en zwakkere kanten (modules) die moeten matchen met het gewicht dat men hecht aan per module gestelde requirements. Geavanceerde zoekproducten (bv. Autonomy) weerspiegelen deze modularisatie in toenemende mate ook in hun architectuur, waardoor de implementatie beter op het zoekprobleem is af te stemmen. Inhoudelijk gezien bestaat zoektechnologie uit een proces dat (tekstuele) informatie indexeert aan de hand van metadata (bijvoorbeeld een thesaurus), en een tweede proces dat een zoekvraag aan de metadata probeert te relateren, en via de index de bijbehorende informatie opzoekt. Er is een sterke relatie tussen zoektechnologie en metadata management, en indien (zoals in WADI) metadata management een centrale rol speelt is het belangrijk om zoekprocessen hieraan te relateren. Eventueel toegepaste zoektechnologie zal voldoende open moeten zijn om een dergelijke koppeling te kunnen maken. Het leveren van zoektechnologie is niet exclusief voorbehouden aan leveranciers die zich profileren in de Enterprise Search markt (bv. Autonomy, Inktomi). In toenemende mate zien we zoektechnologie ook terug in andere producten (recente MS Windows versies, databases). De voor dit onderzoek meest relevante ontwikkeling is de uitgebreide zoekfunctionaliteit die beschikbaar is gekomen in (relationele) databases (bv. Oracle, IBM). Het “gratis” meeleveren van zoektechnologie in andere producten kan worden gezien als een eerste aanzet tot commodisering van deze technologie. Voor steeds meer informatie geldt dat zoeken de enige (of in elk geval de meest praktische) manier is waarop zij ontsloten kan worden. Hierdoor zal zoektechnologie niet langer meer uitsluitend door mensen worden gebruikt, maar in toenemende mate direct worden benaderd door andere software (in het WADI geval bijvoorbeeld datavisualisatie- en analysetools). In dat opzicht wordt zoektechnologie steeds minder “user-interface” en steeds meer “data access” technologie, en verkrijgt het een rol voor “ongestructureerde” data die het relationele model en SQL hebben voor “gestructureerde” data. Voordat het echter een volledig gelijkwaardige rol kan krijgen zal de standaardisatie van zoektalen zich verder moeten ontwikkelen. Op de lange termijn is te verwachten dat het onderscheid in het ontsluiten van gestructureerde en ongestructureerde gegevens sterk zal verminderen – nu al zijn op diverse terreinen ontwikkelingen zichtbaar waarbij het zoeken in tekst en het selecteren van gestructureerde gegevens (databases) naar elkaar toegroeien. Naast de centrale rol die metadata management daarbij zal

6

vervullen, is XML hierbij een belangrijke integrerende technologie. XML wordt nu reeds gebruikt voor modellering van het gehele scala aan gestructureerde en ongestructureerde gegevens – en vormt tevens de bodem van recente ontwikkelingen op metadata gebied.

7

2 Projectbeschrijving 2.1 Introductie

Deze trendrapportage is opgesteld naar aanleiding van de vraag uit het WADI project of zoektechnologie en ontwikkelingen daarin van belang zijn voor de gegevensontsluiting in het kader van WADI. Vanwege de bredere relevantie van de vraagstelling, onder andere voor de natte modelsystemen, is deze trendrapportage uitgevoerd onder auspiciën van het SPIN1 en uitgevoerd door de afdeling ICT-Strategie en -Beleid (IBS) van de Meetkundige Dienst.2

2.2 Vraagstelling

De hierboven beschreven originele vraag is ten behoeve van het onderzoek als volgt veralgemeniseerd: Wat zijn de trends in zoektechnologie, toegespitst op het raakvlak tussen vrij zoeken in ongestructureerde gegevens en gestructureerde querying van databases Voor de beantwoording van deze vraag is primair uitgegaan van de wensen en doelstellingen van het WADI project. Van secondair belang is de relevantie van de in dit rapport beschreven zoektechnologie voor andere natte systemen zoals bijvoorbeeld het SIMONA modelsysteem. Omdat uit deze hoek niet wezenlijk andere problemen of vragen worden voorzien, zal hier in het vervolg van dit rapport verder niet expliciet bij worden stilgestaan. Tijdens het project heeft er afstemming en kennisuitwisseling plaatsgevonden met het kennis project RIKZ/DZH.

2.3 Projectafbakening

Deze trendanalyse geeft een overzicht van de huidige en verwachte toekomstige stand van zaken met betrekking tot relevante (zoek)technologieën voor de ontsluiting van WADI gegevens. Het rapport beperkt zich tot een overzicht en interpretatie van trends en ontwikkelingen, en is nadrukkelijk parallel aan het WADI ontwikkeltraject uitgevoerd (vanzelfsprekend met de nodige afstemming).

2.4 Bronverantwoording

Om de leesbaarheid van dit document niet negatief te beïnvloeden zijn niet alle (gedeeltelijke) citaten uit documenten van Rijkswaterstaat als citaat aangeduid. Dit geld vooral voor die teksten die als algemene kennis gelden en uit meerdere bronnen beschikbaar zijn.

1 2

Zie: http://www.venwnet.minvenw.nl/rws/fwta/spin/ Zie: http://www.venwnet.minvenw.nl/ibs/

8

2.5 Betrokkenen

Om een overzicht te krijgen van toepassingen van zoektechnologie bij Rijkswaterstaat zijn gesprekken gevoerd met de volgende personen: MD-IBC dhr. Wiebrand Bouwkamp dhr. Martin v.d. Burg MD-IBM dhr. Frans Marks AVV dhr. Gerald Prast RIKZ dhr. Ron Bosman dhr. Ronald Marseille dhr. Robbert Verweij dhr. Poul Grashof, Demis DZH dhr. Jan Al dhr. Albert van Schaick

2.6 Het product Trendanalyse

De afdeling ICT-Strategie en -Beleid (IBS) van de Meetkundige Dienst geeft Rijkswaterstaat beleidsondersteunend ICT-advies op strategisch niveau. Klanten van IBS zijn het hoofdkantoor van Rijkswaterstaat en de IT-raden van V&W en RWS. Daarnaast worden er adviesopdrachten uitgevoerd in het kader van lopende RWS projecten. Regionale directies, specialistische diensten van RWS en andere onderdelen van het ministerie kunnen ook een beroep doen op deze dienstverlening. Voor het geven van adviezen over de strategische inzet van ICT betekent dat IBS al deze ontwikkelingen op de voet moet volgen. Trendanalyse is onmisbaar voor een gedegen ICT-beleid dat rekening houdt met ontwikkelingen binnen en buiten de overheid, op het gebied van ICT en ook daarbuiten. De trendanalyse groep binnen IBS houdt zich bezig met het signaleren van nieuwe ontwikkelingen, en analyseert en beoordeelt het belang hiervan voor de kerntaken van het ministerie. IBS onderhoudt daarvoor nauw contact met professionele volgers van de ICT-wereld, waaronder kennisinstituten als de Technische Universiteit Delft en andere universiteiten, en de analistenbureaus Gartner en Butler Group. Door verkenningen, presentaties, rapportages, publicaties en de intranetsite wordt de opgedane kennis verspreid en gebruikt voor het geven van adviezen. Zie voor meer informatie: http://www.venwnet.minvenw.nl/ibs/trendanalyse/

9

3 WADI en DONAR 3.1 Introductie

De inwinning, opslag en verwerking van natte meetgegevens kent een rijke historie. Dit hoofdstuk biedt een overzicht van wat DONAR is en WADI wil zijn, in relatie tot de vraag naar gegevensontsluiting.

3.2 Natte meetgegevens

De “natte meetgegevens” (zoals opgenomen in DONAR) omvatten: · fysische gegevens, zoals waterstanden, golfgegevens, afvoeren, watertemperaturen,en meteorologische gegevens; · chemische informatie, zoals concentraties van chemische stoffen in water, waterbodems, slib, bagger en organismen; · morfologische gegevens, zoals hoogteligging, van rivier-, meer-, zeebodems; · biologische gegevens, zoals informatie over vogels, vissen en microorganismen. De bovengenoemde meetgegevens zijn veelal afkomstig uit reguliere meetprogramma’s. Daarnaast zijn er echter ook veel metingen welke op incidentele basis, vaak ten dienste van een project, zijn uitgevoerd. Deze gegevens zijn soms slechts toegankelijk via de bureaulade van de (voormalige) projectleider, alwaar ze in een onbekend formaat en zonder afdoende beschrijvende gegevens (metagegevens) liggen te verstoffen. Het hergebruik van deze gegevens is een van de doelstellingen van WADI.3 Naast zuivere meetgegevens zijn er ook afgeleide documenten zoals onderzoeksrapporten en verslagen. Hoewel DONAR geen faciliteit biedt voor de opslag van deze documenten, bestaat er sinds enige tijd wel een mogelijkheid om externe referenties op te slaan (o.a. op auteur, ISBN nummer of andere bibliotheekaanduiding).4

3.3 DONAR 3.3.1 Systeemconcepten

DONAR (Data Opslag Natte Rijkswaterstaat) is het huidige systeem voor centrale opslag, beheer en ontsluiting van natte meetgegevens van de rijkswateren. Invoer van gegevens geschiedt door het middels een terminalverbinding uploaden van data in een gestandaardiseerd gegevensformaat. Door deze remote verbinding kunnen regionale diensten gegevens decentraal invoeren. Het omzetten van gegevens in het juiste formaat en eventueel maken van een selectie of uitvoeren van filterfuncties voor de opslag is een decentrale taak. Bij de opslag van de gegevens in DONAR wordt een sterk conceptueel onderscheid gemaakt tussen de meetgegevens en de bijbehorende meta-data. Het begrip meta-data wordt ruim opgevat als alles behalve de meetwaarden 3 4

Zie de Managementsamenvatting van de WADI Definitiestudie Zie: http://131.237.47.40:8080/producten/conversietools.htm

10

zelf, en wordt onderscheiden in “W3H”: Wie, Waar, Wat, Hoe (Een vierde W , de “wanneer”, is niet als zodanig herkenbaar maar indirect aanwezig als “reeks”-selectie). Wat: Om welke gegevens en/of om welke biologische soort gaat het? Wie: Wie is de opdrachtgever, wie heeft de meting verricht, wie heeft de meetwaarde geanalyseerd? Waar: Op welke locatie is de meting uitgevoerd? Hoe: Met welk instrument is de meting verricht, welke analysemethode is gebruikt? Wanneer: Op welk tijdstip is de meting verricht? 3.3.2 Selecteren in DONAR

De W3H (W4H) onderdeling van de meta-gegevens vind zijn weerslag in de wijze van gegevens-selectie in DONAR middels de zgn. “W3H selectie”. Figuur 3.1 is een afbeelding van het (terminalgeoriënteerde) zoekscherm van DONAR. De DONAR handleiding spreekt van noodzakelijke materiekennis voordat men van DONAR gebruik kan maken, en dit geldt zeker voor het zoekinterface. Er wordt in het scherm veel gebruik gemaakt van vaktermen (welke bekend mogen worden verondersteld) maar er is daarnaast sprake van afhankelijkheden tussen de diverse selectievelden. Dit wil zeggen dat een selectie in het ene veld de toegestane waarden in een ander veld beïnvloedt wat zelfs voor materiedeskundigen het opstellen van een query tot een complexe zaak maakt.

Figuur 3.1: Het DONAR selectiescherm

Achter dit zoekscherm bevind zich een relationele database met SQL query mogelijkheid, dus indien men daartoe toegang heeft zijn andere queries mogelijk. Een presentatie van het WADI project meldt de volgende sterke en zwakke punten van DONAR: · Sterke punten o Centrale bron o Veel gegevens o Goed beheer o Metagegevens

11

·

o Heeft standaardisatie bevorderd o Borging investeringen in monitoring Zwakke punten o Niet alles kan erin o Niet alles staat erin o Het verwerkingssysteem sluit niet aan bij de processen o Geografie zwak (alleen puntlocaties) o Onvoldoende open o Matig gebruiksvriendelijk

Hieraan is nog toe te voegen: · Geen expliciet beheer van (meet)nauwkeurigheden · z-positionering; dit valt onder de beperkte geografische mogelijkheden maar is een expliciete wens voor de toekomst. In het algemeen is de huidige DONAR structuur meer gericht op de gegevensinvoerkant dan de ontsluiting van de gegevens. 3.3.3 Analyse en Verwerkingsfuncties

Met DONAR zelf kunnen standaardverwerkingen op gegevens worden uitgevoerd, zoals: · algemene statistiek: het berekenen van gemiddelden en frequentie analyse; · presentaties van gegevens in tabelvorm; · selecties van gegevens d.m.v. filteren van uitschieters, aangeven van grenswaarden; · omrekenen naar andere eenheden en/of coördinaatstelsels; · grafische presentaties: tweedimensionale en driedimensionale grafieken en histogrammen; · een specifieke applicatie voor het valideren, presenteren en analyseren van stroommetingen. Veel gebruikers van het DONAR systeem willen de gegevens verder verwerken in marktpakketten zoals bijvoorbeeld Microsoft office pakketten (MS EXCEL, MS WORD, MS ACCESS). Hiervoor biedt DONAR een exportfunctie.

3.4 Waterbase (Plus)

Het wordt al geruime tijd onderkend dat het opvragen van gegevens uit DONAR te beperkt is gebleven tot een groep specialisten. Dit wordt mede veroorzaakt door een verouderd, minder gebruikersvriendelijke gebruikersinterface. Om DONAR voor een breder publiek toegankelijk te maken, is hiervoor een project opgestart. In het voorjaar van 2002 is de applicatie Waterbase gereed gekomen. Met deze applicatie is, via een eenvoudig gebruikersinterface, een belangrijk deel van de gegevens uit de centrale DONAR database5, te weten fysische en chemische landelijke monitoringgegevens, op internet beschikbaar. Deze applicatie blijkt een succesformule te zijn. WaterBase bevat een selectie van de gegevens uit DONAR. Deze selectie omvat enkel tijdreeksen, is zorgvuldig gecontroleerd en is geoptimaliseerd voor publicatie op het Internet. In een vervolgfase van het project ter ontsluiting van DONAR voor een breed publiek worden alle reekstypen uit de centrale DONAR 5

De oorspronkelijke ambitie van het voorloper-traject WATINDON was zelfs om rechtstreeks meetgegevens uit zowel de centrale als de decentrale DONAR databases te ontsluiten.

12

database ontsloten en zal het mogelijk te zijn om te zoeken in de database welke meetgegevens op een bepaalde locatie, of in een bepaald gebied in een op gegeven periode aanwezig zijn. Vervolgens kunnen alle meetreeksen, of een subset hiervan uit de selectie opgevraagd worden. Er wordt hierbij niet gewerkt op de DONAR database zelf, maar op een schaduwdatabase. Deze schaduwdatabase wordt op regelmatige basis, bijvoorbeeld 1 maal per week, ge-update met de DONAR database. In het hoofdmenu van de applicatie WaterBase zal de gebruiker een keuze kunnen maken uit · zoeken in de fysische en chemische landelijke monitoringgegevens (Waterbase); · uitgebreid zoeken in de complete centrale DONAR database (Waterbase Plus). De eerste mogelijkheid is beschikbaar op Internet. De tweede mogelijkheid is beschikbaar voor Intranet. Dit onderscheid wordt aangebracht omdat de uitgebreide zoek mogelijkheid ook toegang geeft tot projectgegevens en nog niet gevalideerde gegevens. De gebruikersinterface van Waterbase+ zal overeenkomstig de bestaande gebruikersinterface van Waterbase zijn, met enkele extra filtermogelijkheden zodat de omvang van de geselecteerde dataset snel beperkt kan worden. Volgens de huidige planning zal Waterbase+ van het project Waterbase in voorjaar 2003 operationeel zijn. In een vervolg zullen de publicatiemechanisme van de landelijke monitoringgegevens en de uitgebreide zoekmogelijkheden geïntegreerd worden. Een voor “zoeken” relevante functionaliteit is de in Waterbase Plus ingebouwde thesaurus, waarmee bij de gebruiker bekende terminologie kan worden gebruikt in plaats van de dieper in het systeem gebruikte vaktermen.

3.5 WADI 3.5.1 Achtergrond en doelstelling

WADI (Water Data Infrastructuur) is een project dat tot doel heeft de goede eigenschappen van DONAR te behouden en de knelpunten op te lossen. De opdracht voor WADI is:6 “WADI dient, meer dan nu het geval is, het primaire proces te ondersteunen Het blikveld wordt verruimd tot het integrale datamanagement van natte meetgegevens binnen de werkprocessen. Daarom spreken we nu ook niet van het bouwen van een systeem, maar van het zorgen voor een oplossing voor datamanagement.” Aan de basis van WADI staat een duidelijke definitie van doelgroepen en kadering van de functionaliteit. De WADI gebruikers zijn bepaald als: Primair: · Alle onderdelen Rijkswaterstaat · Ministerie van Verkeer en Waterstaat Secondair: 6

Zie “WADI Startdocument”

13

· · · ·

Andere waterbeheerders (waterschappen, provincies) BV Nederland (Andere overheden, burger, bedrijven en instituten) Onderwijsinstellingen Europese en mondiale partners

Het onderscheid primair-secondair komt erop neer dat de eerste groep WADI gebruikt voor de opslag van “eigen” gegevens, en de secondaire groep gebruikers betreft met alleen leestoegang of anderszins beperkte rechten. WADI heeft zoals blijkt uit genoemde gebruikersdefinitie als expliciete doelstelling om de gegevens ter beschikking te stellen aan afnemers buiten Rijkswaterstaat, wat bijzondere eisen stelt aan de makkelijke toegang tot de gegevens. Meer dan bij DONAR is voor WADI een functionele afbakening vastgesteld, die vooral inhoud dat WADI zelf niets aan presentatie en analyse van gegevens zal doen. Evenals bij DONAR valt ook het inwinnen en voorbewerken van gegevens buiten de doelstelling.

Figuur 3.2: Functionele afbakening van WADI Gegevens in WADI: · Meetwaarden · Kengetallen · Indicatoren en graadmeters 3.5.2 Opzet Datamanagementsysteem

Aan het datamanagementsysteem van WADI zijn de volgende eisen gesteld:7 Opslag op maat van ‘natte’ Rijkswaterstaat meetgegevens Opslag op maat betekent dat het invoeren van gegevens soepeler moet verlopen dan in het huidige DONAR, en dat opslag specifieker geschikt moet zijn voor verschillende soorten meetgegevens. Deze gegevens kunnen voortkomen uit meerjarige monitoringprogramma’s of uit eenmalige projecten. 7

Zie WADI

14

Startdocument

Dit leidt niet noodzakelijkerwijs tot één opslagsysteem (zoals DONAR nu). Wel is er één metadatainfrastructuur. Het doel is optimale toegankelijkheid, ook vanuit andere systemen en applicaties. Uitstekende toegankelijkheid van deze gegevens De architectuur en opzet van WADI zorgen ervoor dat de opgeslagen gegevens in maatwerk- of marktapplicaties goed terug te vinden en op te vragen zijn. Er zal één maatwerkapplicatie ontwikkeld worden om gegevens op te vragen (en terug te vinden). Dit zijn de gegevens die hierboven zijn genoemd. Hiermee wordt aangetoond dat het relatief eenvoudig is om toegang tot de data te krijgen. Figuur 3.3 schetst de globale opzet van het datamanagementsysteem dat aan de beoogde doelstellingen beantwoordt. Vanwege het bredere dekkingsgebied dan DONAR wordt uitgegaan van een generiek opslagmodel waar dat kan (inclusief geografische informatie) en specifieke modellen waar dat nodig is voor de diverse toepassingsgebieden.

Gebruiker/ Werkproces 1

Gebruiker/ Werkproces 2 User-interface Waterbase

Gebruiker/ Werkproces 3 Extern systeem User-interface 3 WADI

User-interface 1

View

View

View

Metalaag Metadata Generiek opslagmodel

Metadata Specifiek OpslagModel I

Metadata Specifiek OpslagModel II

Extern opslagsysteem

Figuur 3.3: Systeemschets WADI

De diverse modellen worden geïntegreerd middels een universele metadatainfrastructuur voor zowel de generieke als de specifieke informatie. Externe gegevensverzamelingen die aan een aantal eisen voldoen (zoals stabiliteit) kunnen eveneens worden gekoppeld aan de metalaag. Met de gebruiker wordt gecommuniceerd via views. Zodoende wordt zowel bij het opslaan als bij het ophalen van gegevens een herkenbare omgeving geboden voor gebruikers (zie figuur). Het WADI project gaat uit van een incrementele aanpak en stapsgewijze implementatie. Dit, samen met de mogelijkheid tot het opnemen van externe gegevensverzamelingen, vereist dat de integrerende metadatalaag flexibel wordt opgezet en uitbreidingen zowel als veranderingen eenvoudig toestaat. Diverse toepassingen krijgen toegang tot de WADI gegevens, en bieden hun eigen speciefieke “view” op de data. Waterbase, momenteel een aan DONAR

15

gekoppelde applicatie, kan als een dergelijke toepassing worden gezien, evenals andere visualisatie en analysetools. 3.5.3 Gegevensstandaarden

Waar mogelijk worden gegevens opgeslagen in een generiek opslagmodel, dat zoveel mogelijk voldoet aan de gegevensstandaard van de IDsW (InformatieDesk standaarden Water) en tenminste aan de CIW-gegevensstandaard en de CIW-waarnemingssoorten indien IDsW nog niet voldoende is uitontwikkeld.8 Waar dit niet past, wordt de opslag geregeld via specifieke gegevensmodellering. IDsW (Informatie Desk standaarden Water, gestart begin 2003) is de beoogde integratie van gegevenswoordenboeken Adventus, Omega en de Water Informatie-infrastructuur (bestaande uit 4 producten). Onder de IDsW is het onder meer de bedoeling dat er straks 1 gegevenswoordenboek komt, door het samenvoegen van Adventus en Omega (en daarmee ook de CIW-gegevensstandaard). Dit is echter niet gemakkelijk omdat sommige termen dubbel voorkomen met een andere beschrijving. Het zal nog wel een paar jaar duren voor het zover is.

IDsW

Adventus gegevensstandaard water

CIW standaard

Omega gegevenswoordenboek

Figuur 3.4: Relatie gegevensstandaarden IDsW, Omega, Adventus en CIW 3.6 Toepassing zoektechnologie

Op voorhand zijn twee plaatsen in het WADI project geïdentificeerd waar “zoektechnologie” mogelijk zou kunnen worden toegepast. De voor de hand liggende toepassingsmogelijkheid is in het (gebruikers)interface, de andere is bij het (semi-)automatisch vergaren van ruwe data ten behoeve van opname in WADI. Gegevensontsluiting met WADI vind in eerste instantie plaats door het vinden van de juiste datasets, niet zozeer individuele gegevens. De wijze van ontsluiting is middels de metadata, en niet de data (meetwaarden) zelf. Een vraag als “geef mij die datasets die meetwaarden X bevatten met een waarde groter dan Y” valt volgens de definitie van WADI buiten het WADI domein, en in het domein van analysetools. De “bovengrens” van WADI zoals geschetst in afbeelding 4.4, met een interface tussen WADI en toepassingsspecifieke applicaties, vereist dat zoekacties die in de gebruikersapplicatie worden ingevoerd moeten kunnen worden doorgegeven. Dit maakt tevens mogelijk dat het zoekinterface wordt benaderd door automatische algoritmen, omdat het bij een dergelijke architectuur voor de onderliggende applicatie niet meer relevant (of zelfs maar zichtbaar) is of een zoekactie door een eindgebruiker is ingevoerd of door een andere applicatie is geïnitieerd. 8

Zie “WADI SysteemOmgeving”

16

4 Zoeken als nieuw paradigma 4.1 Introductie

De opkomst van het Internet en de bijbehorende technologie heeft veel veranderingen in de ICT teweeg gebracht, niet in het minst in het denken over user-interfacing en gegevensontsluiting. Naast de browser metafoor voor de ontsluiting van hyperlinked informatie, is de belangrijkste ontwikkeling op dit gebied toch zondermeer de opkomst van het zoeken (de ‘search blank’, zie Gartner: Search Technology Tools Suited for Programs and People). Zoektechnologie heeft historisch gezien altijd al deel uitgemaakt van gesloten informatieverzamelingen zoals bibliotheeksystemen, document management systemen en catalogus CD-ROMs. Zoeken op het Internet, en meer specifiek op het Web,9 heeft het zoeken ten opzichte van deze traditionele gegevensverzamelingen echter op een aantal punten significant veranderd. Zo is Web technologie per definitie geënt op een netwerk, en is de informatie op het Web per definitie gedistribueerd opgeslagen. Gepaard met deze gedistribueerde opslag gaat decentrale wijziging van gegevens, waardoor de enige manier om overzicht over alle gegevens te houden (een ‘index’ op te bouwen) het periodiek aflopen daarvan is (een techniek die ‘spidering’ of ‘crawling’ wordt genoemd in Web zoekterminologie). Niet alleen in technisch opzicht is de aanmaak van content en het doorvoeren van wijzigingen op het Web decentraal, ook kan het Web gezien worden als ultieme democratisering van het publicatieproces en de vleesgeworden vrijheid van meningsuiting. Behalve interessante materie voor filosofen, heeft dit ook directe consequenties voor de wijze van ontsluiting van de informatie. De grote mate van anarchie op het Web betekent dat de structuur die er is gedistribueerd door de content auteurs zelf wordt aangemaakt (de “web” structuur van hyperlinks van pagina naar pagina), of van buitenaf –en achterafaangemaakt door een Web index (directory) als Yahoo of zoekmachine als Google. Niet alleen staat het iedereen vrij om zelf een Web-index of zoekmachine te beginnen, in veel gevallen zijn de gebruikte indexeringsalgoritmen niet publiek. De onafhankelijke opzet van Web-zoekmachines heeft ertoe geleid dat er een ware “wapenwedloop” is ontstaan tussen Websites (die zo hoog mogelijk in de index willen eindigen) en zoekmachines (wiens bestaansrecht voor een groot deel wordt ontleend aan objectiviteit). Niet alleen is het zo dat zoekmachines verantwoordelijk zijn voor het afleiden van metadata uit de content zelf, ze moeten ook nog voorkomen dat ze opzettelijk worden misleid. Hoewel de Web opmaakstandaard HTML mogelijkheden kent voor het aangeven van keywords of categorisering van de content, zullen zoekmachines hier dus helaas niet zondermeer op kunnen vertrouwen. Kwaliteit van informatie is een moeilijk begrip dat al snel leidt tot een kwalificatie van de inhoud en een stellingname over het besprokene. Omdat een zoekresultaat objectief moet zijn maar toch een zekere mate van kwaliteitsbeoordeling wil bevatten, wordt hiervoor vaak teruggegrepen op een beproefde techniek uit de wetenschap: de citation index. Kort samengevat komt dit erop neer dat het aantal hyperlinks naar een pagina toe wordt 9

Informatie op “het Internet” kan ook beschikbaar zijn in nieuwsgroepen, Gopher, etc. Dit onderscheid is echter steeds minder van belang, en in het vervolg zullen we het ook niet meer maken.

17

beschouwd als kwaliteitsmaat – omdat hiervoor de inhoud (hyperlinks) van andere pagina’s dan de betreffende pagina van belang zijn is dit systeem moeilijk te misleiden10, en door de wet van de grote getallen de invloed van een enkele site op de weging van anderen gering. Op deze manier vormt het decentraal gecreëerde web van hyperlinks weer een belangrijke factor bij de weging van de centraal aangeboden zoekresultaten. Samenvattend is het goed om ons te realiseren dat Web zoekmachines zijn ontwikkeld voor een omgeving waarin een hoge mate van standaardisatie van datacommunicatie (alle websites zijn op dezelfde manier benaderbaar), maar een lage graad van organisatie en standaardisatie van de inhoud. Wat maakt zoeken anders dan andere manieren om informatie te ontsluiten, en wat zijn juist eventuele overeenkomsten? In dit hoofdstuk bespreken we zoektechnologie en haar anatomie.

4.2 Zoeken als manier van informatieontsluiting 4.2.1 Toegang tot informatie

Zodra een informatieverzameling een zekere grootte bereikt ontstaat de behoefte om de informatie met hulpmiddelen beter benaderbaar te maken. In een bibliotheek met meer dan een paar boeken zal men al snel de boeken op alfabetische of thematische volgorde zetten. Hier blijkt al snel de beperking van het gebruik van de fysieke locatie van de boeken, namelijk dat er tegelijkertijd maar op 1 manier tegelijkertijd kan worden geordend. Een aparte metadata verzameling in de vorm van een catalogus kan dat probleem ondervangen.

Figuur 4.1: De Google zoekpagina en de Google Directory (index) als voorbeelden van Query-based en Navigation-based information retrieval

Wanneer we de stap maken naar geautomatiseerde informatieverzamelingen, dan zijn er diverse manieren om de ontsluiting te benaderen. Een onderverdeling van deze methoden wordt bijvoorbeeld gepresenteerd door Alexander Linden van Gartner (in Different Approaches to Accessing Information):

10

Hoewel er vanzelfsprekend wel pogingen worden ondernomen m.b.v. zgn. linkfarms

18

A. Query-Based Information Retrieval 1. Conventional Keyword Searching: 2. Concept-Based Searching, Using a Hand-Crafted Thesaurus: 3. Concept-Based Searching, Using Statistical Analysis: 4. Natural-Language-Based Searching: B. Navigation-Based Information Retrieval 1. Linear Browsing: 2. Alphabetical Indexing: 3. Hypertext: 4. Taxonomies: 5. Ontologies: Merk op dat Alexander Linden hier op het hoogste niveau onderscheidt op grond van type user interface (search vs browse), en op een lager niveau onder andere op type categorisering/metadata (taxonomy vs ontology). Dit is zeker geen gegeven, en andere indelingen zijn mogelijk. Later in dit hoofdstuk zullen we bijvoorbeeld zien dat het technisch onderscheid tussen searching en browsing niet zo groot is en beide van veel dezelfde technieken gebruik maken. 4.2.2 Zoeken in plaats van ordenen?

Kijken we in het algemeen naar de vraag wanneer je zult proberen iets te zoeken, dan geldt in het dagelijks spraakgebruik dat je moet zoeken wanneer je iets niet op voorhand hebt geordend. Als je geen vaste plek hebt voor je autosleutels (én een slecht geheugen hebt…) dan zal je ze vaak moeten zoeken. Het zal dan ook geen verbazing wekken dat de grote opkomst van zoektechnologie parallel loopt aan de opkomst van waarschijnlijk de grootste ongestructureerde11 gegevensverzameling ooit:: het World Wide Web. Het is deze tweedeling tussen ordenen en zoeken die een grote rol speelt in elke verhandeling over (nieuwe) methoden om informatie te ontsluiten. Vaak wordt er gesproken van gestructureerde en ongestructureerde data, waarmee grofweg het onderscheid word bedoeld tussen informatie in databases (gestructureerd) en in tekstverzamelingen en (HTML-, Word-) documenten (ongestructureerd). In de praktijk van het informatiebeheer is deze tweedeling echter niet zo eenduidig. We hebben al eerder besproken dat een Internet zoekmachine zelf een ordening definieert op de ongestructureerde verzameling van het Internet, en in het algemeen is het zo dat zoektechnieken niet direct in de ongeordende broninformatie zoeken maar deze eerst proberen te ordenen. Dit is goed te vergelijken met een bibliotheek waar de boeken willekeurig door elkaar staan, maar de (geordende) catalogus van elk boek de juiste positie in de kast aangeeft: het eindresultaat is een zeer gestructureerde bibliotheek ondanks de ongeordendheid in de kasten zelf. Wanneer we de opslag zelf bekijken dan zien we ook veel meer een glijdende schaal dan een strikte scheiding tussen gestructureerd en ongestructureerd: Databases bevatten vaak grotere stukken tekst zo niet hele documenten, en zogenaamd ongestructureerde “documenten” kunnen vaak aanzienlijke structuur hebben. Toenemend gebruik van XML, zowel voor data als

11

De hyperlinks op het Web vormen wel degelijk structuur, maar deze is niet uit zichzelf centraal beschikbaar. Het Semantic Web, een initiatief van de standaardisatieorganisatie W3C (het World Wide Web Consortium) voor een nieuwe generatie Web, is bedoeld om dit gebrek aan semantiek en structuur op het Web te ondervangen.

19

documenten, speelt ook een grote rol bij het vervagen van de grens tussen gestructureerde en ongestructureerde gegevens. 4.2.3 Zoeken vs. Selecteren

Hoewel het onderscheid tussen gestructureerde en ongestructureerde informatie niet altijd scherp is te zien, is er een duidelijker onderscheid te maken in de manieren waarop deze informatie doorgaans wordt opgevraagd. Vaak maakt men impliciet dit onderscheid door het gebruik van de termen “zoeken” (search, voor tekstcollecties) of “selecteren” (ofwel query, voor databases). Ten behoeve van dit onderscheid zullen we deze termen hier ook gebruiken. De genoemde twee methoden voor het bevragen van informatieverzamelingen verschillen allereerst in de wijze van formulering van de zoekvraag. Een (relationele) database querytaal als SQL vereist van de gebruiker uitgebreide kennis van de in de opslag gebruikte datastructuren, omdat deze structuren en relaties in de query moeten worden opgenomen. Een belangrijker onderscheid is echter dat dit soort querytalen zo is ontworpen dat een informatie-item (zoals een database-record) altijd eenduidig binnen of buiten het query-resultaat valt. – de naam selectie die we hiervoor gebruiken geeft dit ook aan. Een query is dan ook bij uitstek geschikt om eenduidige vragen te beantwoorden, en wordt bijvoorbeeld gebruikt voor het selecteren van die artikelen in een voorraadbeheersysteem waarvan minder dan 10 exemplaren op voorraad zijn. “Zoeken” is van oorsprong gericht op het ontsluiten van tekstverzamelingen, en het zal ook niet verbazen dat het door de ambiguïteit van natuurlijke taal is beïnvloed. Hoewel er simpele zoektalen zijn waarbij de gebruiker zelf relaties in het gezochte kan aangeven (bijvoorbeeld de nabijheid van twee woorden in een tekst met een “NEAR” operator) zal er in het algemeen veel meer op de intelligentie in de zoekmachine zelf worden vertrouwd. In het extreme maar veelvoorkomende geval dat een zoekvraag alleen bestaat uit een lijst met zoektermen (keywords) ligt de verantwoordelijkheid voor de interpretatie van de zoekvraag zelfs volledig bij de zoekmachine. De zoekmachine voert deze interpretatie uit met behulp van synoniemenlijsten, begripsverbanden (taxonomieën of ontologieën) of nog andere technologieën. Ten gevolge van het zoeken in zogenaamde vrije tekst zonder eenduidige classificatie (een tekst kan in meer of mindere mate aan meerdere onderwerpen gerelateerd zijn), evenals door het automatisch interpreteren van zoekvragen, is de uitkomst van een zoekvraag niet zo zwart-wit als bij een database selectie. Elke zoekmachine werkt daarom intern met de mate van relevantie van een stuk informatie tot de zoekterm. Soms wordt deze relevantie weergegeven in de lijst met zoekresultaten (doorgaans als percentage), maar altijd wordt ze gebruikt om de gevonden resultaten te sorteren – de zgn. ranking. De wijze waarop deze ranking tot stand komt varieert sterk van oplossing tot oplossing. Het kan zijn dat er simpelweg de aantallen voorkomens van woorden uit de zoekterm in de tekst wordt geteld, of dat er ingewikkelder methoden worden toegepast zoals het proberen af te leiden van een onderwerp in zowel zoekterm als tekst en deze worden vergeleken (bijvoorbeeld de ‘fingerprinting’ techniek van Autonomy). Het is van belang om te realiseren dat deze verschillen in ranking technieken kunnen en ook zullen leiden tot andere resultaten, en mogelijk tot inhoudelijke bias. Bedenk bijvoorbeeld dat een zoekmachine die van de letterlijke tekst uitgaat voor de zoektermen “American infidels” en “American liberators” hele andere resultaten zal teruggeven (waarin de subjectiviteit van de zoekterm in de resultaten is gereflecteerd), terwijl een zoekmachine die eerst beide

20

zoektermen relateert aan het onderwerp “war in Iraq” een meer vergelijkbaar resultaat zal opleveren. Welke van de technieken “beter” is, is niet in het algemeen te zeggen, en zal van het doel van het gebruik van de zoekmachine afhangen. Bij sommige zoekmachines tenslotte, zoals bijvoorbeeld Google, worden ook zaken in de ranking betrokken die betrekkelijk los staan van de zoekterm, zoals de hoeveelheid links naar een pagina toe wat als maat voor “kwaliteit” van de informatie wordt gezien. 4.3 De anatomie van zoektechnologie 4.3.1 Overzicht van de anatomie

In de voorgaande paragrafen hebben we aangegeven waarin zoektechnologie bijzonder is als manier van informatieontsluiting. Hier zullen we dieper ingaan op de manier waarop zoektechnologie zijn doel bereikt, en een universele ontleding in componenten schetsen die voor elke zoektechnologie van toepassing is. Een –voor de ICT- lange tijd geleden kwam het voor dat zoeksoftware pas op het moment dat een zoekopdracht moest worden uitgevoerd alle beschikbare informatie ging doorzoeken op de gezochte termen. Mensen die hebben gewerkt met het DOS commando FIND of de File Search functionaliteit uit oudere Windows versies weten direct hoe traag een dergelijke methode is. De opkomst van grote gedistribueerde gegevensverzamelingen zoals het Internet heeft een dergelijke directe manier van zoeken zelfs ronduit onmogelijk gemaakt. Sinds die tijd bestaat zoektechnologie op hoog niveau altijd uit twee delen: Een deel wat op de achtergrond de informatieverzameling afloopt en indexeert (back-end), en een deel dat op basis van de aangemaakte index zoekvragen beantwoord (front-end). Afleiden semantische structuur

Informatieverzameling

Spidering

Handmatige invoer semantiek

Semantische Structuur

Zoekinterface

Index

Matching zoekterm informatie

Indexering

Figuur 4.2: De anatomie van zoektechnologie: Het back-end (blauw) en frontend (lichtoranje)

Naast de centrale index wordt er ook vaak gebruik gemaakt van centrale opslag en beheer van een semantische structuur waaraan documenten in de index

21

kunnen worden gerelateerd – een categorieënlijst, een woordenboek (thesaurus), een taxonomie (meerlagige classificatieboom) of een ontologie (aanduiding van relaties tussen begrippen). Een dergelijke definitie van semantiek kan vervolgens in de index worden gebruikt om documenten te classificeren, zodat naast het zuivere matchen van voorkomende woorden in de tekst ook intelligenter kan worden gezocht – bijvoorbeeld op synoniemen, foutieve spellingen, verwante begrippen, vertalingen, etc. Het gebruik van de index en semantische structuur voor indirecte informatieontsluiting is goed vergelijkbaar met het gebruik van een catalogus in een (papieren) bibliotheek. We bespreken de voornaamste modulen van het front- en back-end in de volgende paragrafen. 4.3.2 De Spider

De spider module is vernoemd volgens de metafoor van het World Wide Web: spider technologie loopt als een spin in het web links tussen webpagina’s af om nieuwe documenten (pagina’s) te vinden. In dit document gebruiken we het ook voor technologie bedoeld voor andere al dan niet gedistribueerde gegevensverzamelingen zoals directorystructuren of databases, en maken we geen onderscheid tussen de termen crawler en spider. Om zijn werk goed te kunnen doen moet een spider kunnen werken in een omgeving met goed gedefinieerde, gestandaardiseerde communicatieprotocollen. Het Internet, met het gebruik van IP (Internet Protocol) en HTTP (HyperText Transfer Protocol), voldoet hier goed aan. Bij een situatie waarbij men centraal informatie wil ontsluiten die aanwezig is op lokale harde schijven van diverse PC’s wordt daaraan niet voldaan, en zal men maatregelen moeten nemen om de spider toegang tot deze informatie te geven. De spider doet niets anders dan het aflopen en ophalen van informatie – voor de analyse en indexering daarvan geeft de spider deze informatie door aan respectievelijk de indexeringsmodule en de module voor het afleiden van semantische structuren. 4.3.3 Semantische structuren

Semantische structuren geven betekenis van- en relaties tussen woorden en begrippen weer. Een thesaurus of synoniemenwoordenboek is een eenvoudig voorbeeld, en een ontologie een meer complex.12

Knowledge Maps (2) — Different Levels of Fidelity

Types of Metadata

Category Ontological: SHOE, RDF, DAML+OIL, Ontology Exchange Language

Richness of Representation

Knowledge-Based Representations: CBR, Causal models, KRL

Z39.19 Thesauri

Description “IS_broader“ inv “IS_narrower“

Typed Relationships

Taxonomy

Semantic Representations: Knowledge maps, semantic networks, thesauri, topic maps

Advanced thesauri

Classification Systems: Taxonomies, subject heading, hierarchies

Semantic networks

Terms Lists: Indices, glossaries, dictionaries

List of subject terms, related to other subject terms. Relationships can be typed.

vehicle

IS S

ubty OF pe

Ontology

Complexity Copyright © 2003

RDF, Topic Maps, OIL, DAML, RDF-Logic: - constraints, reuse, etc.

ct bje y Su r s ego Ha Cat

Transportation

Air Transportation ct bje y u r S o as eg H Cat Performs aircraft flight process Co Has mp one nt

Aircraft engine

IS OF ce tan Ins

The 2002 transportation industry ... Segmented into air transportation where the most number of passengers..

GE 90

Copyright © 2003

Figuur 4.3: Soorten metadatastructuren 12 Zie voor meer detail de in 2003 te verschijnen trendanalyse over Semantic Web technieken

22

Hoewel semantische structuren onafhankelijk zijn van de gegevensverzameling waarop de zoekmachine werkt, kunnen ze er wel (ten dele) uit worden afgeleid. Zoekmachines kunnen bijvoorbeeld automatisch bij begrippen die in veel documenten bij elkaar voorkomen een inhoudelijk verband vaststellen (veronderstellen) en aan elkaar koppelen. Commercieel verkrijgbare zoekmachines staan vaak ook toe om deze ‘training’ te doen met behulp van een zorgvuldig geselecteerde verzameling documenten zodat foutieve verbanden zoveel mogelijk worden vermeden. Als alternatief is het mogelijk om een bestaande, of handmatig samengestelde, semantische structuur te gebruiken. Een voorbeeld van een generieke taxonomie is de DMOZ directory samengesteld door het Open Directory Project (ODP).13 Deze taxonomie is ondermeer in gebruik bij Google.

Waarom semantiek? “Zoeken op een woord als 'Tjaikovsky' geeft vaak problemen doordat er veel spellingsvarianten van dit woord bestaan. Het zal ook geregeld voorkomen dat er spellingsfouten in de content staan. Of wanneer je zoekt op het woord 'lamp' wil je misschien tegelijk resultaten met de zoektermen 'verlichting' of 'schemerlamp' zien. Veel zoekmachines gaan letterlijk om met de zoekterm die wordt ingetypt, terwijl de gebruiker juist de achterliggende betekenis in zijn hoofd heeft. Wanneer de zoekmachine enige mate van begrip heeft van de betekenis van een zoekterm, dan kan dit helpen bij het bepalen van de juiste zoekopdracht.” (Uit “Zoeken op VenWnet:”) 4.3.4 De Index

Het indexeringsproces indexeert de documenten die het krijgt van de spider. Dit proces creëert een index op de woorden die in het document voorkomen, of -in toenemende mate- een classificatie van (delen van) het document aan de hand van een semantische structuur.

Metadata Structuur

Gegevens

INDEX

Onderwerp A Onderwerp B

A

E

C Onderwerp C

E Onderwerp D

Onderwerp E

Figuur 4.4: De index legt het verband tussen de metadata en de gegevens

23

Bij een ander type gegevensverzameling, een relationele database, wordt ook gesproken van indexen als hulp bij de toegang tot de data. Daar waar een database index echter vooral een efficiëntieverhogend middel is voor toegang tot een in de databasetabellen vastgelegde structuur, wordt een zoekindex (handmatig of automatisch aangemaakt) juist gebruikt om structuur te definiëren. Zo beschouwd is het indexeringsproces in de back-end van een zoekmachine een proces dat een centrale metadata repository opbouwt bij een relatief losse, “ongestructureerde” gegevensverzameling. In de eerder gepresenteerde analogie van een bibliotheek waarin de boeken willekeurig in de kasten staan, is het indexeringsproces de bibliothecaris die een catalogus opbouwt door alle boeken in de bibliotheek af te lopen en van elk een kaartje in de catalogus aan te maken. Een slimme bibliothecaris zal vervolgens als er een nieuw boek arriveert dit direct in de catalogus verwerken – zijn minder slimme collega zal het nieuwe boek meteen in de kast zetten, en de hele bibliotheek periodiek opnieuw indexeren.14 Eerder in dit hoofdstuk relativeerden we al de ogenschijnlijke tegenstelling tussen zoeken en ordenen, of gestructureerde en ongestructureerde gegevens. Hier zien we bevestigd dat dit onderscheid slechts bestaat uit de plaats waar de ordening is gedefinieerd: sterk of zwak gekoppeld aan de gegevens zelf. Een werkelijk verschil bestaat er wel tussen enkelvoudige en eenduidige data, zoals een getal of geocode, en tekstuele gegevens die een meer ambigue betekenis kunnen hebben. 4.3.5 Het User Interface

Niet alleen het creëren van informatie maar ook het gebruik ervan heeft door het Internet een grote mate van liberalisering ondergaan. Was vroeger (lang, lang geleden) het vinden van informatie nog het domein van de bibliothecaris of vakspecialist, tegenwoordig heeft vrijwel iedereen het zoeken ontdekt als panacee van de informatieontsluiting. Door de schijnbare eenvoud van het enkele zoekveld (de ‘search blank’) is onterecht de indruk gewekt dat het zoekproces zelf eenvoudig is – waardoor de taak van het eenvoudig beschikbaar stellen van een complex proces als een boemerang bij het zoekinterface is teruggekomen.15 De interactie tussen gebruiker en zoekmachine bestaat vanzelfsprekend uit twee delen: de opgave van de zoekterm, en de presentatie van de resultaten. Resultatenweergave gebeurt vaak in de vorm van een tekstuele lijst met een korte samenvatting van elk van de hits, soms uitgebreid met de relevantie van het zoekresultaat. Vanuit de resultatenlijst is de oorspronkelijke informatie doorgaans eenvoudig op te roepen.

Een voorbeeld van een ander soort zoekinterface, met een zeer losse koppeling met de achterliggende zoektechnologie, is de Touchgraph Google Browser.16 Deze Java applet geeft een grafische weergave van websites die zijn gerelateerd aan een opgegeven website, en staat ook toe in deze weergave “door te klikken” waardoor nieuwe zoekacties worden uitgevoerd. Op de achtergrond wordt hiervoor de “gewone” Google zoekmachine aangeroepen met de minder bekende, maar niettemin ook in het Google webinterface uit te 13

Zie: http://www.dmoz.org/ Als nieuwe “boeken” niet centraal binnenkomen of worden aangemeld, zoals op het Internet, is de “domme” manier de enige mogelijke – het bestaansrecht van de spider. 15 (Zie: Search Technology Tools Suited for Programs and People) 16 Zie http://touchgraph.com/TGGoogleBrowser.html 14

24

voeren, “related:” zoekaanduiding. Afbeelding 5.6 toont bijvoorbeeld de Google Browser met de grafische weergave van de Google zoekterm: “related:www.rijkswaterstaat.nl”.

Figuur 4.5: Het user-interface van de Touchgraph Google Browser Een soortgelijke grafische weergave kan overigens ook gebruikt worden voor het weergeven van de semantische structuren zoals het voorbeeld van de Visual Thesaurus17 op het Internet toont (afbeelding 4.6). Een voorbeeld van een toepassing van grafische weergave van een thesaurus in een zoekomgeving is de Kennis Browser (zie paragraaf 5.4.5). Ook hier geldt weer dat “browsen” in de grafische weergave leidt tot het uitvoeren van een nieuwe zoekopdracht, waarmee de invoer van de zoekterm en weergave van de resultaten naadloos zijn geïntegreerd. Dit soort zoekinterfaces toont overigens goed aan dat er maar een dunne scheidslijn is tussen het zoeken in- en bladeren door een informatieverzameling, en dat dit verschil zich met name in het user interface bevindt. In beide gevallen wordt gebruik gemaakt van dezelfde index en semantische structuren, maar van een andere presentatiemethode. Dit is ook goed te zien is aan de beide types Google interface op pagina 18. Aan de invoerkant, het stellen van de zoekvraag, zijn er diverse mogelijkheden die sterk samenhangen met de implementatie van de lager in het systeem gelegen zoekmethoden. Hieronder vallen (we beperken ons tot de tekstuele zoektalen): · Keyword based; het bekende zoekinterface van Internet zoekmachines als Google; · Natural Language Processing (NLP); Een zoekterm kan in natuurlijke taal worden ingevoerd, en de zoekmachine zal een poging doen de daadwerkelijke vraag te achterhalen. Dit leunt veel meer op begrip van de vraag dan de simpele keyword methode; 17

Zie http://www.visualthesaurus.com/online/

25

·

XML based; Voor zoeken in XML gegevenscollecties zijn diverse talen of uitbreidingen op bestaande talen in ontwikkeling; zie hoofdstuk 8; SQL based / relational; Zoektalen voor relationele databases; Search by example; deze zoekmethode is veel meer in gebruik voor zoeken in multimedia collecties dan in tekst. Zo werkt IBM aan beelddatabases waarbij de zoekinvoer een ruwe schets van een afbeelding is, en werkt Philips aan het zoeken van muziek op basis van een stukje gezongen, gefloten of geneuriede melodie.

· ·

Figuur 4.6: De online visual thesaurus

Soms kennen deze generieke zoektalen ook toepassingsspecifieke uitbreidingen, bijvoorbeeld voor zoeken in geografische data.

Case: Natural Language Processing “The disadvantages of traditional search engines are well-known and muchdiscussed. Their main drawback is that they enforce a more-or-less exact match between question and answer. Improvements to this keyword-based logic (see “Different Approaches to Accessing Information,” T-13-7030) range from simple thesauri to statistical techniques to NLP-based searching such as One Step. NLP extracts key concepts from the structure of the query and uses those concepts to locate documents. It can match the query and the information-bearing documents more intelligently and is likely to be more successful. However, implementing an NLP search engine takes significant effort (see “Natural Language Interfaces: Do What I Mean,” T-14-2674). Here, we report on Schwab’s deployment of an NLP search engine, which was completed in May 2001. Today, Schwab’s customers can type in natural language queries. Schwab reports that its customers and employees are very satisfied with the new system.” Uit: Gartner: “Schwab ‘Phrases’ a Different Question”

26

Een user interface techniek die goede zoekresultaten oplevert18 is het vooraf laten beperken van het zoekdomein. Als voorbeeld kun je in plaats van in een hele bedrijfswebsite te laten zoeken (waarbij je mogelijk resultaten krijgt uit zowel de biografieën van de directie als uit de software downloads sectie) de gebruiker op voorhand een categorieselectie kunnen laten uitvoeren. Een vergelijkbare techniek is het opnieuw laten zoeken binnen een reeds gevonden zoekresultaat. 4.3.6 Programmatisch interface

Het feit dat steeds meer informatie achter een zoekinterface verdwijnt, ook gegevens die van belang zijn voor verdere verwerking elders, leidt er volgens het Gartner onderzoeksbureau toe dat zoekmachines in toenemende mate zullen worden benaderd door software in plaats van mensen (zie tekstbox). Om deze toegang mogelijk te maken moet er behalve het user interface ook een programmatisch interface beschikbaar zijn op de zoekfunctionaliteit. Het door Gartner genoemde SOAP (Web Services) interface op Google19 kan bijvoorbeeld gebruikt worden om andere user interfaces te voorzien van zoekfunctionaliteit. Deze ontwikkeling kan tevens tot gevolg hebben dat verschillende programmatuur die voorheen direct toegang tot de data had, nu gezamenlijk gebruik maakt van een enkel zoekinterface. Dit hergebruik van (zoek)software kan leiden tot eenduidiger gebruik en minder onderhoud.

Een zoekinterface voor software […] search blanks are increasingly common. A number of forces, however, are converging to elevate the utility of search technology to serve as a tier for locating and integrating unstructured and structured data into the fabric of enterprise applications. In this model, programmatic invocation of search functionality is more common than a user's invocation of the search function. An application selects a key word based on programmed rules and resident data, then invokes a search on the user's behalf. Such a model may seem exotic, but when it is considered as the natural outgrowth of a database query, which is the origin of much of modern search technology, it is clearly inevitable. By YE04, more than one-half of the invocations of search technology within 20 percent of enterprises will be programmatic in origin (0.7 probability). Drivers for this trend include the increasing popularity of Web services interfaces, particularly Simple Object Access Protocol (SOAP), which facilitates the process of posing queries to databases and other content repositories. Google has publicized its application programming interface, which allowed for a SOAP interface, and other search engines have done the same. Uit Gartner: “Search Technology Tools Suited for Programs and People”

4.3.7 Drie-lagen model

In de ICT is een gebruikelijke manier om systemen te beschouwen een onderverdeling in gegevensopslag (en toegang), business logic (de regels en logica die de toepassing specifiek maken) en user interface. Dit zgn. drie-lagen model (three-tier model, of algemener het multi-tier model)20 is bij uitstek, maar niet exclusief, te gebruiken voor de beschrijving van Web applicaties. 18

Zie Gartner: Technology for Enterprise Search Comes in Many Flavors Documentatie over het Google Web Services interface: http://www.google.nl/apis/ 20 Beide zijn weer een veralgemenisering van het twee-lagen model (het client-server model) 19

27

Daarbij is de Web browser te beschouwen als de user interface laag, de web applicatie op de web server als de business logic en de achterliggende gegevens (database) vanzelfsprekend als de gegevensopslag. Tussen deze lagen bevindt zich bijna als regel een netwerk. Moderne zoektechnologie is bij uitstek netwerkgeoriënteerd, en als we de componenten van zoektechnologie uit figuur 4.2 herordenen dan zien we ook dat deze goed in de genoemde drie lagen zijn onder te verdelen (Figuur 4.7). Handmatige invoer semantiek

Afleiden semantische structuur


Spidering

Zoekinterface


Indexering


Index

Figuur 4.7: De anatomie van zoektechnologie in het drielagenmodel

De reden om deze modules in een gestandaardiseerde drie-lagen structuur te tonen is dat dit helpt bij het inpassen van zoektechnologie in een bredere architectuur voor informatiebeheer zoals in het geval van WADI. De middelste business logic laag heeft de afgelopen jaren een grote mate van formalisering ondergaan door de opkomst van applicatie-servers op basis van bijvoorbeeld J2EE of .NET technologie. 4.3.8 Security

Niet zozeer een module als wel een aspect van een zoeksysteem is beveiliging. De overgang van gesloten informatiesystemen naar gedistribueerde heeft op dat vlak een aantal consequenties gehad, die dubbel en dwars gelden voor zoektechnologie. Bij gedistribueerde gegevensverzamelingen geldt dat deze ieder mogelijk andere rechteninstellingen hebben, of zelfs voorzien zijn van een geheel andere rechtentechnologie. Wanneer beveiliging van belang is bij de inzet van zoektechnologie, zal hier op de een of andere manier een integratie moeten plaatsvinden.21 Behalve praktische zaken zoals het koppelen van diverse beveiligingssystemen, valt er ook een afweging te maken welk soort beveiliging noodzakelijk en afdoende is in een bepaalde omgeving. In Making Search Installations Secure maakt het Gartner onderzoekbureau de volgende driedeling:

21

Zie Gartner: “Making Search Installations Secure,” SPA-16-0809

28

“A variety of methods are available for addressing user privilege in searching for, detecting and retrieving documents or other objects (such as catalog entries). They are, loosely: 1. Limiting searchable documents to those that are generally available to all individuals with access to a search function. 2. Requiring all users to log into individual documents or repositories when invoked from a list of search results. 3. Discerning a user’s privileges at query time to limit results and provide access to only those documents that a user may see under policy.” 4.3.9 Personificatie

Een ander aspect dat vaak wordt aangehaald bij de discussie van zoektechnologie is personificatie, ofwel het aanpassen van de zoekactie of resultatenweergave aan de hand van een persoonlijk (of groepsgebonden) profiel. Personificatie vindt altijd plaats op basis van een categorieënindeling of andere semantiek, zoals die reeds in standaard zoektechnologie is opgenomen. In dat opzicht kan personificatie bij zoeken worden beschouwd als een in een profiel opgenomen voorselectie van informatie of een extra vernauwing van de zoekterm. De plaats van het profiel is daardoor in het user-interface, en de invloed op de rest van de modulen in het zoeksysteem is nihil (of zou dat moeten zijn). Informatie push, ofwel het actief gebruikers attenderen op bepaalde informatie op basis van hun profiel, is een andere implementatie van personificatie. Wanneer echter de behoefte ontstaat aan meer geavanceerde functies zoals het reageren op trends, ontwikkelingen met een tijdsaspect, dan kom je echter al gauw op het domein van analysetools en Business Intelligence (BI). 4.4 “Zoeken” in relatie tot andere ICT gebieden

In de voorgaande paragrafen hebben we gekeken naar de anatomie van zoektechnologieën – een interne blik. In deze paragraaf willen we deze blik verruimen, en zoektechnologie plaatsen in een groter geheel. Met het vergelijken van zoeken met database querying hebben we al eerder aandacht besteed aan de relatie met (relationele) databases. In hoofdstuk 6 gaan we hier verder op in. Content management en kennis management zijn twee toepassingsgebieden die zwaar gebruik maken van zoektechnologie. Deze behandelen we verder in hoofdstuk 5 over Enterprise Search. Enterprise Application Integration (EAI) en Information Integration (EII) delen veel van de doelstellingen van zoektechnologie, met name het centraal toegankelijk willen maken van decentrale informatieverzamelingen. In hoofdstuk 7 zullen we deze vergelijking uitdiepen, en kijken of het meer is dan een verschil tussen gestructureerde en ongestructureerde data. In een hele andere hoek zien we de populariteit van peer-to-peer (p2p) software. Dit is de benaming voor elke genetwerkte software-infrastructuur die onafhankelijk is van centrale servers, en de bekendste toepassing is de filesharing door programma’s als KaZaa. Een minder controversiele applicatie

29

gericht op bedrijfstoepassing is Groove22, wat kort kan worden omschreven als een “serverless Lotus Notes”. Beide toepassingen bieden zoekmogelijkheden. Omdat WADI expliciet een centrale structuur voorstaat is er in dit onderzoek verder geen aandacht aan p2p mogelijkheden besteed. Agent technologie tenslotte is een al lange tijd veelbelovende techniek voor eenvoudiger informatieontsluiting. Er bevindt zich echter nog steeds een groot gat tussen de “agents” in praktische toepassingen (doorgaans simpele personificatiemodules), en de belofte van autonome systemen die voor de eigenaar vrijwel automatisch de juiste informatie op het netwerk bij elkaar sprokkelen. Analistenbureau’s besteden de laatste jaren nauwelijks meer aandacht aan agent technologie,23 en een rapport van de Europese onderzoeksgroep Agentlink24 plaatst generiek toepasbare Agents (zonder uitgebreide custom programmering) nog op de lange termijn – onder andere om de belangrijke reden dat standaardisatie zich nog in een zeer pril stadium bevindt.

Figuur 4.8: Roadmap van Agent Technologie zoals gepresenteerd in het AgentLink rapport. Merk op dat dit de meest optimistische schatting is (uitgaande van de juiste investeringen op het juiste tijdstip), die bovendien is gemaakt door “voorstanders” van Agent technologie. 22

Zie http://www.groove.net De meest recente publicatie van de Butler Group is: “The Impact of Agents on Corporate Intelligence”, uit januari 2001

23

30

Het valt overigens te verwachten dat zelfs de impact van vergaande agent technologie op zoeken vooral zal plaatsvinden bij het vinden van informatie, dus de spider technologie. De logica voor het ordenen van gegevens en het evalueren van een zoekterm zullen in de basis weinig veranderen – met dien verstande dat multi-agent systems mogelijk gebruikt kunnen worden voor de distributie van het aanleren van semantiek.

4.5 Zoektechnologie en WADI

In dit hoofdstuk is een beeld geschetst van de anatomie van (Internet) zoektechnologie en de invloed die het Internet heeft gehad op de ontwikkeling daarvan. Het begrip hiervan is essentieel bij het evalueren van zoektechnologie voor gebruik binnen WADI. Zo gebruiken bijvoorbeeld veel op Internet (en intranet) gerichte zoekmachines onderlinge links tussen webpagina’s voor onderwerpen relevantiebepaling, en dat is in een database georiënteerd systeem als WADI niet van toepassing. In het algemeen is zoektechnologie ontwikkeld voor het organiseren en ontsluiten van ongestructureerde gegevens – dit in tegenstelling tot ontsluiting van gestructureerde gegevens met behulp van bijvoorbeeld een taal als SQL. Bij ongestructureerde data denken we eerder aan een documentenverzameling, dan aan een sterk gestructureerde database zoals voor WADI is gepland, en het lijkt op het eerste gezicht dan ook dat zoektechnologie weinig voor WADI kan betekenen. Hoewel WADI met opzet niet ook als documentmanagementsysteem is gepositioneerd, worden er op basis van de gegevens uit WADI (momenteel DONAR) veel rapporten en andere documenten geproduceerd. Het is mogelijk dat het meenemen van deze documenten in een zoektoepassing de ontsluiting van de brongegevens in WADI ook kan verbeteren. We hebben gezien dat zoektechnologie grofweg bestaat uit het (automatisch) opbouwen van relaties (metadata) en het slim doorzoeken daarvan. Binnen dit concept, dat geldt voor alle zoektechnologie, is er sprake van een toenemende intelligentie waarbij het simpel ordenen van gegevens op basis van letterlijke keywords wordt ingehaald door gebruik van relaties tussen woorden en daardoor correcte behandeling van synoniemen, vertalingen, foutieve schrijfwijzen, etc. In deze complexere metadata structuur zijn wel raakvlakken met WADI te zien, waarvan immers het systeemconcept in figuur 3.3 een belangrijke zelfstandige integrerende rol voor metadata schetst. Vanuit het zoekperspectief bestaan de WADI metadata structuren uit twee delen: De vastgestelde standaarden zoals IDsW, en de vrijere woordassociaties ten behoeve van gegevensontsluiting door niet-vakexperts die niet op voorhand kunnen worden bepaald (zoals de associatie van de zoekterm “verontreiniging” met de systeemvelden “cadmium/kwik/lood concentraties”). Actief metadata management, bijvoorbeeld zoals dit is geïmplementeerd in de grotere zoekmachines, kan helpen bij het koppelen tussen deze twee soorten structuren en zelfs bij het koppelen van verschillende standaarden als IDsW en CEN – waarbij men in het laatste geval echter niet moet verwachten dat een koppeling tussen diverse metadata stelsels een echte (handmatige) integratie kan vervangen.

24

Agent Technology: Enabling Next Generation Computing; A Roadmap for Agent Based Computing”; AgentLink, January 2003

31

Zoektechnologie kan ook helpen bij het automatisch afleiden van een thesaurus of andere metadata structuur uit brongegevens. Dit zou toepasbaar moeten zijn voor het vinden van woord-relaties tussen “lekentaal” en IDsW, zoals de hierbovengenoemde “verontreiniging” die herleid kan worden tot “cadmium / kwik / lood concentraties”. Een punt van aandacht hierbij is echter dat er tekstuele brongegevens beschikbaar moeten zijn waaruit deze relaties zijn af te leiden, dus informatie die beide “talen” in dezelfde context gebruikt. Bij het mogelijke gebruik van zoektechnologie voor het ontsluiten van gegevens die nog niet in WADI zijn ingevoerd speelt behalve bovenstaande metadata kwestie ook mee dat deze gegevens fysiek beschikbaar moeten zijn – zoektechnologie werkt zoals gezegd alleen in een situatie waarbij de communicatie gestandaardiseerd is. Het is zeer de vraag of het de moeite waard is een oplossing te implementeren die automatisch “op zoek gaat” naar dit soort informatie – een eenvoudiger implementatie zou toestaan om “ongestandaardiseerde” data wel handmatig centraal op te slaan maar als “onofficieel” te markeren. Omdat WADI uitgaat van het gebruik van verschillende (analyse)tools die het gebruikersinterface op de WADI data gaan bieden, is het waarschijnlijk dat eventueel gebruikte zoektechnologie ook programmatisch toegankelijk zal moeten zijn. Dit past in een algemene trend, en betekent concreet vooral dat eventueel toegepaste zoektechnologie niet sterk moet worden gekoppeld aan een specifiek (web)userinterface.

32

5 Internet en Enterprise Zoekmachines 5.1 Introductie

Hoewel er op zoekgebied grote verschillen zijn tussen het Internet en een enterprise omgeving (zo zou het geen goede zaak zijn als medewerkers moedwillig zouden proberen een zoekmachine te misleiden) zijn er net zo goed vele overeenkomsten. Een moderne bedrijfsomgeving is vaak zeer divers en bestaat als gevolg van de recente golf van fusies en reorganisaties vaak zelfs uit voorheen verschillende organisaties. Diverse schattingen komen uit op het gegeven dat ongeveer 80% à 90% van bedrijfsinformatie alleen beschikbaar is in “ongestructureerde” vorm (documenten), en intranetten nemen steeds vaker een centrale rol in bij de informatievoorziening. Enterprise search heeft zich dan ook ontwikkeld tot een aparte markt, waarvan de spelers directe afgeleiden zijn van Internet zoekbedrijven of sterk gebruik maken van technieken die voor het Internet zijn ontwikkeld. Daarnaast hebben enterprise zoekmachines zich gericht op het ontsluiten van informatie die meer specifiek is voor een bedrijfsomgeving, door uitbreiding met het kunnen lezen van veel diverse bestandsformaten en adapters voor het lezen van informatie uit bedrijfssystemen en databases. Veel van de in dit hoofdstuk gepresenteerde zoekmachines zijn het stadium van het enkel zoeken gepasseerd, en presenteren zich als universele oplossing om bedrijfsinformatie te ontsluiten. Deze enterprise oplossingen reflecteren dat ook in hun prijskaartje, en een belangrijke vraag bij het overwegen van dit soort software dient dan ook te zijn of het gebruik geen overdaad is – en een deel van de functionaliteit wellicht overbodig is, of zelfs al anderszins beschikbaar is. Tenslotte waarschuwt Gartner dat men uit de sterk toegenomen zakelijke rol van zoektechnologie nog niet mag afleiden dat de markt volwassen is:25 “Bottom Line: Search technology’s increasing ubiquity should not be construed as maturity. Enterprises must carefully map the needs of projects and should expect vendor selection for search to be arduous through YE04.” 5.2 Gartner Enterprise Search Magic Quadrant

De Gartner onderzoeksfirma deelt bedrijven en producten in ICT gebieden vaak in in hun zogenaamde magic quadrant – een vierdeling op basis van de twee assen visie en het vermogen om daadwerkelijk te leveren.26

Figuur 5.1: Gartner Enterprise Search Magic Quadrant 25

Zie Gartner: “Search Technology’s Presence Grows, but Maturity Is Slow” Zie Gartner: “Management Update: Many Vendors, Two Leaders in Search Engine Magic Quadrant”

26

33

Gartner Enterprise Search Magic Quadrant 2003 Leaders Autonomy and Verity are the Leaders in Gartner’s Search Engine Magic Quadrant for 2003. They approached the challenge of information location differently. Verity chose a word-by-word sleuthing perspective, and Autonomy chose a pattern-matching, keyword-unexamined direction. Autonomy. This vendor remains highly adept at pattern-matching and word-independent consideration of the content it indexes and processes. However, because it lacks a direct service division, it is handicapped in developing marquee installations and installations for midsize businesses that sometimes prefer not to use expensive systems integrators. It provides a broad spectrum of pricing options but tends to be priced higher, on average, than other vendors. Verity. This vendor’s roots in keyword location and related relevancy analysis, where the word is the critical foundation for comprehension, is different than the Autonomy approach. Just as Autonomy has developed a credible search product, Verity has expanded its ability to address high-sophistication pattern matching and is now capable of matching Autonomy in many deals. Verity’s acquisition of Ultraseek is simultaneously a cause for concern and a reason to be hopeful. Verity will find it challenging to produce a one-size-fits-all, variably priced product from the purchase. Success in doing so would benefit its status as a leader. Visionaries All vendors in this category demonstrated strong flexibility for query input and results output. They also provide flexible, service-oriented architectures capable of interacting dynamically with applications that do not generate documents as output, but that generate values, details or reports. Convera. Substantial financial challenges during 2002 placed Convera in a difficult position with many enterprise prospects. However, it maintained a considerable flow of new customers and continues to provide remarkable scale and a variety of critical features, including cross-lingual search and retrieval for internationalization and government practices. Convera has stemmed losses through significant staff reductions to focus on enterprise search. It continues to offer multimedia-centric search through its Screening Room product. Niche Players Google. The Web search engine and advertising vendor’s innovative appliance continues to ride its brand power, general utility and low price to success among enterprises. It convincingly demonstrates that its Web-wide relevancy innovation of “PageRank” (which analyzes links among Web sites, and factors the popularity picture into results order) is not its only means of providing useful results. However, Google has fewer ways to manage relevancy, limited methods for indexing data in nonstatic repositories and only simple approaches to query syntax. Its three business divisions — Google.com, portal services and the search appliance — raise the potential for distraction.

5.3 De Enterprise Search markt

Waarop zijn producten in de Enterprise Search markt te onderscheiden? Allereerst in de mate van complexiteit. Gartner onderscheidt27 een basale toepassing waarbij eenvoudig zoeken op woorden in de tekst voldoet – welke simpele opdracht door alle zoekmachines kan worden uitgevoerd. Het enige onderlinge verschil tussen applicaties in dit segment is de methode voor ranking van de resultaten. Voor veel bedrijfstoepassingen is deze techniek voldoende – zolang de documentverzameling niet te groot of complex wordt. In de bovenkant van de markt bevinden zich de leveranciers van meer complexe producten, die naast zoeken ook navigeren ondersteunen als mogelijkheid om informatie te vinden, en technieken toepassen als classificatie en het genereren van taxonomieën. Andere features omvatten mogelijk personificatie, actieve informatiedistributie, notificaties en het vinden van gerelateerde documenten of het suggereren van content aan de hand van de

27

Zie Gartner: “Technology for Enterprise Search Comes in Many Flavors”

34

interesses van soortgelijke gebruikers. Gartner noemt de producten van Verity, Lotus en Autonomy als exponenten van dit hogere marktsegment.

Search by Query (1) Category Keywordbased

Thesauribased

Description Boolean, Fuzzy, Stemming, TF-IDF Vendors: AltaVista, Verity, Inktomi, Thunderstone Synonyms, Homonyms, Other Relationships Vendors: Convera, Verity, LexiQuest, Lotus Statistical Thesauri

Statisticsbased

Vendors: Autonomy

Evaluation + easy-to-use + easy to install/maint. + cheap + widespread - diff. terminologies - thesaurus creation and maintenance - may decrease accuracy + improved recall + great for different terminologies + precision and recall - needs lots of text - lack of control - maintenance Copyright © 2003

Figuur 5.2: Gartner vergelijking van drie soorten zoekmethoden

Deze producten gebruiken globaal gezien twee soorten technieken om de precisie en relevantie van zoekresultaten te vergroten ten opzichte van het direct zoeken op woorden: · Linguïstische technieken om concepten in documenten te herkennen zonder de noodzaak om woorden letterlijk terug te vinden. Een voorbeeld van deze implementatie zijn de Semantic Nets van Convera. · Statistische patroonherkenning, bijvoorbeeld op basis van het in combinatie voorkomen van bepaalde woorden. Deze techniek wordt bijvoorbeeld gebruikt door Autonomy en Lotus in zijn Discovery Server. Dit onderscheid dat Gartner maakt komt neer op de wijze waarop semantische structuren (zoals beschreven in paragraaf 4.3.3) worden aangeleerd: in het eerste geval opgebouwd uit een bestaande of bewust gecreëerd woordenboek, en in het tweede geval automatisch afgeleid uit de gegevens zelf. Geen van beide technieken biedt garanties voor goede resultaten: woordenboeken kunnen van slechte kwaliteit zijn, en statistieken moeten op basis van een goede set gegevens worden afgeleid. Er bestaan echter geen algemeen toepasbare benchmarks voor de kwaliteit van zoekresultaten, dus een goede productevaluatie omvat ook een evaluatie met eigen data en echte gebruikers. Statistische technieken hebben de mogelijkheid om gaandeweg het gebruik bij te leren, maar hebben als nadeel dat de resultaten uit een black box komen – het is vrijwel onmogelijk te herleiden waarom de zoekmachine tot bepaalde antwoorden is gekomen. Een geheel onafhankelijke categorie producten richt zich uitsluitend op het categoriseren van gegevens, en telt leveranciers als Semio, Stratify, Sageware en Quiver. Endeca en 80-20 proberen ook het zoekprobleem door middel van categorisatie op te lossen.

35

5.4 Produkten en produktontwikkeling 5.4.1 Autonomy

Autonomy28 wordt vrijwel unaniem als het topklasse product voor generieke informatieontsluiting gezien. Dit betekent vanzelfsprekend een navenant prijskaartje, maar door zijn positie is het wel mogelijk om Autonomy als gouden standaard te zien en overige producten er tegen af te zetten. Aangenomen dat marktleiderschap tenminste deels is toe te schrijven aan innovatie en visie (zie Gartner magic quadrant, figuur 5.1) kan het beschouwen van Autonomy producten ook inzicht geven in de toekomst van de enterprise search markt. Zelf omschrijft Autonomy zich kernachtig als “Autonomy is the leading provider of software infrastructure that automates operations on unstructured information”. Het valt op dat ze zich zeker niet beperken tot “zoektechnologie” in de enge betekenis van het woord, en dit wordt alleen maar duidelijker als we in de volgende tekst lezen dat men zich richt op ontsluiting van alle vormen van ongestructureerde, semi-gestructureerde en gestructureerde informatie, en behalve zuivere ontsluiting ook software aanbiedt voor personalisatie en het automatisch maken van samenvattingen:29 “Technology Introduction Autonomy's unique combination of technologies provides an automatic solution for the categorization, summarization, personalization, hyperlinking and retrieval of all forms of unstructured, semi-structured and structured information. Because Autonomy is a horizontal technology, it is able to intelligently manage information within many different software environments, from CRM systems to portals to HR applications. Proven, high levels of ROI are provided by Autonomy's automatic solution. However, Autonomy's open philosophy enables us to offer in addition the full range of legacy manual approaches, allowing the customer to choose the most suitable options for their business. Unlike so-called 'Black Box' technologies that do not allow users to understand why particular results are returned, Autonomy is a transparent technology, enabling the manual editing of keywords, relationships and weightings […].“ Een (eigen) querytaal maakt het mogelijk om zoekacties te doen over de vrije tekst en tegelijkertijd exacte restricties op te leggen aan de bijbehorende metadata. Personificatie en attendering gebeurt met behulp van wat Autonomy agent technologie noemt, en dat het brede aandachtsgebied zich uitstrekt tot kennismanagement blijkt uit de out-of-the-box functionaliteit om ook de kennis die bij menselijke experts aanwezig is te kanaliseren door middel van een personen-zoekfunctie. Voor de categorisering van content maakt Autonomy gebruik van statistische clustering op basis van “concepten” in plaats van linguïstische technieken: “Rather than computer linguistics or keywords, Autonomy's strength lies in its use of high performance pattern matching algorithms and probability theory. This provides a comprehensive infrastructure for automating the processing of unstructured information, including but by no means limited to, search.” Autonomy presenteert zijn product als een gemodulariseerd systeem, bestaande uit de volgende modules: · Query/Indexing 28 29

Zie: http://www.autonomy.com/ Alle citaten zijn afkomstig van de Autonomy website en produktinformatie

36

· · · · · · ·

Agent Query/Indexing User Agent User Profiling Import Spider Categorization Schedule

Deze modules zijn op diverse manieren van buitenaf aan te spreken, en hoewel de website daar niet geheel eenduidig over is tenminste deels ook via Web Services protocollen (o.a. SOAP): “Autonomy's Intelligent Data Operating Layer enables organizations to seamlessly integrate with other systems across intranets, extranets and the Internet. Founded on a technology that is modular by design and facilitates global distribution, Autonomy has developed a flexible infrastructure that allows optional use of the latest Web Service standards including Simple Object Access Protocol (SOAP), and Web services Description Language (WSDL) to enable organizations to build innovative e-business solutions. Coupled with full support for J2EE environments and EJB, Autonomy has ensured that the technology can be rolled out in any environment.” De MD begeleidt sinds kort twee pilot projecten met autonomy (zie par. 9.3)

Figuur 5.3: Autonomy - indeling in componenten met aparte programma interfaces

5.4.2 Verity

De tekst van deze paragraaf is overgenomen uit het Gartner artikel “Verity: Refocusing on Search Market With New K2 Product”. Verity has been a long-time player in the information retrieval market. It made a late and ineffective entry to the portal market. With the release of K2, Verity returns to its core market. Verity is one of the original vendors providing information-access solutions. In February 1999, we noted that Verity was among five vendors surviving the market turbulence of that time (see "Established Vendors for Enterprise Information Retrieval," T-06-9639). The rationalization of intranets was gaining

37

importance and knowledge management was providing a business framework for consideration of information retrieval. Of the other four vendors: · Dataware has since exited the business. · Open Text has not offered a search product independent of its Livelink suite. · Excalibur changed its name to Convera. In a joint venture with a division of Intel and with a failed attempt to address the digital media market, it has to regroup around its RetrievalWare search product. · Fulcrum was bought by PC DOCS, which was then bought by Hummingbird. Fulcrum's product has only now been integrated within a coherent suite. Since 1999, Autonomy has emerged as a leading competitor for high-end information retrieval requirements, although it prefers to market itself as offering information categorization infrastructure and disdains an association with mere search. A number of the search engines born on the Internet have attempted to enter the enterprise information retrieval space, but only Inktomi (with the purchase of Ultraseek, formerly Infoseek) and AltaVista have made a significant showing. Google is attempting this transition with an interesting twist, by offering its engine as an "appliance" (i.e., combined hardware and software solution). Verity's Strategy: Verity has been on its own journey. Noting the difficulty in sustaining a position in the confused information retrieval market, and finding its search technology needing substantial investment to remain leading edge, it attempted to enter the portal market with its Portal One product. Verity was a late entrant in a market suffering from enormous hype, and had little differentiation. It also found that it was competing with many of its customers, since Verity had become the leading OEM search engine. During 2001, Verity reversed this strategy and started reinvesting in search technology. In 2002 it stopped marketing Portal One and introduced a muchexpanded search product named K2. The K2 name was not new. It had been used for the multiserver configuration of its earlier-generation technology, which Verity used on a project basis for some large customers. However, the current K2 product is substantially new and includes many features not part of the old Information Server product. The K2 Product Set: Although K2 is a single technology and architecture, it is delivered in a range of products. Verity is attempting to provide a product that spans the requirement for basic search, where its old Information Server product would suffice (e.g., competing with Microsoft's Index Server and now SharePoint Portal Server search), through to sophisticated information management to reverse the inroads Autonomy has been making in this market. Verity also has to address its OEM base, providing an effective transition in both technology and price for customers who often only require basic capability. The result is a complex product structure and marketing approach. Using the same core technology for multiple products, Verity is offering three product families: · K2 Enterprise, targeted at internal or knowledge-intensive applications · K2 Developer, primarily for OEM partners · K2 Catalog for the search feature on externally facing Web sites (typically e-commerce applications)

38

The functionality of K2 is presented as three "tiers": · Organize — classification of information (extending the capabilities offered by Verity Topics, providing a range of classification and taxonomy-building options) · Discover — information retrieval in various forms, including parametric search and management of secure access · Connect — use of profiling to link users and information, with expertise location capability K2 Enterprise is delivered in four licensing options: bronze, silver, gold and platinum. Bronze provides basic search functions with spidering/crawling; silver adds multiprocessor support and access management; gold adds taxonomy creation; and platinum introduces user profiling, recommendation and expert location. For OEM customers, the functionality is broken out in different combinations. Verity also offers backward compatibility with its previous APIs (VDK) in K2 Developer. This complexity is due, in part, to the immaturity of the market for advanced information retrieval products. Verity is marketing a conceptual framework (organize, discover, connect), while delivering a product with a different structure (four license options). Autonomy demonstrates this dilemma even more strongly with marketing that has no substantial feature content and a product structure that is evolving toward middleware. Stratify is leaning toward Autonomy-like middleware, and Lotus is emphasizing the business framework of knowledge management. Verity also reflects this market phase by maintaining deal-based pricing and refusing to establish clear price points in the market. Enterprises should be prepared to establish their own competitive benchmarks against Autonomy or IBM-Lotus (Discovery Server) for high-end functionality, or against Inktomi or Microsoft for more-basic search. Product Strategy: Deliver a full-range search and information retrieval solution capable of satisfying the need for basic search, as well as sophisticated requirements including information categorization, taxonomy generation and user profiling. Strengths: · Broad and mature understanding of search market and requirements. · Engineering capability. · Wide range of connectors for document repositories and ability to process many document formats. Challenges: · Improve positioning against a wide range of competitors, covering both more- and less-sophisticated requirements, including vendors such as Autonomy and Google focused on information retrieval, and broad-range vendors, notably Microsoft and IBM-Lotus. · Lack of benchmarks to compare search products in an objective way, leading to lowest-common-denominator solutions. · Lack of clear price points in the market, and difficulty in establishing clear value-proposition for Verity solution vs. any other. Consider This Product When: · Looking for a solution with a broad range of capabilities. · Offered a price that is competitive to alternatives. Consider Alternatives When: · Targeting a single-usage model (e.g., search of Web sites only; search embedded in an e-commerce system).

39

· ·

Search available within a portal, content management or team collaboration-support product is sufficient (may be an OEM version of K2). Willing to adopt multiple search products for different needs and users, which may often be the most-cost-effective solution overall.

Bottom Line: With the new K2 product, Verity returns to the list of front runners in the information retrieval market. Enterprises should consider K2 as an option when looking for a search product, but ensure the options selected match the intended use and negotiate on price using competitive offers. 5.4.3 Inktomi

De tekst van deze paragraaf is overgenomen uit het Gartner artikel “Inktomi Enterprise Search: Maturing the Ultraseek Promise”. The technology formerly known as Ultraseek, now at Inktomi, has matured so that enterprises considering internal or external installations that focus on multiple repositories of documents or other data should consider it. Inktomi's Enterprise Search applications are aggressively priced and attractive for basic search installations in enterprises for outward- or inward-facing installations. Inktomi's greatest challenge will be in driving development of value-added applications, such as modules for customer relationship management and self-service. Inktomi's original technical focus was on significantly parallelprocessing applications; its Web-wide search technology, for a while generally considered the most comprehensive and effective for the Internet at large, was the foundation for its caching and traffic management products. Like many other technology vendors, Inktomi's acquisition strategy has sought to bolster its original mission. Roots in Web Portals The Ultraseek technology, now the basis for Inktomi Enterprise Search, was developed within Infoseek, a pioneer of Web-wide and mixed proprietary/Web search technologies familiar to those who used the Internet in 1995 or earlier. The technology initially was sponsored by Sun Microsystems as an "AltaVista killer," when that engine was driving prominence for the former Digital Equipment's high-end servers. (Inktomi Enterprise search does not tap the parallel model of Inktomi's earliest installations, but relies on powerful Unix servers to run.) Disney ultimately acquired Infoseek through a series of complex transactions, but shuttered its business successor, Go, in June 2000. Inktomi acquired the enterprise search technology from Disney prior to Go's ultimate demise. Inktomi has aggressively expanded its customer base in the period following the acquisition. The vendor claims more than 2,500 enterprise users, including smaller enterprises that download and install the software themselves, and extremely large customers such as Hewlett-Packard and Sony, as well as longtime user, and initial sponsor, Sun. Inktomi has expanded the offering from an initial focus on HTML and other common document types, such as Microsoft Word and Adobe Acrobat, to include database-driven dynamic repositories of documents and content management systems. These auspicious improvements, as well as Inktomi's internal commitments to the search division, including increased sales staff and development spending, improve the likelihood that the vendor will not turn away from enterprise search.

40

Strong Partners Netegrity is Inktomi's partner for single-sign-on support, an increasingly critical aspect of enterprise search technologies as their scope is expanded throughout public and sensitive or secure data within an enterprise. Netegrity has developed a strong palette of connectors for integration to Microsoft SQL Server, Oracle, Sybase and DB2 relational database management systems, and also offers an Open Database Connectivity connector. Its content management roster includes Documentum, Broadvision and Interwoven (but excepts Vignette). These formats have become central to many search strategies. However, Inktomi still lacks the ability to index the most esoteric formats, including multimedia file formats and image formats. Also, its relevancy is strong on delivery, but does not offer the sorts of complex, fine-tunable relevance methodologies that are the stock-in-trade of Verity, Autonomy and other vendors of more-expensive products. This will be a hindrance in knowledge management-style installations, but should not be considered a major detractor in more-general-purpose installations. Product Strategy: Inktomi is aggressively priced: An enterprise with fewer than 100,000 documents available via Internet protocols should expect a base price lower than $50,000. Many installations are markedly less. The vendor's long-term strategy seeks to develop its technology into serving a variety of other information-intensive applications, from families that include customer relationship management and knowledge management. Its per-page pricing strategy and simple installation have won it a strong reputation in unsophisticated installations; its central challenge is developing a reputation for handling more-extensive and customized projects with an internal service division and service partners. Strengths: · Per-page pricing makes it inexpensive for starter projects · It has partnerships with content management, portal and security vendors · The compatibility of its relational database management system is broader than that of some rivals Challenges: · An immature sales and integration channel · No Web-services-standard readiness · No vertical specialty Consider This Product When: · Per-page pricing will result in an advantageous deal · Your user base is experienced in search query construction skills · Federated search of a limited external Web environment will be necessary · Dynamic repositories include one or more from Oracle, Sybase, IBM or Microsoft (SQL Server) · Netegrity is already in-house as a single-sign-on vendor Consider Alternatives When: · An extremely low price or an application service provider model is necessary · Dynamic page repository does not include a supported vendor or standard application programming interface · Advanced methods, such as native taxonomy generation, are required

41

Bottom Line: Through 1H03, Inktomi will remain a moderately priced and robust search solution for document location and retrieval. Its major long-term challenge is to reconcile its reasonable cost with the need to match market leaders in vision and creativity. Enterprises considering search installations for external applications or intranets should consider Inktomi. 5.4.4 Google-in-a-box

Google functionaliteit is sinds enige tijd ook beschikbaar in de vorm van een zgn. appliance, een oplossing bestaande uit een bundeling van soft- en hardware.30 Het product is bedoeld om eenvoudig bruikbare, goed te onderscheiden zoekfunctionaliteit te bieden voor corporate inter- en intranetsites. Google is een echte Internet oplossing, in die zin dat er voor relevantiebepaling van informatie voor een groot deel wordt uitgegaan van de aanwezige onderlinge links. Dit maakt de technologie minder bruikbaar voor niet-web content, en daarbij noemt Gartner het ontbreken van speciale voorzieningen voor dynamische sites. Er bestaan enkele koppelingen naar Web Content Management systemen, maar niet naar generieke databases. Al met al is dit product niet relevant voor de WADI probleemstelling.

5.4.5 KennisBrowser en AquaBrowser, Medialab

De KennisBrowser, oorspronkelijk AquaBrowser, is een door het Nederlandse bedrijf MediaLab31 voor RIKZ ontwikkelde zoekmachine. Er bestaan twee varianten van, een met een web-interface en de ander met een MS Windows client, waarvan de achterliggende logica zoveel mogelijk (maar niet geheel) overeenkomt. Een voorbeeld van gebruik van de online Aqua Browser is te zien op: http://www.waddenzee.nl/ Hoewel we de KennisBrowser hier hebben opgenomen bij de “internet” zoekmachines, is sommige functionaliteit pas beschikbaar bij installatie van client software (zie figuur 5.4). Veel van de uitrolproblemen bij de toepassing van de KennisBrowser bij RIKZ/DZH zijn hierop terug te leiden (zie paragraaf 9.2). De KennisBrowser indexeert momenteel Word documenten, HTML en tekst documenten op (netwerk)schijven. Oorspronkelijk was het de bedoeling om ook Adobe Acrobat bestanden en e-mail (*.pst van Outlook) te indexeren, maar deze functionaliteit is nog niet ontwikkeld. De spider is niet in staat om informatie aan een bestaande index toe te voegen, en tijdens het indexeren wordt van de tussenresultaten nog geen gebruik gemaakt (de nieuwe index is pas beschikbaar als hij geheel klaar is). Een interessante mogelijkheid is het tegelijkertijd werken met meerdere catalogi (indexen) en thesauri. Doordat deze los te distribueren zijn is het mogelijk om een catalogus bij de geïndexeerde informatie op een CD-ROM te plaatsen, en in de KennisBrowser client software tegelijk met bijvoorbeeld het netwerk te doorzoeken.

30 31

Zie Gartner: “Google Offers Enterprise Search in a Service, or in a Box” Zie: http://www.medialab.nl/

42

Het user interface van de client software wordt in het algemeen als prettig ervaren, wat voor een deel is toe te schrijven aan de grafische weergave van aan de zoekterm gerelateerde woorden (zie figuur 5.4). In deze zogenaamde woordenwolk worden alternatieven van ingetypte of aangeklikte zoekterm(en) weergegeven. Deze weergave maakt het mogelijk om zoeken en bladeren in de informatie naadloos af te wisselen.

Figuur 5.4: Het user interface van de Kennisbrowser

In het navigatievenster kunnen vier verschillende woordtypen voorkomen: - Associaties: woorden die vaak in combinatie met de zoekterm voorkomen. - Fuzzy alternatieven: woorden die qua spelling sterk lijken op de zoekterm. - Vertalingen: woorden die synoniem zijn aan de zoekterm of de Nederlandse vertaling(en) van een zoekterm in het Engels, Duits of Fries - Thesaurus: woorden die in de thesaurus gekoppeld zijn aan de zoekterm. 5.4.6 Collexis.com

Collexis32 is een Nederlands bedrijf wiens product voortbouwt op binnen de SHARED33 ‘concerted action’ van de Europese Commissie ontwikkelde zoektechnologie. Collexis technologie werkt met concept-matching, in hun eigen terminologie fingerprinting genoemd. Deze vingerafdrukken bevatten op een compacte manier de kernconcepten uit een stuk tekst, wat volgens Collexis zelf leidt tot een efficiënte matching.

32 33

Zie: http://www.collexis.com/ Zie: http://shared-global.collexis.net/main.asp

43

Deze techniek leent zich ook voor het beschrijven van menselijke expertise als een verzameling van alle vingerafdrukken van teksten die door een persoon zijn geschreven. Ook betekent het feit dat van zowel zoekterm als documenten vingerafdrukken gemaakt worden, dat eenvoudig een heel document als zoekterm kan worden opgegeven wat leidt tot een zoekactie naar soortgelijke documenten. De website meldt dat een ander doel van de Collexis zoektechnologie is om in een enkele actie te kunnen zoeken in gestructureerde en ongestructureerde informatie. Het is echter niet duidelijk hoe zich dit in het product vertaalt. 5.4.7 Convera Retrievalware

Convera, een samenwerking van voorheen Excalibur en Intel, probeert zich met haar Retrievalware product te onderscheiden door te spreken over kennisontsluiting in plaats van informatieontsluiting. Retrievalware maakt gebruik van Semantic Nets als achterliggende technologie, en dit komt in grote mate overeen met het gebruik van ontologieen. Daarnaast heeft Retrievalware ook evenals bijvoorbeeld Autonomy een patroonherkenningsmodule voor het automatisch herkennen van onderwerpclusters. 5.5 Content Management en Kennismanagement

Op het gebied van informatie indexering en ontsluiting hebben Content Management en kennismanagement systemen grote overeenkomsten met enterprise zoekmachines. Het is dan ook niet verbazingwekkend dat de Butler Group in een onderzoek heeft gevonden dat in een lijst van verwachte functionaliteit in Enterprise Content Management Systemen “Index, Search and Retrieval” op de eerste plaats staat (met een score van 4.4 uit 5) en “Metadata tagging” op de tweede (met een score van 4.2).34 Gezien de overeenkomsten tussen Enterprise Search en Content Management, ook wat betreft de noodzaak om informatie te lezen uit vele diverse informatiebronnen, is de volgende passage uit hetzelfde rapport ook van belang: “At the next layer is the technical integration layer – the adapters and transport mechanism that make access to the repository possible. Although this has so far been addressed by specialist providers, or by the ECM vendors’ in-house technology, we believe that this will soon converge into the EAI domain, as the distinction between structured and unstructured content becomes blurred. We would therefore expect to see further examples of the traditional EAI vendors extending their product offerings in the direction of content integration.” Allereerst wordt hierin weer gesproken van integratie van gestructureerde en ongestructureerde gegevens, maar daarnaast wordt gesuggereerd dat informatie-integratie in toenemende mate een afzonderlijk domein wordt (opgepikt door de EAI leveranciers) dat los kan worden gemaakt van de specifieke informatiekoppelingen in de diverse zoekmachines en content management systemen.

34

Zie Butler Group Review issue 6, March 2003: Special Feature (p. II) Enterprise Content Management:; p. 110.

44

In de praktijk wordt de overeenkomst tussen Enterprise Search en zoekfunctionaliteit in content management bevestigd doordat meerdere content management systemen een bestaande zoekmachine integreren in plaats van deze zelf te ontwikkelen. Zo wordt Autonomy toegepast in Vignette en maakt het Stellent content management systeem gebruik van Verity. Wanneer er in een organisatie selectie van zowel content management als zoektechnologie speelt, dan is het aan te bevelen deze relatie in ogenschouw te nemen. 5.6 Overzicht

Bij het lezen van productbeschrijvingen van de verschillende leveranciers valt op hoezeer de doelstellingen en methoden van de producten op papier op elkaar lijken. Globaal is er echter een onderscheid te maken tussen de producten die gebruik maken van linguïstische technieken, en zij die zijn gebaseerd op statistische methoden (een paar lijken gebruik te maken van beide technieken). Statistische (zelflerende) technieken zijn echter voor WADI niet goed bruikbaar omdat te verwachten valt dat deze pas werken op grotere tekstverzamelingen. Het valt op dat Enterprise Search oplossingen zichzelf vaak presenteren als een volledig out-of-the-box product dat de data-, applicatie- en presentatielagen bestrijkt. Enkele oplossingen zoals Autonomy worden weliswaar nadrukkelijk gepresenteerd als verzameling van losse componenten, maar bij anderen is dit niet altijd even duidelijk. Toepassing van zoektechnologie zal echter altijd in een omgeving gebeuren waarmee op diverse niveau’s gekoppeld moet kunnen worden, dus een uit componenten opgebouwd systeem is haast een vereiste. Afgezien van deze technische overweging is het natuurlijk ook zaak om niet te hoeven betalen voor onnodige functionaliteit. Hieraan verwant zien we dat enkele van de componenten die nu nog in een zoekmachine zijn geïntegreerd steeds meer een zelfstandige rol krijgen. Zo is de behoefte om verschillende databronnen te integreren breder dan de zoek- of content management toepassing, en is het waarschijnlijk dat ook zoekmachines gebruik gaan maken van afzonderlijke Information Integration toepassingen (Zie hoofdstuk 7).

45

6 Database technologie 6.1 Introductie

In dit hoofdstuk belichten we de voor zoeken relevante aspecten van diverse databasetechnologieën en de ontwikkelingen daarin. Eerder, in hoofdstuk 4, hebben we de relatie aangegeven tussen zoeken en database queries. Hiertussen bestond historisch gezien een onderscheid doordat relationele databases vooral voor zogenaamde gestructureerde data werden gebruikt. Door de opkomst van o.a. database-driven websites, content management, en het gebruik van XML is het gebruik van databases voor de opslag van tekst echter toegenomen. 6.2 Databases en XML

Een belangrijke ontwikkeling in databaseland de laatste jaren is de opkomst van opslag van XML documenten. In eerste instantie betrof dit een aparte ontwikkeling van specifieke databases voor XML opslag, maar in een later stadium heeft zich dit ontwikkeld tot een heel spectrum van specialistische XML databases tot relationele databases met voorzieningen voor het opslaan van XML. De Butler Group besteed dan ook in een generiek database rapport veel aandacht aan de XML toepassingen daarvan.35 Gartner analist Friedman deelt databases geschikt voor het opslaan van XML op in drie categorieën: · Zij die XML afbeelden op een relationele structuur. Bij opslag van een XML document wordt dit ge-shred, ofwel opgehakt in de samenstellende elementen en attributen, die ieder apart in databasetabellen worden opgeslagen. Deze methode maakt het lastig het originele document te reconstrueren, en is dus vooral geschikt voor toepassingen waarbij XML primair fungeert als informatie transportmedium. · Databases die de XML in zijn geheel of in grote blokken opslaat. Deze systemen bewaren dus het oorspronkelijke formaat van het document, en moeten kunnen indexeren en zoeken binnenin de XML structuur. Deze categorie ontbeert soms nog de geavanceerdere database technieken die in de relationele wereld wel volledig zijn ontwikkeld, zoals transacties en administratieve tools. · De categorie “XML data repositories”, die het aanmaken, management en ontsluiting ondersteunt van in het algemeen ongestructureerde gegevens. Deze systemen worden getypeerd doordat ze zijn opgebouwd rond de structuur van de documenten, en dat ze dus meer weg hebben van documentmanagementsystemen dan van databases. Hierdoor hebben deze systemen minder van doen met transactiebewerking, en meer met versiebeheer, workflow, multimedia en het indexeren van- en zoeken in een scala aan ongestructureerde gegevens. 6.3 XML en de grote drie

Informatie in deze paragraaf is overgenomen uit een artikel in XML en Web Services Magazine.36

35

Zie: Butler Group report Database Management Systems ([BR-DBMS]) van september 2002 Zie: http://www.fawcette.com/xmlmag/2002_04/magazine/features/sjohnson/default_pf.asp

36

46

6.3.1 Oracle

[…] Oracle began adding XML support two versions ago in Oracle 8i. Now, the database is up to version 9i, and the company is readying version 9i release 2, which provides even more XML support as XML & Web Services Magazine prepares to go to press. "Our philosophy from the outset is to support all of the industry standards for storing and retrieving data, whether it's XML schema, XPath, SQLX, JavaBeans, JNDI (Java Naming & Directory services API) and on and on," said Jacobs. More change is coming soon: at Oracle's OpenWorld Conference in December, officials demoed the soon-to-ship 9i release 2—previously code-named Project XDB. "It adds a lot of other XML capabilities supporting XML schema, supporting the capabilities for DOM fidelity and query ability and generation of XML from SQL—the whole range of things that we think you ultimately want," said Jacobs. Figuur 6.1: Oracle's 9i carries on the tradition of its earlier relational database versions by incorporating XML support. (Source: Oracle)

Longer term, Oracle is working to implement the SQLX specification when it is formalized. "It's a way of unifying SQL and XML, providing all of the benefits of SQL for transaction processing and business intelligence, and all of the benefits of XML for documents, messages, and Web services," Jacobs said. "It's really a unified environment, so you get access to all of your data through Java apps while getting all of the traditional benefits of the most popular, scaleable, reliable, highly available, highly secure, unbreakable database on the planet." 6.3.2 Microsoft SQL Server

[…] Microsoft is aiming for native XML support without compromising its relational capabilities […]. One way of doing that is by having more than one data store that can be installed much in the same manner as Windows NT/2000's installable file system feature. Figuur 6.2: Microsoft brings XML support to its relational SQL Server database by including more than one data store that installs similarly to Microsoft Windows NT/2000 installable file system. (Source: Microsoft Corporation)

47

When we shipped SQL Server 2000, we included the key elements for doing storage and retrieval of XML," Ressler said. "The way we do that is an extension of the relational model, because we don't actually store XML data in the database, but we do maintain a two-way relationship between data we persist relationally in tables and the XML description or outline of that data. So when you take an XML document and store it in SQL Server, we shred it and put it in relational tables. Then, when you want that data out as XML, you issue a select query with a clause on it to say 'for XML,' and then we format the outgoing data as XML," he said. Microsoft's upcoming Yukon version of its popular SQL Server database, due out in beta later this year and in final form in 2003, will feature a native XML data store. It will also become the store for Exchange Server messages. Eventually, that data store or one based on it will evolve into a standard installable file system for Windows .Net Server, although that may have to wait for the Windows Blackcomb release, which is still years off. Given its importance to Microsoft's overall data strategy, however, expect it sooner rather than later, according to informed observers. 6.3.3 IBM DB2

"We are enhancing our XML capabilities to provide what I would call native XML support. . . . IBM has been leading the XML schema and XML query standards efforts, and we'll be implementing those capabilities as the standards stabilize. In fact, we demoed a prototype of the XQuery standard running against DB2 back in May of last year, at the DB2 users' conference," said Nelson Mattos, IBM distinguished engineer and director of information integration.

Figuur 6.3: IBM marks its foray into the XML database arena with its DB2 product, that began with the delivery of the DB2 XML Extender. (Source: IBM)

6.3.4 What's in Store for XML DBs

Corporations probably will never completely replace many of those legacy database management systems with native XML databases; although, even today's relational heavy hitters will evolve to handle XML better over time. Meanwhile, it seems likely that within the next three or four years the categories of XML-enabled (relational) and native XML databases will merge, even though native databases will tend to be strongest in document-centric applications and places where transparent automated exchange of information with other parties dominate.

48

XML will eventually hit critical mass and then the avalanche effect—XML becoming the data format of choice for certain types of data—will be enormous. At that point, it is likely that at least some companies will adopt XML-only policies. Why? Because easy information interchange between business parties will become crucial, and unstructured data—basically knowledge tied up in individual employees' documents and its integration with structured relational data—will become the pivot points in determining which companies survive and which do not. 6.4 Text queries

Naast ondersteuning voor XML bevatten grotere relationele databases, zoals Oracle en IBM’s DB2, vaak ook speciale onderteuning voor tekst.37 De daarvoor noodzakelijke uitbreidingen van de SQL querytaal zijn helaas wel productspecifiek. Oracle, die de tekstondersteuning in haar database inmiddels een “fundamental native feature” noemt, geeft de volgende omschrijving van het produkt op haar website:38 ”Oracle Text uses standard SQL to index, search, and analyze text and documents stored in the Oracle database, files and on the Web. Oracle Text can analyze document themes and gists; search text using variety of strategies including full-text: boolean, exact phrase, proximity, section searching, misspellings, stemming, wildcard, thesarus, word equivalence, and scoring, mixed: text index plus relational attributes, and thematic; search HTML and XML sections and tag values; render search results in various formats including unformated text, HTML with automatic keyword highlighting, and original document format; analyze and index most document formats with over 150 document filters; supports 39 languages; bulk load documents in Oracle8i/9i with SQL*Loader.” 6.5 Databases en zoeken

Databases hebben traditioneel de indexering altijd gezien als een interne aangelegenheid, waar niet of nauwelijks toegang toe te krijgen is. We hebben echter gezien dat traditionele (relationele) databases steeds meer vrije tekst functionaliteit krijgen (zie paragraaf 6.4), en het lijkt erop dat de daarvoor toegenomen complexiteit van de indexen ook heeft geleid tot wat grotere openheid – zo biedt Oracle tools aan voor het opbouwen en onderhouden van thesauri. In hoeverre andere tekst-gerelateerde indexen, zoals die ten behoeve van classificatie en automatische clustering, ook eenvoudig toegankelijk zijn is moeilijk in de beperkte informatie terug te vinden. Voor de juiste toepassing van zoektechnologie is openheid van dit soort informatie essentieel. XML heeft een significante rol te veroverd in databaseland. XML functionaliteit is tegenwoordig standaard in elke grotere relationele database, en daarnaast worden ook gespecialiseerde XML databases serieus genomen en toegepast voor met name documentgeoriënteerde applicaties of als tussenstap in een publicatieproces uit een relationele database. Met dit toenemend XML gebruik worden query talen als Xquery ook gemeengoed in de databasewereld, en daarmee mogelijk op termijn ook het gestandaardiseerd zoeken in vrije tekst (zie hoofdstuk 8). 37

38

Zie Gartner: “Technology for Enterprise Search Comes in Many Flavors” Zie: http://otn.oracle.com/products/text/content.html

49

7 XML Middleware en Information Integration 7.1 Introductie

Als we kijken naar overeenkomsten tussen de diverse implementaties van generieke zoektechnologie, dan valt op dat een belangrijke functionaliteit – en een waar veel ontwikkeltijd in gaat zitten- de technologie is die het mogelijk maakt om informatie te kunnen halen uit verschillende systemen en om diverse bestandsformaten te kunnen lezen. Deze technologie is nu vaak in huis ontwikkeld door de Enterprise Search leverancier, maar wij delen de verwachting van de Butler Group (zie het citaat in paragraaf 5.5) dat de ontwikkeling van deze technologie vanwege de veel bredere toepasbaarheid zal worden overgenomen door de produkten van de Enterprise Application Integration (EAI) en vooral Enterprise Information Integration (EII) leveranciers. In dit hoofdstuk zullen we daarom de rol van middleware in relatie tot het zoeken belichten. Omdat middleware in zijn algemeenheid een groot onderwerp is,39 beperken we ons hier tot de zogenoemde (Enterprise) Information Integration (EII) – hoewel het waarschijnlijk is dat ook de scheidslijn tussen Information Integration en Application Integration in de toekomst zal vervagen. EII gebruikt vaak XML als universeel tussenformaat, en het is dan ook niet verbazingwekkend dat juist vanuit bedrijven die (ook) op deze markt opereren een grote impuls uitgaat naar de ontwikkeling van Xquery (de querytaal voor XML, zie paragraaf 8.3): IBM, BEA en DataDirect leveren ieder een editor voor het redigeren van de Xquery definitie. Voor WADI zijn de ontwikkelingen in de EII markt extra interessant omdat de systeemschets (figuur 3.3) rekening houdt met meerdere (conceptuele) databases in het systeem. Afhankelijk van implementatiekeuzes daarin zal er mogelijk gebruik (moeten) worden gemaakt van Information Integration software, en zullen de mogelijkheden daarvan de toepassing van zoektechnologie sterk beïnvloeden. Het komt de eenvoud van het systeem ten goede als er een enkele integratielaag kan worden gebruikt voor diverse wijzen van informatieontsluiting – in andere woorden, wanneer er door de EII software behalve op traditionele query-achtige manier ook op een zoek-achtige manier kan worden gewerkt. 7.2 IBM Information Integrator (eXperanto)

IBM presenteert een ontwikkeltraject naar een universeel information integration product genaamd Information Integrator: “DB2® Information Integrator V8.1 is a new product to access structured and unstructured information across and beyond the enterprise. Components include a federated data server and a replication server -- to integrate diverse data types on demand in real time. Applications that use SQL or tools that generate SQL (e.g. integrated development environments or reporting and analytical tools) can access, integrate, and manipulate distributed and diverse data through a federated system server as if it were a single data source.”40 De belofte is een enkel product dat gestructureerde en ongestructureerde data aankan, en queries begrijpt in SQL, Xquery of een querytaal voor “Content” (Zie figuur 7.1). Voor het bereiken van dit doel is het project Xperanto in het 39 40

Zie in dat verband ook de nog te verschijnen trendrapportage Web Services Tekst van de IBM website: http://www.ibm.com/software/data/integration/

50

leven geroepen. Vooralsnog levert IBM echter nog geëvolueerde versies van oudere producten, en is er op dit moment nog sprake van drie verschillende ontwikkelingen: · DB2 Information Integrator – een product dat SQL kan worden aangesproken, en data integreert uit relationele databases maar ook XML, files, message queues en Web Services. Gartner voorspelt voorlopig beperkte toepassing van deze technologie in specifieke markten waar nietreal-time datamining tools niet voldoen.41 · Het nog experimentele XML Integrator project42 voor het maken van een XML gebaseerde toegang tot relationele data, waarschijnlijk voor toepassing in bovengenoemde Information Integrator (waarvoor een Xquery interface is aangekondigd). · DB2 Information Integrator for content – een product dat content, ongestructureerde informatie, uit diverse bronnen (o.a. RDBMS) kan integreren.

Figuur 7.1: Geïntegreerd universum van gestructureerde en ongestructureerde gegevens volgens het IBM Xperanto project (Bron: IBM) Het valt op dat er zeker op dit moment nog sprake is van verschillende producten voor gestructureerde en ongestructureerde informatie – ook al bieden ze koppelingen met veel dezelfde soorten gegevensopslag. De DB2 Information Integrator for content biedt functionaliteit die sterk is te vergelijken met die van een Enterprise Search Engine: · Language identification to determine in what language a document is written · Information extraction to identify meaningful entities within documents, such as names of people or organizations, domain technical terms, abbreviations, dates, numbers or currency amounts · Categorization to assign documents into pre-existing categories based on a predefined taxonomy, such as product lines or competitors · Clustering groups to relate documents automatically based on content— without requiring predefined classes 41 42

Zie Gartner: “IBM's Xperanto Database Middleware Will See Narrow Early Use” Zie: http://alphaworks.ibm.com/tech/XI

51

· ·

Summarization to extract the most relevant sentences from each document to create a synopsis A Web-based information structuring tool to create, train, evaluate and maintain taxonomies for categorization.

7.3 OpenLink Software

OpenLink levert met Virtuoso43 een product om diverse databases, zowel relationeel als XML gebaseerd, te benaderen met behulp van diverse protocollen. Het betreft hier echter zuiver “gestructureerde” data, en nergens wordt de indruk gegeven dat er een uitbreiding richting meer ongestructureerde data plaatsvindt. 7.4 BEA Liquid Data

BEA,44 een bekende leverancier uit de EAI hoek, heeft sinds november 2002 ook de dataintegratietool LiquidData in zijn portfolio. Gartner schrijft daarover: “Liquid Data follows earlier industry attempts at federated data stores. However, the use of XML and XQuery, the DBMS-independence of the vendor as well as the emphasis on programmatic data sources (J2CA, Web services) give it a visionary flair. The combination of adapter technology and products employing XQuery (such as Liquid Data) could become a popular approach for heterogeneous data access. In the long term, with the addition of a businesssemantic personality and update capability, W3C XQuery and technologies like Liquid Data could evolve to become the new semantic data interface model.”45 LiquidData is in deze eerste release alleen voor data-retrieval geschikt, en er is geen indicatie van toekomstige uitbreiding voor ongestructureerde data. 7.5 MetaMatrix

MetaMatrix46 houdt zich bezig met informatie integratie uit een verscheidenheid aan bronnen: File systems, ftp sources, Web sites, Email systems, Application servers, ERP systems, CRM systems, Wireless devices, Relational databases, Real-time data feeds, Message Oriented Middleware. Ondanks dat men zegt ook niet-gestructureerde bronnen te kunnen gebruiken, spreekt de rest van de publieke documentatie helaas alleen van expliciete datamodellering. 7.6 Nimble Technology

Nimble Technology47 gebruikt XML als datamodel in hun EII product, en accepteert zowel Xquery als SQL queries. Hoewel ook zij ongestructureerde datasources noemen, verwijst de rest van de documentatie alleen naar gestructureerde query talen.

43

Zie: http://www.openlinksw.com/virtuoso/index.htm Zie: http://www.bea.com/ 45 Zie Gartner: “BEA Liquid Data Offers Integration Shortcut for Some Projects” 46 Zie: http://www.metamatrix.com/ 47 Zie: http://www.nimble.com 44

52

7.7 EII en zoeken

Enterprise Information Integration (EII) tools maken het mogelijk om met een enkele query data uit diverse bronnen te kunnen ophalen. Omdat een zoekmachine ongeveer hetzelfde beoogt voor ongestructureerde gegevens, is het de vraag in hoeverre deze producten naar elkaar toe zullen groeien. Ondanks suggesties in die richting van diverse EII leveranciers, is integratie van zoeken en querying op het niveau van informatie integratie niet op korte termijn te verwachten. Een van de oorzaken is dat de EII markt zelf nog een jonge markt is, en zijn handen meer dan vol lijkt te hebben aan het op orde krijgen van zogenaamde federated dataviews op gestructureerde bronnen. Het gebruik van XML en in toenemende mate Xquery door EII tools lijkt gemeengoed – wat in elk geval technologie is die een toekomstige uitbreiding naar ongestructureerde data niet uitsluit. Voor de wat langere termijn echter ligt alles nog open. IBM biedt met haar Xperanto project het meest complete strategische beeld waarin universele toegang tot gestructureerde en ongestructureerde gegevens wordt geschetst, maar op productniveau zijn beide producten nog gescheiden. Het is nog te vroeg om te kunnen beoordelen of deze integratie uiteindelijk ook in de praktijk door IBM zal worden uitgevoerd, en of dit in de EII markt bredere weerslag zal krijgen.

53

8 Standaardisatie 8.1 Introductie

Een goede maat voor de volwassenheid van een toepassingsgebied in de ICT is de mate van standaardisatie daarbinnen, en de status van standaardisatieactiviteiten op relevante vakgebieden. Hierbij valt te denken aan standaardisatie op productniveau (zijn produkten in de markt met elkaar te vergelijken?), en op het meer technische vlak van gegevensopslag en communicatieprotocollen. In eerdere hoofdstukken hebben we al van diverse gebieden het productaanbod bekeken, zodat we in dit hoofdstuk dieper in kunnen gaan op de mate van standaardisatie van gegevens, met bijzondere aandacht voor de rol van zoektalen. Hoewel het bestaan van gestandaardiseerde communicatieprotocollen essentieel is voor het integreren (doorzoekbaar maken) van gedistribueerde gegevenscollecties, nemen we het bestaan daarvan hier voor gegeven aan. Bij een selectieproces van zoeksoftware is de ondersteuning van communicatiestandaarden vanzelfsprekend wel van groot belang. In de gegevensstandaarden en daarbij behorende zoektalen die we in dit hoofdstuk behandelen zullen we een tweedeling maken: Die standaarden die zich vooral richten op de gegevens zelf, en die standaarden die erop gericht zijn om metadata op te slaan en doorzoekbaar te maken. 8.2 XML

XML, de eXtensible Markup Language, is een standaard voor het weergeven en annoteren van gegevens in gestructureerde, maar tekstuele vorm. Deze wellicht cryptische omschrijving geeft goed de dualiteit van XML weer: In de tekstuele en flexibele vorm toont XML goed haar oorsprong in de SGML taal uit de uitgeverswereld, terwijl anderzijds de mogelijkheden voor het vastleggen van structuur groot zijn door het gebruik van datatypering (het definiëren dat iets een getal is, of tekst, of een bedrag) en schema-definities (het vastleggen dat een stuk tekst een persoonsnaam is, en dat deze uit een eigennaam en familienaam moet bestaan). Deze flexibiliteit in toepassing heeft ertoe geleid dat XML zowel voor gestructureerde als tekstuele gegevens wordt gebruikt, en een positie heeft veroverd als de universele gegevenstaal – vooral op het grensvlak tussen systemen maar in toenemende mate ook als opslagformaat voor brongegevens. Dit betekent niet dat voor alle gegevens XML het perfecte opslagformaat is, maar wel dat XML helpt de grens tussen gestructureerd en ongestructureerd te vervagen. Onder deze trend valt ook de ontwikkeling die we in hoofdstuk 6 hebben kunnen zien dat, na een initiële tweedeling in relationele en XML databases, er een toenadering heeft plaatsgevonden waarbij er aan relationele databases XML functionaliteit is toegevoegd. De dualiteit van XML helpt ook mee bij de ontwikkeling om bij het zoeken de betekenis van het onderscheid tussen gestructureerde querying en vrije-tekst zoeken te verminderen. Van XML wordt vaak gezegd dat een sterk punt de weergave van “betekenis” van gegevens is, maar dat is slechts ten dele waar. Het annoteren in XML betekent immers niets meer of minder dan het labellen van de gegevens – het opplakken van een naametiket. In die zin bevat XML data niet meer of minder “betekenis” dan veldnamen in een relationele databasetabel die aangeven wat voor gegevens er in die kolom staan. Wel zullen we in een volgende paragraaf

54

zien dat XML de basis vormt voor de RDF standaard, die er specifiek voor is bedoeld om semantiek vast te leggen. Het feit dat zowel de data als de semantiek dezelfde taal XML als basis hebben, opent nieuwe perspectieven voor interoperabiliteit van semantiek. 8.3 XML Query

XML Query (Xquery) is de W3C standaard-in-wording voor het specificeren van queries op (verzamelingen van) XML documenten. In de huidige vorm is Xquery een XML equivalent van SQL, en vooral gericht op het selecteren van stukken XML op basis van structuur. Recent, in februari 2003, hebben leden van de XML Query en XSL werkgroepen van de W3C public working drafts uitgebracht met respectievelijk requirements48 en use cases49 voor de uitbreiding van XML Query met full-text functionaliteit. Het requirements document beschrijft het zoeken van woorden en zinsfragmenten en het zoeken op nabijheid (proximity search). Ook wordt de noodzaak van ranking beschreven. De use cases omvatten het basale zoeken naar woorden en zinfragmenten, maar ook het gebruik van “thesauri, woordenboeken en taxonomieën”. De belangrijkste use case in onze context echter is die van “COMPOSABILITY", welke aangeeft hoe het vrije-tekst zoeken moet kunnen worden gecombineerd met de overige XQuery functionaliteit. In het algemeen beperkt de XML Query standaard zich overigens tot het omschrijven van wat een query in een bepaalde syntax voor resultaat moet opleveren, maar niet hoe dat resultaat moet worden bereikt. Wat voor consequenties dat zal hebben voor het zoeken in vrije tekst, en de openheid van de gebruikte semantische structuren, is nog onduidelijk. Merk overigens op dat hoewel deze documenten indicatief zijn voor de richting waarin deze groep denkt, de status van deze documenten formeel nog geen garantie biedt dat XML Query zich ook daadwerkelijk zo zal ontwikkelen. Het leidt echter geen twijfel dat XML Query op termijn een integratie te zien zal geven van gestructureerde querying en vrije tekst zoeken. 8.4 SQLX

SQLX,50 ook wel SQL/XML genoemd, is een standaard in ontwikkeling gesteund door de International Organization for Standardization (ISO) en het American National Standards Institute (ANSI). SQLX definieert vertalingen in beide richtingen tussen SQL en XML queries. Het is de bedoeling om XML en de SQL querytaal tot elkaar te brengen door SQL uit te breiden met XML extensies of XPath expressies. 8.5 RDF en Topic Maps

RDF, het Resource Description Framework, is de W3C standaard voor het uitdrukken van metadata. Meer specifiek is het een op XML gebaseerde syntax om relaties tussen zaken (“resources”) weer te geven. De basisstructuur in RDF is dan ook het zogenaamde triplet (drie-ding): Iets (1) heeft een relatie (2) tot iets anders (3).

Zie: XQuery and XPath Full-Text Requirements; W3C Working Draft 14-February-2003 Zie: XQuery and XPath Full-Text Use Cases; W3C Working Draft 14-February-2003 50 Zie: http://www.sqlx.org/ 48 49

55

RDF heeft voor zoektechnologie, of algemener voor gegevensontsluiting, twee mogelijke toepassingen: Enerzijds het gestandaardiseerd opslaan van relaties tussen woorden in een thesaurus, en anderzijds het opbouwen van een relatiestructuur tussen concepten of categorieën. In het geval van een thesaurus kunnen de objecten (woorden) onderlinge relaties hebben als “is een synoniem van” en “is de Engelse vertaling van”. De Visual Thesaurus zoals afgebeeld in figuur 4.6 geeft een goed idee van hoe dergelijke relaties in een woordenboek grafisch zijn weer te geven. Web indexen (directories) zijn eenvoudige voorbeelden van een semantische structuur van concepten of categorieën. De boomstructuur die zij hebben bestaat simpelweg uit “is een subcategorie van” relaties. In het voorbeeld hieronder is bijvoorbeeld Software een subcategorie van Computers, en Internet weer een subcategorie van Software.

Top: Computers: Software: Internet Vaak hebben dergelijke indexen ook dwarsverbanden van gerelateerde categorieën. De relaties tussen begrippen blijven echter voldoen aan de triplet structuur van RDF, en het Open Directory Project heeft zijn volledige structuur dan ook beschikbaar gesteld in RDF formaat.51

Figuur 8.1: Een grafische weergave van de uitspraken dat Sue drie publicaties heeft gemaakt – een voorbeeld van relaties tussen concepten zoals die in RDF zouden kunnen worden vastgelegd (Bron: W3C)

De RDF standaard vormt de basis van de Semantic Web activiteit van het W3C.52 Topic Maps53 en de XML implementatie daarvan54 zijn een onder ISO vlag ontwikkelde alternatieve manier om informatie of metadata op te slaan. Een voorbeeld van een toepassing van Topic Maps is de bij OASIS in ontwikkeling zijnde Topic Map voor de ontsluiting van informatie op basis van geografie.55

51

Zie: http://rdf.dmoz.org/ Zie de in 2003 te verschijnen trendrapportage over metadata en het Semantic Web 53 Zie: http://www.topicmaps.org/ en http://www.isotopicmaps.org/ 54 Zie: http://www.topicmaps.org/xtm/index.html 55 Zie: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=geolang 52

56

8.6 RDF en Topic Map query talen

In semantische structuren zoals een RDF “web” van begrippen en verbanden wil men kunnen navigeren of kunnen doorzoeken. Het navigeren is eenvoudig te doen, maar voor het zoeken komt er meer om de hoek kijken. Het doorzoeken van RDF structuren bevindt zich nog overduidelijk in het beginstadium van standaardisatie. Een enkele Google search op “RDF query language” leidt tot vele resultaten, wat aangeeft dat er voldoende onderzoek naar wordt gedaan maar tevens dat er nog maar beperkt consolidatie heeft plaatsgevonden. Zie het tekstveld voor een aantal querytalen en softwareimplementaties voor het doorzoeken van RDF structuren. RDF Query Talen - Een selectief overzicht: Een aantal semantische query talen zijn gepresenteerd als position papers voor de XML query taal workshop van de W3C in 1998 (welke ook kan worden beschouwd als het startpunt van de Xquery ontwikkeling). http://www.w3.org/TandS/QL/QL98/pp.html Metalog Metalog is a next-generation query/logical system for the Semantic Web based on RDF, the Resource Description Framework. Metalog has been the first system to introduce yet another level in the Semantic Web hierarchy, the (pseudo) natural language layer, that makes much easier for common people to understand semantic web assertions, without having to learn heavy formalisms. http://www.w3.org/RDF/Metalog/ RQL Sesame is a Java-based storage and querying middleware system for RDF and RDF Schema, developed by Aidministrator Nederland BV. It contains an API for RDF(S) manipulations on repositories, an RDF Model Theory inference engine, and support for the RQL and RDQL query languages. Available as open source under the LGPL license. http://sesame.aidministrator.nl/ HP Jena The "fast-track" query being developed for Jena2 allows bigger queries to be constructed and given to models, where query engines can take advantage of knowing all the parts. In particular, RDB models can translate parts of these queries into SQL so that the database can take advantage of its own indexing & optimization capabilities. http://www.hpl.hp.com/semweb/jena2.htm TRIPLE TRIPLE is an RDF query, inference, and transformation language for the Semantic Web. Instead of having a built-in semantics for RDF Schema (as many other RDF query languages have), TRIPLE allows the semantics of languages on top of RDF (like RDF Schema, Topic Maps, UML, etc.) to be defined with rules. As a result, TRIPLE allows RDF reasoning and transformation under several different semantics, which is necessary if you need to access multiple data source in one application (e.g., for data integration). http://triple.semanticweb.org/ SquishQL Query of RDF data provides a declarative access mechanism that is suitable for application usage and remote access. SquishQL uses a conceptual model for querying RDF data that refines ideas first presented in at the W3C workshop on Query Languages. It is derived from rdfDB, and is suitable for application programmers. Three independent implementations of the query language exist. http://www.hpl.hp.com/techreports/2002/HPL-2002-110.html

57

Voor Topic Maps wordt er gewerkt aan een zoektaal genaamd TMQL - de Topic Map Query Language.56 Dit is een ontwikkeling op basis van meerdere proprietary topic map talen, waaronder beide talen van de bedrijven Ontopia en Empolis. 8.7 Samenvatting

In dit hoofdstuk hebben we gezien dat er diverse voor zoektechnologie relevante ontwikkelingen plaatsvinden op het standaardisatievlak. Allereerst zijn er recent voorstellen verschenen voor full-text search uitbreidingen op Xquery, waarvan een impuls kan worden verwacht wat betreft de integratie van gestructureerd en full-text zoeken. Daarnaast worden de allereerste stappen gezet op de weg naar standaardisatie van zoektalen op semantische structuren zoals RDF en Topic Maps. Daar waar Xquery zich vooral richt op het specificeren van een zoekinterface taal en zich niet bezig houdt met de vraag hoe een zoekmachine tot het resultaat op de zoekopdracht komt, zijn deze talen juist gericht op het redeneren met metadata. Het is interessant om te zien hoe Xquery zich in de toekomst zal gaan verhouden met zoektalen voor semantische structuren zoals TMQL en RDFgerelateerde talen. Hoewel het waarschijnlijk is dat beide methoden zich uiteindelijk naar elkaar toe zullen ontwikkelen, valt te verwachten dat ze voorlopig ieder hun eigen toepassing zullen vinden: Xquery voor ongecompliceerde toegang tot grotere (XML-)tekstbestanden, en de semantische zoektalen voor toepassingen waarbij bewust omgaan met semantiek centraal staat. Als we de WADI situatie beschouwen, waar geen grote hoeveelheid vrije tekst meespeelt maar wel bewust rekening wordt gehouden met gedefinieerde gegevenswoordenboeken als IDsW, dan sluit het gebruik van RDF-achtige technieken in de metadata laag (zie figuur 3.3) daarbij aan. Omdat we echter de mate van standaardisatie in een vakgebied nemen als maat van volwassenheid, dan kunnen we uit het scala van zoektalen voor semantiek wel afleiden dat men pas net de kinderschoenen heeft verlaten. Hoewel dit dus de voor de hand liggende ontwikkelrichting is voor een systeem als WADI, is het goed om rekening te houden met een overgangsperiode. In dit hele hoofdstuk zijn (Enterprise) Search Engines niet aan bod geweest. In de praktijk gebruiken deze voornamelijk gestandaardiseerde communicatieprotocollen aan de content invoerkant en de user interface uitvoerkant. De interne werking en metadata is vaak afgeschermd, of in elk geval niet van standaard interfaces voorzien. Gezien het gebruik van zoekmachines voor indexering van vele soorten gegevens waarvan XML hooguit een deel zal uitmaken, zal de rol van Xquery als adapter voor de spider overeenkomstig beperkt zijn – en gebruikt worden naast adapters voor andere soorten content. XML wordt veel gebruikt als universele datataal in dataintegratielagen en Xquery zal daar zeker een toenemende rol gaan spelen (zie HX). In dat opzicht is het verhelderend om te zien dat van de vijf redacteuren van het XML Query Use Cases draft document er drie bij bedrijven werken die produkten hebben op de data integration markt (IBM, BEA en DataDirect Technologies). 56

Zie: http://www.isotopicmaps.org/tmql/

58

9 “Zoeken” bij Rijkswaterstaat 9.1 Introductie

In dit hoofdstuk gaan we nader in op projecten binnen de RWS en V&W organisaties welke mogelijk voor dit onderzoek relevante resultaten hebben opgeleverd. Het bleek dat er maar in beperkte mate specifiek onderzoek naar zoektechnologieën is gedaan. Wel is er een groot aantal kennismanagement projecten binnen RWS en V&W gaande, die vanuit dat perspectief “zoeken” als aspect behandelen. Als gevolg hiervan is er veelal uitgegaan van document gebaseerde kennisopslag waarover een zoekactie kan worden uitgevoerd. 9.2 Project KM, RIKZ

RIKZ is sinds 1999 bezig met de ontwikkeling van een intranet gebaseerd kennissysteem (KenSys), en de implementatie daarvan bij de Directie ZuidHolland (DZH). De gedachte achter het KenSys systeem is “dom opbergen, slim zoeken” omdat men uitgaat van de aanname dat (opberg)structuren per definitie in de loop der tijd veranderen.

Webmanager

Smoelenboek Wizard

Boekenkast Wizard

Thesaurus

Smoelenboek Smoelenboek

Open Open boekenkast boekenkast

Telefoongids DZH Officiële Officiële boekenkast boekenkast

Zoekmachine RWS Kennisbrowser

Persoonsinformatie

Open documenten

Officiële documenten Als MER rapporten

KENSYS PORTAAL KENSYS

Figuur 9.1: KenSys concept diagram, uit:: “EINDRAPPORTAGE OVEREENKOMST RKZ 1158 Periode Januari 2002 – Februari 2003”

KenSys rust op drie content-pijlers en de KennisBrowser (vh. Aqua Browser) zoekmachine (zie paragraaf 5.4.5). Zoals te zien in figuur 9.1 betreft de content in twee van de drie gevallen een documentrepository, en in het derde geval een database met telefoonboekgegevens – deze worden echter ook met een tussenstap gelezen door het zoekproces (er is geen databasekoppeling). Tussen de documenten in KenSys wordt onderscheid gemaakt op grond van definitieve of voorlopige status, maar er is op dit moment geen autorisatiesysteem.

59

De KennisBrowser heeft eveneens de interessante mogelijkheid om tegelijkertijd met meerdere thesauri om te gaan. In het geval van KenSys betreft het drie voorgedefinieerde woordenboeken, maar het is ook mogelijk deze af te leiden uit een documentverzameling. Tenslotte is het met de client software mogelijk een lokale (persoonlijke) thesaurus bij te houden en deze geïntegreerd te gebruiken met een centrale (gedeelde) thesaurus. De grafische manier om naast het zoeken ook door een web van gerelateerde termen te kunnen lopen wordt ervaren als een sterk punt van de Kennis Browser. In 2001 is er binnen KenSys een korte verkenning gedaan naar voor op web sites toepasbare Search Engines (genoemd zijn Altavista, Excalibur RetrievalWare Webexpress, Inktomi, Fast Search, Google SiteSearch en Verity).57 9.3 VenW Intranet

Het V&W Intranet bestaat feitelijk uit honderden decentraal bijgehouden sites, die logisch maar vaak ook fysiek gescheiden zijn. Als deze verschillende sites integraal doorzoekbaar zouden zijn met behulp van de juiste zoektechnologie, hoeft de gebruiker daar echter weinig van te merken. Omdat men niet tevreden was met de bestaande op Verity gebaseerde oplossing is er in opdracht van Bureau Intranet in 2001 gekeken naar een alternatieve oplossing.58 Het rapport concludeerde dat de drie producten van Autonomy, Excalibur en Verity allemaal ongeveer vergelijkbare functionaliteit bieden. Vanwege de (verwachte) toename in de toepassing van dynamische sites was een van de selectiecriteria de mogelijkheid tot database access – op dit vlak biedt het rapport echter geen directe vergelijking tussen de drie genoemde partijen. Recent wordt er aan bovenstaande een vervolg gegeven met de ondersteuning van twee Autonomy pilots binnen Rijkswaterstaat bij de projecten Professioneel 59 Opdrachtgeverschap (POG) en Informatie Zonder Grenzen (IZG). 9.4 AVV

De Adviesdienst Verkeer en Vervoer heeft een applicatie in gebruik op basis van het Retrievalware produkt van Convera (voorheen Excalibur) voor het ontsluiten van eigen (en soms externe) documenten. Inmiddels heeft men documenten uit de afgelopen tien jaar in het systeem ingevoerd en van de juiste metadata voorzien. Het zoeken wordt ondersteund met een tweetalig semantisch netwerk, en met de nederlandstalige V&W thesaurus. Het systeem is beschikbaar binnen AVV, maar zal volgens planning voor de zomer van 2003 ook op het V&W Net beschikbaar moeten komen. Op basis van dezelfde technologie wordt ook de informatie in het V&W Literatuur Informatie Systeem (V&W-LIS) ontsloten (200.000 records). 57

Zie “Search engines voor KenSys” Zie “Zoeken op VenWnet” 59 Zie: http://www.venwnet.minvenw.nl/werkplaats/901.html 58

60

10 Conclusies 10.1 Ontwikkelingen in zoektechnologie

Bij zoektechnologie denken we in eerste instantie aan de bekende zoekmachines op het Internet, maar in werkelijkheid komen we het veel vaker tegen: Op het Internet, maar ook op onze desktop PC, het bedrijfsintranet en in zelfs in relationele databases – overal waar tekstuele informatie moet worden ontsloten. Aan de ene kant betekent een dergelijke brede beschikbaarheid van zoektechnologie dat wanneer men naar een zoekoplossing wil selecteren de keuze groot is en zeker niet beperkt tot de traditionele aanbieders van gespecialiseerde Enterprise Search software. Aan de andere kant zien we dat door de brede toepassing van zoektechnologie deze voor zogenaamde ongestructureerde informatie de centrale rol gaat krijgen die het relationele model en de SQL zoektaal voor gestructureerde data hebben. Voor de beoordeling van zoekoplossingen is het belangrijk om de opdeling van de technologie in diverse componenten te begrijpen: de rol van de spider, de soorten metadata structuren, de index, het match-proces en het (user)interface. Elk zoekprobleem legt de nadruk op andere componenten, en stelt andere eisen aan elk component afzonderlijk. Behalve als een handig theoretisch model begint de het opdelen van zoektechnologie in componenten ook in de praktijk vorm te krijgen. Een product als Autonomy is al in grote mate opgedeeld in losse componenten die afzonderlijk zijn in te zetten en aan te spreken. Dit vergroot de inzetbaarheid van de technologie voor individuele implementaties, maar is ook noodzakelijk voor het inpassen van de technologie in bijvoorbeeld content management en portal oplossingen in het kader van OEM contracten (een significant deel van de toepassingen van producten als Autonomy en Verity). Een zeer belangrijk gevolg van het “openbreken” van zoektechnologie is dat het onvermijdelijk is dat de in zoeken gespecialiseerde aanbieders zich op termijn meer zullen richten op de kerncompetentie van metadata management en het zoeken zelf – en dat zij voor de meer perifere technologie als user interface en datakoppelingen aansluiting zullen zoeken bij anderen. Hierdoor zal het zwaartepunt van zoektechnologie in de applicatie-lagenstructuur “naar beneden zakken” richting data access – een ontwikkeling in lijn met de analogie tussen zoektechnologie en het relationele model/SQL voor de ontsluiting van respectievelijk ongestructureerde en gestructureerde gegevens. Anders geformuleerd zal zoektechnologie op termijn geen specifieke userinterface technologie meer zijn, maar zal het een plek dieper in de architectuur krijgen die in overeenstemming met de ware waarde van zoektechnologie: metadata management, indexering, thesauri, etc. Toegang tot deze zoektechnologie zal in toenemende mate worden verkregen door andere software in plaats van direct door de eindgebruiker. Om de vergelijking met het relationele model en de SQL querytaal waar te kunnen maken zal voor zoektechnologie eenzelfde mate van standaardisatie op het interface (de zoektaal) moeten plaatsvinden. Op dit moment is standaardisatie echter nog niet ver gevorderd, en moeten we zorgvuldig zijn in de ontwikkeling en toepassing van programmatische zoekinterfaces.

61

Parallel aan bovengenoemde ontwikkelingen zien we ook de behoefte (en de reactie daarop) om ontsluiting van alle soorten data en informatie te integreren: zoeken in gestructureerde gegevens (“databases”) en ongestructureerde gegevens (tekst). Deze trend is waarneembaar in (voorheen niet gerelateerde) gebieden als Enterprise Search Engines, Database engines en Application / Information Integration suites. 10.2 Zoektechnologie en informatie integratie

De verhouding tussen zoektechnologie en informatie integratie is een tweeslachtige. In feite is een zoekmachine een gereedschap voor de integratie van tekstuele informatie uit diverse bronnen, en doen zogenaamde Information Integration tools hetzelfde voor gestructureerde informatie. De laatste zijn nog relatief onvolwassen, en hebben aan het relationele model voorlopig hun handen vol. Hoewel te verwachten is dat de toenadering van gestructureerde en ongestructureerde informatie juist op de EII markt een grote invloed zal hebben, zal dit nog geruime tijd op zich laten wachten. Slechts IBM heeft meer dan vage plannen in die richting, en zelfs zij zijn nog ver verwijderd van daadwerkelijke implementatie. Aan de andere kant wil men met metadata en zoektechnologie soms informatie uit meerdere databases indexeren. Wanneer EII tools hun belofte waarmaken hoeft dit niet anders te zijn dan het indexeren van een enkele (virtuele) database. 10.3 WADI en zoektechnologie

Bij het WADI project zijn er twee metadata structuren van belang voor het ontsluiten van de natte meetgegevens: Het centraal vastgestelde IDsW metadata woordenboek en de meer flexibele vertaling tussen “lekentaal” en “experttaal” zoals die wordt gevraagd om de informatie breder beschikbaar te kunnen stellen. Deze beide woordenboeken zijn sterk gerelateerd, en het verdient dan ook aanbeveling ze op gelijke wijze (zo al niet geïntegreerd) te behandelen. Zoektechnologie is voor een groot deel metadata management en gegevensontsluiting, en dient in de WADI systeemschets dan ook op hetzelfde niveau geplaatst te worden als de integrerende metadata laag (zie figuur 3.3). Het is van belang om zoeken te zien als integraal deel van de dataontsluiting, en niet als iets wezenlijks anders dan het browsen door informatie of het doen van SQL queries – de basistechnologieën (thesauri, ontologieën, taxonomieën) zijn overeenkomstig. Wanneer we de WADI wensen aanhouden tegen de diverse componenten van zoektechnologie zien we het volgende: · Spidering, het aflopen van decentrale informatiebronnen, is voor WADI niet van belang omdat er wordt gewerkt met een enkele centrale database. · Het afleiden van een semantische structuur uit brongegevens werkt pas goed op basis van grote hoeveelheden tekstuele informatie. In het geval van WADI, met vooral korte en relatief gestructureerde tekst is het onwaarschijnlijk dat dit goed zal werken. · Het IDsW (met daarin een gegevensmodel en gegevenswoordenboek) en het vertaalmodel tussen het formele gegevenswoordenboek en de “lekentaal” zijn twee sterk gerelateerde metadata structuren die voor WADI van belang zijn. · Indexering van gegevens aan de hand van de IDsW structuur zal op exacte wijze gebeuren, en niet op een fuzzy manier zoals gebruikelijk is bij

62

· ·

zoektechnologie. De relatie tussen de IDsW structuur en de “lekentaal” kan wel als min of meer zacht worden gezien. WADI zal mogelijk gebruik maken van een eigen (zoek)webinterface, maar voornamelijk direct programmatisch worden benaderd door andere (analyse- en visualisatie-)software. Het matchen van zoekvraag en antwoorden kan op een “zachte” manier worden uitgevoerd, en op basis van een prioriteitstelling (ranking) worden weergegeven. Afleiden semantische structuur


Spidering

Handmatige invoer semantiek


Zoekinterface

Index


Indexering

Figuur 10.1: De anatomie van zoektechnologie

Het blijkt dat er binnen WADI maar behoefte is aan een beperkt deel van het geheel aan zoekfunctionaliteit, waarbij zorgvuldige toepassing van metadata management centraal staat. Dit sluit overigens niet uit dat men zou kunnen kiezen voor geselecteerde toepassing van delen uit een zoeksysteem mits het systeem voldoende modulair is opgebouwd (en niet voor onnodige functionaliteit hoeft te worden betaald). Het is waarschijnlijk dat een dergelijke aanpak echter maar op beperkt enthousiasme kan rekenen van de kant van Enterprise Search leveranciers die zichzelf graag zien in de rol van spin in het web van het corporate intranet. We hebben echter gezien dat zoektechnologie op meer plaatsen is te vinden dan bij de leveranciers van Enterprise Search engines – en in toenemende mate ook wordt meegeleverd met andere technologie. Voor belang van WADI is bijvoorbeeld de “gratis” met de Oracle database meegeleverde teksten XMLfunctionaliteit. Als alternatieve oplossingsrichting kan men bij het ontwerpen en selecteren van voor WADI benodigde metadata technologie rekening houden met een flexibele manier van zoeken. In dit rapport hebben we niet in detail naar beschikbare metadata technologie gekeken, maar dit type software biedt mogelijk voldoende aanknopingspunten om ook een voor WADI afdoende zoekinterface op te bouwen. Deze oplossing is toekomstgericht, maar zorgvuldigheid is geboden gezien de korte staat van dienst van dit soort software.

63

Speciale aandacht zal binnen het WADI project moeten worden geschonken aan het opbouwen van de “lekentaal”-“experttaal” woordenlijst. De beschikbare meetgegevens bieden slechts inzicht in de experttaal, en per definitie is deze woordenlijst niet door enkel experts op te stellen. Mogelijk kan het proces worden ondersteund door automatische analyse van op basis van de meetgegevens geschreven rapporten (bijvoorbeeld milieueffectrapportages), maar het is onvermijdelijk dat er (ook) veel handwerk in dit proces zal gaan zitten. 10.4 WADI en de omgeving

Op de uitvoer van WADI-voorganger DONAR zijn veel visualisatie- en analysetools gebouwd die de overgang naar WADI naar verwachting zullen overleven. Het is dan ook niet overdreven om te zeggen dat de vorm van het (programmatische) WADI query-interface van invloed zal zijn voor de doorontwikkeling van deze software de komende 10 tot 15 jaar. Het aanbieden van een programmatisch zoekinterface (in plaats van, of naast, gestructureerde querying) past goed in de door Gartner gesignaleerde trend dat software zelf ook steeds meer zal gaan “zoeken”: De eindgebruiker zal de WADI data in veel gevallen indirect via de analysetools willen benaderen – een geünificeerd programmatisch zoekinterface op WADI helpt daarbij om in diverse tools dezelfde zoekresultaten te kunnen krijgen. Omdat standaard zoektalen momenteel nog niet zijn uitgekristalliseerd, is het waarschijnlijk verstandig om rekening te houden met een aanpassing dan wel uitbreiding van het zoekinterface wanneer standaarden worden vastgelegd. Doordat zoeken als algemeen interface zal worden toegepast, mogelijk ook voor gegevensanalyse, is het niet meer acceptabel als zoeken gebeurt op een niet-synchrone schaduw-copie van de originele data (mogelijk wil men wel diverse “service levels” instellen voor verschillende gebruikersgroepen, maar deze scheidslijn ligt niet bij het zoeken dat voor alle partijen beschikbaar moet zijn). Op langere termijn is integratie van gestructureerde querying en zoeken te verwachten. Het WADI interface kan daarop anticiperen door beide interfaces op elkaar af te stemmen. 10.5 Zoektechnologie voor het verzamelen van gegevens

Het is de bedoeling om met WADI gebruik te maken van een enkel gegevensmodel, waarvoor in principe IDsW is gekozen. De WADI data zal dus in hoge mate gestructureerd zijn, met twee uitzonderingen: · Er is sprake van gegevens die momenteel niet in DONAR zijn opgeslagen, en die wel in WADI worden opgenomen. Deze gegevens zijn niet volgens een centraal vastgelegde standaard gemodelleerd, wat de aanleiding is geweest voor de vraag of zoektechnologieën mogelijk bruikbaar zijn bij het samenstellen van een enkele WADI database; · Wanneer er word besloten tot uitbreiding of aanpassing van het in gebruik zijnde model, waarna er mogelijk gegevens in meerdere modellen beschikbaar zijn (indien het niet mogelijk of wenselijk is om de historische gegevens naar het nieuwe formaat te converteren). In beide gevallen bestaat de situatie dat er voor eenzelfde soort gegevens verschillende modellen in gebruik zijn. Het verschil is echter dat gegevens die nog niet in WADI zitten aan geen enkel hard gegevensmodel voldoen, of er geen eenduidige relatie bestaat tussen het bestaande model en IDsW.

64

Zoektechnologie biedt hier helaas geen uitkomst, want zij is er weliswaar erop gericht om ongestructureerde data te structureren maar de indeling die door een automatische indexeerder wordt bereikt blijft altijd in meer of mindere mate “zacht”. De doelstelling om binnen WADI uitsluitend gebruik te maken van “harde” gegevensstandaarden als IDsW en CIW staat daarmee op gespannen voet, en zonder menselijke tussenkomst blijft het onmogelijk om deze transformatie tussen zachte en harde indeling te maken. De expliciete toepassing van metadata management kan wel worden gebruikt om een overgang van diverse modellen (bijvoorbeeld CIW naar IDsW) tijdens de levensduur van het systeem op te vangen, mits er een eenduidige relatie tussen de modellen bestaat. Bij het zoeken kan dan eenzelfde proces worden gebruikt om tussen de modeltermen te vertalen als de geplande vertaling tussen “lekentaal” en “experttaal”. 10.6 Evaluatiecriteria zoekmachines

Op basis van het uitgevoerde onderzoek kunnen we enkele richtlijnen geven bij de selectie van Enterprise Search software bij andere trajecten dan WADI. Zoektechnieken zijn onder te verdelen in zij die met expliciete metadata afhandeling werken (het gebruik van expliciete metadata structuren als ontologieen, etc) en zij die op basis van statistische clustering werken. De laatste bieden vaak slechts beperkt inzicht in de oorsprong van de gelegde relaties tussen blokken informatie (documenten), en zijn daarom ook alleen te gebruiken waar deze kennis van geen belang is. Begrip van de anatomie van zoektechnologie is belangrijk bij de selectie omdat per component aparte eisen kunnen worden opgesteld. In de markt verkrijgbare software heeft vaak sterkere en zwakkere modulen, waarmee rekening moet worden gehouden in relatie tot de eigen prioriteiten. In toenemende mate zien we de (theoretische) opdeling in componenten ook in de realisatie van de zoeksoftware terug. Een pakket als Autonomy bestaat uit losse modulen die afzonderlijk zijn aan te spreken naast het feit dat de zoekmachine als geheel programmatisch is te benaderen. Een dergelijke modulaire benadering, bij voorkeur aanspreekbaar via standaarden als SOAP (Web Services), is van groot belang bij toepassingen waarbij vereiste integratie in de IT-omgeving een black-box benadering niet verdraagt. Bij voorkeur zijn ook de bij het zoeken gebruikte semantische structuren van buitenaf benaderbaar. Tenslotte is de toepasbaarheid van specifieke zoeksoftware in een bepaalde omgeving niet alleen op basis van de specificaties vast te stellen. Gartner adviseert dan ook in alle gevallen een praktijktest met echte gegevens en echte gebruikers.

65

11 Referenties 11.1 Rijkswaterstaat

Algemene informatie over het DONAR project is te vinden op: http://131.237.47.40:8080/ Algemene informatie over het WADI project is te vinden op: http://www.wadi.nl/

“WADI Definitiestudie” Managementsamenvatting

http://www.wadi.nl/managementsamenvattingdefinitiestudiewadi.pdf Deel 1: Informatie-analyse

http://www.wadi.nl/definitiestudiedl1inf.pdf Deel 2: Oplossingsrichtingen http://www.wadi.nl/definitiestudiedl2opl.pdf

“WADI Systeemomgeving” Definitieve versie (2.1); Martin Bruggink (RIKZ); 1 oktober 2002 http://www.wadi.nl/wadisysteemomgeving.doc

“WADI Startdocument” Projectgroep WADI; 18 oktober 2001; http://www.wadi.nl/startdocument2.doc

“KENSYS: Kennismanagement bij RWS-DZH, Rapportage fasen 1 en 2 van het kennismanagement project KENSYS en beschrijving van fase 3” R. Bosman en R. Kint, RIKZ, RWS.; november 2000; Rapport RIKZ/2000.055

“Search Engines voor KenSys” Literatuuronderzoek naar search engines ten behoeve van kennissystemen; 19 april 2001

“Zoeken op VenWnet” Trends in zoekfunctionaliteit, huidige zoekfunctionaliteit en knelpunten op VenWnet en de mogelijkheden voor verbetering.; 14 februari 2001

11.2 Butler Group

“Database Management Systems; Managing Relational and XML Data Structures” Butler In-Depth Report:; September 2002

66

11.3 Gartner

“Different Approaches to Accessing Information” Research Note; A Linden; 24 May 2001; Technology, T-13-7030

“Management Update: Many Vendors, Two Leaders in Search Engine Magic Quadrant” Whit Andrews; 14 May 2003; Note Number: IGG-05142003-02

“IBM’s Xperanto Database Middleware Will See Narrow Early Use” Gartner FirstTake; Roy Schulte, Ted Friedman; 6 February 2003; FT-19-3531

“BEA Liquid Data Offers Integration Shortcut for Some Projects” Gartner FirstTake; Yefim Natis, Ted Friedman; 7 November 2002; FT-18-7297

Research cluster: “Update on Search Technology” “Letter From the Editor” French Caldwell, Whit Andrews; 7 June 2002; LE-16-9553 “Four ‘Arms’ Define Search Technology” Research Note; W. Andrews; 6 June 2002; Technology, T-16-4511 “Search Technology Tools Suited for Programs and People” Research Note; W. Andrews; 6 June 2002; Strategic Planning, SPA-16-0810 “Searching Dynamic Content: Three Ways to Succeed” Research Note; W. Andrews, M. Gilbert; 6 June 2002; Technology, T-16-1777

Research cluster: “Search Technology Finds Its Future” “Letter From the Editor” Whit Andrews; 17 April 2002; LE-16-2474 “Search Technology’s Presence Grows, but Maturity Is Slow” Whit Andrews, Gartner Article Top View, 17 April 2002; AV-16-2329; “Making Search Installations Secure” Research Note; W. Andrews; 11 April 2002; Strategic Planning, SPA-16-0809 “Where Search ASPs Will and Will Not Prosper” Research Note; W. Andrews; 9 April 2002; Strategic Planning, SPA-15-3087 “Verity: Refocusing on Search Market With New K2 Product” Research Note; S. Hayward; 10 April 2002; Products, P-15-9911 “Inktomi Enterprise Search: Maturing the Ultraseek Promise” Research Note; W. Andrews; 9 April 2002; Products, P-15-2910 “Google Offers Enterprise Search in a Service, or in a Box” Research Note; W. Andrews; 28 February 2002; Products, P-15-2916

67

“Technology for Enterprise Search Comes in Many Flavors” Research Note; S. Hayward, W. Andrews; 7 February 2002; Technology, T-153607 “Glossary of Search Engine Terminology” Research Note; D. Logan, A. Linden, K. Shegda; 17 April 2002; Technology, T16-0284 “The Gartner 2002 Enterprise Search Magic Quadrant” Research Note; W. Andrews, S. Hayward, A. Linden; 7 February 2002; Markets, M-14-9748 “Schwab ‘Phrases’ a Different Question” Research Note; D. Furlonger, A. Linden; 23 August 2001; Case Studies, CS-143503

11.4 Overige referenties

“XQuery and XPath Full-Text Requirements” W3C Working Draft 14-February-2003; Edited by Stephen Buxton (Oracle Corp) and Michael Rys (Microsoft). This version: http://www.w3.org/TR/2003/WD-xmlquery-full-textrequirements-20030214/ Latest version: http://www.w3.org/TR/xmlquery-full-text-requirements/

“XQuery and XPath Full-Text Use Cases” W3C Working Draft 14-February-2003; Edited by Sihem Amer-Yahia (AT&T Labs) and Pat Case (US Library of Congress). This Version: http://www.w3.org/TR/2003/WD-xmlquery-full-text-use-cases20030214/ Latest version: http://www.w3.org/TR/xmlquery-full-text-use-cases

“W3C Publishes Working Draft Specifications for Full-Text Search” Coverpages http://xml.coverpages.org/ni2003-02-17-b.html

“RDF, SQL and the Semantic Web - a case study” Dan Brickley , Libby Miller http://ilrt.org/discovery/2000/10/swsql/

“Database Strategies for Unstructured Content” XMLMagazine; Stuart J. Johnston; 2002/04 http://www.fawcette.com/xmlmag/2002_04/magazine/features/sjohnson/def ault_pf.asp

11.5 Achtergrondinformatie

“The Semantic Web: Trying to Link the World” Gartner Research Note; A. Linden; 30 August 2001; Technology, T-14-2779

68

“Understanding and Using Taxonomies” Research Note; D. Logan; 21 May 2001; Tutorials, TU-13-5274

“Enterprises Widen the Search Net” http://www.idg.net/go.cgi?id=798730 Computerworld; Drew Robb; APRIL 21, 2003

“What is XQuery?” XML.com; Per Bothner; October 16, 2002 http://www.xml.com/pub/a/2002/10/16/xquery.html

“Introduction to Native XML Databases” XML.com; Kimbro Staken; October 31, 2001 http://www.xml.com/pub/a/2001/10/31/nativexmldb.html

69

70

71

72

Ministerie van Verkeer en Waterstaat. jklmnopq. Meetkundige Dienst

Recommend Documents