Wij zijn verhuisd! We bloggen verder met onze collega's van de afdeling I&M: http://im2punt0.wordpress.com/

prezi

Vast niet nieuw voor sommige van jullie, maar ik was onder de indruk: prezi.com.

Een alternatief voor powerpoint, je kunt er prachtige dingen mee maken. Je werkt natuurlijk online, dus geen applicatie op je pc nodig, en het levert een presentatie op, die je online kan afspelen, maar ook als flash object kan downloaden.

Mjin probeersel staat hier: https://prezi.com/secure/5d82d263bf9ac957fdaab8dfa273f72e245bb97f/

Account is gratis, en als 'educational' user kun je nog gratis upgraden naar een account met wat meer mogelijkheden.

Voor u gelezen

Mastering the Requirements Process (Second Edition)

Suzanne Robertson, James Robertson

Addison-Wesley Professional, 2006

ISBN: 978-0-321-41949-1

592 pagina's

In de loop van een project blijkt vaak dat nog niet helemaal duidelijk is wat nou precies de eisen zijn voor het eindproduct. We willen een systeem voor X, maar waar moet dat systeem precies aan voldoen? Wie moet het gebruiken? Wat moeten ze er mee kunnen doen? Wat zijn de randvoorwaarden?

Daarmee loop je het risico dat het eindproduct toch niet is wat de opdrachtgever er van verwachtte. Of dat de gebruikers er niet beter of sneller mee kunnen werken dan met wat er al was.

Uiteraard zijn er methodes ontwikkeld om die eisen (oftewel de requirements) vooraf zo goed mogelijk boven tafel te krijgen.

Eén zo'n methode wordt beschreven in het onderhavige boek.

In 15 hoofdstukken, plus 4 uitgebreide appendices, komen het hele proces aan de orde; van de "project blastoff" tot en met het moment dat de requirements voldoende compleet zijn om aan de ontwikkelaars te geven.

Een korte samenvatting:

Hoofdstuk 1. What are requirements?

Inleiding en het een en ander over het "Volere Requirements Process" (waar dit boek op gebaseerd is)

Hoofdstuk 2. The requirements process

Een overzicht van het proces.

Daarbij worden drie soorten projecten onderscheiden, gebaseerd op de mate van formaliteit.

Hoofdstuk 3. Project blastoff

Aan het begin van het project wil je een ruw beeld hebben van wat het eindproduct moet gaan doen en wie de "stakeholders" zijn.

Daarbij is het ook van belang te weten wat er wel en niet bij hoort. Bijvoorbeeld:

als je eindproduct gebruik gaat maken van een bestaand systeem, vallen eventuele wijzigingen of uitbreidingen van dat systeem ook bij je project?

Overigens kan dit ook in de voorfase van het project al gebeuren, als je eerst wil weten of een project wel uitvoerbaar is.

Hoofdstuk 4. Event-driven use cases

Hierin wordt het schrijven van use cases behandeld. "Event driven" wil zeggen: er komt een signaal bij je product

(dat kan een handeling van een gebruiker zijn of een automatisch signaal) en je product reageert daarop.

Hoofdstuk 5. Trawling for requirements

Het is lang niet altijd voldoende om mensen alleen te vragen wat ze willen.

Je mist dan bijvoorbeeld dingen die zij vanzelfsprekend vinden, maar anderen niet.

Daarom worden in dit hoofdstuk diverse technieken besproken om requirements te ontdekken.

Hoofdstuk 6. Scenarios and requirements

Scenarios zijn ook een methode om requirements te ontdekken. Het zijn gedetailleerde uitwerkingen van use cases: wat moet er precies gebeuren? Wat zijn de voorwaarden vooraf? Wat is het eindresultaat van deze use case? Daarbij kan ook naar boven komen dat een use case bestaat uit een stukje "te maken product" en een stukje "bestaat al".

Lang niet alles wat in zo'n scenario staat hoeft dus terug te komen in je eindproduct.

Hoofdstuk 7. Functional requirements

In de "functional requirements" beschrijf je wat je product moet doen om een scenario uit te voeren. Deze requirements kun je vastleggen in data- of domeinmodellen.

NB: in deze fase kijk je nog niet naar de techniek. Je modellen zullen dus niet één-op-één vertaald kunnen worden naar een programmeertaal.

Hoofdstuk 8. Nonfunctional requirements

De "niet-funtionele" requirements beschrijven niet wat je product moet doen, maar hoe goed. Denk aan dingen als: het moet er begrijpelijk uitzien; het moet snel zijn; het moet werken op een standaard computer binnen deze organisatie.

Hoofdstuk 9: Fit criteria

Je hebt nu een heel stel eisen, maar die zijn lang niet altijd SMART geformuleerd. Zie het voorbeeld hierboven: het moet er begrijpelijk uitzien, maar hoe meet je dat?

De belangrijkste les uit dit hoofdstuk is: elk requirement is meetbaar te maken. Zo kun je voor "er begrijpelijk uitzien" stellen "bij een gebruikersonderzoek geeft 90% van de gebruikers aan dat het er begrijpelijk uit ziet".

Vergeet ook niet om hierbij collega's te betrekken die ervaring hebben met testen en gebruikersonderzoeken.

Hoofdstuk 10. Writing the requirements

Hoe schrijf je je requirements zodanig op dat je er ook echt wat aan hebt?

De stakeholders moeten het er mee eens zijn, de ontwikkelaars moeten ze begrijpen en je wilt ook graag een manier om straks bij te houden hoe het staat met de implementatie.

In bijlage B van het boek staat een "requirements specification template" om je op weg te helpen.

Hoofdstuk 11. The quality gateway

Het is een goed idee om de requirements nog eens kritisch te laten bekijken voordat je verder gaat. De kwaliteitscontroleur kijkt naar dingen als "zijn de requirements compleet", "zijn ze onderling consistent", "is dit uitvoerbaar". Ook is het belangrijk om te controleren dat het echt requirements zijn en niet al oplossingen. Een requirement mag wel zijn "het moet werken op mobiele apparaten", maar niet "we gaan een iPhone app maken".

En de kwaliteitscontroleur kijkt of er geen requirements zijn ingeslopen die buiten de scope vallen van wat er in het begin van het project is afgesproken.

Hoofdstuk 12. Prototyping the requirements

Je maakt een prototype op basis van de requirements die je hebt en laat stakeholders daar naar kijken. De kans is groot dat je daarmee nog meer requirements ontdekt. Bijvoorbeeld "je moet hier ook kunnen zoeken" of "je doet hier alsof X altijd voor Y komt, maar in praktijk komt Y ook vaak voor X".

Het moge duidelijk zijn dat dat weer leidt tot aanpassingen van je requirements documenten.

Hoofdstuk 13. Reusing requirements

Veel requirements komen steeds weer terug en zijn dus herbruikbaar. Als je bijvoorbeeld vaak back-office systemen maakt, dan weet je al voor wat voor welke gebruikers het is en wat de technische grenzen zijn ("moet kunnen werken op onze bestaande computers").

Hoofdstuk 14. Reviewing the specification

Op een gegeven moment heb je een stel requirements waar je wat mee kunt. De kwaliteitscontroleur heeft ze goedgekeurd en de ontwikkelaars willen er mee aan de gang. Dat is het moment om prioriteiten te gaan stellen. Welke requirements moeten

als eerste geïmplementeerd worden? Zijn er geen requirements die elkaar in de weg gaan zitten?

De projectleider zal ook willen weten hoeveel tijd en geld het zal gaan kosten om het product te maken en wat ongeveer de planning zal worden.

Bij sommige requirements zul je risico's ontdekt hebben. De stakeholders willen iets heel graag, maar het is nog niet duidelijk of het mogelijk is. Ook die wil de projectleider dan graag weten.

De risico's, kosten en urenschatting kunnen weer aanleiding zijn om de requirements nog aan te passen.

En in het uiterste geval kan op dit punt nog worden besloten om het project toch maar niet voort te zetten, omdat het niet mogelijk zal zijn om iets te maken wat aan de eisen voldoet.

Hoofdstuk 15. Whither requirements

De auteurs beseffen dat het opstellen van goede requirements niet een kwestie is van simpelweg alle stappen uitvoeren die in de voorgaande hoofdstukken zijn beschreven. In dit laatste hoofdstuk geven ze tips over hoe je het proces kunt aanpassen aan je eigen project, wat voor tools je kunt gebruiken en hoe je om kunt gaan met de onvermijdelijk veranderingen in de requirements.

In de bijlagen vind je tenslotte:

Volere Requirements Process Model

Volere Requirements Specification Template (handig als checklist)

Function Point Counting (een manier om urenschattingen te maken)

Project Sociology Analysis Templates (hoe weet ik wie de stakeholders zijn?)

Na lezing van dit boek hebben we een aardig idee van hoe onze projecten nog beter kunnen worden. Het is dan wel van belang dat er in het project ook tijd gereserveerd wordt voor het ontdekken en uitwerken van de requirements.

Voor U Gelezen
Titel: Organiseer je informatie
Aan de slag met thesauri, taxonomieën, tags en topics
Auteurs: H. Magrijn, E. Sieverts, M. van der Linden, P. Becker
Geïllustreerd | gebonden | 240 bladzijden | 24 x 17 cm | 2010
Publisher: Biblion Nbd (September 2010)
http://www.nbdbiblion.nl/?pagina=22659
Language: Nederlands
ISBN: 978 90 5483 954 5




Er is bijna geen beter moment om wat vakliteratuur ter hand te nemen dan te bed met een griep. Te slap om op te staan maar te sterk om domweg niets te doen. Dit boek kreeg ik in mijn hand gedrukt door mijn collega en co-auteur Eric Sieverts en heeft de uitdagende en verleidelijke titel 'Organiseer je informatie'. Uitdagend in de zin dat dit niet alleen een gebiedende wijs is, maar ook dat in deze tijden van 'informatieoverload' het ordenen van informatie een noodzaak is. Verleidelijk ook, want is het niet een droom om al je informatie voor eens en altijd keurig op een rij te hebben na het lezen van een boek? 'Organiseer je informatie' is geclassificeerd als basisboek voor HBO- en GO-opleidingen maar ook voor informatiespecialisten,webmasters en kenniswerkers. Als snellezer heb ik mij schuldig gemaakt aan het overslaan van de ondertitel 'Aan de slag met thesauri, taxonomieën, tags en topics' en kwam daardoor in een totaal ander boek terecht dan ik had verwacht.

In de twaalf hoofdstukken wordt een ferme en brede basis gelegd hoe en met welke gereedschappen informatie georganiseerd kan worden. Met een goed gevoel voor opbouw weten de auteurs de soms subtiele verschillen tussen diverse begrippen, concepten en definities helder uiteen te zetten. De vele sprekende voorbeelden zijn daarbij een prima aanvulling. Intrigerend voorbeeld is de verwijzing naar een youtube fragment van bibliothecaris André van Duin die de boeken sorteert op kleur. Waarom ook niet?
Dit uiterst vermakelijke filmpje is niet direct te vinden op youtube met zoektermen als André van duin , blauwe boeken, bibliothecaris , uitlenen , lenen etc. Het is in werkelijkheid omschreven als 'De dik voor mekaar show - TELETHEATER - Vreemde Bibliotheek met Ron Brandsteder' en te vinden op http://www.youtube.com/watch?v=sg2KRGrkNWA Een beter voorbeeld voor de noodzaak tot organiseren is er niet lijkt mij.

Tijdens het lezen had ik meerdere malen een niet onplezierig gevoel van 'AHA'. In het dagelijkse werk lopen concepten en begrippen onbewust in elkaar over (of lijken soms samen te smelten) en de kracht van het boek is nu juist dat deze stapsgewijs en overzichtelijk beschreven worden. Met recht mag dit boek dus een basisboek heten en wat mij betreft kan het tevens als naslagwerk dienen.

Kan ik na het lezen van dit boek nu mijn informatie organiseren ? Gezien het aantal bestanden in de root van mijn schijf zou ik zeggen : Nee ! Daarbij laat ik mij graag inspireren door het plagende hoofdstuk 7.3 'Is ordening noodzakelijk?'. Verwezen wordt naar het boek 'Everything is miscellaneous: the power of digital disorder' (prachtige titel) van David Weinberger waarbij 'disorder' geen probleem is zolang die 'disorder' maar doeltreffend doorzocht kan worden. Maar....we zijn nu wel weer bij de les en weten hoe het allemaal zou moeten. Ik zou bibliotheken aanraden dit boek bij het kerstpakket te verpakken zodat niet alleen de auteurs hierbij baat hebben maar ook de lezers van het boek die dan nog beter onze informatie kunnen organiseren.

Don't cut on innovation, because innovation is essential

Even een preek voor eigen parochie.
In de recente aflevering/uitzending van "This week in libraries" vanuit de OBA, breekt presentator Erik Boekestein een lans voor innovatie. Hij vreest veel bezuinigingen bij bibliotheken, maar:
"There's one thing that I do hope, that's that libraries do not cut on innovation, because innovation, I think, is essential ....".
En als je dan toch gaat kijken kun je meteen een lang interview met Bas meenemen.

Eric

Digitale universiteit laat student wel aan zijn trekken komen

Mijn reactie op een opinie van Ewoud Sanders in een NRC weekend-bijlage van 4/5 september [NRC-archief, foto van de krant] heeft de redactionele zeef helaas niet overleefd. Daarom hier alsnog die reactie.

In de bijlage Opinie & Debat van 4 september suggereert Ewoud Sanders dat de digitale student op onze universiteiten niet aan zijn trekken komt. Het daarbij door hem geschetste beeld van zowel 'de student' als 'de universiteit' doet nogal karikaturaal aan en noopt tot enige reactie.

In zijn stuk beschrijft Sanders een wel heel specifiek soort student, met heel specifieke informatiebehoeften, die zeker niet kenmerkend is voor een meerderheid van de studenten waarmee we op universiteiten te maken hebben. Op dit detailniveau zouden we wel duizend soorten studenten met uiteenlopende wensen en behoeften kunnen onderscheiden. Zijn beeld gaat er bovendien vanuit dat studenten zo veel mogelijk van leesvoer in de vorm van hapklare brokken voorzien moeten worden. Nog afgezien van het feit dat het een praktische onmogelijkheid is om centraal die hapklare brokken voor al die verschillende soorten studenten klaar te zetten, moet je dat ook niet willen. Om studenten klaar te stomen voor de later van hen verwachte wetenschappelijke werkwijze is het juist belangrijk dat studenten zelf methoden en technieken ontwikkelen om de voor hun onderzoek relevante informatiebronnen te ontdekken en selecteren. Dat daar in de eerste jaren ondersteuning bij nodig is, behoeft geen betoog. Maar die ondersteuning wordt vanuit universiteitsbibliotheken en faculteiten ook in toenemende mate geboden.
Dat Google voor veel studenten het referentiekader voor hun informatievoorziening is ben ik uiteraard met Ewoud eens. Webzoekmachines hebben echter ook (bij ons allemaal) een verwachtingspatroon van 'instant satisfaction' doen ontstaan. Het resultaat van zoekacties op het web levert meteen de gezochte informatie in zijn volledige vorm op ons beeldscherm, zonder vertragende tussenstap van fysiek bibliotheekbezoek of (online) aanvragen van artikelen die later moeten worden toegestuurd. Sterker nog, die niet online beschikbare artikelen zal de student ook meestal helemaal niet met Google lunnen vinden, zoals Ewoud Sanders suggereert.

Het door Sanders geschetste beeld van de universiteit doet ook geen recht aan de werkelijke huidige situatie. Universiteiten en in het bijzonder universiteitsbibliotheken spelen in dit opzicht al een heel andere rol. Daarbij ter illustratie een paar voorbeelden van de situatie in Utrecht. In de eerste plaats is al heel veel wetenschappelijke informatie digitaal toegankelijk in de vorm van wetenschappelijke artikelen, proefschriften, rapporten en boeken. Voor deze informatie die in veel gevallen niet met Google te vinden is, komen steeds vaker aparte zoekmachines beschikbaar, specifiek gericht op het materiaal waarvoor de betreffende bibliotheek licenties heeft. Zo kan ook voor dit materiaal aan die verwachting van 'instant satisfaction' worden voldaan. In Utrecht is al 10 jaar ervaring met het Omega-systeem dat onder studenten en aankomende onderzoekers populair is, omdat het laagdrempelig, in een enkele Google-achtige zoekgang, directe toegang biedt tot de volledige teksten van al die bronnen.
Eerder gaf ik al aan dat bibliotheken niet ambiëren om voor alle specifieke soorten studenten kant en klare literatuurcollecties klaar te zetten. Wat wel gebeurt, is dat per studierichting verwijzingen naar de daarvoor relevante bronnen worden gegeven, niet alleen naar de door Sanders schijnbaar verfoeide bibliografische databases, maar ook naar de full-text bronnen op dat terrein. Bovendien kan elke Utrechtse student in zijn 'Personal Library' de basiscollectie voor zijn studierichting aanvullen en daarin wieden naar eigen behoefte en inzicht.

Ewoud Sanders suggereert verder nog dat men zich zorgen zou (horen te) maken over het feit dat studenten geen fysieke bibliotheek meer zouden bezoeken. En ook dat dat een nieuw verschijnsel zou zijn. Toen ik zelf 40 jaar geleden als natuurkundige afstudeerde, had ik zelf ook nog nooit een UB van binnen gezien. Nu iedereen toegang heeft tot de eerder geschetste digitale bibliotheek, doet zich het opmerkelijke feit voor dat studenten juist in steeds groter getale de werkplekken van de fysieke bibliotheek blijken te bevolken, ook al is dat misschien om gebruik te maken van die digitale diensten en bronnen die ze ook op hun studentenkamertje online ter beschikking hebben.


Eric Sieverts

Expert PHP 5 Tools Boek bespreking

Expert PHP 5 Tools - Dirk Merkel

Voor U Gelezen in drie uur (447 pagina's )
ISBN 978-1-847198-38-9
Aanschaf op basis van 'Look inside this book' van Amazon.





Tegenvaller: het is nu gratis beschikbaar via http://www.fileserve.com/file/t8btUdR/Packtpub.Expert.PHP.5.Tools.Mar.2010.rar
Example Source code: http://www.packtpub.com/files/code/8389_Code.zip
Mijn mening: Expert Tools zijn veelal bekend bij 'PHP experts'. De bijbehorende manuals en docs van dit soort tools zijn dan de meest voor de hand liggende ingangen voor een developer. Het is dan ook een hele opgave om daar nog eens een zinvol boek over te schrijven. Echter de heldere samenvattingen en inzichten in dit boek voegen wel een zekere meerwaarde toe. Neemt niet weg dat bepaalde hoofdstukken overbodig zijn doordat deze zaken aanpakken die zich niet in enkele pagina's laten beschrijven (frameworks, UML, Unit testing). Het is wel een prima overzicht voor de groep die meer wil dan coderen alleen en de 'peripherals' wil verkennen.

Samenvatting

Hoofdstuk 1 Code style and Standards
De auteur geeft tamelijk strikte regels over hoe te coderen.
Enkele instructies:
-gebruik 'heredoc' voor lange strings (page 10)
-scheidt de instantiating (constructor) van de initialisatie bij een object (page 19)
-gebruik altijd require_once (page 22)
-Opmerkelijk is dat de auteur er op staat dat files UNIX style zijn dus geen '\r\n'maar enkel '\n'.Daarbij kan via de tool PHP_CodeSniffer de code gecontroleerd worden op afwijkingen en het is maar goed dat daar een eigen 'style' aan gekoppeld kan worden. Welnu, als iedereen op de wereld daaraan voldoet dan kan globaal code sneller geladen worden en kunnen datacenters toe met minder energie en kunnen we zo bijdragen aan het milieu.
Vlug naar het volgende hoofdstuk want dit onderwerp staat altijd garant voor fundamentalistische discussies.

Hoofdstuk 2 Documentation with phpDocumentor

Allereerst een pleidooi waarom inline documentatie behoort tot 'goede' php code en een kleine inleiding tot phpDoc. Niets nieuws onder de zon met betrekking tot de bestaande manuals van phpDoc. Wel is dit een handig en 'comprehensive' hoofdstuk omtrent phpDoc en zeker het naslaan waard. Aardig weetje is het gebruik van customtags (page 92). In een voorbeeld project schets de auteur vervolgens hoe en waar phpDoc ingepast kan worden.

Hoofdstuk 3: The Eclipse Integrated Development Environment

Specifiek over de Eclipse IDE. De auteur stelt dat Ecplipse de meest stabiele, meest gebruikte IDE tool is die ook nog eens probleemloos voor andere talen gebruikt kan worden. Voortgekomen uit IBM is de tool nu in handen van een non-profit organisatie. In een 'quick overview' komen de voordelen langs zoals highlighting, code completion, code assist, workspaces , projects , phpDoc, templates,debugging etc.
Jammer dat de auteur geen andere alternatieven aanstipt.


Hoofdstuk 4: Source Code and Version Control

Een hoofdstuk omtrent source control met focus op Subversion waarvan het online handboek te vinden is op http://svnbook.red-bean.com/
In het kort worden de diverse concepten en definities van Subversion helder neergezet. De svn command-line client wordt besproken compleet met de reference guide en een voorbeeld hoe een project onder source control te starten. Dit wel op basis van wat custom scripts ('hooks') van de auteur en dat maakt het wat minder generiek. Wel biedt dit dan de mogelijkheid om bijvoorbeeld code standards af te dwingen of notifications te verzenden. Het concept branching en merging komt aan bod inclusief een verhelderend diagram (page 181). Dit allemaal weer via de svn commandline. Nb: voor onze problemen met checkouts op Samba shares kan dit wel een goed alternatief zijn. Andere clients worden kort genoemd zoals Tortoise.
Aardig weetje is WebSVN, een mooi project van SVN om diverse zaken van 1 of meerdere repositories te bekijken. Inclusief RSS. Wellicht een handige feature om ook te installeren.
Zie ook http://www.websvn.info/
De 'best practices' noemt de veelgebruikte indeling 'trunks, tags, branches'. Weliswaar niet verplicht maar wel een indeling die wereldwijd gebruikt wordt.
Dit hoofdstuk is niet alleen waardevol als naslag maar geeft ook net wat extra informatie die ook voor reguliere SVN gebruikers handig is.

Hoofdstuk 5: Debugging 197

Alle debugopties in php.ini komen voorbij evenals enkele core php functies die handig zijn bij debuggen. Varieërend van var_dump tm get_object_vars. Vreemd genoeg ontbreekt het handige 'get_defined_vars'. Dan een uitgebreid voorbeeld van een eigen debug class.
Net iets te breed uitgesponnen temeer daar ook veel voorbeelden te vinden op http://www.phpclasses.org/ en frameworks in het algemeen deze voorzieningen al bieden 'out of the box'. Dan een specifiek stuk over Zend's XDebug. Zend (en ook Eclipse etc) maken het mogelijk om aan een proces te attachen en vervolgens door de code heen te stappen met breakpoints en dump s van vars en parameters.

Hoofdstuk 6: PHP Frameworks 251

Een lijst met frameworks gebaseerd op het MVC pattern. Genoemd worden Zend, CodeIgniter, CakePHP, YII en Symphony. Kohana (HMVC pattern) wordt niet genoemd. Vervolgens wordt dit hoofdstuk gevuld met een lang Zend example. Gezien de docs van Zend zelf een overbodig hoofdstuk.

Hoofdstuk 7: Testing 291

Verhelderend definitie overzicht van

• unit testing
• black or white or gray box testing
• integrationtest
• continuous integrationtest
• regression test
• system test (ketentest)
• user acceptance test

Testmethodes op basis van het veelgebruikte PHPUnit framework worden nader toegelicht. Dit aan de hand van een codevoorbeeld met een bepaald zoek algorithme wat we willen testen. Dit laat zien dat Unit testing zeer zinvol is maar ook dat dit een leercurve kent en een behoorlijke tijdinvestering vergt.

TDD of Test driven development is het omgekeerde mechanisme. Schrijf de code welke voldoet aan de test. Het diagram op pagina 322 schetst dit iteratieve proces.

Hoofdstuk 8: Deploying Applications 329

Dit hoofdstuk bevat weinig interessante informatie. Het behelst een simpele applicatie (script met database) welke uitgerold wordt mbv. Subversion en andere tools. Het advies om zoveel mogelijk te automatiseren nemen we natuurlijk ter harte zeker waar het gaat om bijvoorbeeld DB schemas updates. Een build tool met uitgewerkt voorbeeld is 'Phing' (pagina 335)

Hoofdstuk 9: PHP Application Design with UML 363

Een overzicht van 14 UML diagrammen en een beknopte beschrijving van UML met een uitgewerkt voorbeeld. Voegt niet veel toe voor ontwikkelaars die reeds werken met UML.

Hoofdstuk 10: Continuous Integration 395

Het laatste hoofdstuk omtrent 'putting it all together'. Uit de summary: 'Continuous Integration is simply a combination of tasks that you are likely to perform anyway during the development and release of a project. The difference, however, is that with continuous integration, you do it earlier and more frequently. Decreasing the time between automated builds allows you to view the development of the project over time rather than to look at a single snapshot of the code. It allows you to keep a fnger on the pulse of your project and catch any problems early on.'

Even voorstellen

Is het een handige vorm van faceted search of is het vooral een dommere vorm van zoeken? Of juist een hele grafische? De toekomst misschien?
Wat do you suggest http://whatdoyousuggest.net is een zoekhulp die gebruik maakt van door Google verzameld gedrag om suggesties te doen om je zoekopdracht te verfijnen. De userinterface is zeer grafisch en nogal, ehm, Zwartwit.

2010, the library of the future

Voor wie wel deze blog volgt, maar niet de redactieblog van InformatieProfessional, verwijs ik hier toch ook nog maar even naar de post die ik daar (intussen al weer twee weken geleden) geplaatst had. Het ging over een kinderboekje uit 1972 dat bijna 40 jaar vooruit keek naar 2010 (ja naar NU!) en daarbij ook de bibliotheek van de toekomst beschreef:
"A very popular room is the library. There are no books. ...." [lees verder wat er in 2010 dan wel zou zijn ...].

Het volgende Omega-decennium (5)

[aflevering 1]
[aflevering 2]
[aflevering 3]
[aflevering 4]

Omega is nooit opgezet of bedoeld geweest als alternatief voor de bibliografische databases op diverse vakgebieden waarvoor de UU via de bibliotheek licenties heeft. Deze databases bieden een vollediger overzicht van wat gepubliceerd is, ook in tijdschriften waarop de universiteit geen (digitaal) abonnement heeft (en waaruit artikelen dus meestal moeilijker verkrijgbaar zijn). Vaak hebben die databases ook speciale zoekmogelijkheden die specifiek zijn voor een bepaald vakgebied, in veel gevallen ook met gebruik van voor zo'n vakgebied ontwikkelde, gestandaardiseerde onderwerpsingangen en thesauri.

Ter verlichting van het probleem dat voor veel onderwerpen gezocht moet worden in een aantal verschillende databases, die vaak werken met zoeksystemen met uiteenlopende gebruikersinterfaces en functionaliteit, hebben veel bibliotheken er in het verleden voor gekozen deze databases via federated search (metasearch) beschikbaar te stellen. In Utrecht is dat niet gebeurd. De nadelen - die intussen ook elders meer en meer worden onderkend - wogen onzes inziens onvoldoende op tegen de voordelen. Eén van die nadelen was bijvoorbeeld dat je ook bij metasearch vrijwel geen gebruik kunt maken van al die mooie vakgebied-specifieke zaken.

Zelfs de eerste hinderpaal die gebruikers vaak ondervinden, de keuze welke bestanden voor een vraag in aanmerking komen, wordt in nu beschikbare systemen voor federated search onvoldoende opgelost:

• Het is niet mogelijk (en meestal ook niet gewenst) om in "alle" beschikbare bestanden tegelijk te zoeken, zodat toch nog keuzes gemaakt moeten worden.
  
• Ook al zijn hiervoor voorgedefinieerde groepen aanwezig, dan nog zal bij de gebruiker enige kennis over die bestanden aanwezig moeten zijn.
  
• Voorgedefinieerde groepen zijn niet afgestemd op elk soort vraag, zodat gebruikers ze vaak toch nog naar eigen wensen moeten aanpassen.
  
• Niet alle bestanden blijken in metasearch mee te nemen, zodat meestal toch nog aanvullend in een paar losse bestanden gezocht moet worden.

Daarnaast is er een aantal zoektechnische problemen:

• Via metasearch kan alleen een grootste gemene deler van de zoekfunctionaliteit van de afzonderlijke zoeksystemen worden geboden; meer gesofisticeerde functionaliteit ontbreekt dus en ook zal niet goed gebruik gemaakt kunnen worden van de hierboven genoemde specifieke vakgerichte zoekfunctionaliteit van de afzonderlijke databases.
  
• Metasearch is traag, want de uiteindelijke responsetijd wordt beperkt door de response van het traagste systeem.

Voor de veeleisende gebruiker (die niet genoeg heeft aan Omega en/of de catalogus) heeft het dus ontegenzeggelijk voordeel als die (aanvullend) in het native interface van de betreffende systemen zoekt. Alleen blijft daarbij nog steeds als noodzakelijke voorwaarde dat de gebruiker moet weten in welke systemen voor een bepaalde zoekvraag gezocht moet worden. Daartoe zouden gebruikers ondersteund kunnen worden door een automatische "recommender", die bij elke vraag de daarvoor meest in aanmerking komende bestanden opsomt.

Het in Groningen ontwikkelde PurpleSearch bevat een "recommender" die daarvoor gebruikt zou kunnen worden. In het volledige PurpleSearch-systeem worden vragen in de praktijk ook meteen automatisch uitgevoerd in de top-tien bestanden die uit de recommender komen. Om alleen de aanbevelingen als verlengstuk voor Omega in te zetten, zou het handig zijn als deze functie als webservice beschikbaar is, wat nu nog niet het geval is.
Bij nader inzien is het echter de vraag of een tamelijk complex systeem als de PurpleSearch recommender in onze situatie wel nodig is (en zelfs of die wel tot optimale resultaten leidt). In PurpleSearch moeten de suggesties voor bestandskeuze gedaan worden op basis van alleen de paar door de gebruiker ingetikte zoektermen. Daartoe wordt op de achtergrond een zoekactie gedaan in vrij willekeurig verzameld materiaal uit die databases, teneinde een verband te kunnen leggen tussen de zoekvraag en de inhoud van de individuele databases. Het resultaat van die achtergrondzoekactie zelf wordt verder niet voor de zoeker gebruikt.
Onze situatie is een andere. Daarbij kan een zoekactie sowieso al in Omega worden gedaan, waarvan de gebruiker het resultaat ook te zien krijgt. Op basis van dat zoekresultaat is veel eenvoudiger - en misschien ook nog wel betrouwbaarder - een match te maken met meest in aanmerking komende externe databases.

Dat kan bijvoorbeeld door zogenaamde vectorrepresentaties te gebruiken van zowel de bij ons beschikbare databases, als van het resultaat van de zoekvraag. Die vector-representaties kunnen gebaseerd zijn op tijdschrifttitels (of hun ISSN's). Van al onze ca. 100 (?) in aanmerking komende databases kunnen eenmalig, vooraf vector-vingerafdrukken gemaakt worden, die aangeven welke tijdschriften in welke onderlinge verhouding karakteristiek zijn voor de inhoud van elk van die bestanden. Uit het resultaat van een Omega-zoekactie kan ook zo'n vingerafdruk worden gegenereerd, op basis van de tijdschriften waar de al gevonden artikelen uit afkomstig blijken te zijn. Een best-match tussen die vraagresultaatvector en de database-vectoren levert dan eenvoudig een op relevantie/belang geordend lijstje op van voor dat onderwerp te doorzoeken databases. Daarvoor is geen enkele menselijke interpretatie nodig welke databases of welke tijdschriften voor welk vakgebied belangrijk geacht worden. Alleen zal misschien nog wat gespeeld moeten worden met de weging van de vectorcomponenten in de vingerafdrukken. Rekentechnisch is het werken met deze vectoren een al lang door informatici opgelost probleem.

In eerste instantie zouden de zoekvragen (zoals uitgevoerd in Omega) nog niet vertaald hoeven worden naar de zoeksyntax van de betreffende databases, teneinde ze meteen al te laten uitvoeren. Om van bestandspecifieke functionaliteit gebruik te kunnen maken, zal de gebruiker zijn zoekvraag immers toch nog zelf aan de situatie moeten aanpassen. Toch zou het prettig zijn als wel al een eerste indicatie van de te verwachten opbrengst gegeven kan worden, zodat we die vertaling in een later stadium misschien toch nog moeten ontwikkelen.

[dit was voorlopig (?) de laatste aflevering van deze serie]

Het volgende Omega-decennium (4)

[aflevering 1]
[aflevering 2]
[aflevering 3]

In eerdere posts in deze serie kwamen aan de orde:

• ontwikkelingen rond "geïntegreerd zoeken"
  
• algemene voor- en nadelen van verdergaande integratie van materiaal in zoeksystemen, met het huidige Omega als uitgangspunt
  
• zoekproblemen die kunnen optreden bij integratie van artikelen (met uitgebreide inhoudelijke metadata) en catalogusrecords (met heel weinig en vaak nogal algemene metadata).

Dit keer gaat het om functionaliteit die essentieel is (of lijkt) bij het zoeken in een catalogus, maar die van weinig nut (of zelfs onmogelijk) is bij het zoeken in collecties artikelen.

Op dit moment is er vrij veel verschil in geboden zoekfunctionaliteit tussen de huidige Omega en de Aleph-OPAC (en eigenlijk elke OPAC {!**!}). Belangrijke reden daarvoor is het verschil in de wijze van gebruik tussen catalogi en artikel-databases. In een catalogus wordt relatief vaak gezocht naar "known items", teneinde dat item te kunnen lenen of het in de kast te kunnen lokaliseren. Omdat een gebruiker niet altijd de exacte naam of voorletters van een auteur, of de exacte titel van een boek kent, bieden catalogi meestal een bladerfunctie om de alfabetische omgeving van een auteursnaam of van een boektitel te zien te krijgen, om zo uit een lijstje de juiste auteur of de gewenste titel te selecteren.

Dit is een functionaliteit die op dit moment niet in Omega zit. Het is ook een functionaliteit die daar niet makkelijk - maar vooral ook niet zinvol - is in te bouwen. De auteursnamen in een catalogus zijn - als het goed is - zorgvuldig gestandaardiseerd en zelfs gethesaureerd, zodat varianten van voorletters, voornamen en zelfs achternamen en pseudoniemen, toch (bijna) altijd aan de juiste standaard naam gekoppeld zijn. Zo is het in principe mogelijk alle publicaties van een auteur te vinden, op welke naamsvariant ook gezocht is. Bij de auteursnamen van de artikelen in Omega is dat niet het geval. De metadata in Omega zijn afkomstig van allerlei verschillende leveranciers die er voor hun auteursnamen uiteenlopende standaarden op na houden (zo ze die standaarden al hebben). Zelf die gegevens (geautomatiseerd) standaardiseren zal maar in zeer beperkte mate mogelijk zijn, evenals het koppelen van de van leveranciers ontvangen naamsvarianten. En ook de DAI, de Digital Author Identifier, is daar vooralsnog niet bruikbaar voor. Voor het overgrote merendeel van de inhoud van Omega - de full-text toegankelijke artikelen en andere publicaties - is het dus niet zinvol zo'n bladerfunctie voor auteursnamen te ontwikkelen.

Voor artikeltitels is zo'n bladerfunctie ook niet echt nuttig, omdat die manier van zoeken voor dat type materiaal nogal ongebruikelijk is. De enkele keer dat iemand een known-item-search voor een artikel(titel) doet, zal dat gedaan worden op basis van een combinatie van een paar kenmerkende titelwoorden. Die aanpak hebben onze gebruikers intussen wel geleerd van hun ervaring met webzoekmachines. Overigens is dat een techniek die voor boektitels even bruikbaar is, zodat het maar de vraag is of een titel-bladerfunctie voor cataloguszoekacties in de toekomst nodig blijft.

Behalve een beetje aan de zoekkant, vereist het fysieke materiaal vooral extra functionaliteit om de gebruiker aan gevonden materiaal te laten komen. Zo moeten gegevens getoond worden over beschikbaarheid (uitgeleend of niet, meer beschikbare exemplaren op verschillende locaties, ...) en over mogelijkheden tot reservering van gevonden items. Allemaal functionaliteit die voor de digitaal aanwezige artikelen overbodig is. En wat verder voor gebruikers nog van belang is aan een catalogus-systeem: controle op aflopen van uitleentermijnen, boetes e.d., dat is allemaal administratie die niets met zoekintegratie van doen heeft. In een meer digitale toekomst die ons te wachten staat (lees het nieuwe beleidsplan van de KB daar maar eens op na) zijn dat zaken die er al helemaal niet meer toe doen - of in elk geval heel anders moeten worden.

{!**!}   Oeps, nu zie ik net dat zelfs Worldcat al geen auteursnamenbladerfunctie meer heeft. Eigenlijk ook niet zo gek, gezien het volslagen ratjetoe aan materiaal dat ze daar langzamerhand ingepompt hebben, en waar dus ook - net als bij Omega - geen enkele namenstandaardisatie of thesaurering meer wordt toegepast. Anderzijds zou zo'n kijkje in een auteursindex aan zorgvuldige gebruikers wel de kans bieden om zelf alle varianten bij elkaar te zoeken.

[wordt vervolgd]

Mobile Design and Development , Voor U Gelezen

Voor U Gelezen in ca. 4 uur in een wiebelende auto

Titel: Mobile Design and Development: Practical Concepts and Techniques for Creating Mobile Sites and Web Apps

Auteur: Fling, Brian

Paperback: 336 pages

Publisher: O'Reilly Media; 1 edition (August 24, 2009)

Language: English

ISBN-10: 0596155441

ISBN-13: 978-0596155445

Table of contents: http://www.amazon.com/Mobile-Design-Development-Practical-Techniques/dp/0596155441

Dit boek schetst een uitgebreid beeld van het mobiele landschap. Dit landschap is zo snel in beweging dat de auteur beweert dat alles ouder dan 6 maanden al weer ongeldig is en vergeten kan worden. Anders dan de titel doet vermoeden komt coderen voor mobile web vrijwel niet aan bod. De doelgroep van dit boek is dan ook veel breder dan ontwikkelaars alleen en zeker ook aan te bevelen voor iedereen die in projecten stapt die raken aan het mobiele domein. Er komen veel verfrissende inzichten aan bod hoewel de auteur soms een beetje doordraaft.

Het boek geeft ook goed inzicht in wat je beslist niet moet doen en naar mijn mening is dan ook de allerbelangrijkste uitspraak: Don't convert, Create

Meest weerzinwekkende uitspraak: good mobile design will make the lifes of peoples better.

Ik heb zelf geen mobiel en heb niet het idee dat ik wat mis en zeker niet als ik naar mijn grommende en zwetende medemens kijk die zich op het Mobile 2.0 web durft te begeven.

In een vogelvlucht de inhoud van het boek

• Hoofdstukken 1 tm 3

Deze schetsen de historie van mobile devices en bijbehorende 'ecosystemen' zoals platforms en application frameworks (androïd, windows mobile, java etc.) De scope van mobile web wordt als enorm beschouwd en ook wel 'the seventh mass medium' genoemd

(print,recording,cinema,radio,tv,internet....mobile) welke spoedig het conventionele internet gebruik zal overstijgen. Dit omdat met mobile nu eenmaal veel geld kan worden verdiend.

Daarbij is mobile internet bij uitstek het platform voor personalisatie. Want wie geeft nu ooit zijn telefoon uit handen ?

• Hoofdstuk 4 - Designing for context

Behandelt het begrip 'Context' met een grote C en 'context' met een kleine c. Een beetje een zweverig hoofdstuk maar wel één met een belangrijke boodschap.

De context van de gebruiker speelt een cruciale rol in het gebruik en het soort informatie.

• Hoofdstuk 5

Een belangrijk hoofdstuk welke uit de doeken doet waarom een 'Mobile Stategy' noodzaak is waarbij geconstateerd wordt dat mobile design en development geen goedkope zaken zijn.

Opgesomd worden 7 (soms obligate) regels.

De belangrijkste

-Focus on context, goals and needs.

-You can't support everything

-Don't convert, Create

-Keep it simple

• Hoofdstuk 6

Hier worden diverse Mobile applicaties opgesomd waaronder Native Applications (specifiek compiled voor een platform) of Mobile Web Applications (plat gesteld een website gebaseerd op xhtml,css,javascript). Duidelijk mag zijn dat de laatste als nadeel heeft dat deze niet de optimale ervaring biedt van een native application die allerlei zaken van een device kan aanspreken.

• Hoofdstuk 7

Bevat veel rijke informatie omtrent de mobiele informatie architectuur en user experiences.

Na een verhelderend diagram op http://www.jjg.net/elements/pdf/elements.pdf komen diverse praktische zaken aan bod.

(Clickstreams, sitemaps, keep it simple, labels,wireframes,prototyping etc.)

Opvallende uitspraak: 'people don't respond to visual aesthetics as much as you might think'.

Kortom: een hoofdstuk wat het lezen waard is.

• Hoofdstuk 8

Over Mobile design met een wat meer praktisch gehalte.

Look and feel , Layout, color, graphics , typography, readability. Hier komen we ook te weten dat de kleur 'rood' staat voor passie, sex, kracht en huwelijk (India only) dus dat zit wel goed bij de UBU.

• Hoofdstuk 9

Mobile Web Application versus Native applications. Plat samengevat: maak een Mobile Web Application tenzij je echt functionaliliteit van het device nodig hebt zoals filesystem, offline gebruik, camera etc.

• Hoofdstuk 10

Allereerst een opsomming van wat Web 2.0 volgens de auteur is. Dan de constatering dat niemand goed weet wat Mobile 2.0 nu eigenlijk is. Wel enige handige weetjes:

-Wil je dat de batterij snel leeg is gebruik dan veel Javascript

-Idem voor data intensieve applicatie (er wordt voor veel AJAX gewaarschuwd)

-Mobile widgets are the next big thing

-De mobile community heeft een groot ego en staat haaks op de web community.

• Hoofdstuk 11

Over de ondersteuning van verschillende devices. Een 'device plan' op organisatie niveau is daarbij onontbeerlijk. Hierin ook een matrix waarbij de mobile browsers worden opgedeeld in classes lopend van 'A tm F' waarbij de ondersteuning voor markup, css en javascript inzichtelijk wordt gemaakt. Enkel Class A komt in de buurt van de bekende desktop browsers en javascript ondersteuning is uitermate pover bij overige classes.

Daarnaast is de ontwikkeling van DIAL als device onafhankelijke markup taal in opmars.

Het hoofdstuk sluit af met een stuk over de CSS ondersteuning aangeduid als Wireless CSS of WAP CSS.

Een W3C mobile validator http://ready.mobi/launch.jsp?locale=en_EN

• Hoofdstuk 12

Geheel gewijd aan iPhone en bijbehorende tools zoals webkit.

• Hoofdstuk 13

Een hoofdstuk van importantie over 'adapting to devices' via detect, adapt and deliver.

Er zijn verschillende opties

1) Do nothing. Dit stoelt op de W3C gedachte van 'One Web' en dat een device zelf in staat is te renderen o.a. op basis van bv. CSS3.

Een optimistische gedachte en weinig compatible momenteel.

2) Progressive enhancement. Gebaseerd op fallback techniek bijvoorbeeld varierend van 'geen stylesheet' tot een bijna volledige CSS2\CSS3 ondersteuning

3) Device targeting. Probeer zo goed mogelijk het device te detecteren. Op page 248 en verder zijn diverse voorbeelden gegeven om dit te doen. Niet enkel in Javascript of PHP maar ook bv. in .htaccess en zelfs in Apache \ IIS modules.

4) Full adaption. Ondersteuning van elke Class

Een zeer complete oplossing inclusief PHP API wordt aangeboden via opensource project WURFL

http://wurfl.sourceforge.net/nphp/index.php

http://wurfl.sourceforge.net/

Andere opties o.a vanaf page 248-260

http://www.detectmobilebrowsers.mobi/

http://www.passani.it/

http://www.passani.it/switcher/ (niet gratis)

http://ohryan.ca/blog/2009/02/18/revisiting-mobile-redirection-using-htaccess-rewrite-rules/

Voor de constructie van een mobile URL worden enkele mogelijkheden geschetsts

domain.com/mobile

domain.com/m

m.domain.com

of zelfs per device

iphone.domain.com

domain.com/iphone

Tips:

-lange URL's zijn lastig op een mobile dus het kan handig zijn om een tinyurl alias te gebruiken

-Popup windows: DON'T

• Hoofdstuk 14

Geheel gewijd aan 'making money in mobile' en wellicht interessant voor de mensen die een tweede huis willen kopen.

• Hoofdstuk 15

Omtrent 'supporting devices' en 'device plans'

Een rommelig en onvolledig stuk over de kosten en baten van device support en bijbehorende plans en testscenario's.

Een suggestie voor testen is 'guerilla testing' oftewel langsgaan bij diverse winkels en daar diverse modellen testen. Meer praktisch is het testen op een desktop o.a via een iframe of via webkit

Opera heeft de mini browser op http://www.opera.com/mini/demo/

iPhone http://www.testiphone.com/

Erg handig ook is de useragent switcher van de welbekende http://chrispederick.com/work/user-agent-switcher/

• Hoofdstuk 16

Dit laatste hoofdstuk schetst de toekomst van mobiel. Allereerst gelooft de auteur dat web 2.0 al enige tijd dood is. De uitdaging ligt in data portability en 'making content accesible to all people regardless of location,education,ability...'

Het boek staat meestal in de kast bij I&O ontwikkelaars.

Het volgende Omega-decennium (3)

[aflevering 1]
[aflevering 2]

De eerste post in deze serie ging over nieuwe ontwikkelingen rond "geïntegreerd zoeken". De tweede ging in op algemene voor- en nadelen van verdergaande integratie, met het huidige Omega als uitgangspunt. Dit keer wat specifieker over retrievalproblemen die daarbij kunnen optreden.

Het overgrote merendeel van de artikelen in Omega bevat uitgebreide inhoudelijke metadata in de vorm van samenvattingen, die geheel doorzoekbaar zijn. Van het fysieke materiaal, zoals dat in Aleph gecatalogiseerd is, hebben we daarentegen nauwelijks inhoudelijke metadata. Behalve een vaak korte en soms ook weinigzeggende titel, zijn er hoogstens nog twee of drie tamelijk algemene trefwoorden toegekend. Dat verschil in hoeveelheid en specificiteit van de aanwezige zoekingangen voor die beide soorten materiaal, maakt dat daar op heel verschillende wijze in gezocht moet worden om een enigszins optimaal resultaat te krijgen.
Om de gespecialiseerde artikelen in Omega te vinden, zijn zoekacties op vrij specifieke zoekwoorden nodig. Maar die zullen in Aleph-materiaal vrij weinig opleveren. Zelfs boeken die wel degelijk informatie over het gezochte specialisme bevatten, zullen niet gevonden worden, omdat ze alleen vindbaar zijn op een paar titelwoorden en enkele veel algemenere trefwoorden (zo die al zijn toegekend). Die problematiek had ik in zijn algemeenheid al eens beschreven in een digitale bijdrage aan InformatieProfessional, "De mythe van de catalogus".

Om fysiek materiaal uit de catalogus te kunnen vinden, is het dus vaak nodig om op vrij algemene zoekwoorden te zoeken. Maar die zullen in Omega-materiaal juist weer weinig opleveren, omdat artikelen veel vaker specialistische deelonderwerpen behandelen dan zulke algemene onderwerpen. Wel degelijk aanwezige gespecialiseerde artikelen over onderdelen van het gevraagde onderwerp zullen daarbij voor het grootste deel gemist worden, omdat gebruikte algemene zoektermen daar niet in voorkomen, en er ook geen hiërarchische thesaurus is, waarmee zogenaamd "generiek" gezocht kan worden. Daarbij had een zoekvraag automatisch uitgebreid kunnen worden met in zo'n thesaurus beschikbare specifieke zoekwoorden.
Zoeken in de catalogus vraagt dus in de meeste gevallen een andere zoekaanpak dan zoeken in het huidige Omega. Deze zoekaanpakken zullen pas op termijn naar elkaar toegroeien, als ook van het merendeel van het in de catalogus beschreven materiaal uitgebreider gegevens digitaal beschikbaar en doorzoekbaar zijn, zoals inhoudsopgaven, samenvattingen, inleidingen en/of besprekingen. Op termijn zullen dat hopelijk ook de volledige teksten zijn, als meer E-books aan onze collectie worden toegevoegd. Daarmee kan voor dit materiaal dan ook meteen de Omega-meerwaarde van de "instant satisfaction" verwezenlijkt worden.

[wordt vervolgd]

Het volgende Omega-decennium (2)

In mijn vorige blogpost keek ik naar ontwikkelingen met betrekking tot geïntegreerd zoeken. Daaruit bleek dat er steeds meer aanhang komt voor de weg die we in Utrecht 10 jaar geleden met Omega waren ingeslagen - met een eigen zoekmachine zelf zo veel mogelijk materiaal indexeren, in plaats van een metasearch-oplossing. Of kortweg "integrated search" in plaats van "federated search".

In dit kader wil ik eens bekijken of en hoe we meer soorten materiaal dan alleen wat nu in Omega zit, op een betere manier geïntegreerd kunnen aanbieden. Steeds verdergaande integratie past in elk geval in een trend. We zagen dat al bij enkele van de vorige keer gesignaleerde ontwikkelingen.
We zagen het recent ook bij OCLC, dat in Worldcat niet alleen de fysieke collecties van deelnemende bibliotheken doorzoekbaar maakt, maar die sinds kort integreert met de inhoud van OAIster. Die zoekmachine voor OAI materiaal, met ruim 20 miljoen publicaties die zijn geoogst uit institutionele repositories (niet beperkt tot OCLC-bibliotheken) heeft OCLC onlangs overgenomen van de Universiteit van Michigan. Hij is zelfs zover geïntegreerd, dat het OAIster-materiaal niet meer apart kan worden doorzocht.
We zien het ook bij webzoekmachines zoals Google. Onder het motto "Universal search" mengt die - op bescheiden schaal - resultaten uit image-search, video-search, News, Scholar, Books, blog-search en (sinds kort) "real-time web" (o.a. Twitter) door zijn gewone zoekresultaten.

Ook al is iets een kennelijke trend, toch blijft de vraag of verregaande integratie altijd wenselijk is. Wil iemand die op zoek is naar inhoudelijke informatie uit websites, worden afgeleid door afbeeldingen, video's of 2-regelig tweets die wellicht iets met het gezochte onderwerp te maken hebben (Google)? Wil iemand die op zoek is naar een eenvoudig leerboek ook superspecialistische OAI-artikelen over dat onderwerp vinden, of bij een zoekactie naar vrij online toegankelijke artikelen, juist afgeleid worden door boeken uit onbereikbare collecties aan de andere kant van de wereld (Worldcat)?

In onze situatie verdient de vraag hoe nauw en hoe volledig ander materiaal met het huidige Omega geïntegreerd zou moeten worden, dus zeker enige aandacht. Verregaande integratie, waarbij je alles in één grote vergaarbak gooit, heeft ontegenzeggelijk voordelen. Gebruikers hoeven niet vooraf te bepalen waarin ze gaan zoeken en bovendien lopen ze hierdoor de kans informatie te vinden die ze anders nooit zouden zijn tegengekomen. Toch spelen de nadelen waarop ik net zinspeelde ook in onze situatie en rol.

• Gebruikers lopen de kans een grote verscheidenheid aan soorten materiaal te vinden waarnaar ze niet op zoek waren, waardoor het gezochte materiaal (in het slechtste geval) aan het oog wordt onttrokken door de overmaat aan ander materiaal.
  
• Gebruikers vinden zowel materiaal dat zij meteen op het scherm kunnen krijgen (zoals zij intussen van Omega gewend zijn), als materiaal dat alleen fysiek beschikbaar is en waarvoor zij dus ergens heen moeten om het op te halen (en dat op dat moment misschien zelfs helemaal niet beschikbaar is, omdat het is uitgeleend of vermist).

Voor deze nadelen kan een te ontwikkelen "faceted search" in principe een oplossing bieden. Als resultaat van een zoekvraag kunnen gebruikers dan een uitsplitsing van hun zoekresultaat te zien krijgen
- naar aard van het materiaal,
- naar full-text digitale beschikbaarheid / fysieke beschikbaarheid,
- naar andere nog nader vast te stellen geformaliseerde kenmerken.
Van elke afzonderlijk aanklikbare deelverzameling zal daarbij vermeld staan, hoeveel van het oorspronkelijke resultaat die bevat. Dat vereist natuurlijk wel dat alle materiaal consistent en uniform van metadata voor deze kenmerken is voorzien. Nadeel voor gebruikers blijft dat bij deze methode nog altijd een extra keuzeactie nodig is. Bijvoorbeeld voor zo iemand die uit is op de "instant satisfaction" die het thema was van mijn column in het november-nummer van InformatieProfessional, die bij voorbaat dus al uitsluitend op zoek is naar direct digitaal op het scherm verkrijgbaar materiaal.

Belangrijker nog, is dat faceted search functionaliteit geen oplossing biedt voor zoek-technische problemen die optreden als gegevens uit ons huidige Omega worden gemengd met gegevens uit de catalogus. Enerzijds is er een retrievalprobleem: voorlopig zijn nog heel verschillende aanpakken vereist voor die twee soorten materiaal. Anderzijds worden in een catalogus vaak andersoortige zoekacties gedaan, die ook andere zoekfunctionaliteit vereisen. Op deze twee punten zal ik in een volgende aflevering verder ingaan.

[wordt vervolgd]
[vorige aflevering]

Het volgende Omega-decennium (1)

In mijn vorige blogpost keek ik 10 jaar terug naar de voorloper van ons Omega-systeem, het zoeksysteem waarmee we zelf de Elsevier tijdschriften doorzoekbaar maakten. In deze en volgende blogposts wil ik eens vooruit kijken naar mogelijke nieuwe ontwikkelingen op het terrein van geïntegreerd zoeken.
Al eerder beschreef ik hier en hier dat ook andere UB's intussen een voorkeur beginnen te krijgen voor de oplossing voor geïntegreerd zoeken zoals die bij ons de afgelopen 10 jaar vorm heeft gekregen in Omega.
Die voorkeur voor "integrated search" (zoeken via de index van een eigen zoekmachine waarin je alles integreert), boven "federated search" (een metasearch in een verscheidenheid aan zoeksystemen met nogal diverse indexeertechnieken) zien we overigens ook bij leveranciers doordringen.
Delft en Tilburg gebruiken Meresco (waarvan de ME van "metadata", de RE van "repository" en de S van "search" komt). Dat komt weliswaar uit de Open Source gemeenschap, maar wordt wel door een commercieel bedrijf ontwikkeld, onderhouden en geïmplementeerd.
Als zeer commercieel bedrijf is ook ExLibris een paar jaar geleden met Primo begonnen, een zoeksysteem gebaseerd op dezelfde Open Source zoekmachine Lucene/Solr als Meresco. Dat was aanvankelijk nog stevig gecombineerd met hun MetaLib metasearch. Maar intussen verzet men de bakens meer richting afzonderlijke Primo-indexen, die vanwege toepassing van dezelfde indexeertechniek makkelijk te combineren zijn. En zelfs kun je de te indexeren metadata, of die nu afkomstig zijn van tijdschriftuitgevers of uit je eigen catalogus, extern bij ExLibris laten hosten (en dus ook daar laten indexeren) onder de naam Primo Central. Een oplossing die ExLibris ons uiteraard ook probeert aan te smeren.
En een soortgelijke oplossing wordt nu ook door SerialsSolutions aangeboden onder de naam Summon. Hetgeen niet toevallig erg lijkt op Summa, een ooit bij Deense bibliotheken opgezet systeem op basis van Lucene, waarover ik ook ooit al eens blogde. Summon is intussen onder meer in gebruik bij de Universiteit van Liverpool en bij Dartmouth College en wordt ook een dezer dagen op proef bij onze Rotterdamse collega's in gebruik genomen.
Sommige van deze producten kunnen ons op ideeën brengen voor functionaliteit die we op dit moment nog niet in Omega gerealiseerd hebben. In volgende posts wil ik echter vooral kijken in hoeverre ook wij de integratie van onze zoeksystemen nog verder kunnen verbeteren.

[wordt vervolgd]

10 jaar Omega?

Voor mijn maandelijkse column in InformatieProfessional had ik in het kader van wat jubilea ook weer eens een 15 jaar oude Dutch Home Page van stal gehaald. Die was niet meer in echt digitale vorm te vinden op internet (bij de way-back-machine of elders). Als afbeelding uit de NRC geknipt, had ik die nog wel op papier en dat vervolgens weer gescand. Voor de grap had ik daar ook een link naar de UBU website anno 1996 in verwerkt, die ik uit de Way-back-machine gecopieerd had en waar je ook nog wat in kunt doorlinken.

Wat daarin helaas ontbrak was de fraaie zoekmachine die was ontwikkeld door Theo van Veen (toen nog bij ons werkzaam). Ooit had ik die nog wel eens op de Way-back-machine gezien, maar zelfs daar blijken sommige dingen toch ook weer te verdwijnen. Wat daar ook ontbreekt is de "echte" zoekmachine die we ruim 10 jaar geleden in Utrecht zijn begonnen om de full-text tijdschriften van Elsevier doorzoekbaar te maken. De eerste stap op weg naar ons huidige Omega, toen nog op basis van de Muscat zoekmachinesoftware. Ja de pagina met de links naar "alle" drie full-text bestanden waartoe we januari 1999 toegang hadden, is nog wel beschikbaar, maar de fraai vormgegeven (en voor sommige gebruikers daardoor onbegrijpelijke?) beginpagina van dit zoeksysteem vind je niet op de Way-back-machine. Jammer.

Tot ik me plotseling herinnerde dat ik voorjaar 2000 op de Online Conferentie een verhaal had gehouden over onze aanpak bij deze zoekmachine. Als toenmalig powerpointhater, had ik daarbij een presentatie in HTML gemaakt. En om ook voorbeelden te kunnen laten zien, had ik tevens een heleboel schermen van ons zoeksysteem gedownload, soms inclusief de resultaatschermen van enkele zoekacties. Al dat spul - een paar honderd files - bleek ik toch nog ergens op mijn PC te hebben staan.
Ter gelegenheid van (ruim?) 10 jaar Omega en zijn voorganger heb ik dat zaakje nu ook maar weer op internet gezet.

• Hier de beginpagina van de Elsevier tijdschriften.
  De links doen het allemaal nog tot één niveau diep. Kijk vooral ook eens naar dat mooie alfabet! Als je wilt zoeken kan dat ook. Als je in het "free search" scherm met de muis boven de FIND-knop komt, wordt nu een voorgebakken zoekvraag ingevuld; bij klikken op die knop wordt het (toenmalige) antwoord getoond.
  
• Hier de beginpagina van de Core Collection in Physics.
  Ook daar kun je zoeken volgens hetzelfde recept.
  
• Tenslotte ook nog de goede oude BNSW.
  Met ook een zoekactie als je op [zoeken] klikt.
  

PS: Overigens wordt ons huidige Omega ook zorgvuldig buiten de Way-Back Machine gehouden. Daarom ook daarvan, ter herinnering, alleen een link naar de verwijspagina anno mei 2002 (pas over 2 jaar een jubileum), waarin naar "Omega-one" wordt gelinkt. Bij "Omega-hoeveel" zijn we intussen?

Boek = Wiki

Een blog gebruiken om een boek te maken is een prestatie die ik al verschillende keren gezien heb. Een auteur publiceert een reeks artikelen en maakt daar later een boek van. Goed voor de lezers, die de informatie eerder en gratis krijgen, goed voor de auteur, die via de comments een openbaar reviewproces voert. Het is wel jammer dat het resultaat achteraf niet echt leesbaar is. Je moet alle posts en alle comments doorwerken (die daarvoor in de verkeerde volgorde staan).

Gina Trapani heeft met haar nieuwe boek, 'The complete guide to Google Wave' (http://completewaveguide.com) een andere benadering gekozen. Ze heeft het boek geschreven in een wiki. Slim, want de naam dekt de lading natuurlijk nog lang niet, Wave is nog volop in ontwikkeling. Gina kan het boek steeds aanpassen. Handig voor de lezer, het boek kan gewoon van a-z doorgelezen worden. De discussie-pagina's van de wiki geven gelegenheid voor feedback aan de auteur en de history maakt voor iedereen zichtbaar wat er verandert.

Op een dag zal het boek vast ook op papier verschijnen, maar nu al wordt het door de auteur tegen een bescheiden vergoeding als PDF aangeboden. Deze auteur is helemaal 'in tune' met de tijdgeest. Maar dat is eigenlijk geen verrassing. Gina is een van de oprichters van Lifehacker.

SFX met bX recommender service

In Nederlandse blogs heb ik er op een enkele post na maar weinig over gelezen: de nieuwe dienst van Ex Libris voor het attenderen op artikelen in de SFX omgeving. Ex Libris heeft hier, gebaseerd op werk van Van de Sompel en Bollen in Los Alamos, een dienst voor ontwikkeld: bX. Hiermee wordt op basis van transacties van de 1700 sfx-gebruikende instellingen aan sfx-gebruikers een Amazon-achtige aanbeveling voor gedaan. Dit is mogelijk interessant om het idee van de Personal Library te completeren, hoewel het ook daarbuiten werkt. Het is helaas geen gratis service. Uiteraard kunnen wij ook zelf sfx-transacties monitoren en die data gebruiken (Groningen doet zoiets al voor Purple Search), maar de grotere massa van alle gebruikers wereldwijd kan de aanbevelingen veel sterker maken vermoed ik. Wat theoretisch gezien wel een interessante vraag is tenslotte, is of het gemengde en niet te scheiden gebruik van sfx door studenten en wetenschappers maakt dat de aanbevelingen voor beide groepen minder goed worden. Juist het gemak en de snelheid van de UBUlink maakt dat deze veel wordt gebruikt, ook wanneer betere lezing van een abstract dat had voorkomen.

Sneak peek: de subjectrepository is er!

Onder de naam Ivy Academic Search is de (eerste?) subjectrepository van de UBU een feit. De techniek is gereed, een deel van de inhoud is er ook al. Daar wordt vanzelfsprekend nog veel meer aan toegevoegd. De officiële lancering is pas over een tijdje maar wie wil kan alvast een kijkje nemen op:
http://www.ivyacademicsearch.org/

Seasonal site

Documentaires tonen verzetswerk Utrechtse studenten

De Universiteitsbibliotheek Utrecht heeft een serie korte documentaires gemaakt waarin een aantal oud-studenten van de Universiteit Utrecht vertelt over hun verzetsdaden tijdens de Tweede Wereldoorlog. Deze verhalen worden geïllustreerd met foto's, brieven en andere documenten. De documentaires en documenten zijn te zien op http://studenteninverzet.library.uu.nl/.