characters sets en foutafhandeling

wellicht ten overvloede nog even een paar opmerkingen over xslt's in samenwerking met WebQuery:

a) als er gebruik gemaakt wordt van xslt's (dus inmiddels bijna altijd) bepaalt WebQuery aan de hand van de output opties van de xslt wat de eigenschappen van de output zijn. Neem dus in IEDERE xslt een output regel op, en geef daarin een method en een encoding aan. Vergeet je die, dan zijn de defaults xml en utf-8, dus waarschijnlijk niet wat je wilt.

b) als er een fout optreedt buiten de xslt, wordt ALTIJD de xslt aangeroepen. Bij een aantal algemene fouten kan dat een andere dan de "gewenste" xslt zijn, omdat wq_sfx dan nog niet is geinterpreteerd. Zorg er dus voor dat IEDERE xslt gebruik maakt van (voorlopig nog) ora-errors.xslt voor de foutafhandeling.

Klaar voor OAI interface !

In minisis konden we zoeken op een range van waarden, bijvoorbeeld jaren van uitgave, door de twee waarden gescheiden door een dubbele slash als zoek criterium mee te geven. (bv 1950//1960 of sneeuw//sneeuwschuiver). Dit is niet erg eenvoudig te realiseren in een text georiënteerde zoekindex. In Minisis is het pas in een van de laatste versies op veler verzoek geïmplementeerd. In Oracle text retrieval bestaat deze mogelijkheid dus niet.
Dit is een probleem voor onze OAI (Open Archive Inititative) interface op de Wageningen UR publicaties.
Daarvoor moeten we namelijk eenvoudig kunnen zoeken naar gewijzigde dan wel ingevoerde records tussen twee datums. Om dit mogelijk te maken moeten we een extra index definiëren. We hadden tot nu toe voor iedere Oracle tabel 2 indexen. De text index op het gehele xml document en een aparte index voor het ISN. Er komen nu standaard 2 indexen bij voor de invoer- en wijzigingsdatum van een record.

In WebQuery 5.32 en wqoracle 1.2, die sinds gisteren de productieversies zijn, is het gebruik van deze nieuwe indexen mogelijk gemaakt. Je kunt nu in de "creation date" en de "modification date" zoeken op een range . Daarvoor zijn twee nieuwe pseudo-velden gedefinieerd, wq_cdt en wq_mdt. De zoekstring voor deze velden MOET een (één) slash bevatten als delimiter tussen begin- en eind-moment. Beide momenten mogen afgekapt worden waar je wilt. Een paar voorbeelden: wq_mdt=2005-10/2005-11 zoekt alle in oktober gewijzigde records in dit geval in de NIEUWS database.
De zoekvraag wq_cdt=2005-10-19T11:30/2005-10-20 betekent: zoek alle op 19 oktober na 11:30 uur ingevoerde records.

Zo kan ook de OIA interface op Wageningen UR publicaties gebruik gaan maken van de snellere Oracle database.

De nabijheidsoperator

In een eerdere post vertelde ik al dat in het nieuwe Bibliotheek Content Management System we te maken hebben met standaard 'phrase searching' en dat word searching expliciet moet worden gedaan door het gebruik van de 'AND' operator. We hebben nu echter ook de "near()" operator om te zoeken naar woorden binnen een record. Zo kan bijvoorbeeld met http://library.wur.nl/WebQuery/wurpubs?title=near((water,management),2) gezocht worden naar alle records in WaY waarbij in de titel de woorden water en management voorkomen, mits tussen deze woorden maximaal 2 andere woorden zitten.
In dit geval vinden we dus titels waarin "water management" staat, maar ook "water quality management" en "management of irrigation water" wordt gevonden.

Waarom zie je nieuwe records soms niet op het web ?

Wanneer je, op dit moment, een nieuw record of nieuw exemlaar in de catalogus invoert, dan valt op dat je het record of exemplaar nog niet in de catalogus op het web kunt vinden. Dit verschijnsel is een gevolg van de wijze waarop Minisis het laatst ingevoerde record bijhoudt. Om deze 'pointer' bij te werken moet Minisis namelijk de database heropenen. Op het web wordt de database in principe alleen 's-avonds gesloten en heropent en soms overdag als een zoekvraag een time out veroorzaakt. Vandaar dat je de nieuwe dingen doorgaans pas de volgende dag ziet verschijnen in de webcatalogus. In de Oracle situatie is dat straks afgelopen en zal je de nieuwe records wel direct te zien krijgen.

SEP overzichten snel te genereren in WebQuery Oracle

SEP (Standard Evaluation Protocol) overzichten zijn verplicht materiaal voor de wetenschappelijke verslaglegging. Die zijn nu eenvoudig te genereren uit WaY met één stylesheet. Het duurt weliswaar een seconde of 4 á 5 maar dan staat ie er. Daarvoor zijn in die tijd 72 (!!) zoekvragen aan WebQuery gesteld. Dan is die response tijd wel acceptabel dacht ik.

zoeken op PLANT-BZ geeft als resultaat PLANT-HG

Da's raar. Zoeken op PLANT-BZ geeft PLANT-HG :) Dat is nou het gevolg van het transparant doorgeven van zoekvragen aan Oracle text Retrieval. Wanneer in de text een Oracle operator staat wordt dat doorgegeven. Dat kunnen we voorkomen, maar dan kunnen subtiele dingen als het afwijken van standaard 'phrase searching' (zie mijn vorige post) niet meer. Dus het is uitkijken met die operatoren. De '-' is bijvoorbeeld zo'n operator. Zoeken op het acroniem PLANT-BZ is dus zoeken op records waar in het acroniem het woord PLANT staat, mits er niet het woord BZ in voorkomt !!! Wil je voorkomen dat operatoren niet als zodanig worden herkend dan moet je om het geheel accolades zetten. Wil je dat sommige operatoren wel ( in dit geval 'or' om zowel PLANT-BZ als PLANT-HG te vinden) worden herkend en anderen niet, escape dan die niet gewenste operatoren met een '/'.

Word searching en phrase searching

Ofschoon we met WebQuery eigenlijk verschoond willen blijven van database afhankelijke dingen, blijkt het in de praktijk toch te verleidelijk om niet gebruik te maken van directe kracht van onderliggende database. We gaan er maar van uit dat we niet te vaak van database zullen wisselen. Daarom toch maar wat oplossingen gebaseerd op Oracle text retrieval.
Onder Minisis was zoeken in een veld standaard 'word searching'. Onder Oracle is het standaard 'phrase searching'. Om toch word searching te doen binnen een veld moet je expliciet een operator tussen woorden gebruiken. In Oracle text retrieval is dat bijvoorbeeld 'and' en | of 'or'. In plaats van een 'or' of | mag je ook een comma gebruiken. Het heeft een iets andere betekenis, maar in de praktijk geeft het hetzelfde resutaat als een or. Vergeet niet haakjes om de totale vraag te zetten. We gaan dat overigens WebQuery automatisch laten doen.

Waarom niet in het Nederlands

Ik ben deze blog begonnen in het Engels. Ik denk echter dat het interessanter is om hem voornamelijk intern te gebruiken binnen Bibliotheek Wageningen UR. Misschien zelfs voornamelijk binnen AOB. Vandaar dat ik maar over ga in het Nederlands. Op dit moment ben ik zelf bezig met Cardex en Way.