Islandoracon 2019

IslandoraCon is de Islandora Conferentie die eens in de 2 jaar wordt gehouden. Islandora is het open source digitaal repository systeem dat door de Universiteit Leiden gebruikt wordt voor haar Digitale collecties en binnenkort ook voor het Scholarly Repository en het Student Repository.
IslandoraCon werd na Charlottetown (2015) en Hamilton (2017) dit jaar in Vancouver gehouden. Het was een vooral Canadees/Amerikaanse aangelegenheid want van de 110+ bezoekers kwamen er 3 van buiten Canada en Amerika; een uit Afrika, een uit Nieuw-Zeeland en een uit Europa (ik). Het congres zelf duurde 3 dagen maar werd voorafgegaan door een dag met workshops en afgesloten door een Use-a-Thon/unconference.
Hieronder een verslag van de 5 dagen.

De eerste workshop waar ik aan deelnam ging over ISLE. De afkorting staat voor Islandora Enterprise en wordt ontwikkeld door de Islandora Collaboration Group (ICG). Eigenlijk is dit Islandora als een Docker container, waardoor naar eigen zeggen het minder werk is om Islandora te installeren en onderhouden, makkelijker overgegaan kan worden naar nieuwe versies (dus ook de overstap van Islandora 7 naar Islandora 8) en het betere security en reliability biedt omdat het vaker geüpdatet wordt. Natuurlijk staat daar tegenover dat er minder mogelijk is wat betreft eigen invulling van hoe de componenten samenwerken en waar ze geïnstalleerd zijn (meerdere servers). We hebben zelf ISLE geïnstalleerd op onze lokale laptop met behulp van Docker, dit was redelijk eenvoudig maar vereiste dan wel weer kennis van Docker en andere componenten zoals Traefik.

De tweede workshop ging over plugins maken voor Drupal 8. Dit was erg interessant maar drukte me meteen met de neus op de feiten: er is nog een heleboel te leren, alleen al over Drupal 8.
Een plugin is een nieuwe API in Drupal 8. Het is de bedoeling dat een plugin precies 1 ding doet, zodat het goed herbruikbaar en snel is. Plugins zijn configureerbaar, ze kunnen verschillend gedrag/functionaliteit implementeren via een zelfde interface. In Drupal 8 zijn er ook services. Services zijn uitwisselbaar met elkaar en bieden hetzelfde gedrag/functionaliteit maar met verschillende interne implementaties. Een voorbeeld van een service is bijvoorbeeld caching; er zijn verschillende services die caching binnen Drupal kunnen verzorgen, en deze zijn uitwisselbaar al naar gelang de wensen en eisen. Een voorbeeld van een plugin is bijvoorbeeld het maken van afgeleide plaatjes wanneer er een TIF plaatje wordt ingeladen binnen Islandora 8 (wat dus eigenlijk Drupal 8 is aan de voorkant).
Het plugin systeem vervangt het hook systeem van Drupal 7 en is net zo krachtig, maar duidelijker gedefinieerd en meer toekomst bestendig.

Na de workshops van dag 1 werd de conferentie echt geopend met een overzicht van Islandora nu en in de toekomst. Natuurlijk ligt de focus nu op Islandora 8, wat voorheen Islandora CLAW genoemd werd. Maar Islandora 7 wordt zeker niet vergeten. Er wordt voor Islandora 7 overgegaan naar een jaarlijkse release (dit was 2 keer per jaar), maar aangezien er nog steeds veel instellingen gebruikmaken van Islandora 7, wordt het voorlopig nog ondersteund: na november 2020 wordt er geen nieuwe functionaliteit meer toegevoegd, na november 2021 worden er geen bug fixes meer gedaan en na april 2022 worden er geen security fixes meer gedaan. Dit hangt ook samen met Drupal 7 dat vanaf november 2021 niet meer ondersteund wordt.
Verschillende aspecten van Islandora worden behartigd door verschillende groepen: de Coordinating Committee (voorheen de Roadmap Committee) bepaalt de richting van Islandora op de langere termijn en bevordert de Islandora community, de Technical Advisory Group doet aanbevelingen met betrekking tot de architectuur en technische roadmap van Islandora, de Multi-tenancy Interest Group houdt zich bezig met multi-site support in Islandora 8 (één Islandora installatie met meerdere websites) en de Metadata Interest Group focust op metadata (vooral in Islandora 8 aangezien het hier heel anders werkt). Andere interest groups zijn hier te vinden: https://github.com/islandora-interest-groups

Er werd deze dag veel over Islandora 8 verteld. Versie 1.0.0 is op 5 juni 2019 officieel uitgekomen. Waar Islandora 7 nog als een hamburger werd gerepresenteerd, wordt Islandora 8 als een bento box gezien, namelijk verschillende onderdelen die goed met elkaar samengaan (samenwerken) maar uitwisselbaar zijn. Islandora 8 is veel meer verweven met Drupal 8. Waar Islandora 7 het mogelijk maakte om Islandora objecten binnen Drupal te gebruiken, is het bij Islandora 8 zo dat die objecten volledige Drupal nodes zijn. Islandora 8 maakt gebruik van nodes (waar islandora 7 een object gebruikt), files (vergelijkbaar met de datastreams in 7) en media (deze koppelt de nodes aan de files en hier wordt de technische metadata bewaard). Islandora objecten zijn dus “first-class citizens“. Dit betekent dat alle modules die voor Drupal 8 geschreven zijn, ook meteen toepasbaar zijn voor Islandora 8. Eigenlijk is Islandora 8 zelf onder andere een Drupal 8 module die de functionaliteit van een digital repository aan Drupal toevoegt. Veel functionaliteit waarvoor in Islandora 7 veel code nodig was, is in Islandora 8 al beschikbaar via Drupal 8 en door configureren beschikbaar te maken. Islandora 8 voegt aan Drupal 8 onder andere het volgende toe: JSON-LD (een manier om Linked Data over te dragen als JSON), een koppeling met Fedora Commons (met behulp van Flysystem worden bepaalde bestanden in Fedora bewaard) en het genereren van afgeleiden.
Er wordt al hard gewerkt aan de volgende versies van Islandora 8: er worden onder andere breadcrumbs, paged content (wat boeken en kranten mogelijk maakt), IIIF manifesten, text extraction en versioning toegevoegd. Dit zou voor het eind van dit jaar gereed moeten zijn. Ook wordt er gekeken naar de migratie naar Drupal 9 en Fedora Commons 6, aangezien Drupal 9 eind 2020 uitkomt. Dit betreft een kleine update en is zeker geen migratie zoals van Islandora 7 naar 8. Wel biedt Fedora Commons 6 het Oxford Common File Format. Dit is een standaard manier voor opslaan van digitale informatie waardoor deze data compleet (de hele repository kan opnieuw opgebouwd worden met deze data), leesbaar (voor mens en machine, ook zonder de originele software), robuust (fouten in bestanden kunnen ontdekt worden, migratie is makkelijker) en versiebeheerd (wijzigingen zijn herleidbaar en kunnen teruggedraaid worden) opgeslagen kan worden op verschillende storage mogelijkheden (filesystem, cloud, etc.).
Migratie van data naar Islandora 8 werd ook uitvoerig besproken. Ook dit gaat op een standaard Drupal 8 manier. Er is een Migrate API in Drupal 8 ingebouwd die werkt volgens het ETL principe; Extract – Transform – Load. Hier zijn al meerdere plugins voor beschikbaar en migratie is dus vooral een kwestie van veel configuratie bestanden maken of aanpassen, testen en migreren. Er wordt druk gewerkt aan standaard manieren om Islandora 7 data te migreren naar Islandora 8, maar aangezien er altijd “eigen wensen” zijn zal geen enkele migratie dit zonder aanpassingen kunnen gebruiken.

Gedurende de hele conferentie waren er interessante presentaties van andere Islandora gebruikers. Er was een presentatie over een interactieve kaart met verhalen over Vancouver, waarbij op de kaart aangegeven was waar het verhaal was verteld. De verhalen worden zo op een heel andere manier gevonden. Zoals veel bij Islandora, is de code achter de site vrij toegankelijk. Zie https://thisvancouver.vpl.ca/story-city
De mensen van Discover Okanagan Historical Resources hadden een aparte kijk op digitaliseren: het afbreken van een collectie en het opnieuw digitaal opbouwen ervan, waarbij bepaalde impliciete relaties worden verwijderd die later opgebouwd moeten worden in metadata.
Er was een sessie over performance van Islandora, waaruit bleek dat we al veel goed doen, maar Solr optimalisatie is nog wel een belangrijk punt wat nog gedaan moet worden. Optimalisatie bleek ook nu weer een zeer gespecialiseerd onderwerp te zijn waarbij er niet altijd standaard oplossingen zijn.
Een andere sessie ging over microservices. Dit zijn een of meerdere gespecialiseerde programma’s die communiceren met Drupal over (meestal) http. Deze microservices kunnen draaien op “any server, in any language and under any technology”. Islandora 8 maakt veel gebruik van microservices, onder andere voor afgeleiden maken (audio, video, images), FITS (File Information Tool Set, technische metadata uit bestanden halen), text extraction, fixity checks en BagIt integration. In Drupal kan een bepaalde actie gedaan worden als binnen een context aan bepaalde condities voldaan is. Dit is zonder veel code te configureren, zodat bijvoorbeeld als er een original file aan de media wordt toegevoegd (context en conditie), deze door Drupal aan CrayFITS (microservice) gegeven wordt, die de technische metadata uit het bestand haalt en weer binnen Drupal bewaard (action), waarna dit weer in Solr geïndexeerd wordt (dit is weer een andere microservice).
Er waren nog vele andere interessante presentaties, onder andere over content modelling in Islandora 8, diverse manieren van inlezen van content, over namen (“Falsehoods librarians believe about names”) en over headless Islandora. Helaas staan deze presentaties nog niet online, dus kan ik hier niet naar linken.

De laatste dag was gereserveerd voor een Use-a-Thon en de unconference. Tijdens de Use-a-Thon werden bepaalde usecases opgelost in groepsverband, waarbij mooie prijzen te winnen waren. De winnaars hadden een oplossing voor Oral History Transcriptions, Collection Search en multi-tenancy. Helaas viel onze groep (de “Exhibitionists”) net buiten de prijzen, maar toch een mooi resultaat.

Het was een erg zinvolle conferentie waarbij ik veel geleerd heb, maar waar het ook duidelijk werd dat er nog heel veel te leren valt, vooral over Islandora 8.

Islandora Camp Limerick 2018

Ook dit jaar ben ik weer naar Islandora Camp geweest. Dit keer was het in Limerick in Ierland. Ik zou met Jan Jouke en Mick van DD beheer gaan, maar Mick kon wegens ziekte helaas niet mee. Aangezien dit al mijn derde Islandora Camp was (na Delft en Madrid) en we inmiddels veel ervaring hebben met Islandora, was niet alles even interessant meer, maar het was wel goed om andere Islandora gebruikers te ontmoeten en te kunnen spreken.

Islandora Camp duurt 3 dagen en is altijd hetzelfde opgedeeld: de eerste dag gaat het om kennismaken met Islandora en met elkaar. De tweede dag wordt de diepte ingedoken met code (dev track) of beheer (admin track) en worden allerlei vragen beantwoord. De derde en laatste dag worden er presentaties gehouden door gebruikers van Islandora en wordt het camp afgesloten met zowel een prijsuitreiking als een “unconference”. Hieronder een verslag van het hele camp.

Jan Jouke en ik waren dinsdag al aangekomen en woensdag was de eerste dag van het Camp. Het werd gehouden in de Tierney building op de campus van de Universiteit van Limerick (“Ollscoil Luimnigh” in Iers). Na een korte opening en introductie kon iedereen zichzelf voorstellen. Aangezien er 22 mensen waren, was dit goed te doen. Hierna werd de architectuur van Islandora uitgelegd, inclusief hamburger. Je kan daar meer over lezen in mijn blog van vorig jaar.

De nieuwste versie van Islandora (versie 7.x-1.11) heeft de mogelijkheid om een andere Image Server te gebruiken, namelijk Cantaloupe. Dat is interessant omdat Cantaloupe de IIIF image API ondersteund. Voor wie niet bekend is met IIIF, ik heb er eerder over geschreven hier en hier. Dit betekent niet dat Islandora nu IIIF compliant is, maar het is wel een stap in de juiste richting.

Verder werd er veel gesproken over de CLAW, dit is een geheel nieuwe versie van Islandora die in ontwikkeling is. De onderliggende componenten van de huidige Islandora (zoals Fedora Commons, Drupal en SOLR) zijn inmiddels allemaal geüpgraded en zijn zodanig veranderd dat de huidige architectuur van Islandora niet meer geschikt is. Dit was de reden om aan een hele nieuwe versie van de Islandora architectuur te gaan bouwen, die dus bekend staat onder de naam CLAW (een recursief acroniem wat staat voor CLAW Linked Asset WebFramework). De architectuur can de CLAW heeft een hele andere opzet dan de huidige versie van Islandora. Nu is het zo dat Islandora tussen Fedora en Drupal staat en de communicatie tussen deze twee regelt. Fedora wordt gebruik voor de opslag van alle data en Drupal wordt gebruikt voor het afbeelden van deze data, maar binnen Drupal is eigenlijk niks bekend over een Islandora object. Dit heeft als nadeel dat veel Drupal modules (uitbreidingen op Drupal functionaliteit, waarvan er duizenden bestaan) gebruik maken van de data die in Drupal zit en dus niet gebruikmaken van Islandora data. Hier zijn vaak wel oplossingen voor te vinden, maar dat houdt in dat er een extra module geschreven moet worden om deze Drupal functionaliteit ook binnen Islandora mogelijk te maken.
Binnen de CLAW worden de objecten behandeld als Drupal objecten. De archiefkopieën worden nog steeds opgeslagen in Fedora, maar het object met de afgeleiden bestaat in zijn geheel in Drupal. Dit heeft als voordeel dat alle Drupal modules direct te gebruiken zijn, aangezien deze kunnen omgaan met Drupal objecten. Dit belooft dus een hechtere band met de grote Drupal community, waardoor het makkelijker wordt om functionaliteit aan de voorkant van het systeem toe te voegen.
Verder is de CLAW veel modulairder opgezet en is de koppeling tussen de verschillende onderdelen veel losser. Dit heeft als voordeel dat een onderdeel wat een bepaalde functionaliteit biedt, makkelijker uitgewisseld kan worden door een ander onderdeel wat dezelfde functionaliteit biedt.
De Drupal objecten kunnen relaties met elkaar hebben, bijvoorbeeld dat een object onderdeel uitmaakt van een ander object (boek-pagina of compound-child relatie) of een object wat op een andere manier aan een ander object gerelateerd is. Elk Drupal object heeft daarnaast tags, waarmee het op meerdere manieren geclassificeerd kan worden.
Alle acties die op een Drupal object uitgevoerd (kunnen) worden, worden bepaald aan de hand van de tags van het Drupal object. Acties zijn dus veel minder gebonden aan het content model van het object. Bijvoorbeeld bij het inladen van een object wordt aan de hand van de tags bepaald welke afgeleiden gemaakt gaan worden. Ook wordt aan de hand van de tags bepaald hoe het object afgebeeld gaat worden. Dit heeft als voordeel dat het geheel veel flexibeler wordt. Acties zijn zelf te definiëren binnen Drupal en te koppelen aan tags.

Aan de CLAW wordt op dit moment nog hard gewerkt en getest. Momenteel is het alleen mogelijk om plaatjes op te nemen; boeken, video, audio, compounds, tijdschriften zijn allemaal niet mogelijk. Er is een aantal kleine sites die op de CLAW draaien, maar dat is nog erg in de testfase. Er werd wel gevraagd of meer instituten interesse hadden om mee te testen en een collectie in de CLAW te zetten. Op dit moment hebben wij er geen tijd voor, maar mogelijk is dit iets voor de toekomst.

Dag 2 werd de diepte ingedoken. Na enige discussie werd besloten dat de ochtend werd gebruikt voor de huidige versie van Islandora en de middag voor de CLAW. In de ochtend ging het vooral over performance; hoe zorg je ervoor dat Islandora snel blijft aanvoelen. Verschillende performance improvements kwamen voorbij, waarvan wij er heel wat al hebben geïmplementeerd. Andere mogelijkheden zijn interessant om uit te zoeken, want wellicht is daar nog wat snelheid te halen. Helaas kost dit uitzoeken natuurlijk ook tijd (en geld), dus dat is iets voor de toekomst.
In de middag hebben we meer gehoord en gezien van de CLAW. Een groot deel van de tijd zijn we ook bezig geweest om de CLAW te installeren op onze eigen laptop, door gebruik te maken van ansible en vagrant. Hieruit bleek dat hoewel CLAW al best goed werkt, het nog bij lange na niet geschikt is als productie systeem.

De derde dag begon met de camp awards. Er worden elk jaar prijzen uitgereikt in diverse categorieën en dit jaar won Jan Jouke de “camp spirit” award.
Hierna werden diverse presentaties gehouden door gebruikers van Islandora:
Cillian Joy van NUI Galway vertelde over hun Maker Space, een ruimte met 3D printers, Raspberry pi’s, animatie software en Arduino boards. Hij vertelde ook een project over het vertellen van een verhaal met behulp van boeken. Hiervoor werd zowel Islandora, Omeka als Neatline gebruikt. Zie O’Shaughnessy Memoirs.
Ik had zelf ook een presentatie over onze module “conditional access rights”. Hiermee kan op basis van condities de toegangsrechten van objecten geregeld worden. Condities kunnen bijvoorbeeld gedefinieerd worden door bepaalde inhoud van metadata velden, locatie van de gebruiker of wel of niet ingelogd zijn. Aan de condities kan een actie gekoppeld worden, zoals toegang tot een object en/of de datastreams van het object, kunnen downloaden van deze datastreams en het zichtbaar maken van bepaalde copyright data. Ook vertelde ik iets over onze module om data te exporteren uit Islandora en over onze module om data in Islandora achteraf in batch te kunnen wijzigen.

De derde dag eindigde met de unconference, waarbij iedereen vragen kon stellen in een relaxte setting. Jan Jouke en ik hadden nog wel wat vragen en al snel waren 2 van de 3 instructeurs die het camp leidden, voor ons bezig met aanpassingen aan Islandora en het opstellen van change requests.

Zoals elk jaar heb ik weer een hoop nieuwe zaken gehoord, nieuwe ideeën gekregen, nog meer vragen die beantwoord moeten worden en vooral een berg zaken waar ik toch echt een keer nog naar moet kijken.

Islandora Camp Delft 2017

islandora_camp_delft

Van 13 tot en met 15 juni 2017 werd het Islandora Camp in Delft gehouden. Een Islandora Camp is een bijeenkomst van gebruikers van Islandora (een digitaal repository) waar presentaties, workshops en tutorials gehouden worden door de Islandora Foundation en ook de gebruikers zelf. Ook wordt er veel gepraat en vooral kennis gedeeld tussen alle gebruikers van Islandora, wat ook dit keer weer heel zinvol was. Vanuit Leiden waren we met een (zware) delegatie van 4 personen: Wouter Kool van de faculteit Archeologie, Liesbeth van Wijk en Niels Molenaar van Digitale Diensten, en ik.
islandoraburger
De eerste dag werd uitgelegd wat Islandora nu eigenlijk is, wat je ermee kan, hoe je kan bijdragen en wat er in de (nabije) toekomst gaat gebeuren. Elk jaar wordt bij de uitleg van wat islandora is de Islandora hamburger erbij gehaald. Het ene jaar is het plaatje wat mooier dan het andere jaar maar het komt erop neer dat Islandora als hamburger tussen de broodjes “Fedora” (de DAM architectuur, waar de digitale objecten worden bewaard) en “Drupal” (het CMS, die de presentatie van de digitale objecten doet) in zit. Er zijn dan verschillende toppings op de hamburger mogelijk, waaronder Solr (een zoek platform). Aangezien Solr vaak als de kaas van de hamburger wordt afgebeeld en eigenlijk een standaard component is, wordt tegenwoordig ook wel gesproken van de “cheeseburger”.

Islandora kan uitgebreid worden op verschillende manieren, oftewel er zijn verschillende toppings mogelijk. Voor verschillende types content zijn er solution packs beschikbaar, zoals voor plaatjes, boeken, video, pdf, enzovoorts. Maar als je content van een ander type in Islandora wil zetten, dan is dat mogelijk door een eigen solution pack hiervoor te ontwikkelen. Ook kan de functionaliteit uitgebreid worden door een module te installeren of zelf te maken. Het uiterlijk kan helemaal aangepast worden door in Drupal een theme te installeren of zelf te maken.

Islandora is een erg flexibel, modulair, aanpasbaar en uitbreidbaar repositorium en biedt dus veel mogelijkheden om naar eigen wens aan te passen, uit te breiden en te verbeteren. Hiervoor is echter wel veel kennis nodig en die konden we voor een deel opdoen tijdens dit camp.

Er werd ook uitgebreid stilgestaan bij de toekomst; de broodjes (Fedora en Drupal) hebben namelijk allebei een nieuwe versie die nogal verschilt van de versie die de huidige Islandora gebruikt, en daarom wordt er hard gewerkt aan een nieuwe versie van Islandora. Deze nieuwe versie staat bekend onder de naam Islandora CLAW. Deze kan ook niet meer als een hamburger gerepresenteerd worden, aangezien de verschillende onderdelen op een andere manier met elkaar omgaan. Islandora zelf is geen laag meer hierin, maar integreert in elk onderdeel en speelt daarin verschillende rollen. Als er iets gebeurt in een onderdeel (bijvoorbeeld een nieuwe digitaal object wordt ingelezen in Fedora), dan worden andere onderdelen daarvan via events op de hoogte gebracht waarop zij kunnen handelen (bijv. Solr doet indexering). Door deze asynchrone manier van werken lijken acties veel sneller uitgevoerd te worden, omdat er niet meer op gewacht hoeft te worden. Eigenlijk wordt alleen maar gezegd dat een actie uitgevoerd moet worden en het systeem handelt dit dan af op het eerste beschikbare moment.

Ook wordt het onderliggende data model gewijzigd. Aangezien Fedora 4 alle data opslaat als RDF en via Linked Data communiceert, is er hiervoor (dit is dus meer omvattend dan Islandora alleen) een nieuw data model ontwikkeld genaamd het Portland Common data model. Dit is een uitbreidbaar, flexibel domein model dat als basis moet dienen voor veel DAMS.

Een mooie ontwikkeling is het plan is om binnen Islandora CLAW IIIF te gaan ondersteunen. Wanneer dit ontwikkeld wordt en in welke mate, bleef echter nog even onduidelijk, maar er zijn wel concrete plannen voor.

Islandora CLAW wordt op dit moment ontwikkeld. Een eerste minimale versie staat gepland voor eind juni 2017, maar dat is zeker geen versie die al gebruikt kan gaan worden. Dit is absoluut iets om in de gaten te houden, maar niet iets waar we concreet mee aan de slag kunnen op korte termijn.

In de huidige Islandora versie zijn er ook genoeg ontwikkelingen. Hieronder een korte beschrijving van de meest interessante:

Het Oral History Solution Pack maakt het mogelijk om audio en video in Islandora in te laden. Op zich was dit al mogelijk, maar nu kunnen ondertitels en transcript er ook bij ingeladen en afgebeeld worden. Binnen de ondertitels en transcripts kan gezocht worden, zelfs op de naam van de spreker.

May Bragdon Diaries is een Islandora site die de moeite waard is om te bekijken. De site bevat 10 dagboeken die volledig doorzoekbaar en geannoteerd zijn. Via links kan men meer te weten komen over de verschillende personen en objecten, die allemaal bekend staan onder verschillende namen. Sommige bladzijdes bevatten krantenknipsels, foto’s of ansichtkaarten en deze zijn als geheel maar ook los gescand en dus te bekijken. Deze site laat goed de kracht en flexibiliteit van Islandora zien, maar ook dat zoiets veel werk is (een projectteam van 10 personen heeft hier 5 jaar aan gewerkt).

Natuurlijk werden er andere leuke Islandora sites ook getoond; katten, honden, geneeskunde, violen en St. Andrews. Ook werden er veel (nieuwe) Islandora modules getoond, allemaal te vinden via Islandora awesome. Zo is er een EAD solution pack, een Serial solution pack, een Document solution pack (waarmee Office documenten ingeladen kunnen worden), een Binary solution pack (alle bestandstypes maar zonder een manier om die te tonen), een XML solution pack (XML bestanden ingelezen in Islandora kunnen met een XSL transformatie getoond worden) en een Streaming media solution pack (kan MP4 video bestanden die ergens anders zijn opgeslagen via Islandora streamen naar de gebruiker).

Op dag 2 was er een dev track en een admin track. Ik heb de dev track gevolgd, waarin van alles werd besproken en veel vragen beantwoord werden. Zo heb ik weer wat nieuws geleerd over SOLR en XACML die beide belangrijk zijn binnen Islandora. Al deze dingen waren heel leerzaam voor mij, maar helaas niet heel geschikt om in een blog over te schrijven. Wel bleek er iemand bezig te zijn met een IIIF module voor de huidige versie van Islandora. Deze module is nog in ontwikkeling maar is wel interessant om dit te volgen en wellicht hieraan bij te dragen.

Op de derde en laatste dag werden als eerste zoals gebruikelijk de “Islandora Camp awards” uitgereikt. Dit zijn prijzen voor degene die het verst gereisd heeft, die het meest betrokken was bij het camp enzovoorts. Deze prijzen zijn een ludiek en terugkerend thema op de Islandora Camps.

De derde dag was ook de dag van de presentaties. Er werd door een aantal gebruikers van Islandora een presentatie gegeven over hoe zij Islandora gebruikten en/of hadden aangepast aan hun wensen. Een van de mensen was ik. In mijn presentatie heb ik uitgelegd hoe wij de data van onze oude systemen in ons nieuwe Islandora repositorie importeren. Het probleem is namelijk dat de data die geëxporteerd wordt uit deze oude systemen, niet in een formaat staat wat ingelezen kan worden door Islandora. En aangezien we meerdere oude systemen hebben die allemaal meerdere eigen formaten exporteren, is dit een groot probleem. Hiervoor heb ik een module (Prepare Ingest) gebouwd waarmee een workflow gemaakt kan worden waarmee de data van het ene formaat in een formaat wat Islandora in kan lezen, omgezet kan worden. Tijdens de presentatie demonstreerde ik dit met een relatief simpele export van plaatjes die meerdere boeken representeerden. Gelukkig ging dit allemaal goed.

Als de data is omgezet met deze module, kan het ingelezen worden in Islandora. Deze maakt er dan automatisch afgeleiden van. Aangezien dit niet altijd goed gaat en we een mogelijkheid wilden hebben om te controleren of een importeeractie goed was gegaan, heb ik een module (Check datastreams) gemaakt die controleert of alle objecten compleet zijn. Deze module heb ik ook gepresenteerd.

Metadata wordt bij ons in Alma geregistreerd. Natuurlijk willen we deze metadata ook binnen Islandora gebruiken. Ik heb hiervoor een module (Metadata synchronisation) gemaakt die metadata van een OAI-PMH bron kan ophalen en gebruiken binnen Islandora. Ook deze module heb ik op het Islandora Camp gepresenteerd. Mijn volledige presentatie is hier te vinden.

Na mijn presentatie was er nog een presentatie van de man die de meeste lovende woorden over mijn modules had. Hij (Diego Pino Navarro) presenteerde zijn eigen module de Multi Importer. Hiermee kunnen objecten van verschillende types tegelijkertijd ingelezen worden in Islandora. Deze module heeft voor een deel soortgelijke functionaliteit als mijn module Prepare Ingest. We hebben nog hierover gepraat en vonden het allebei een goed idee om meer naar elkaars werk te kijken en wellicht delen van elkaars werk in het eigen werk op te nemen. Dit is dus nog een van de dingen die op mijn to do lijstje staat.

Islandora Camp eindigde met een unconference; oftewel stel alle vragen die je nog hebt en dan proberen we samen een antwoord te vinden. Dat hebben we natuurlijk gedaan en onze vragen werden ook allemaal beantwoord. Dit was echter wel een conferentie waar je vandaan komt met een heel pak huiswerk; ik moet nog veel dingen bekijken, nader uitzoeken en vooral heel veel lezen. Dus ik ga nu maar weer ’s aan mijn huiswerk!

 

 

 

IIIF 2017 Vaticaanstad

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!

 

TPDL 2016

img_1392Begin september 2016 was ik bij het TPDL 2016 in Hannover. Het TPDL is een conferentie betreffende de theorie en praktijk van Digitale bibliotheken. Deze conferentie was tot 2011 bekend onder de naam ECDL (nee, niet het European Computer Driving Licence, maar dat was wel de reden van de naamswijziging) en wordt al bijna 20 jaar gehouden. img_1390
De conferentie werd gehouden in het Hannover Congress Centrum, wat op ongeveer 25 minuten lopen vanaf mijn hotel lag, naast de Hannover ZOO en een groot park.
De conferentie was een mix van keynotes, presentaties van wetenschappelijk onderzoek en workshops (soms hands-on). Hieronder een verslag van een deel van wat ik heb gezien.

De eerste keynote was door David Bainbridge (University of Waikato, Hamilton, New Zealand) met als titel “Mozart’s laptop”, wat mij intrigeerde. Op zich was het onderwerp interessant, namelijk over muziek in de Digitale Library, maar het ging eigenlijk niet over Mozart’s laptop. Ik had verwacht te horen hoe Mozart gebruik zou maken van een laptop als die beschikbaar was in zijn tijd. In plaats daarvan ging het over een systeem (Expediteee) waarin men op een gelijksoortige manier tekst, plaatjes, vector graphics en muziek kon opgeslaan en samenvoegen. Grappig was dat in muziek gezocht kon worden door “query by humming”. Hier werd gebruik gemaakt van audio finger printing. Ook werd Online Dynamic Time Warping (OTW) getoond. Dit is een techniek waarbij de computer de muziek kan volgen die van bijv. een iPad gespeeld wordt. Hiervoor is een soort OCR voor muziekschrift nodig zodat de computer de noten kan lezen en interpreteren, de gespeelde muziek moet geanalyseerd worden en hieruit wordt bepaald welk stuk van de muziek op dat moment wordt gespeeld. Zo kan de computer de bladmuziek op het juiste moment “omslaan”, zodat de musicus dat niet hoeft te doen.
Ook werd er een manier getoond om muziekvideo’s uit te breiden met extra lagen, zoals lyrics, scores, trivia en gitaarakkoorden. Deze lagen konden dan getoond worden terwijl de muziekvideo speelt.

Er was een presentatie waarin het volgende doel werd gesteld: spotify the sciences. Door het delen van verhalen kan meer onderzoek gedaan worden, dus deel de kennis met de wereld. Dat was the bereiken door bibliotheken, archieven en musea te verbinden, data delen makkelijk te maken, primaire data persistent beschikbaar te maken, een corpus moet clickable zijn (eenvoudig downloaden/gebruiken van hele selectie) en collaborative research moet beter ondersteund worden. Allemaal zaken waar iedereen het vast over eens is, maar wat toch lastig te bereiken zijn.

Er was een heel gepassioneerde presentatie van Annika Hinze: The challenge of creating geo-location markup for digital books. Leuk om naar te luisteren omdat de presentatrice duidelijk er heel enthousiast over was. Het ging over Literacy tourism (het boek lezen op de plaats waar het over gaat) en vooral over de problemen die overkomen moeten worden om de data te verkrijgen: welke soort kaart gebruik je? Het detailniveau is niet altijd hetzelfde namelijk en moet passen bij het boek. De hiërarchie in het verhaal is ook belangrijk. Soms gaat het hele verhaal over een bepaalde plek (bijv. een tuin), dit kan je dan aangeven als een gateway. Daarna gaat het verhaal over specifieke plekken binnen die plek (De Chinese tuinen), die je aangeeft als area. Ook kan er beschreven worden hoe je van een plek naar een andere plek loopt (bijv. van de Chinese tuinen naar de waterval), dit wordt aangegeven met een path. Tenslotte kan een specifieke plek worden beschreven (bijv. onder de waterval), dit is dan een point. img_1394
Om dit allemaal goed te kunnen doen moet de markup met de hand gedaan worden. Als een specifieke plek in het verhaal genoemd wordt, gaat vaak de tekst hierna ook nog over die plek of houdt daar verband mee. Omdat het handwerk is, moeten duidelijke instructies worden gegeven aan de personen die het uitvoeren om zoveel mogelijk consistente resultaten te krijgen.
Soms is het gewoon niet duidelijk om welke locatie het gaat (te globaal aangeduid), soms is de locatie niet te vinden, soms wordt er alleen maar gepraat of gedacht over een locatie, en soms zijn het fictionele locaties (platform 9 3/4 uit Harry Potter). De beslissingen die genomen worden hierover tijdens het maken van de markup, moeten dan ook onderbouwd opgeslagen worden.

David Wilcox van DuraSpace hield een workshop over Fedora 4, wat interessant voor ons is aangezien we Fedora 3 gebruiken in onze nieuwe repository infrastructuur en de overstap naar Fedora 4 een kwestie van tijd is. Fedora staat voor Flexible Extensible Durable Object Repository Architecture en is zoals gezegd de basis van onze repository infrastructuur. Het verschil tussen Fedora 3 en 4 is dat de laatste nog meer gebruik maakt van open standaarden, het alles opslaan als een web resource waarvan alle “eigenschappen” (properties zoals metadata) opgeslagen zijn als RDF triples. Hierdoor is Fedora 4 Linked Data Platform compatible. Hiernaast gebruiken ze open standaarden zoals Memento (voor versioning) en WebAccessControl (voor authorization, XACML wordt nog wel ondersteund).
Interessant is dat Fedora 4 echt terug naar de basis gaat; het gaat vooral om het duurzaam bewaren van de objecten en gerelateerde metadata en het heeft een API om objecten en metadata toe te voegen, lezen, wijzigen en verwijderen (CRUD), inclusief transactions en versioning. Alle andere zaken (zoals zoeken en afbeelden van objecten) worden uitbesteed aan andere componenten. Dit lijkt in eerste instantie nogal een mager systeem op te leveren wat eigenlijk niet veel kan. Maar op zich is die focus goed, want wat het wel doet, doet het als de beste. Andere componenten kunnen op een standaard manier gekoppeld worden aan Fedora 4. Ten eerste via de API. Ten tweede wordt bij elke gebeurtenis (event) binnen Fedora 4 een bericht uitgezonden, waarbij ze gebruik maken van de JMS standaard. Hier kunnen andere componenten naar luisteren en actie ondernemen als er een gebeurtenis is die hen interesseert. Ook kan bijvoorbeeld Apache Camel gebruikt worden om te luisteren naar de berichten, waarbij deze SOLR aanstuurt om de indexen bij te werken. Op deze manier is er een krachtige samenwerking mogelijk tussen componenten waarbij elk component doet waarin ie het beste is.
Zowel met Islandora en Hydra wordt nauw samengewerkt zodat deze componenten goed passen binnen Fedora 4.
In de pauze heb ik even met David Wilcox gepraat over Islandora en met name de CLAW. De CLAW is het project om de volgende generatie van Islandora te maken, die samen kan werken met Fedora 4 en Drupal 8. Hij wist niet precies wanneer de CLAW klaar zou zijn, maar wist wel te vertellen dat er een script zou zijn om makkelijk over te gaan naar de nieuwe versie en dat er gewerkt werd om dit nog makkelijker te maken.
Hierna hebben we nog gekeken naar de REST API die Fedora 4 gebruikt. Hier kan je ook zelf mee spelen op http://demo.fcrepo.org:8080/fcrepo/rest. Bedenk wel dat dit een test systeem is dat elke nacht opgeschoond wordt. Met behulp van SPARQL update kunnen de RDF triples gewijzigd worden. Voor meer informatie zie introducing-fedora-4 en hands-on-with-fedora-4.

Een andere interessante presentatie ging over Stylometrie (Jan Rybicki: Pretty Things Done with (Electronic) Texts: Why We Need Full-Text Access). Stylometrie is het tellen van de telbare kenmerken van teksten. Dus bijvoorbeeld het tellen van woorden, maar niet alleen enkele woorden maar ook woordgroepen. Je kan stylometrie gebruiken om teksten met elkaar te vergelijken door de “afstand” (distance) tussen twee of meerdere teksten te bepalen. Hierdoor kan je achterhalen of een tekst door een bepaald persoon is geschreven, of je kan de chronologie in bepaalde werken van een auteur nagaan.
Je kan ook de wijziging van taalgebruik door de jaren heen zien van een bepaald auteur. Ook kan je zien hoe een vertaler invloed heeft op de stijl van het boek. Jan Rybicki is zelf vertaler en drukt tot zijn spijt nogal een stempel op de vertaling; zijn eigen stijl is duidelijk terug te zien.
Met stylometrie heb je veel teksten nodig. Helaas is het moeilijk om (legaal) aan de teksten te komen, vooral als het budget beperkt is. Teksten via OCR zijn niet geschikt vanwege het grote aantal fouten, al zal het verschil niet te zien zijn als tot 20% van de woorden foutief zijn. De presentator is dus erg voorstander van open access van teksten en verwees ook naar het idee van een vorige presentatie: spotify the sciences.

Hieronder nog enkele andere presentaties en workshops die ik nog kort wil noemen omdat ze apart, leuk of interessant waren.
Ten eerste was er een presentatie over een manier om muziek bij een video te suggereren door iemand van de TU Delft: From Water Music to ‘Underwater Music’: Multimedia Soundtrack Retrieval with Social Mass Media Resources (Cynthia C. S. Liem). Het bleek dat het bij een video vooral om het verhaal gaat en minder om het beeld bij de keuze van de muziek. Ze maakte gebruik van IMdb om een soortgelijke film te vinden en daarin stond dan een referentie naar de film muziek die via last.fm werd gevonden.

Een workshop over text mining was ook interessant: Text mining workflows for indexing archives with automatically extracted semantic metadata (Riza Batista-Navarro). Hierbij ging het over een manier om text mining te gebruiken om beter te kunnen zoeken. Als full-text search wordt toegepast kunnen sommige woorden een dubbele betekenis hebben (zoals bank voor geldzaken of om op te zitten) en dingen hebben vaak meerdere woorden die naar hetzelfde ding verwijzen (zoals bank en sofa). Hierdoor is full-text search minder geschikt om het juiste te vinden. Een oplossing hiervoor is om alleen de belangrijke woorden binnen een tekst te herkennen en van betekenis te voorzien: Named Entity Recognition. Er is een aantal benaderingen:
– dictionary-based: hierbij wordt een set van woorden gebruikt om de entities in de tekst te herkennen. Dit heeft als voordeel dat het simpel is en dat woordenlijsten beschikbaar zijn. Het nadeel is dat woordenlijsten groot zijn, maar niet compleet en de entiteiten overlappen elkaar soms.
– rule-based: hierbij wordt gebruik gemaakt van regular expressions. Bijv. woorden die met een hoofdletter beginnen zijn altijd namen of woorden die eindigen op land, weg of straat zijn altijd geografisch van aard. Iets ingewikkelder is contextual matching, waarbij de context van de woorden de betekenis geeft. Bijv. “Jan werkt bij de KLM”, waarbij “werkt bij” de relatie aangeeft tussen de naam van een persoon en een bedrijf. Het voordeel is dat de handmatig opgebouwde regels precies zijn, maar het nadeel is dat het domeinspecifiek is en een dure ontwikkeling.
– machine learning: hierbij is de computer geleerd hoe het entiteiten uit een tekst moet halen. Hierbij kan men onderscheid maken tussen supervised learning, waarbij veel voorbeelden (trainingsdata) nodig zijn, semi-supervised learning, beetje trainingsdata nodig, en unsupervised learning waarbij geen training data nodig is.
Hierna werd nog uitgebreid gesproken over Elasticsearch, een zoekmachine, die net als SOLR gebaseerd is op Lucene.

De conferentie werd afgesloten met een presentatie van Tony Veale: “Metaphors All the Way Down: The many practical uses of figurative language understanding”. Hij had het vooral over metaforen. Bijvoorbeeld over een bibliotheek waarin alle boeken die ooit geschreven zouden kunnen worden. Dus ook een boek wat een normaal boek lijkt, maar waarvan de laatste paar bladzijdes onzin bevatten, waardoor je eigenlijk niks aan het boek hebt. Zo’n bibliotheek, ook al zou die alle mogelijke boeken bevatten, zou niet zinvol zijn omdat je alleen met zekerheid kan zeggen of je het juiste boek hebt, als je het boek ook helemaal leest. Vandaar deze quote: “What makes a good library is not what you put into it, but what you don’t put into it.”
Verder had hij en zijn team onderzoek gedaan naar tweetbots die op basis van de inhoud van Digital Libraries, tweets schrijven op twitter. Daar kwamen soms hele verrassende uitspraken van de tweetbots uit, zoals:
“One does not simply walk hand-in-hand with violence.”
“Suspicions were once nurtured by informed investigators.”
Meer hiervan is te vinden op twitter onder @MetaphorMagnet, @MetaphorMirror@bestofbotworlds en de tweetbot die delen van ebooks tweet @horse_ebooks

De volgende TPDL conferentie is op Thessaloniki in Griekenland van 17 tot 21 september 2017, dus ik hou me zeker aanbevolen.

IIIF we could present images

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”:”http://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”:”http://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!

Behendig software-ontwikkelen

Software-ontwikkelen kan op vele manieren (watervalmethode, cowboy-coding, iteratief) maar de Agile-software-ontwikkelingsmethoden zijn de laatste jaren in populariteit gestegen. In dit blog beschrijf ik wat Agile-software-ontwikkeling nu eigenlijk is, wat de verhouding met SCRUM is en hoe we het gebruiken binnen het project “Voorbereiding nieuwe repository infrastructuur”. Het projectteam heeft ook een tweedaagse cursus gedaan om te leren wat Agile nu inhoudt en hoe het te gebruiken is.

Agile-software-ontwikkeling is een conceptueel raamwerk voor het uitvoeren van software-ontwikkelingsprojecten als alternatief voor traditionele starre praktijken.

Agile werkt met iteraties, waarbij elke iteraties eigenlijk een miniatuurproject op zichzelf is die in een korte periode uitgevoerd wordt. Dit miniatuurproject omvat planning, analyse, ontwerp, bouw, testen en documentatie. Dit miniatuurproject levert altijd iets bruikbaars op; dat kan in de vorm van een webpagina, een procedure, een prototype, een mockup, een functie of een deel van een werkend programma zijn.

Bij Agile-software-ontwikkeling ligt de nadruk op directe communicatie, bij voorkeur persoonlijk contact. Een Agile team moet op 1 locatie werken, liefst zelfs binnen een ruimte, waarbij het team in elk geval bestaat uit mensen die het product definiëren en mensen die de ontwikkeling doen. Tijdens de cursus hebben we geleerd hoe belangrijk communicatie is en hoeveel makkelijker directe communicatie gaat. Of eigenlijk hebben we zelf meegemaakt met oefeningen hoe lastig communiceren is als je niet direct contact hebt. Een van de oefeningen was om een tekening na te tekenen, waarbij de tekenaar de originele tekening niet zag. Communicatie met degene die de tekening wel voor zich had, ging door middel van briefjes. Hiermee leerden we hoe specifiek je moet zijn met communicatie, dat woorden altijd anders geïnterpreteerd worden en dat directe feedback cruciaal is.

Natuurlijk gaat het bij Agile-software-ontwikkeling niet alleen om de directe communicatie, maar heeft het meerdere aspecten. Om het hoe en waarom van deze aspecten beter te kunnen uitleggen, een korte geschiedenis van de Agile-software-ontwikkeling.

De geschiedenis van Agile-software-ontwikkeling begon midden jaren 90 als onderdeel van een reactie op “zwaargewicht”-methoden. Deze methoden zijn zwaar gereguleerd, detail-gestuurd en maken gebruik van waterval-ontwikkelmodellen. Deze modellen werden als bureaucratisch, traag en bekrompen ervaren en belemmeren de creativiteit en effectiviteit van ontwikkelaars. Hierdoor ontstaat er een aantal nieuwe methoden van software-ontwikkeling, zoals DSDM, SCRUM, Crystal Clear, Extreme Programming, ASD en FDD. Al deze nieuwe methoden hebben een aantal waarden gemeen. Deze waarden werden in 2001 in het Agile Manifesto vastgelegd en ondertekend door een groot aantal software ontwikkelaars.

Manifest voor Agile Software Ontwikkeling (vertaalde versie)

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we:

  • Mensen en hun onderlinge interactie boven processen en hulpmiddelen
  • Werkende software boven allesomvattende documentatie
  • Samenwerking met de klant boven contractonderhandelingen
  • Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.

Het Agile Manifesto is gebaseerd op de onderstaande 12 principes:

  • Klanttevredenheid door frequente, snelle levering van bruikbare software
  • Regelmatig aanbod van nieuwe werkende software
  • Voortgang wordt afgemeten a.d.h.v. werkende software
  • Wijziging van doelstellingen zijn welkom, zelfs laat in het proces
  • Nauwe samenwerking op een dagelijkse basis tussen ontwikkelaars en hun belanghebbenden
  • Direct persoonlijk contact als beste vorm van communicatie
  • Projecten worden opgezet rondom gemotiveerde individuen, en die moeten dan vertrouwd worden
  • Voortdurende aandacht aan technische hoogstandjes en goed ontwerp
  • Eenvoud is essentieel
  • Zelf-organiserende teams
  • Voortdurende aanpassing aan veranderende omstandigheden

In 2005 werd er nog een addendum geschreven aan het Agile Manifesto.

Declaration of Interdependence

“We …

  • increase return on investment by — making continuous flow of value our focus.
  • deliver reliable results by — engaging customers in frequent interactions and shared ownership.
  • expect uncertainty and manage for it through — iterations, anticipation and adaptation.
  • unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • boost performance through — group accountability for results and shared responsibility for team effectiveness.
  • improve effectiveness and reliability through — situationally specific strategies, processes and practices.

Dus wat is Agile nu eigenlijk:

  • Adaptief
    gericht op snel aanpassen aan de veranderende werkelijkheid, dus wanneer het moeilijk is om de toekomst exact te omschrijven en te plannen (heeft veel gemeen met RAD methoden)
  • Timeboxed
    Agile neemt de timebox letterlijk (kort, hooguit enkele weken)
  • Klant centraal
    De klant is onderdeel van het team. Na elke iteratie wordt voorgang besproken en de prioriteiten heroverwogen
  • Product als doel
    Voortgang wordt gemeten aan de hand van werkende producten
  • Communicatie
    Communicatie is heel belangrijk en gebeurt op persoonlijk nivo. Rapporten zijn geen communicatiemiddel.

Maar binnen de UBL maken we toch gebruik van de PRINCE2 methodiek? Betekent dit dat Agile werken en werken met PRINCE2 niet samengaan? Dat deze twee methodes elkaar bijten?
Nee, ze bijten elkaar niet, maar ze hebben wel verschillende doelstellingen. PRINCE2 is een projectmanagement methode, Agile is een software-ontwikkelingsmethode. Binnen het project “Voorbereiding nieuwe repository infrastructuur” worden beide methodes gebruikt naast elkaar. SCRUM (een Agile methode, hierover later meer) als de software-ontwikkeling en PRINCE2 als project management methode. Veel kernwaarden komen overeen bij deze twee methoden, alleen worden ze anders uitgewerkt. Het is echter goed mogelijk (en dat doen we dan ook) om binnen een PRINCE2 project de software ontwikkeling op een Agile manier uit te voeren.

We gebruiken SCRUM als Agile-software-ontwikkelingsmethodiek binnen het project “Voorbereiding nieuwe repository infrastructuur”. SCRUM werkt met een multidisciplinair team dat in korte sprints producten oplevert. Deze producten zijn meestal een aantal gerelateerde functionaliteiten binnen de repository infrastructuur. De sprint duurt bij ons 2 weken, niet langer maar ook niet korter.

De requirements die nog geïmplementeerd moeten worden, zijn beschreven in het product backlog. Deze requirements zijn geschreven in de vorm van een user story, zodat deze begrepen kunnen worden door alle teamleden en niet te technisch zijn. Aan de start van een nieuwe sprint wordt uit de items in de product back log de sprint backlog gemaakt. Dit gebeurt in een overleg tussen het team en de product owner. Er wordt een aantal items gekozen die de hoogste prioriteit hebben en binnen 2 weken te implementeren zijn.scrum-overview

Na elke sprint is er een potentially shippable product increment, oftewel een product dat echt aan de klant getoond kan worden.

Elke werkdag wordt er ook een scrum-meeting van 15 minuten gehouden. Hierin beantwoordt elk teamlid de volgende vragen:

  • Wat heb je gedaan?
  • Wat ga je doen?
  • Wat zijn je problemen?

Natuurlijk is er nog veel meer te vertellen over Agile-software-ontwikkeling en in het bijzonder de SCRUM methodiek. Maar voor deze blog laat ik het hier bij, maar vragen mag je natuurlijk altijd stellen (bij voorkeur via directe communicatie!).

SWIB14

Begin december 2014 werd SWIB14 gehouden in Bonn, Duitsland. Dit is een conferentie over het Semantisch Web in bibliotheken, die dit jaar over Linked Open Data ging.
Linked Open Data is een manier om gestructureerde data te publiceren op zo’n manier dat de data met elkaar verbonden is, vrij toegankelijk is (open) en op een betekenisvolle manier bevraagd kan worden. Linked Open Data maakt gebruik van technieken als HTTP, URI en RDF.
Wat bovenstaande precies inhoudt en ook hoe het toe te passen is, daar ging de conferentie over.
De conferentie zelf was 2 dagen, maar de dag ervoor werden er workshops gegeven. Ik ben naar de workshop “Introduction to Linked Open Data” geweest:
Het internet draaide eerst helemaal om computers (computers met elkaar verbonden), later om documenten (websites), maar binnen het semantische web draait eigenlijk alles om dingen. Tja, dingen, en wat zijn dat dan die dingen, vraag je je misschien af. Nou, dat kan van alles zijn; boeken, documenten (dus ook weer websites), personen, maar ook concepten of ideeën.
Over die dingen kan je dingen beweren, zoals die auto is rood of dat boek is geschreven door “Douglas Adams”. De dingen zijn dan “die auto” en “dat boek”, maar ook “rood” en “Douglas Adams”. Een bewering wordt gedaan in de vorm subject-predicate-object, ook wel triple genaamd. Bijvoorbeeld bij de bewering “die auto is rood” is “die auto” het subject, “is” is het predicaat en “rood” is het subject.
Als je uitspraken over dingen wilt doen en die met anderen wilt delen, moet je die dingen wel uniek kunnen identificeren. Dit doe je met behulp van URI’s. Maar ook de predicaten worden met URI’s aangeduid. Maar dat is niet voldoende; je moet ook afspraken maken wat wat betekent en dat een en hetzelfde ding of predicaat dezelfde URI heeft. Hiervoor is het nodig om een vocabulary (woordenschat) te gebruiken.
Er zijn verschillende vocabularies beschikbaar, zoals FOAF, DBpedia, DC terms. En voor bijna elk ding is wel een vocabulary te vinden, bijvoorbeeld via Linked Open Vocabularies.

Linked Open Data in de praktijk
Linked Open Data kan op verschillende manieren genoteerd worden, zoals Turt> le, N3, RDFa, RDF/XML en JSON-LD). Turtle is de meest simpele manier waar vrij duidelijk te zien is dat alles in triples (subject-predicate-object) beschreven kan worden:

<isbn:0330258648> <httpː//purl.org/dc/elements/1.1/creator> "Douglas Adams" .
<isbn:0330258648> <httpː//purl.org/dc/elements/1.1/title> "The Hitchhiker's Guide to the Galaxy" .

Hier zijn de drie delen goed te zien. Let op de punt op het eind.
Als meerdere statements over hetzelfde ding geschreven moeten worden, dan gaat het vervelen om steeds weer het subject in zijn geheel op te schrijven. Ook het gebruikte vocabulair kan korter (of eigenlijk eenmalig) opgeschreven worden:

@prefix dc: <httpː//purl.org/dc/elements/1.1/>
<isbn:0330258648> dc:creator "Douglas Adams" ;

dc:title "The Hitchhiker's Guide to the Galaxy" .
De titel van het boek is nu in het Engels, terwijl dat niet duidelijk gemaakt is. Bovendien willen we wellicht ook de Nederlandse titel kwijt:

@prefix dc: <httpː//purl.org/dc/elements/1.1/>
<isbn:0330258648> dc:creator "Douglas Adams" ;

dc:title "The Hitchhiker's Guide to the Galaxy"@en,
"Het Transgalactisch liftershandboek"@nl .

 

Wat is nu het grote voordeel van linked open data?

  • verbonden: het is linked open data. Als de dingen met een URI benoemd worden, kan de data makkelijk met elkaar verbonden worden omdat duidelijk is dat over hetzelfde ding gesproken wordt;
  • open: de data is vrij toegankelijk. Niet alleen omdat het niks (of in elk geval weinig) kost, maar ook omdat er geen restricties op het gebruik zitten;
  • eenduidig: doordat er gebruik wordt gemaakt van URI’s, kunnen de dingen eenduidig benoemd worden, ook als ze in praktijk dezelfde naam hebben. Bijvoorbeeld bij het woord “venus” kan de planeet, de godin, de plaats (in Florida, Roemenie of Texas), de film, het lied, de popgroep, het scheermes, het schip of de tennister bedoeld worden. Echter, elk van deze dingen heeft een eigen URI;
  • betekenisvol: door linked open data krijgt data betekenis, zelfs meer dan op het eerste gezicht lijkt. Linked open data maakt gebruik van vocabularies (een dataset die betekenis geeft aan bepaalde begrippen). Door deze vocabularies te gebruiken krijgt de data zelf al meer betekenis, niet alleen voor mensen maar ook voor computers die de data interpretteren. Bijv. als het Schema vocabulary gebruikt wordt om aan te geven dat Henk werkt bij de Universiteit Leiden, dan is niet alleen daarmee bekend dat Henk werkt bij de Universiteit Leiden, maar ook dat Henk blijkbaar een Persoon (een bepaalde klasse binnen Schema) is en dat “Universiteit Leiden” een Organisatie (een andere Klasse binnen Schema) is. Door dus dat vocabulary te gebruiken is er meer betekenis gegeven aan de data;
  • meerwaarde: doordat de data open, verbonden, eenduidig en betekenisvol is, krijgt de data meerwaarde. Niet alleen voor de producent van de data, maar ook voor de consument van de data. En daarbij kan de producent optreden als consument van andere Linked Open Data;
  • taalonafhankelijk: linked open data werkt met dingen in plaats van met woorden. Elk ding, of eigenlijk concept, kan in meerdere talen beschreven zijn. Zoeken op “Den Haag” levert dan ook resultaten voor “The Hague” en “’s Gravenhage” op omdat deze alle zijn gekoppeld aan dezelfde URI.

Natuurlijk werkt Linked Open Data alleen goed als gebruik gemaakt wordt van dezelfde vocabularies. Dit gebeurt voor een deel, maar er zijn ook wel weer een groot aantal vocabularies beschikbaar (zie LOV). Deels worden termen uit de verschillende vocabularies (impliciet of expliciet) weer met elkaar verbonden.

Er waren op SWIB14 diverse presentaties over het gebruik van Linked Open Data. Hieronder een verslag van de naar mijn mening interessantste:

Tom Grahame van de BBC sprak over hoe de BBC Linked Open Data gebruikt. Ze begonnen hiermee met het WK van 2010 en daarna de Olympische Spelen van 2012. Elke atleet was een entiteit (ding) en had een eigen pagina die geheel werd opgebouwd uit Linked Data. Hierdoor had ook een minder bekende atleet een eigen pagina, die qua opbouw gelijk was aan die van een zeer bekende atleet, gevuld met informatie. Hiervoor hoefde een redacteur niet de pagina te maken, maar werd alleen data toegevoegd (ook uit andere bronnen). Voor het nieuws zijn ze nu bezig, maar dat is een stuk lastiger omdat het veel diverser is. Voor de ontologies (een formeel gebruikt woord voor vocabularies) hebben ze een eigen website, evenals een website om alle dingen te beschrijven.
Ze gebruiken hun eigen ontologie omdat het lastig is (maar wel het beste!) om een bestaande ontologie te gebruiken.
Alle linked data wordt in een triplestore opgeslagen en daar liggen diverse lagen overheen zodat de data beschikbaar wordt gesteld aan hun eigen apps maar ook aan derde partijen.

De Pina Bausch Foundation heeft een digitaal archief gemaakt van de danseres/choreografe Pina Bausch. Deze danseres had tijdens haar leven al zelf een digitaal archief bijgehouden. De data is als Linked Data beschikbaar gemaakt en gebruikt verschillende vocabularies zoals purl.orgDC termsFOAF en SKOS. Op basis hiervan is ook een iPad app gemaakt.

Wikidata had ook een interessante presentatie. Wikidata valt onder Wikimedia, waar ook weer Wikipedia onder valt. Wikipedia bevat heel veel data, maar heeft ook een aantal uitdagingen: ze zijn afhankelijk van vrijwilligers en daardoor zijn er veel verschillen tussen talen. Je zou zeggen dat de meeste informatie beschikbaar is in het Engels. Maar dat is niet zo: slechts 50% van de data op Wikipedia is in het Engels beschikbaar. Helaas zijn andere talen slechter vertegenwoordigd. Wikipedia heeft wel heel veel data, maar is niet altijd toegankelijk. Sommige vragen zijn niet te beantwoorden, terwijl de data wel beschikbaar is op Wikipedia. Wikidata probeert dit probleem op te lossen door de data uit Wikipedia op een soort Linked Open Data manier te beschrijven. Deze data wordt weer binnen Wikipedia gebruikt in bijvoorbeeld de informatieboxen aan de rechterkant van een Wikipedia pagina (zie bijvoorbeeld hier). De data in WikiData is veel gestructureerder, meertalig en met vaste verwijzigingen (URI’s) naar andere bronnen. Ook probeert men voor alle data die toegevoegd wordt een bronvermelding te doen.

Europeana had een presentatie over problemen bij meertaligheid. Ze probeerden een deel van de problemen op te lossen met een nieuwe datamodel gebaseerd op SKOS. Ze hadden voor verschillende termen de vertalingen in verschillende talen en die onderling gerelateerd.

BIBFRAME is de MARC21 opvolger, of althans dat zou het moeten zijn volgens Eric Miller van het bedrijf Zepheira. Bibliotheken hebben veel goede data en zijn op veel punten ver vooruit (“libraries are credibility engines”), maar de data die ze hebben is niet zichtbaar op het internet. De data moet meer naar buiten gebracht worden, bijvoorbeeld via Libhub. We spreken nu niet op een manier die het web begrijpt, maar dat zouden we wel moeten doen. Schema.org is een nieuwe manier om op het web te komen, maar niet dé manier. Links zijn dat. We moeten de search engines gebruiken om gevonden te worden. Niet door te vragen aan de search engines of ze ons en onze data willen opnemen, maar door ze zelf te gebruiken. Met BIBFRAME zou dit mogelijk moeten worden, het is een sociaal data model. Helaas is BIBFRAME nog in de draft/test fase en wordt nog niet echt door bibliotheken gebruikt.

De eindpresentatie werd gedaan door Richard Wallis van OCLC. Hij herhaalde nogmaals dat de bibliotheek niet gelinkt was aan het web: “Why catalog? So we can find things. Why are we on the web? So todays users can find our resources”. Wat bibliotheken moeten doen volgens hem is gebruik gaan maken van linked data met Schema.org als vocabulair. Met Hadoop kan makkelijk data geconverteerd worden. We moeten niet meer denken in records, maar focussen op entiteiten. WorldCat loopt daar volgens hem in voorop.

Natuurlijk waren er nog veel andere interessante presentaties, zoals over alles annoteren, SKOS, KOS, Microtask Crowdsourcing, d:swarm (demo.dswarm.org), ElasticSearch en nog veel meer.

AppsWorld

Voor de AppsWorld conferentie was ik van 19 tot en met 23 oktober in London. Eerst een paar dagen met vrouw en kinderen Londen bekeken: Tower of London (de zes raven leven nog), Big Ben, London Eye, Trafalgar square, National Gallery, de wisseling van de wacht en veel tubes.

Dinsdagochtend vlogen mijn vrouw en kinderen weer naar Nederland en ik ging naar de AppsWorld conferentie die gehouden werd in Earls Court Exhibition Centre. AppsWorld is een tweedaagse conferentie en expositie die al 4 jaar wordt gehouden in Europa en Noord-Amerika. Het gaat over apps en app eco-systemen op elke manier: apps voor mobiel (Android, iOS), apps voor televisie, apps voor in de auto, games, HTML5, marketing, betalingen en nog veel meer.

Naast veel bedrijven die hun apps en spullen laten zien, zijn er ook workshops en presentaties. Ik heb er een paar gevolgd waarover ik hieronder meer zal vertellen. Maar nog eerst wat cijfers: ruim 8000 bezoekers, 250 bedrijven en meer dan 200 sprekers (waaronder Steve Wozniak). Deze sprekers werden per track ingedeeld, zoals API strategies, HTML5, Developer World, Tech World, Droid World. Sommige tracks daarvan waren alleen toegankelijk met premium passes.

Dinsdagmorgen begon met verschillende openingstoespraken. Van verschillende sprekers die dag en woensdag ben ik de volgende interessante/opmerkelijke feiten of meningen te weten gekomen:

Meerdere sprekers dachten dat HTML5 steeds meer binnen een mobiele app gebruikt zou gaan worden. Deels komt dit door het feit dat er 2 grote en verschillende mobiele platformen zijn (iOS en Android) en het ontwikkelen voor 1 platform (HTML5) is goedkoper dan ontwikkelen voor 2 platformen.  Verder is ontwikkelen voor Android duurder dan voor iOS of ontwikkelen in HTML5. Dit komt voor een deel door de fragmentatie binnen Android. Maar, de klant verwacht wel een “echte” app die uit een App Store komt. Aan die wens is dus tegemoet te komen door een “echte” app als schil te gebruiken voor de HTML5 app (net zoals wij doen binnen de “Leiden Univ” app).

Naast HTML5 waren er nog andere oplossingen om voor meerdere platformen tegelijkertijd te ontwikkelen. Microsoft had een praatje over crossplatformdevelopment met hun Azure platform. Hiermee is een crossplatform app ontwikkeld voor een rugby team wat er indrukwekkend uitzag (zowel de app als het team). AppMachine heeft een andere oplossing, waarmee je met “building blocks” een crossplatform app in elkaar zet. Dit Nederlandse bedrijf (in de “Fryslân Valley”) was goed vertegenwoordigd en had een mooi product, waarmee je op basis van een website een app kon laten genereren.

De betaalmodellen van apps veranderen ook: het freemium model wordt steeds populairder. 25% van de Android apps en 45% van de iOS apps is nog betaald, de rest is gratis of freemium. Android ontwikkelaars verdienen vooral aan contract werk, niet aan de verkoop van apps. Ook is er nu een mogelijkheid om via Amazon reseller te worden en daarmee geld te verdienen. Paypal had ook een API om binnen een app geld over te maken.

Er wordt steeds meer gezocht naar technologie die niet in de weg zit. Hiervan is Google Glass een duidelijk voorbeeld. Dit is echt bedoeld om de hele dag te gebruiken. Tijdens het praatje over Google Glass bleek het vrij simpel of juist heel moeilijk te zijn om een app te maken voor Google Glass. Dit kwam omdat er 3 manieren zijn om dit te doen, die ook nog ’s door elkaar lopen. Het makkelijkst is om de mirror API te gebruiken, waarbij je eigenlijk op je eigen server bepaalde data klaar zet die via een REST service opgehaald wordt. De mogelijkheden zijn beperkt. Je kan ook de Android Foundation gebruiken, wat je ook gebruikt bij programmeren voor Android. En dan heb je nog de GDK, maar die is nog niet klaar.

De marketing van apps kwam ook aan bod; er was een presentatie van de (vervelende) CEO van ooVoo over SoLoMo. ooVoo heeft 80 miljoen geregistreerde gebruikers, dus ondanks die CEO doen ze toch iets goed.

Over de gebruikservaring van mobiele apps was een heel interessante presentatie van de BBC. Daarin werd duidelijk dat ze eerst veel UX aanpassingen deden en dat ze daar nu op terugkomen omdat het veel extra werk oplevert. Wel vonden ze het belangrijk om een duidelijk thema of terugkerend element te hebben binnen hun mobile apps. Dat deden ze nu door (subtiel) kleurgebruik en 1 custom element. Verder gebruiken ze veel web content binnen hun apps, zoals al eerder aangegeven werd. Het voordeel is dat de content dan altijd up-to-date is. Verder hadden ze als motto: de gebruiker wil de app gebruiken, dus zit hem/haar niet in de weg.
In een paneldiscussie werd daarna duidelijk dat men dacht dat de interactie steeds meer zou gaan naar praten tegen de computer/mobiel. De huidige generatie heeft daar nog wel problemen mee (bang voor reactie van anderen), maar het bleek dat dat niet meer speelde bij de jongere generatie. Ook dacht men dat bij scherminteractie gestures steeds belangrijker worden.

Het interview met Steve Wozniak was erg druk bezocht maar wel interessant. Hij is een echte geek en dat laat ie ook duidelijk merken. Zo heeft ie 2 horloges om, een iPod nano en een Nixie watch. Hij denkt dat smart watches de toekomst zijn, waarbij ze aan de binnenkant open kunnen klappen zodat gebeld kan worden. Ook zou het horloge continu mee kijken en je (als een goede vriend) opmerkzaam moeten maken op dingen; als het een taartenwinkel ziet je laten weten dat je nog een taart moet kopen, maar als er een mooi meisje voorbij komt dit ook laten weten. Techniek moet alles zo makkelijk mogelijk maken en wordt steeds persoonlijker; “who do you ask life’s questions? It starts with G-O and it is not God”

Het was een leuke tijd waarin ik veel gezien en geleerd heb. De nadruk lag vooral op Android en iOS, maar Windows Phone en Blackberry waren ook aanwezig. Wat betreft marktaandeel stellen die (nog) niet / niet meer zoveel voor binnen mobiele apparaten.

Het web is niet meer

Het web is niet meer. Althans, niet meer zoals het vroeger was.

Vroeger, toen moesten er allemaal trucs uit gehaald worden om ervoor te zorgen dat een website op verschillende (versies van) browsers het goed deed en er goed uitzag. Vroeger, eind jaren 90 en begin 2000, toen de browser wars in volle gang waren en je als sitebouwer moest weten welke feature op welke versie van welke browser bestond. Vroeger, toen je meer tijd kwijt was om een website er op elke browser goed uit te laten zien dan met het hele design en ontwerp van de site zelf. Vroeger, toen iedereen alleen nog maar een browser had op zijn PC. Of hooguit een WAP browser op je mobiele telefoon die je niet gebruikte omdat het zo traag was en de sites zo slecht.

Vroeger was alles beter….

De tijden zijn veranderd. Het web verandert mee. Het web zoals het was, is niet meer(!)

Het bouwen voor een versie van een browser behoort tot het verleden. Geen browser sniffing meer nodig, dat zou iedereen wel moeten beseffen. Tegenwoordig is het voldoende om te checken op features.

Nu zijn er heel andere problemen, die gelukkig gepaard gaan met goede oplossingen. En als alle sitebouwers weten en gebruik maken van deze oplossingen, dan ziet de toekomst van het web er heel zonnig uit.

Welke problemen zijn er dan? De meeste browsers houden zich goed aan de W3C standaarden. Er zijn er wel die voorop lopen en features ingebouwd hebben die nog niet tot een (officiële) W3C standaard behoren, maar dat zijn kleine problemen die met wat extra typen op te lossen zijn (bijvoorbeeld het stylesheet element ‘column-count‘ heet in FireFox ‘–moz-column-count’ en in WebKit browsers zoals Chrome en Safari ‘–webkit-column-count’. Die moeten dus in een stylesheet alle drie vermeld worden, wil het op de meeste browsers goed werken).

Het grote probleem van vandaag (en morgen) is dat je website niet alleen meer bekeken wordt op een PC met een scherm van 1024×768 of 1366×768 (meest populair een paar jaar terug en in 2013 nog goed voor 33% van de PC’s) of nog groter (nu ruim 40% van de PC’s), maar ook steeds meer op mobiele apparaten. Deze hebben vaak schermen niet breder dan 320 points (nee, geen pixels!). En, wat vaak vergeten wordt, ze werken niet met een muis! Dat betekent dus dat de links en knoppen die gebruikt worden eigenlijk minstens 40 points breed en hoog moeten worden om goed aantapbaar te zijn.

Gelukkig zijn er technieken beschikbaar om met deze problemen om te gaan: HTML5, CSS3 en JavaScript. Samen bieden ze diverse mogelijkheden om op basis van afmetingen en resolutie van het scherm het design van de site aan te passen, zodat dezelfde site op een PC met groot scherm of op een mobiel met een (relatief) klein scherm goed leesbaar is en goed werkt. Een webdesign benadering die gebruik maakt van deze mogelijkheden is Responsive webdesign. Deze term is bedacht door Ethan Marcotte in 2010. Het houdt in dat de website zich aanpast aan de omgeving waarin deze getoond wordt met behulp van flexibele grids, flexibele afbeeldingen en CSS3 media queries.

Responsive webdesign werkt met relatieve eenheden (percentages en ems) in plaats van absolute eenheden als pixels. Hierdoor wordt de breedte en hoogte van de elementen aangepast aan de breedte (en eventueel hoogte) van het scherm. Zo kunnen bepaalde elementen bij een breed scherm naast elkaar staan en bij een smaller scherm onder elkaar door gebruik te maken van float in het stylesheet.

Ook werkt Responsive webdesign zoals gezegd met CSS3 media queries. Hiermee kunnen stijlen afhankelijk gemaakt worden van het medium dat gebruikt wordt. Dus voor een scherm kleiner dan 400 points breed kunnen stijlen gedefinieerd worden die bepaalde plaatjes verkleinen of bepaalde elementen onzichtbaar maken.

De ideeën en de technieken zijn er dus, maar het vraagt wel een hele andere manier van denken over een website. Mijn mening is dat er niet begonnen moet worden met hoe een site er uit moet zien, maar welke content getoond moet worden. Dus ga uit van de content. Hier biedt HTML5 ook hele goede ingangen omdat hier niet meer de presentatie voorop staat, maar de betekenis. Oftewel je kan in HTML5 aangeven dat iets belangrijk is, of dat het een header, footer, navigatie of een figuur is, maar je doet geen uitspraak over de presentatie in de HTML (dus geen <B> om iets belangrijk en dikgedrukt te krijgen). De presentatie wordt geheel geregeld door stylesheets en eventueel JavaScript.

Content en semantiek kunnen dus geheel gescheiden worden van de presentatielaag. Dit heeft grote voordelen bij het aanpakken van het grote probleem van vandaag (en morgen): veel verschillende schermgroottes en resoluties. Met JavaScript kan de interactielaag aangepast worden aan de mobiele apparaten. Deze werken immers niet met een muis! Je kan dus niet gebruik maken van het feit dat de gebruiker zijn muis over een element op je website beweegt, maar je kan wel weer gebruik maken van allerlei andere interacties die niet met een muis kunnen, zoals vegen of tappen met 2 vingers.

De scheiding tussen content/semantiek, presentatie en interactie heeft nog meer voordelen:

  • Zoekmachines kunnen beter indexeren, omdat ze verschil zien tussen de echt belangrijke teksten, en teksten voor navigatie en minder belangrijke teksten (zogenaamde aside)
  • De inhoud (content) is makkelijk aan te passen door iemand zonder veel verstand van HTML
  • Een andere presentatie vorm is makkelijker te verwezenlijken
  • De interactie is aan te passen aan nieuwe mogelijkheden, zoals bijvoorbeeld voorlezen of stembesturing

Responsive webdesign gaat uit van de website in zijn geheel, waarbij elementen verkleind of uitgezet worden als het scherm te klein is voor alles. Dit heeft als nadeel dat alle HTML, plaatjes en javascript geladen moeten worden, ook op een mobiel met slechte netwerk verbinding. Een andere benadering is mobile first: ontwerp/bouw voor het kleinste scherm (een mobiel) en voeg elementen toe naarmate het scherm groter wordt. Dit heeft als nadeel dat de wat minder capabele browsers (oude versies of bij mensen die bijvoorbeeld javascript uit hebben staan) alleen de mobiele versie zien.

Ik denk dat een derde manier de beste oplossing is: ga niet uit van de hele site en verklein of laat weg (responsive webdesign) en ga ook niet uit van het kleinste scherm (mobile first), maar ga uit van de inhoud: content first. Hoe zou dat kunnen werken:

  • Bij ontwerp en bouw wordt uitgegaan van de content
  • De content die belangrijk is, wordt eerst in betekenisvolle blokken opgebouwd. Hier kan prima HTML5 voor worden gebruikt. Content die niet altijd (dus niet op elk apparaat) getoond wordt, wordt nog buiten beschouwing gelaten. Denk hierbij aan aside blokken of sommige navigatie blokken. De volgorde van de blokken moet logisch zijn, maar de correcte plaatsing op het scherm gebeurt later.
  • Plaatjes of video kunnen ook geplaatst worden, maar niet op hele hoge resolutie.
  • Om de content nog toegankelijker te maken zou gebruik kunnen worden gemaakt van microdata en ARIA attributen
  • Met stylesheets en media queries wordt de presentatie van de blokken gemaakt voor verschillende schermgroottes. Hier kunnen de technieken van responsive webdesign goed gebruikt worden. Er wordt bij deze stap al rekening gehouden met extra content, zoals asides.
  • Met javascript kan nu de extra inhoud en/of betere versies van plaatjes of video ingeladen worden. Bijvoorbeeld, er kan op een groot scherm een aside geladen worden. Ook kunnen de hoge resolutie versies van plaatjes ingeladen worden, als het doelsysteem dit toelaat (denk aan of het scherm het aan kan en of de netwerkverbinding goed genoeg is)
  • Met javascript kan een extra interactie laag aangebracht worden, bijvoorbeeld voor ondersteuning van swipen of tappen met meerdere vingers voor mobiel, maar ook voor mouseovers voor de desktop.

Alle extra content kan met technieken als media queries en javascript geladen worden, zodat webbrowsers die daar geen capaciteit voor hebben, er ook niet mee belast worden.

Content first vereist een andere manier van websites ontwerpen en bouwen. Maar de technieken zijn voor een groot deel bij de meeste webbrowsers al beschikbaar. Oudere webbrowsers worden ook goed getoond, maar hebben wellicht minder functionaliteit. Het belangrijkste, namelijk de content, wordt goed afgebeeld.

Op naar een zonnige toekomst!

PS: na het schrijven van deze blog kwam ik erachter dat de term “content first” al eerder werd gebruikt. Zeker de moeite waard om ook deze artikelen te lezen, waarbij de invalshoek net anders is:
http://www.frankwatching.com/archive/2012/10/09/van-mobile-first-naar-content-first/
http://www.frankwatching.com/archive/2013/08/16/content-first-van-responsive-design-naar-dynamische-website/
http://www.marketingfacts.nl/berichten/content-first-bij-de-nieuwe-responsive-website-van-ing-commercial-bank
http://www.lukew.com/ff/entry.asp?1430