Categorie archieven: Innovatie

107. Bibliothekartag 2018

Geplaatst op door
1

DBT2018_Final_WEB_Low
Een kort overzicht:
De Bibliothekartag is het grootste Duitse (en Duitstalige) congres voor bibliothecarissen. Het is ieder jaar een drukte van belang en met 4 dagen lang de hele dag door 20 (!) parallelsessies is het soms lastig te bepalen waar je aandacht naartoe moet. Ik bezocht de Bibliothekartag als I&P’er, maar nog meer als lid van het Innovatieteam.

Sommige thema’s werden net als in 2017 weer veel besproken. Denk bijvoorbeeld aan de ‘bibliotheek der dingen’, MakerSpaces (bijv. iLab, virtual reality, etc), en er ging zoals ieder jaar weer veel aandacht naar bibliotheekopleidingen. Meer focus dan vorig jaar lag er op Gamification binnen bibliotheken.

Een speciaal thema dit jaar was populisme en omgang met extreemrechts in de huidige bibliotheekwereld. Dit thema werd ondersteund door een aantal lezingen over de geschiedenis van nationaal-socialisme en roofkunst ten tijde van de Tweede Wereldoorlog specifiek met betrekking op bibliotheken. Ook was er tijdens de conferentie een tentoonstelling te vinden over “Berliner Bibliotheken im NS”.

Lees verder →

IIIF 2017 Vaticaanstad

Geplaatst op door
Beantwoorden

iiif2017vatican

Van 6 tot 9 juni 2017 was ik met Laurents Sesink (CDS) naar de IIIF (spreek uit als Triple-Eye-Eff) conferentie in Vaticaanstad. Natuurlijk was er veel te zien in Rome en Vaticaanstad zelf, maar de conferentie was ook erg interessant, dus hieronder een korte impressie.

De dag voor de eigenlijke conferentie begon, was er een IIIF showcase waarin duidelijk werd gemaakt wat IIIF nu eigenlijk is en wat je ermee kan. Hieronder nog een korte uitleg over de verschillende mogelijkheden van IIIF, maar ook mijn vorige blog is interessant om (nog eens) te lezen.

IIIF is een verzameling API’s en ideeën/concepten over het tonen van, delen van en samenwerken met plaatjes. Het bestaat momenteel uit 4 verschillende API’s:

  1. Image API, waarmee op een eenduidige manier (delen van) plaatjes opgevraagd kunnen worden in o.a. verschillende groottes en formaten en waarmee informatie over het plaatje verkregen kan worden;
  2. Presentation API, waarmee de structuur en opmaak (layout) van een object bestaand uit meerdere plaatjes beschreven en getoond kan worden inclusief eventuele annotaties;
  3. Authentication API, beschrijft een aantal manieren hoe een IIIF viewer om kan gaan met bestaande authenticatie systemen;
  4. Content Search API, waarmee binnen de structuur van een object en de gerelateerde annotaties gezocht kan worden.

Tijdens de eerste dag van de conferentie werd veel aandacht aan de community gegeven. IIIF is een community-driven framework, wat inhoudt dat het bedacht, gedocumenteerd en onderhouden wordt door een groot aantal mensen van verschillende organisaties. Voor elke specialisatie is er een aparte community die elk wat voorbeelden lieten zien van waar ze mee bezig waren. Een leuk voorbeeld van de manuscript community is hier te vinden. Je kan daar zoeken in een groot aantal manifesten en deze met elkaar vergelijken. Kies rechtsboven in voor “Change Layout” en dan 1×2. Sleep een van de IIIF iconen van links naar de viewer. Je moet soms wat geduldig/vasthoudend zijn, maar het is een mooi voorbeeld van wat kan met IIIF.

De Museums community had een brief opgesteld en verstuurd waarin werd gevraagd aan de makers van bibliotheek software om IIIF te ondersteunen. Aangezien de brief  ondertekend was door meerdere musea in de VS en Europa, zou dit meer gewicht geven aan de vraag om ondersteuning voor IIIF in bibliotheek software.

Verder wordt er hard gewerkt aan Discovery, oftewel er zijn veel organisaties die IIIF gebruiken en hun plaatjes via IIIF aanbieden, maar hoe zorg je er nu voor dat deze ook te vinden zijn. Deze community was druk bezig met het uitzoeken hoe dit het best opgelost kon worden

Er waren ook veel “lightning talks” waarbij verschillende organisaties maar ook software leveranciers lieten zijn waar ze mee bezig waren. Interessant was dat het al veel en steeds meer gebruikt wordt, maar ook dat bijvoorbeeld Europeana zei dat ze IIIF zien “as key to sharing images”. Dit betekent dus dat IIIF steeds beter populairder wordt en dus ook door de grotere spelers gezien en ondersteund wordt.

Verschillende organisaties zijn druk bezig om IIIF op nieuwe en innovatieve manieren in te zetten. Zo is Getty Research bezig met het omzetten van EAD (Encoded Archival Description) naar manifesten voor het gebruik van IIIF. De Johns Hopkins University is bezig met een project om Fedora Commons (de software die wij ook gebruiken als backend van onze nieuwe repository) IIIF te laten praten. Maar helaas bleek dit nog een theoretisch verhaal.

Ook aan het gebruik van annotaties werd door verschillende partijen veel aandacht besteed. Annotaties zijn een essentieel onderdeel van de IIIF API’s maar ze worden hierin niet gespecificeerd. Hiervoor wordt namelijk de Open Annotations Data Model gebruikt. Het annotatie model is heel flexibel opgezet, eigenlijk zijn overal annotaties op te maken, er kunnen zelfs annotaties op annotaties gemaakt worden. Ook kunnen de annotaties van andere bronnen komen dan de manifesten zelf, wat weer meer vrijheid geeft.

Het was zeker een interessante conferentie waarbij heel veel te zien en horen was (en dan heb ik het niet eens gehad over de ICT monnik in habijt, met overgewicht en bloempotkapsel). En natuurlijk was er buiten de conferentie ook veel te zien en lekker te eten!

 

Waarom zijn ijsberen linkspotig?

Geplaatst op door
Beantwoorden

Polar_Bear_0319_-_23-11-06

Om te illustreren hoe slecht kinderen vaak toegerust zijn om internet te gebruiken vertelde Hanna Jochmann tijdens de Vogin IP-lezing op 3 maart in de OBA dat ze vaak hele vragen in Google invoeren. Even later spoorde de Amerikaanse zoekgoeroe Ran Hock ons juist aan om veel vaker dit soort vormen van natuurlijke taal te gebruiken bij zoekacties.

Huh?

Natuurlijk hebben ze alle twee op hun eigen manier gelijk. Jochmann toont hiermee aan dat kinderen Google niet zien als een zoekmachine, maar als een vraag-en-antwoordapparaat, waardoor ze geen optimale zoekopdrachten geven. En Ran Hock is enthousiast over de vooruitgang in Natural Language Programming (NLP), waardoor spreektaal steeds beter te interpreteren is door zoekmachines.

Hoe komt het dan dat er toch een vreemde tegenstelling in lijkt te zitten?

Het antwoord is simpel. Het stellen van vragen aan een Google duidt op onvermogen of een gebrek aan kennis van de mens (en echt niet alleen de schoolgaande mens) , terwijl de eigenschap om in spreektaal gestelde vragen te beantwoorden een kwaliteit is van de zoekmachine (en echt niet alleen Google). Als je er met een zonnige blik naar kijkt zou je kunnen zeggen dat het gebrek van de één wordt opgeheven door het vermogen van de ander. Maar is dat ook zo? Zonder mezelf als een Somberman te willen afschilderen, denk ik dat daar wel wat aan af te dingen valt.

Uit allerlei onderzoeken blijkt dat veel mensen geen onderscheid maken tussen feit en mening.’Als het op het internet staat zal het wel waar zijn.’ Peter Burger vertelde in zijn lezing dat journalisten zich vaak wel bewust zijn van het nut van factchecking, maar dat dat uiteindelijk veel te weinig gebeurt. Als de serieuze pers dat al niet doet, is het nauwelijks verwonderlijk dat ´gewone´ mensen blind varen op wat zij via internet tot zich nemen.
Er zit een niet eens zo subtiel verschil tussen de zoekopdracht
`Donald Trump´ AND Racist
en
`Is Donald Trump een racist?´
In het eerste geval is de opdracht ondubbelzinnig: geef resultaten met daarin ‘Donald Trump’ en Racist. Ik het tweede geval wordt minimaal de suggestie gewekt dat de zoekmachine met het (juiste) antwoord op de vraag komt en dan is het bovenste zoekresultaat bepalend, als we uitgaan van hoe mensen doorgaans hun zoekresultaten beoordelen.

Over dit soort zaken mag ik graag wat mijmeren, overigens zonder dat het mijn leven vergalt, en ik was dan ook geïntrigeerd door de titel van Ran Hocks verhaal: “Brave new search world”. Ik dacht dat hij daarmee verwees naar Aldous Huxley’s Brave New World, waarin hij een totalitaire, technologische samenleving beschrijft, een maatschappij die wordt geleid en gemanipuleerd door een kleine bovenklasse die de kennis beheert.

images

Met dat in het achterhoofd verwachte ik een verhaal van Hock over de nieuwste technologische inzichten met daarbij de nodige kanttekeningen. Maar van dat laatste was weinig te merken, waardoor het voor de Huxley-lezers leek of hij die wereld wel zag zitten. En ook het verhaal van de andere keynote speaker Pieter Cobelens, Generaal-Majoor B.D. en voormalig hoofd van de MIVD, ging in die richting. Zijn betoog ging over de noodzaak van hooggeschoolde informatieprofessionals die optimaal gebruik moeten maken van de nieuwste technieken (ik refereer nog maar even aan de kleine bovenklasse die de kennis beheert). En passant vertelde hij ons dat we rustig onze informatie op het internet kunnen achterlaten. Als je het maar versleutelt. En de overheid zorgt er wel voor dat er verder niets mee gebeurt.

Wat is dat toch met die door technologie, landsbelang of anderszins gedreven mensen die zo opgaan in hun fascinatie dat ze de doorsnee internetgebruiker, bewust of onbewust, veronachtzamen?

Het merendeel van de bezoekers aan de Vogin IP-lezing is verbonden aan een bibliotheek. Ze zijn er bij gebaat als hun klanten beschikken over de kritische vaardigheden om de informatie te vinden waar ze echt behoefte aan hebben. Voor het merendeel van de internetgebruikers is niet zoeken het probleem, maar vinden. Ik heb in de OBA allerlei interessante verhalen gehoord over de nieuwste technologische ontwikkelingen, over een veilig internet voor kinderen, professionele factchecking, social media tools en nog veel meer, maar het verhaal over hoe we er voor kunnen zorgen dat onze klanten kritische vinders worden heb ik ook hier weer gemist.

‘Zoeken en vinden’ was het thema van de Vogin IP-dag. Het zou mooi zijn als dat volgend jaar ‘Zoeken, vinden en er iets van vinden’ is. Oh ja, en over die ijsberen: als je zoekt op ‘Wist je dat ijsberen linkspotig zijn?’ vind je weliswaar een paar honderd hits, maar wie even kritisch verder zoekt , komt erachter dat dat pure onzin is.

IIIF we could present images

Geplaatst op door
Beantwoorden

Je zou denken dat plaatjes aanleveren via het internet toch heel eenvoudig is. En dat is ook zo, tenminste voor de “normale” plaatjes. Maar als het gaat om plaatjes van meer dan 100 MB groot, dan wordt het wat ingewikkelder. Zeker als die plaatjes niet in zijn geheel afgebeeld kunnen worden op het beeldscherm omdat de afmeting van de plaatjes meer dan 10.000 pixels breed zijn. Je kan je afvragen of het dan verstandig is om voor het afbeelden van deze plaatjes de plaatjes in zijn geheel op de volledig beschikbare resolutie te versturen naar een scherm dat dat toch niet aan kan. Nou inderdaad, dat is niet verstandig.

Het is dan beter om een manier te hebben om het plaatje te versturen op 800 pixels breed naar iemand die een scherm heeft van 800 pixels breed en het hele plaatje wil zien. Of alleen de rechterbovenhoek van het plaatje op 800 pixels breed voor iemand die de rechterbovenhoek van het plaatje ingezoomd wil zien. Nu is dit al lang technisch mogelijk, maar sinds september 2014 is er een officiële API voor, gemaakt door het IIIF.

API staat voor Application Programming Interface. Dit is een beschrijving van hoe een stuk software communiceert met een ander stuk software. Het IIIF  is het International Image Interoperability Framework. Deze API beschrijft hoe je op een standaard manier (een deel van) een plaatje kan opvragen. En dat is niet het enige wat het beschrijft, maar daarover later meer.

Wat heb je nu aan zo’n API? Als een systeem deze API implementeert, dan kunnen andere systemen daar gebruik van maken, aangezien beschreven is hoe de API werkt en hoe die te gebruiken is. Als je plaatjes van een systeem wilt halen die de IIIF API implementeert, dan is het meteen duidelijk hoe je dat moet doen. Oftewel, het is voor iedereen duidelijk welke taal er wordt gesproken en aangezien het een taal is waar meerdere partijen het over eens zijn, kan je ook gebruikmaken van de systemen van meerdere partijen. En wat voor systemen zijn dat dan? Dat kan bijvoorbeeld gaan om een systeem wat een plaatje op een nette manier afbeeldt. Dit wordt ook wel een image viewer genoemd. Door de IIIF API is het dus mogelijk om verschillende image viewers te gebruiken, zolang die aan de IIIF API voldoen.

Er zijn 2 IIIF API’s beschikbaar: de IIIF image API en de IIIF presentation API.

Met de IIIF image API is het mogelijk om informatie over een plaatje op te vragen, zoals hoe groot het plaatje is, hoe ver ingezoomd kan worden, welke formaten beschikbaar zijn en wat er allemaal mogelijk is met dit plaatje via de IIIF image API. Ook kan natuurlijk (een deel van) het plaatje op een bepaalde grootte opgevraagd worden. Om dit te doen, kan een regio (deel van het plaatje) in absolute eenheden of percentage gevraagd worden. Daarna kan opgegeven worden hoe groot het resulterende deel van het plaatje teruggegeven moet worden. Eventueel kan ook opgegeven worden dat het plaatje in kleur, grijstinten of zwartwit geleverd wordt, en eventueel geroteerd of gespiegeld.

Hoe werkt het nu concreet? Hieronder een URL wat een deel van een plaatje opvraagt:

https://images-
dev.harvardx.harvard.edu/ids/iiif/47174896/750,840,256,256/256,/0/native.jpg

nativeWaarbij de URL uit de verschillende onderdelen bestaat, die  door de IIIF image API beschreven worden:

  • https://images-dev.harvardx.harvard.edu/ids/iiif/
    Dit is een IIIF image server URL
  • 47174896
    Dit is de image identifier
  • 750,840,256,256
    De regio van het plaatje wat gewenst is. Dit zijn achtereenvolgens de x, y en breedte en hoogte van de regio in absolute eenheden, ten opzichte van het originele plaatje. Dit kunnen ook percentages zijn. Om het hele plaatje op te vragen kan ‘full’ gebruikt worden.
  • 256,
    Dit is de grootte van het plaatje wat gewenst is. Hier wordt alleen de breedte gegeven, aangezien de hoogte hieruit afgeleid kan worden. Aangezien de breedte gelijk is aan de breedte die eerder in de regio gedefinieerd werd, kan dit ook worden vervangen door ‘full’, wat betekent dat de volledig beschikbare resolutie wordt gebruikt.
  • 0
    Dit is de rotatie in graden. Hier wordt niet geroteerd. Vaak worden alleen veelvouden van 90 ondersteund (dat is bij de IIIF image server ook het geval)
  • native
    Dit is de kwaliteit van het plaatje. Hier kan ook color (kleur), gray (grijstinten) of bitonal (zwart/wit) gebruikt worden.
  • jpg
    Dit is het formaat van het plaatje, andere waarden zijn onder andere png,tif en pdf

Op deze manier kan ook het volgende plaatje opgevraagd worden:

nativehttps://images-dev.harvardx.harvard.edu/ids/iiif/47174896/full/100,/180/native.jpg

Voor de duidelijkheid, het basisplaatje is steeds dezelfde, namelijk een plaatje met JPEG2000 formaat. Hieruit kunnen de andere plaatjes gegenereerd worden. De IIIF image API beschrijft alleen welk deel van het plaatje op welke manier geleverd moet worden, maar niet hoe dat gebeurt.

Ook kan de informatie van het plaatje opgevraagd worden met:

https://images-dev.harvardx.harvard.edu/ids/iiif/47174896/info.json

Dit levert het volgende resultaat:

{
“@context”:”https://library.stanford.edu/iiif/image-api/1.1/context.json”,
“@id”:”https://images-dev.harvardx.harvard.edu/ids/iiif/47174896″,
“width”:2087,
“height”:2550,
“scale_factors”:[1,2,4,8,16,32],
“tile_width”:256,
“tile_height”:256,
“formats”:[“jpg”],
“qualities”:[“native”],
“profile”:”https://library.stanford.edu/iiif/image-api/1.1/compliance.html#level1″
}

Hieruit wordt duidelijk wat de grootte van het plaatje is (width/height), welke schalen omndersteund worden (dus hoever ingezoomd kan worden) (scale_factors), in welke grootte de verschillende delen van het plaatje het best opgevraagd kunnen worden (tile_width/tile_height), welke formaten ondersteund worden (formats), de mogelijke kwaliteiten waarin het plaatje opgevraagd kan worden (qualities) en welke versie en niveau van de IIIF image API ondersteund wordt (profile). Zoals hier te zien is, wordt versie 1.1 van de IIIF image API gebruikt op level 1. Helaas ondersteunt dit niet alle hierboven genoemde mogelijkheden.

Met de IIIF image API kan een image viewer alle informatie en onderdelen van een plaatje opvragen om die op een nette manier af te beelden, zodat in- en uitgezoomd kan worden. Een voorbeeld van hoe dat werkt is hier te vinden.

Maar dit is nog niet alles, want waar het interessant wordt, is met de tweede API, de IIIF presentation API. Met deze API kan de structurele en presentatie informatie van een object opgevraagd worden. Een object? Het ging hier toch om plaatjes? Ja, maar een object bestaat hier uit een of meerdere plaatjes. Bijvoorbeeld een schilderij kan uit één plaatje bestaan, een foto uit 2 plaatjes (voor- en achterkant), een standbeeld uit 4 plaatjes (voor- en achterkant en beide zijkanten) en een boek uit meerdere plaatjes. De IIIF image API is bedoeld om een plaatje af te kunnen beelden, maar de IIIF presentation API is bedoeld om een object, bestaand uit allerlei plaatjes, in context te kunnen presenteren.

objectsHoe werkt het? De IIIF presentation API biedt de mogelijkheid om een manifest op te halen en in dit manifest staat beschreven hoe het object gepresenteerd moet worden en bevat een beschrijving (metadata) van het object en van de verschillende componenten van het object. Het manifest bevat 1 of meerdere opeenvolgingen (sequences) van beelden (canvas) voor het object. Een boek bijvoorbeeld heeft 1 opeenvolging van bladzijdes (in volgorde), maar er zijn boeken waar er meerdere opeenvolgingen mogelijk zijn. Elk beeld bevat ook weer inhoud (content). Dit kan bijvoorbeeld het plaatje zijn wat via de IIIF image API afgebeeld kan worden, maar het kan eveneens de OCR tekst zijn. Een beeld hoeft zelfs geen inhoud te hebben, wat het mogelijk maakt om een deels gescand boek ook netjes te beschrijven in een manifest en af te beelden (de niet-gescande bladzijdes blijven dan leeg).

Wat kan je er nu eigenlijk mee? Afbeelden van allerlei materiaal, maar wellicht kan het beter getoond worden dan beschreven. Hieronder enkele voorbeelden van de UniversalViewer, een viewer die beide IIIF API’s ondersteund.

Boek: The biocrats

Brief: Copied letter from Francis Crick to Michael Crick

Folio: Pseudo-Albert the Great

Collectie: The biological basis of medicine

Kaart: Typus Orbis Terrarum

De inhoud van het “more information” tabje (rechts) wordt geleverd via de IIIF presentation API, evenals de volgorde van de bladzijdes of zelfs de hiërarchie bij het collectie voorbeeld. Bemerk dat ook de attribution, conditions of use, de license en een link naar het catalogus record in sommige gevallen zijn opgenomen. Dit alles wordt ook door de IIIF presentation API ondersteund. Bij het kaart voorbeeld wordt duidelijk hoe ver ingezoomd kan worden en hoe soepel dit gaat. Ook kan het plaatje gedraaid worden terwijl al ingezoomd is, terwijl op de juiste plek gebleven wordt. Dit alles dankzij de IIIF image API.

 

Het idee is om deze twee IIIF API’s te ondersteunen binnen de nieuwe repository infrastructuur. Op deze manier kunnen we de objecten mooi presenteren, gebruikmakend van een IIIF-compatible viewer zoals de UniversalViewer. Maar andere partijen kunnen ook onze objecten of delen daarvan binnen hun eigen website afbeelden. Ook kunnen we binnen de repository infrastructuur (delen van) objecten presenteren van partijen die ook de IIIF API’s ondersteunen. Dus als we van een object maar een deel hebben, kunnen we een manifest maken dat andere delen bij andere partijen die de IIIF API’s ondersteunen, ophaalt.

De IIIF API’s bieden dus veel meerwaarden, maar we moeten er nog wel wat voor doen. Helaas worden deze IIIF API’s nog niet nu al ondersteund binnen de nieuwe repository infrastructuur. Maar we kunnen dit wel zelf (met hulp van derden) implementeren. Hierna kunnen we een bestaande IIIF-compatible viewer binnen de repository infrastructuur implementeren die gebruik maakt van deze API’s.

Zoals gezegd, het wordt mooi als we plaatjes kunnen presenteren!

Het meten van wetenschap

Geplaatst op door
Beantwoorden

Het onderwerp “kwaliteit en impact van wetenschappelijke publicaties” staat de laatste tijd veel in de aandacht. De discussie richt zich vaak op de vraag of het uberhaupt wel mogelijk is om een abstract gegeven als wetenschappelijke kwaliteit in cijfers uit te drukken. Het CWTS in Leiden heeft in 2012 een interessant rapport over dit onderwerp geschreven. Ook tijdens het OAI8 congres, dat ik in juni heb bijgewoond, was er veel aandacht voor dit onderwerp.

In zijn presentatie “Scholarly Impact Measures: An Overview” benadrukte Johan Bollen van de Universiteit van Indiana (voorheen ook de Los Alamos National Library) dat wetenschappelijke impact in feite een heel ongrijpbaar fenomeen is. Wetenschappers produceren bepaalde ideeën en bepaalde nieuwe informatie. Niet alle ideeën zijn natuurlijk even waardevol. Is het op een of andere manier mogelijk om aan te geven wat de waarde of de relevantie is van een idee? Volgens Bollen komt de relevantie van een bepaald idee vooral tot uitdrukking via de status die een wetenschapper verwerft dankzij de publicatie van deze ideeën. De kwaliteit van meetinstrumenten hangt dus samen met hoe goed of hoe slecht deze reputatie onder vakgenoten in beeld wordt gebracht.

Traditioneel worden de wetenschappelijke kwaliteit en impact afgelezen aan de hand van citatiedata (met indicatoren zoals de Journal Impact Factor en de H-Index). Deze citatiegegevens hebben verschillende praktische nadelen. Als een publicatie verschijnt duurt het uiteraard enige tijd voordat er andere publicaties kunnen verschijnen die dit artikel weer citeren. De citaties worden meestal ontleend aan Web of Science of aan Scopus, maar het is bekend dat publicaties op het gebied van de geesteswetenschappen en de sociale wetenschappen, en teksten die niet in het Engels zijn geschreven, niet goed zijn vertegenwoordigd in deze databases. Het belangrijkste probleem is volgens Bollen echter dat de lijst met high impact journals vaak helemaal niet overeenkomt met wat wetenschappers zelf als belangrijke tijdschriften ervaren.

De wetenschappelijke communicatie verplaatst zich meer en meer naar het web, en wetenschappelijke ideeën worden tegenwoordig ook verspreid via weblogs, via repositories en via social media. Het is dus eigenlijk niet meer van deze tijd om impact alleen maar te beoordelen via traditionele publicaties. Een alternatieve methode is, bijvoorbeeld, om te kijken naar het aantal downloads van een digitale publicatie. Deze gegevens zijn over het algemeen gewoon beschikbaar, zowel bij de institutionele repositories als bij de uitgevers. De mogelijkheden van download-statistieken in deze context zijn onder meer onderzocht in het project MESUR, en ook in PIRUS en COUNTER (waarin de Journal Usage Factor is ontwikkeld, als tegenhanger van de Journal Impact Factor).

Hiernaast geeft ook de vertegenwoordiging in social media (“attention data”) een goed beeld van het gebruik en van de impact. Deze laatste categorie data wordt meestal aangeduid met de term ‘altmetrics’. Het kan dan gaan om twitterberichten over artikelen, of over blogposts met verwijzingen naar publicaties. Het bedrijf altmetrics.com, dat wordt gefinancierd door de Macmillan Group, heeft zich tot doel gesteld om zo veel mogelijk van dit soort gegevens uit social media posts in te zamelen. Het doel van Altmeric.com is in eerste instantie om de data te verzamelen. Het bouwen van applicaties rond deze data laten zij aan andere partijen over. Interessant voor de UBL is dat Ex Libris één van de partijen is die gebruik maakt van de gegevens van altmetrics.com. Er bestaat al een code extension voor Primo waarmee het mogelijk wordt om altmetrics-gegevens weer te geven bij de zoekresultaten in Primo. Zo kan bij ieder artikel worden weergegeven hoe vaak er over die publicatie is getweet, hoeveel mensen die titel in hun Mendeley-bibliotheek hebben opgenomen, en hoe vaak het artikel in een blogpost is genoemd. Dit geeft uiteraard ook een heel goed beeld van de impact van het artikel.

Bollen eindigde zijn lezing bij OAI8 met een interessante gedachte. Aangezien wetenschappers zelf over het algemeen het beste weten welke collega’s het beste werk produceren is het misschien beter om al het onderzoeksgeld dat beschikbaar is in gelijke mate te verdelen over de gehele onderzoekspopulatie en om de gemeenschap vervolgens zelf te laten besluiten waar subsidies naar toe gaan. Dan zijn er ook geen metrics meer nodig …

Open Annotation Collaboration

Geplaatst op door
Beantwoorden

Dit is een tweede post in de serie over dingen die mij opvielen tijdens OAI8. In deze post ga ik in op Open Annotation Collaboration (OAC). Over deze standaard heb ik tijdens OAI8 een presentatie en een workshop bijgewoond. Beide werden gegeven door Rob Sanderson van de Los Alamos National Library.

OAC is eigenlijk al een aantal jaren oud. Het werk begon rond 2010, en is min of meer onstaan in de periode waarin Herbert Van de Sompel als visiting researcher verbleef bij DANS en bij het Huyghens Instituut. Veel onderzoekers op het gebied van de digital humanities houden zich bezig met het annoteren van bronnen, zoals digitale edities van literaire teksten, of reproducties van kunstwerken. Vaak worden er daarbij specifieke systemen gebruikt en kunnen die annotaties niet gemakkelijk worden hergebruikt. Maar het annoteren van bronnen is uiteraard een breder fenomeen. In systemen zoals Flickr of FaceBook kunnen er uiteraard ook opmerkingen bij bronnen worden geschreven. Ook hier speelt het probleem dat deze opmerkingen vastzitten aan die specifieke omgevingen. Het doel van OAC is om een manier van annoteren te ontwikkelen die generiek is en die los van het systeem waarin deze bronnen worden beheerd.

Open Annotation is gebaseerd op een simpel data model, en maakt ook volledig gebruik van de architectuur van het web. In de visie van W3C bestaat het web uit entiteiten die worden geïdentificeerd door een URI. In het data model van Open Annotation bestaan alle componenten van de annotatie dus uit ‘Web Resources’ met een eigen URI. De basisgedachte is dat een annotatie bestaat uit twee onderdelen. De eerste bron is de annotatie zelf is (de ‘Body’). De tweede bron is datgene is dat wordt geannoteerd (de ‘Target’). Deze eerste twee bronnen worden bij elkaar gebracht door een derde Web Resource, namelijk de ‘Annotation’. Een ‘Target’ kan bijvoorbeeld een scan zijn van een schilderij, en een “Body” is dan een tekst waarin wordt toegelicht wat er op het schilderij te zien is. Een annotatie kan natuurlijk ook gaan over specifieke details van het schilderij. OAC voorziet ook in technieken waarmee specifieke onderdelen van bronnen kunnen worden geaddresseerd (zogenaamde ‘selectors’).

intro_model

Recentelijk zijn er nog een aantal termen aan het data model toegevoegd. Het is nu ook mogelijk om het doel van de annotatie op te geven (gaat het om wetenschappelijk onderzoek? Of is het een soort ‘Bookmark’ of geheugensteun?). Er zijn ook termen toegevoegd waarmee de “provenance” kan worden vastgelegd (de persoon die verantwoordelijk is voor de annotatie). Hiernaast is ook de term “SemanticTag” gedefinieerd, zodat er bij het annoteren ook termen uit bestaande ontologieën kunnen worden gebruikt.

Open Annotation is voor de UBL een heel interessante techniek. Terwijl de technologie rond nanopublicaties (die ook is gebaseerd op  Semantic Web technologie) toch voornamelijk toepassingen lijkt te hebben binnen de natuurwetenschappen, kunnen onderzoeksgroepen binnen de Geesteswetenschappen via OAC ook een stap zetten naar Linked Data en naar herbruikbare en gestructureerde onderzoeksannotaties. Een goed voorbeeld van humaniora-onderzoek waarin OAC momenteel al wordt toegepast is het Emblemata-project, waar onder meer ook onderzoekers van de Universiteit Utrecht aan deelnemen. Er zijn inmiddels ook al een aantal open source applicaties beschikbaar waarmee vrij gemakkelijk Open Annotations kunnen worden aangemaakt, namelijk SharedCanvas en in Pund.It. Voor bijvoorbeeld kunsthistorici die heel gedetailleerd bepaalde uitsnedes van kunstwerken willen beschrijven, of voor literatuurcritici die commentaar geven op specifieke tekstfragmenten, kunnen dit heel nuttige tools zijn.

Repositories gelijkzetten

Geplaatst op door
Beantwoorden

In juni bezocht ik het Open Archives Initiative congres in Genève. Dit congres richt op innovatieve technologie op het gebied van wetenschappelijke communicatie, en wordt om de twee jaar georganiseerd. OAI vond dit jaar al weer voor de achtste keer plaats. In verschillende blogposts bespreek ik een aantal interessante nieuwe ontwikkelingen die ik daar heb gehoord.

resourcesync_logo

Voorafgaand aan OAI8 waren er een aantal workshops, en de workshop die ik zelf heb bijgewoond ging over het nieuwe protocol ResourceSync. Het initiatief voor de ontwikkeling van deze techniek is genomen door de mensen van OAI (onder meer Herbert Van de Sompel, Simeon Warner en Carl Lagoze). Zij waren eerder ook verantwoordelijk voor belangrijke standaarden en protocollen zoals OAI-PMH, OAI-ORE en Memento. Aan de ontwikkeling van ResourceSync hebben inmiddels ook partijen als NISO, OCLC, de Library of Congress, Cottage Labs, Ex Libris en JISC bijgedragen.

ResourceSync is, simpel gezegd, een protocol waarmee de inhoud van verschillende repositories kan worden gesynchroniseerd. De site ArXiv.org, waarop veel publicaties in open access worden gepubliceerd, heeft een aantal mirror sites opgericht, onder meer vanuit de LOCKSS-gedachte (“Lots of copies keep stuff safe”). Arxiv ondervindt momenteel veel problemen bij het kopiëren van die bestanden naar de andere servers. Ook vanuit Europeana is interesse getoond voor ResourceSync. Voor de Europeana-portal worden op dit moment alleen nog de metadata van de verschillende aangesloten instellingen geharvest. Europeana wil op termijn ook graag de digitale objecten zelf gaan harvesten. ResourceSync probeert in dit soort situaties een oplossing te bieden.

Zoals bij de meeste standaarden is ResourceSync gebaseerd op een data model. Dit model is in eigenlijk heel simpel. Op de eerste plaats is er een “Destination” server. Deze server wil graag documenten of gegevens overnemen van een “Source”. Er wordt onderscheid gemaakt tussen een “baseline synchronisation” en een “incremental synchronisation”. Het eerste geval is in feite het begin van het synchronisatieproces. Alle aangemerkte bestanden worden daarbij direct overgebracht van de “Source” naar de “Destination”. Na deze initiële synchronsatie ontstaat er een situatie waarin de ontvangende server goed op de hoogte moet blijven van toevoegingen of wijzigingen op de bron-server. Hierbij kan gebruik worden gemaakt van een pull-mechanisme, waarbij de Destination server een verzoek om informatie verstuurt, of van een push-mechanisme, waarbij de Source een bericht naar de Destination stuurt op het moment dat er nieuwe of gewijzigde bestanden zijn. Wanneer een server met ResourceSync wil werken moet deze server er voor zorgen dat er altijd een actuele siteMap is waarop een volledige inventaris te vinden is van de bronnen op de site, samen met de datum van de laatste wijziging.

ResourceSync is op dit moment nog in de ontwikkelfase. Het theoretische model is al heel goed uitgedacht, maar de onderliggende techniek is nog niet volledig uitgewerkt. Er zijn ook nog geen concrete implementaties van ResourceSync. Er is op dit moment nog onduidelijkheid over hoe bestanden concreet moeten worden overgeheveld. Bestanden kunnen individueel worden gedownload, maar door de “Source” server kunnen er eventueel ook zip-mappen met gewijzigde files worden klaargezet.

Wat tijdens de workshop wel duidelijk werd benadrukt is dat met ResourceSync een aantal van de huidige nadelen van OAI-PMH kunnen worden opgelost. OAI-PMH gaat op de eerste plaats alleen over metadata. Er zijn wel pogingen geweest om ook digitale objecten over te dragen via OAI-PMH, maar dat bleek technisch heel complex. Bij OAI-PMH moeten alle metadata worden opgenomen als onderdeel van de response, en zijn er beperkingen aan het aantal records dat per response kan worden verstuurd. Hierdoor onstaan er vaak vertragingen. Belangrijk is ook dat er bij OAI-PMH geen push-mechanisme bestaat. Instellingen die willen harvesten moeten dus periodiek polsen of er nieuwe of aangepaste metadata zijn. OAI-PMH is al meer dan tien jaar oud en de web-technologie is inmiddels natuurlijk verder geëvolueerd. Gezien de huidige problemen rond OAI-PMH is het niet ondenkbaar dat instellingen die nu harvesten via dit protocol (een voorbeeld hiervan is natuurlijk de KNAW, die ons repository harvesten voor de NARCIS-portal) op termijn zullen overstappen naar ResourceSync. Het is daarom zeker een ontwikkeling om goed in de gaten te houden!

De presentatie die tijdens OAI8 is gegeven door Herbert Van de Sompel, Robert Sanderson en Stuart Lewis is hier te bekijken.

Helemaal Poka Yoke!

Geplaatst op door
Beantwoorden

Saskia van Bergen

Als medewerker van de afdeling Innovatie & Projecten houd ik mij vooral bezig met projectmanagement. Hierbij werk je binnen een beperkte periode en budget naar een concreet einddoel of eindproduct. De laatste tijd kom ik steeds vaker de term procesmanagement tegen. Hierbij gaat het om het ontwikkelen en verbeteren van doorlopende activiteiten. Denk bijvoorbeeld aan het inrichten van een productielijn in een fabriek of – om het wat dichter bij huis te houden – de gang van het boek in onze bibliotheek. In de praktijk komt het een meestal uit het ander voort. Zo wordt er vaak een project gestart om een onderdeel in een proces in te richten of te verbeteren. 

Het een-na-laatste nummer van Informatie Professional bevat een inspirerend artikel van de hand van Matthijs van Otegem over de toepassing van procesmanagement in de Koninklijke Bibliotheek. Als case-study gebruikt hij de verbetering van het digitaliseringstraject,  wat gezien de projecten met Google en ProQuest een belangrijke activiteit is voor de KB. Toen een oud-collega me vertelde dat de KB een workshop organiseerde over hetzelfde onderwerp, aarzelde ik geen moment en heb direct gevraagd of ik aan mocht sluiten. Gelukkig was ik van harte welkom!

Tijdens de workshop werd uitgebreid ingegaan op één van de bekendere procesmanagementmethodes Lean Six Sigma. Hierin staat het verbeteren van klanttevredenheid en het verhogen van efficiëntie centraal. “Door te focussen op datgene wat voor de klant écht belangrijk is en fouten in de uitvoering terug te dringen, wordt het aantal processtappen gereduceerd (Lean) en de uitkomst van de processen voorspelbaar gemaakt (Six Sigma) “. Doordat de methode van oorsprong Japans is, kwamen er flink wat exotische termen voorbij, zoals Poka Yoke – een proces wordt zodanig ingericht dat mensen geen fouten kunnen maken – en Jidoka – de volgende productiestap mag pas worden genomen wanneer het deelproduct defectvrij is. Ook wordt veel verantwoordelijkheid bij de medewerkers neergelegd; verbetering wordt niet van boven opgelegd, maar doe je samen. De deelnemers aan de workshop werden daarom ook zelf aan het werk gezet. De opdracht was om in groepjes te bedenken hoe de klanttevredenheid bij het aanvragen van boeken uit het Depot Nederlandse Publicaties verbeterd kon worden. Deze boeken mogen het gebouw niet verlaten, wat regelmatig tot misverstanden en ontevredenheid leidt bij klanten.

Na afloop realiseerde ik me dat we op de UB ook al tamelijk Lean werken. Dit is namelijk precies wat wij proberen te bereiken met de nieuwe dienst “Digitalisering op verzoek”. Ook hier vormde de klant het uitgangspunt voor de inrichting van een efficiëntere workflow. Door het proces te vereenvoudigen en te automatiseren kunnen de scans sneller aan de klant worden geleverd, en kost het ons tegelijk minder tijd en inzet. Hiervoor hebben we uiteenlopende deelproducten gerealiseerd, waaronder:
– Buttons in PRIMO waarmee klanten direct vanuit de catalogus scans kunnen bestellen
– Geautomatiseerde levering van scans door middel van FTP
– Een betaalmodule waarmee klanten snel en eenvoudig kunnen betalen

Ook de aanschaf van het softwarepakket GOOBI voor het inrichten en managen van de digitaliseringsworkflow helpt hierbij. Goobi deelt het productieproces op in deeltaken, en koppelt aan elke taak een rol, zoals ‘baliemedewerkers’, en ‘scanmedewerkers’. Taken worden na afronding automatisch naar de volgende in het proces doorgestuurd, of -wanneer een fout wordt geconstateerd- teruggestuurd naar de vorige. Ook is een aantal validaties ingebouwd, waarmee medewerkers gedwongen worden om bepaalde velden in de database in te vullen. Niet alleen helemaal Jidoka, maar ook echt Poka Yoke dus!

Innovatie is een modewoord voor iets dat vaak mislukt

Geplaatst op door
Beantwoorden

De titel van deze blogpost heb ik niet zelf verzonnen, maar vormt de kop van een artikel in NRC Opinie & Debat van zaterdag 29 juni 2013.  Sinds mijn afdeling volmondig Innovatie & Projecten heet, valt mijn oog vaker dan voorheen op dit soort artikelen en lijkt het woord Innovatie ook vaker voor te komen. (Hoe heet dat effect ook al weer?)

De bibliotheekwereld heeft het de laatste tijd ook veel over innovatie; zonder dat zou de toekomst van de (universitaire) bibliotheek wel eens heel somber kunnen zijn. daarom kijken alle bibliotheken, en dus ook de UBL, goed naar de eigen rol en naar mogelijkheden voor innovatie.

Een paar zinnen in het NRC artikel vielen mij extra op.

“Innoveren is vernieuwen, een stap verder gaan dat de status quo. … Innovatie is iets anders dan inventie, uitvinden.”  Dit stelt mij gerust, we zijn niet zo goed in uitvinden, maar doen wel redelijk mee  als het gaat om vernieuwen.

“Innoveren wordt ook wel gedefinieerd als het ontwikkelen van nieuwe combinaties.” Een goed voorbeeld hiervan zijn de lockers die de UBL in gebruik heeft voor uitlenen van materialen zonder dat daar direct bibliotheekpersoneel voor nodig is. Een combinatie van lockers (zoals ook in gebruik bij zwembaden) en een uitleenautomaat (zoals veel bibliotheken die gebruiken, met als protocol SIP2) heeft gezorgd voor een mooie innovatie. Recent hebben we onze locatie in Den Haag ook van lockers voorzien: materialen kunnen uit de UBL collectie worden opgevraagd en worden via de lockers op de Campus Den Haag uitgeleend. Wellicht komt er binnenkort nog zo’n vestiging bij.

“Innoveren heeft twee fundamentele kenmerken die elke manager tot wanhoop kunnen drijven: een onzekere uitkomst en een onzeker proces.” Ik prijs me dan ook gelukkig dat ik geen manager ben. Bij het management van de UBL valt die wanhoop overigens ook niet te merken. Juist onze directeur Kurt De Belder, loopt graag voorop als het gaat om innovatie en heeft een duidelijke visie voor de toekomst van de UBL en ook de overige MT leden zijn bepaald niet vies van vernieuwing.

“In een innovatietraject kun je vier type activiteiten onderscheiden … bedenken op welk gebied je wilt innoveren … iets bedenken dat hiervoor een oplossing biedt … concept goed uitwerken … innovatie op de juiste manier implementeren in je organisatie.”  Persoonlijk vind ik het eerste en het laatste punt het lastigste. Met de kennis die we bij de UBL in huis hebben kunnen we vrij goed oplossingen bedenken en uitwerken, binnen de beperkte mogelijkheden.  De typen activiteiten lopen ook vaak door elkaar heen, bij het bedenken van een mogelijkheid moet je al rekening houden met haalbaarheid (beperkte middelen!) en mogelijkheden voor implementatie, waarbij ook acceptatie een belangrijke rol speelt.

“We vinden innoveren leuk.” Dat geldt zeker voor de medewerkers van de afdeling Innovatie & Projecten van de UBL. We zijn dan ook volop bezig om (al dan niet in projecten) te werken aan vernieuwing van diensten, processen en systemen. Een aantal van de belangrijkere innovatieve projecten:

  • Samenwerkingsomgevingen voor onderzoekers en ook voor het betrekken van studenten bij onderzoek
  • Catalogiseren van onze bijzondere collecties (handschriften, prenten, fotografie, brieven, etc.) met gebruik van standaard infrastructuur als GGC en WorldCat
  • Metadata van leveranciers gebruiken in plaats van deze zelf in te voeren

De komende jaren staat de UBL nog veel innovatie te wachten, waaronder waarschijnlijk een hele nieuwe generatie bibliotheeksystemen die moeten leiden tot een aanzienlijk lagere “Total Cost of Ownership”.

Gelukkig dus ruim voldoende werk….

P.S.  Volgens INSEAD staat Nederland op plek 4 van “The World’s Most Innovative Countries: The Global Innovation Index 2013”. Zo slecht doen we het dus ook weer niet

Toch maar wel weer bloggen

Geplaatst op door
1

Tegen de stroom in hebben wij bedacht dat we (weer) willen gaan bloggen. Maar dan wel op een nieuwe plek en onder een nieuwe naam : UBL innovatie . Het moet een blog worden door de medewerkers van de afdeling Innovatie & Projecten van de Universitaire Bibliotheken leiden (UBL), geïnspireerd door ons dagelijks werk, maar op persoonlijke titel.

Google Reader is er net mee gestopt (1 juli!). Er is op diverse bekende bibliobblogs over geschreven met als titels “Is it the end of an era for librarian blogging?” , “Niet bloggen maar joggen?”, “Biblioblog(gers) in vrije val”  en “De bloggende bibliothecaris anno 2013” : bloggen is uit!

Ook op een recente interne UBL bijeenkomst werd geconstateerd dat Twitter wellicht veel belangrijker zou zijn dan bloggen. En dat RSS readers hun langste tijd wel gehad zouden hebben.

Vervolgens werd er heel veel getweet (en geblogd) over de beste vervanger voor Google Reader, met Feedly als winnaar. En komen er toch ook weer nieuwe blogs bij, zoals Skills for InformatieProfessionals van onze eigen divisiemanager Josje Calff.  Onze collega’s van de UB Utrecht zijn in staat om inspirerend gezamenlijk te bloggen met hun I&M / I&O 2.0 blog.

Als je dat samenvoegt met alle discussies over het bestaansrecht van universitaire bibliotheken en recente organisatorische veranderingen bij de UBL, met als resultaat een zelfstandige afdeling Innovatie & Projecten,  ontstaat toch het gevoel van “dat zouden wij toch ook moeten kunnen?” Dus: we gaan weer bloggen. Nu nog voldoende inspiratie.En lezers natuurlijk, met liefst inhoudelijke reacties. Wij denken dat we genoeg te vertellen hebben, voor ons geldt: bloggen is in!