Fleet

Onderstaande column verscheen eerder in de rubriek IP Lingo van het blad IP.

Deze rubriek gaat over nieuwe woorden en begrippen in de informatiewereld. Tussen het moment van schrijven en de publicatiedatum zitten een paar weken. Dat is in onze snelle wereld een hele tijd.  Een begrip kan in die periode oud nieuws geworden zijn, of een algemeen ingeburgerd begrip. Of dat ook opgaat voor fleet is voor mij een vraag en voor u als lezer een weet. Toen ik vanochtend (half november) een rondje maakte langs een aantal bekenden kon niemand me in ieder geval vertellen wat fleets zijn. Ze bestaan op het moment dat ik dit schrijf dan ook nog niet in Nederland. Het is aan u om te zien hoe snel een ontwikkeling kan gaan (of niet).

Natuurlijk bestaat het woord fleet al wel. Er zijn een paar plaatsen in Engeland met de naam Fleet. Het betekent vloot in het Engels en is tevens de naam van een Belgische keten van autodealers, een Australisch motorfietsmerk én een firma die handelt in klysma’s. De Urban Dictionary spreekt bij fleet dan ook van ‘a term to describe when someone is cleaning out their ass/vagina’.

Maar de fleet die ik bedoel is de nieuwste  functie van Twitter. Het gaat om een bericht dat na 24 uur automatisch verdwijnt. Hiermee sluit Twitter aan bij een richting die bedrijven als Snapchat, Instagram en Facebook al veel eerder insloegen. “Omdat ze na een dag verdwijnen, helpen fleets de mensen om zich niet geremd te voelen om hun persoonlijke en terloopse gedachten, meningen en gevoelens te delen”, blogden Joshua Harris en Sam Haveson, respectievelijk design director en product manager bij Twitter.  Mijn optimistische ik is blij omdat een hoop vuilspuiterij daarmee automatisch verdwijnt, maar aan de andere kant kan het betekenen dat reaguurders en andere gekkies zich bevrijd voelen van hun laatste remmingen en helemaal los gaan. Wie zal het zeggen? U misschien/niet/waarschijnlijk/uiteraard?

Eerder verschenen in IP #9/2020

Islandora Online: Islandora as an Institutional Repository

Dit jaar wordt er vanwege de corona crisis ook door Islandora een Online event gehouden. Of eigenlijk zijn het 4 events van elk 5 uur.
Hieronder het verslag van het vierde en laatste event, gehouden op 11 augustus. Eerdere verslagen zijn hier te vinden: Islandora 8, Islandora & Metadata, en Migration.

Islandora as an IR

Eerst wordt er een overzicht gegeven van de huidige stand van zaken. Er is een aantal modules in Islandora 7 die het mogelijk maken om Islandora als een IR te gebruiken. PDF solution pack, Usage Stats, Entities solution pack, Scholar, IP Embargo zijn voorbeelden. Het LASIR project heeft ook veel gedaan voor IR in Islandora 7. Drupal 8 biedt zelf al een groot deel van de functionaliteit die deze modules verschaffen. Een ander deel zit nu al in Islandora 8. Wat vooral nog ontbreekt, zijn embargo’s en importeren van DOIs, PubMed, en dergelijke. Wat er al wel is, is LDAP for institutional login, Orcid login, OAI-PMH, Simple XML Sitemap, MetaTag (for Google Scholar), Entity Browser, Linked Data Lookup Field, PDF.js (embedded PDF viewer)* en meer.

Momenteel wordt er al hard gewerkt aan het implementeren van Embargoes. Hierbij wordt gewerkt met restricties op zowel IP als tijdsgebonden. Dit kan op “object” (node) niveau en op “bestanden” (media) niveau. Permissions by term maakt het nu al mogelijk in Drupal 8 om restricties via metadata terms te regelen. In Persistent Identifiers wordt Handles en DataCite DOIs geïmplementeerd. CrossRef DOIs wordt aan gewerkt. Er zijn plannen voor andere identifiers via een generiek framework. Over “dynamic citaties display” wordt momenteel veel nagedacht, maar er is nog geen implementatie van.

Open Access Kent State (OAKS) heeft een IR in de lucht in Islandora 8. OAKS bevat 3500 artikelen, 12 tijdschriften en 1600 conference proceedings. Discovery Garden heeft een IR oplossing gemaakt voor Islandora 8. Hier zijn speciale content types en open standaard taxonomieën voor ontwikkeld. Ook bieden ze een invoer-workflow, access control, embargo’s, rights and license management, versioning, SSO, OAI-PMH en een speciale IR presentatie laag.

Islandora as an Data Repository

UPEI (University of Prince Edward Island, de geboorteplek van Islandora) deed een project van 18 maanden om Islandora 8 als Data Repository in te richten. Dit is goed gedocumenteerd op https://islandora-rdm.researchspaces.ca/. Een onderzoeker kan hiermee de data van een onderzoek plannen, bewaren, mee (samen)werken, publiceren onafhankelijk van formaat of grootte van de dataset. De dataset krijgt een DOI, is doorzoekbaar, krijgt metadata, verwijst via ORCID en FundRef en is veilig.

Standaard node-media-files relatie

Het project bevat zowel code als veel documentatie en manieren waarop een Data Repository ingericht kan worden. Een van de grote verschillen met Islandora 8 (en standaard Drupal 8) is hoe bestanden gerelateerd worden. Normaal gesproken wordt elk bestand in Drupal 8 vertegenwoordigd door een Media type. Een media type bevat velden (voor metadata), heeft versie beheer en kan bijna alles wat een Content node ook kan. Een media type heeft ook een source type. Een source type bepaalt of het om een plaatje, video, geluid of iets anders gaat. Content node is het eigenlijke item in Drupal. Dit content node kan een of meerdere media types bevatten.

Het project heeft de relatie tussen nodes, media en bestanden aangepast zodat een media type meerdere bestanden kan bevatten. Dit maakt het beheer van een dataset eenvoudiger omdat er eigenlijk een laag minder is. In de normale situatie bevat een dataset bijvoorbeeld 3 delen. Elk deel bevat een media entity voor het oorspronkelijke bestand en 2 media entities voor elke afgeleiden. Er zijn dus 9 media entities nodig.

In de nieuwe situatie hebben ze aan het media type een aantal velden toegevoegd voor deze afgeleiden, waardoor een media entity het oorspronkelijke bestand en de afgeleiden bestanden kan bevatten.

Complexe workflows

Drupal 8 bevat support voor complexe workflows om publicaties in te voeren en te wijzigen. Formulieren kunnen op diverse manieren gemaakt worden. Hier zijn veel mogelijkheden voor. Maar een ingevoerde publicatie moet nog door diverse mensen gecontroleerd kunnen worden. Die publicatie moet op dat moment nog niet zichtbaar zijn voor het publiek. De publicatie moet echter wel zichtbaar en bewerkbaar zijn voor een selecte groep mensen. Een publicatie moet eigenlijk een bepaalde status hebben waarbij een bepaalde groep mensen toegang heeft. Tussen deze statussen moet een overgang zitten van de ene status naar een andere status. Content moderation biedt deze functionaliteit. Ook kan de Rules module reageren op status overgangen. Bijvoorbeeld kan een mailtje gestuurd worden als de status wordt aangepast van een publicatie. Alle bouwblokken voor complexe workflows zijn dus in principe beschikbaar in Drupal 8. Alleen moeten deze bouwblokken nog wel “gestapeld” worden en geconfigureerd.

Dit was het laatste verslag van Islandora Online. Natuurlijk heb ik niet alle onderwerpen die voorbij kwamen behandeld, dus hierbij ook een link naar de event pagina met daarop de dagprogramma’s en een link naar de video’s die gemaakt zijn van de presentaties.

Islandora Online: Islandora and Migration

Dit jaar wordt er vanwege de corona crisis ook door Islandora een Online event gehouden, of eigenlijk zijn het 4 events van elk 5 uur.
Hieronder het verslag van het derde event, gehouden op 4 augustus. Het verslag van het eerste event is hier te vinden. Het verslag van het tweede event is hier te vinden.

Helaas kon ik niet “live” aanwezig zijn bij dit event vanwege vakantie, maar gelukkig is het hele event opgenomen. Hierbij een verslag gebaseerd op het opgenomen event.

Uitdagingen

Het onderwerp van dit event is het migreren van content naar Islandora 8 vanaf Islandora 7 of een ander systeem. Migreren levert altijd vragen en problemen op, tenzij de data die gemigreerd wordt al perfect is. En dat is eigenlijk nooit het geval. Migreren levert altijd uitdagingen op: Omdat de metadata niet perfect is. Omdat lastige keuzes gemaakt moeten worden. Omdat bepaalde delen van de data niet passen in het nieuwe systeem. Omdat het nieuwe systeem (een nieuw soort) data verwacht of kan bieden die nog niet in het oude systeem zat. Omdat de metadata op een ander precisie niveau ingevoerd moet worden.

Soms moeten er lastige keuzes gemaakt worden tijdens de migratie, die er later voor zorgen dat er meer mogelijk wordt. Zo heeft in de metadata een persoon vaak een rol. Ook kan een persoon identifiers hebben en/of een of meerdere namen. De manier waarop deze data gemigreerd wordt, bepaalt voor een groot deel wat er daarna in Drupal (mee) gedaan kan worden.

Drupal Migrate

Drupal Migrate is de manier om veel migraties te doen. Natuurlijk zijn ook andere manieren mogelijk, maar bij alle zijn twee technieken te onderscheiden: ETL en ELT. ETL staat voor Extract data, Transform data en Load data. Dus eigenlijk haal je de data eerst uit het oorspronkelijke systeem, daarna vorm je de data zo dat het ingelezen kan worden in het nieuwe systeem en dan lees je het in. De letters van ELT staan ook voor Extract, Transform en Load. Alleen wordt de data nu eerst ingelezen waarna het wordt omgevormd.

Drupal Migrate gebruikt ETL, waarbij deze fases duidelijk te onderkennen zijn binnen het proces. Een migratie wordt uitgedrukt als een YAML document. Drupal Migrate maakt ook gebruik van de Drupal Plugin API waardoor het mogelijk is om eigen acties tijdens de migratie te definiëren. Natuurlijk bestaan er al veel van dit soort plugins in de Drupal community en worden ze ook gebruikt binnen Islandora 8. Zo is er een plugin om data te “extracten” uit Islandora 7, maar ook data van bestanden of data via een web API kan gebruikt worden. Maar ook zelf een plugin ontwikkelen is relatief simpel.

Drupal Migrate ondersteunt ook high water marks, wat betekent dat bij een migratie die niet helemaal goed gaat alleen het stuk wat misgaat opnieuw gedaan hoeft te worden. Mocht het helemaal misgaan, dan kan ook een rollback (terug naar een punt waar het nog wel goed was) gedaan worden.

Hulpmiddelen en tutorials

migrate_islandora_csv is een online begeleiding (tutorial) over hoe men Drupal Migrate kan gebruiken. Als bron gebruikt men een CSV bestand, maar er wordt uitgebreid stilgestaan bij het opschonen en vormen van de data (de T van ETL) en hoe men relaties tussen data aanlegt tijdens de migratie. Bovendien wordt dit alles stap-voor-stap uitgelegd.

migrate_7x_claw is een module bedoeld om te migreren vanaf Islandora 7 naar Islandora 8. Alle datastreams worden hiermee gemigreerd, inclusief “audit trail“. De metadata wordt gemigreerd vanuit Solr of een willekeurige XML datastream. Maar migrate_7x_claw is vooral een startpunt voor de migratie en nog geen volledige oplossing. Het is iets wat nog verder ingevuld en ontwikkeld moet worden voor de specifieke situatie. Om migrate_7x_claw goed te kunnen gebruiken en begrijpen, is migrate_islandora_csv een goed startpunt. Ook is het belangrijk om de Drupal Migrate API goed te begrijpen, maar ook Drupal config synchronization en Drupal features.

Andere migratie methodes

Migratie kan natuurlijk ook op een andere manier. Islandora 7 content wordt opgeslagen in Fedora 3.x. Islandora 8 content wordt (deels) opgeslagen in Fedora 5. Fedora 5 en 6 verschillen niet veel van elkaar, in elk geval veel minder dan Fedora 3 verschilt van Fedora 5. Islandora 8 of 9 gaat op een gegeven moment ook draaien op Fedora 6. Vanuit de Fedora community is er een project om de overgang van Fedora 3 naar Fedora 6 wat betreft migratie zo simpel mogelijk te houden. Ze zijn hier ook druk mee bezig dus het is interessant om te kijken of dit ook een manier is om van Islandora 7 naar Islandora 8 over te gaan.

Zowel Islandora 7 als Fedora 3 hebben een REST API. Ook Islandora 8 bevat een REST API. Dus in principe is het mogelijk om data uit het oude systeem te halen via de REST API. Daarna deze data omzetten in een ander formaat met welke methode/programmeertaal dan ook. Vervolgens de data inlezen via de Islandora 8 REST API. Voordeel is dat je volledige controle hebt over de data en het proces, maar dat is ook meteen het nadeel. Dit betekent namelijk dat je alles zelf moet doen.

Islandora Workbench is een ander hulpmiddel om te gebruiken bij migraties. Het gebruikt de REST API en gebruikt als bron een CSV bestand. Dit bestand moet al wel het juiste formaat hebben. De export en transform moet dus eigenlijk buiten Workbench om gedaan worden. Hierdoor is de configuratie en gebruik van Workbench vrij simpel, maar het werk ervoor kan complex(er) zijn. Workbench heeft allerlei manieren om de data voor ingesten te checken, zodat bij ingest er geen verrassingen zijn.

Migratie naar Islandora 8 kan dus op veel manieren, maar zal altijd (in meer of mindere mate) werk en hoofdbrekers opleveren. Al met al een erg interessant event, waarbij ik veel geleerd heb. Migratie naar Islandora 8 is veel verder dan ik gedacht had. Het verslag van het vierde en laatste event is hier te vinden.

Islandora Online: Islandora & Metadata

Dit jaar wordt vanwege de corona crisis ook door Islandora een Online event gehouden. Eigenlijk zijn het 4 events van elk 5 uur. Hieronder het verslag van het tweede event, gehouden op 28 juli. Het verslag van het eerste event is hier te vinden.

Metadata anders

Het tweede event had als onderwerp metadata. Islandora 8 behandelt metadata anders dan Islandora 7. In Islandora 7 wordt de metadata in een XML bestand ingeladen. MODS, Dublin Core, METS en MADS (voor personen) zijn opties, waarbij meestal MODS gekozen wordt. Islandora 7 genereert dan Dublin Core metadata uit de MODS omdat Dublin Core in Fedora verplicht is. Islandora 8 slaat de metadata op in Drupal fields die aan een “Repository item” hangen. Deze velden kunnen bepaalde beperkingen hebben, zoals lengte of inhoud. Zo kan je instellen dat bijvoorbeeld een datum veld ook echt alleen datums kan bevatten.

Beperkter met meer mogelijkheden

Islandora 8 levert standaard al veel metadata velden mee. Er is een mapping van MODS naar deze velden. Maar MODS (en andere metadata schema’s) bieden veel meer mogelijkheden om de metadata precies te typeren/classificeren. Er werd dus gediscussieerd over deze mapping en of het gebruik van velden niet te beperkend is. Hier werd geen concensus over bereikt.

Nu is het wel zo dat hoewel wij in Islandora 7 MODS gebruiken met een groot aantal velden, we lang niet alle velden van deze MODS ook echt afbeelden of op andere manieren gebruiken. Deel van de discussie was ook of Islandora nu echt de plek is om al je metadata te managen. Of zijn er systemen die daar beter geschikt voor zijn. Ik denk dat het laatste het geval is.

Taxonomie en Linked Data

Drupal 8 maakt voor de velden (indien gewenst) wel gebruik van een taxonomie. Deze kan zowel open (gebruikers kunnen eigen termen toevoegen) als gesloten (gebruiker kan alleen kiezen uit een vastgestelde lijst) zijn.
Er was ook een praatje over hoe je een autocomplete veld maakt die via Linked Data de data ophaalt. Hierbij werd zowel de tekst als een URI opgeslagen, zodat de relatie gehouden blijft.
De metadata bij een Repository item wordt in Fedora als Linked Data opgeslagen. Wanneer de metadata wijzigt van een item, dan wordt deze geserialiseerd in RDF en vanuit Drupal naar Fedora gestuurd, zodat de metadata ook duurzaam bewaard blijft.

Gebruik en tools

Er werd natuurlijk ook gesproken over het gebruik van metadata; welke velden missen in welke situaties en hoe wordt metadata opgeruimd in Islandora 7 zodat de migratie naar Islandora 8 beter en soepeler verloopt. Dat de metadata in Islandora 7 opgeruimd moet worden voordat aan de migratie naar Islandora 8 begonnen wordt, staat als een paal boven water.
Islandora Workbench is een tool om metadata (maar ook objecten) te kunnen wijzigen of inladen. Er zijn verschillende andere manieren om dit te doen voor zowel Islandora 7 als 8. Maar het is goed te zien dat verschillende tools worden ontwikkeld want dan is er iets te kiezen.

De dagen zijn wel lang als je een online event “bezoekt” wat in Canada gehost wordt. Ze hielden wel een beetje rekening met andere landen door het begin uur steeds te verschuiven, maar dit event was pas om 10 uur ’s avonds afgelopen. Hier is het verslag van het derde event te lezen.

Islandora Online: Islandora 8

Dit jaar wordt vanwege de corona crisis ook door Islandora een Online event gehouden. Eigenlijk zijn het 4 events van elk 5 uur. Hieronder een verslag van het eerste event, gehouden op 21 juli en alleen online (dus geen mooie plaatjes van exotische oorden).
De events hebben allemaal een soortgelijke opbouw: steeds ongeveer 1 uur praatjes en daarna korte pauze, met in het midden een langere pauze van een uur waarvan een half uur “social” is: je kan praten met de anderen (business or pleasure) of een spelletje spelen (vooral kruiswoordraadsels in het Engels zijn een uitdaging).

Verschil tussen Islandora 7 en Islandora 8

Het eerste event had als onderwerp Islandora 8. Islandora 8 verschilt van Islandora 7 nog meer dan Drupal 7 verschilt van Drupal 8. Maar dat is zeker niet slecht. Waar Islandora 7 Drupal 7 gebruikt om Islandora content te tonen, is in Islandora 8 deze content eigenlijk gewoon al Drupal 8 content. Dit houdt in dat Islandora 8 veel dichter bij Drupal 8 blijft en daardoor allemaal technieken maar vooral ook modules van Drupal 8 (een soort plug-ins voor extra functionaliteit) zonder enige aanpassing meteen kan gebruiken. Dit maakt Islandora 8 flexibeler en makkelijker uitbreidbaar.

Taken en microservices

Taken worden ook veel beter gescheiden van andere zaken: microservices voeren precies 1 bepaalde taak uit, los van de rest van het systeem. Bijvoorbeeld het aanmaken van afgeleiden of “optische tekenherkenning” (OCR) wordt geheel los van Drupal uitgevoerd, eventueel op hele andere servers. Een bepaalde actie start de microservice vanuit code door een en met een bepaalde context. De microservice wordt echter niet meteen gestart. De vraag en context worden in een wachtrij gezet totdat de microservice vrij is om de vraag te beantwoorden. Als de microservice klaar is, komt het antwoord (bijvoorbeeld een afgeleide of een OCR bestand) terug naar Drupal.

Digitale preservatie en opslaan

De taak van het opslaan van de data wordt uitbesteed aan Flysystem. Flysystem zorgt ervoor dat de plek waar de data opgeslagen wordt en de manier waarop opgeslagen wordt abstract is voor Drupal. Flysystem koppelt Fedora aan Drupal, waardoor de belangrijke data in een Digital Asset Management system wordt opgeslagen. Aangezien dit allemaal in te stellen is, kan gekozen worden wat nu eigenlijk belangrijke data is die dus opgeslagen wordt in Fedora, zodat Fedora de digitale preservatie kan regelen. Maar als de data naar een andere plek moet, kan dit ook. Opties hierbij zijn ondere andere local disk, (s)ftp, dropbox, AWS S3 of andere Cloud storage (via OpenStack swift).

Integraties en community

Islandora 8 heeft inmiddels een grote groep mensen die eraan werken en ook integraties met andere systemen maken. Zo is er al een integratie met ArchivesSpace. Voor statistieken wordt Matomo gebruikt, maar dit staat nog in de kinderschoenen. Islandora 8 biedt ook OAI-PMH. Zoals bij alles in Drupal 8 is ook dit een view, die helemaal is in te stellen zoals je wilt. Ook is Islandora 8 uit de box IIIF compatible. Cantaloupe implementeert de IIIF image API. Drupal 8 genereert de IIIF manifests (ook een view). Islandora 8 kan een manifest interpreteren en via een ingebouwde IIIF viewer afbeelden.

Support en updates

Drupal 7 support is uitgebreid tot november 2022. Islandora 7 houdt vast aan de eerdere datums. Dit betekent features tot november 2020, bug fixes tot november 2021 en security updates tot april 2022. Drupal 8 support loopt (gek genoeg) tot november 2021, maar de overstap naar Drupal 9 is relatief klein. Wanneer Islandora 9 uitkomt en de support voor Islandora 8 eindigt, is nu nog niet bekend.

Het was een hele interessante middag en avond. Over de andere 3 events verschijnt binnenkort ook een blog. Hier staat de blog van de tweede dag en hier die van de derde dag.

Coronamoe

Voor deze rubriek gaan we iedere maand op zoek naar nieuwe taaluitingen. Soms is het even zoeken en staat er niet meer dan één woord op mijn keuzelijstje, maar deze keer viel de oogst erg mee:

Anderhalve-meter-challenge, afschalen, amateurviroloog, anderhalve-meter-economie, balkonzanger, buitenschaamte, coroneus, coronials, coronomie, corontaine, digitale pandemie, disselen, druppelbesmetting, ellebooggroet, elleboogniezen, epidemiologische paraatheidsinnovaties, groepsimmuniteit, hamsterschaamte, handenschudverbod, hoestschaamte, hoestscherm, houdt-afstandhesje, infectietsunami, intelligente lockdown, kuchscherm, landelijk coördinatiecentrum patiëntenspreiding, lichaamscondoom, lockdown, lockdownparty, lockdownpopulisme, luchtmuur, massasurveillance, no-fly-periode, onthamsteren, oversterfte, pandemierooster, paniekwinkelen, physical distancing, quarantainehotel, raambezoek, Skypevisite, social distancing, sociale onthouding, superverspreider, thuisquarantaine, toerismeverbod, TOGS-regeling, virusbuddy, voetgroet, weigerklant, winkelprotocol, wuhanshake, zelfisolatie, ziektelast, ziektebubbel, ziektepiramide, zoomen, zorgapplaus en zorgheld.

En natuurlijk corana-aanpak, corana-advies, corana-afdeling, corana-alarm, coranababy, coranabesmetting, coranabrandhaard, coranacontactadvertentie, coronacrimineel, coranacrisis, coranadagboek, coronadictatuur, coronadienst, coronadode, coronadossier, corona-emoji, corona-epidemie, corona-expert, coronafeest, coronagebied, coronahotspot, coronahulpverlening, corona-informatie, corona-invloed, coronalied, coronaloket, coronamaatregel, corona-on-ice, coronaoverleg, coronapandemie, coronapatiënt, coronaregering, coronarichtlijnen, coronaroman, coronaslachtoffer, coronasticker, coronastress, coronasymptomen, coronatest, corona-uitbraak, coronavirus, coronazieke, coronaziekenhuis, corona-akkoord, corona-angst, corona-apocalyps, corona-app, coronaboete, coronacocooning, coronacontainer, coronacrash, coronagezant, coronagriep, coronahufter, coronakiller, coronaklever, coronanie, corona-ontkenner, coronaparanoia, coronapiek, coronaprotocol, coronaspuger, coronavakantie, coronaverdacht en coronaviering.

Maar de keuze viel deze maand, zonder concurrentie, op het woord boven dit stukje.

Infodemie

Het coronavirus zorgt naast een hoop ellende ook voor een nieuw woord in de Nederlandse taal: infodemie. Het is een mixwoord van informatie en epidemie. De eerste vermelding die ik vond, staat op de website van de Vereniging België China en dateert van 3 februari. De site gebruikt infodemie als vertaling van het Engelse infodemic, in een verwijzing naar een uitspraak van directeur-generaal Tedros Adhanom Ghebreyesus van de World Health Organization (WHO). Ghebreyesus zegt dat er niet alleen gevochten wordt tegen een epidemic, maar ook tegen een infodemic, die zich sneller verspreidt dan het Coronavirus en net zo gevaarlijk is. Een infodemic, en dus ook een infodemie, is een overvloed aan informatie, waardoor het lastig is om betrouwbare berichten te vinden. Het gaat dan niet alleen om de stroom aan geruchten, complottheorieën en (ander) fake news, maar bijvoorbeeld ook om experts die tegenstrijdige dingen zeggen over het gebruik van mondkapjes en andere voorzorgsmaatregelen. Net als bij een epidemie is het zaak om de infodemie in de kiem te smoren, aldus Ghebreyesus. De WHO werkt samen met Facebook, Pinterest, Tencent, Twitter, TikTok, YouTube en andere social media om de geruchten en desinformatie de kop in te drukken. In samenwerking met Google wordt berichtgeving van de WHO bovenaan de zoekresultaten gezet.

Het gekke is dat de oorsprong van het woord Infodemic in Nederland ligt. Al in 1999 werd het IT-bedrijf Infodemic bv ingeschreven bij de Kamer van Koophandel. In het Engelse taalgebied komen we Infodemic voor het eerst tegen in 2003. Toen ging het over de stroom aan berichten over SARS. Omdat die epidemie aan ons land voorbij ging, is het toen nooit tot een vertaling gekomen. Overigens ging het Nederlandse Infodemic bv een paar jaar na de oprichting failliet. Laten we hopen dat het de huidige infodemie niet veel beter vergaat.

(Eerder verschenen in de rubriek IP Lingo van IP-Vakblad voor informatiespecialisten 2020-3)

Digital Curation Conference Dublin

Mart van Duijn bezocht van 17-20 februari 2020 de International Digital Curation Conference in Dublin. Hieronder volgt een beknopt verslag.

Op 17 t/m 20 februari vond in Dublin de International Digital Curation Conference (IDCC) plaats, georganiseerd door het Digital Curation Centre (DCC), een expertisecentrum voor digital curation dat is ondergebracht bij de University of Edinburgh. Het IDCC is een jaarlijks internationaal congres (vanaf 2005) dat volledig is gericht op het gebruik en beheer van digitale objecten door onderzoekers, organisaties en instellingen.

Op de keynote lezingen na, zijn de bijdragen tijdens deze editie van het IDCC grofweg in te delen in presentaties over research data management (RDM) en digital preservation (DP). Voor Bijzondere Collecties is vooral digital preservation van belang, research data management is bij het CDS in portefeuille. DP draait voornamelijk om het acquireren, duurzaam opslaan en beschikbaar stellen van zowel gedigitaliseerd als born digital materiaal. Lezingen op dit punt gingen in op verschillende rollen en verantwoordelijkheden, namelijk die van de onderzoekers die zich meer bewust zouden moeten zijn van de noodzaak van het duurzaam bewaren van digitale onderzoeksdata en -objecten, instellingen die de juiste infrastructuur moeten inrichten voor dergelijk materiaal en actief bij het aanmaken daarvan betrokken zouden moeten zijn, en gebruikers die bediend moeten worden zodat digitaal materiaal hergebruikt kan worden. Een rode draad door hele congres heen waren dan ook de FAIR principes: Findable, Accessible, Interoperable, Reusable. Meerdere malen werd tevens herhaald dat die principes alleen nagestreefd kunnen worden als er communicatie en samenwerking is tussen de verschillende betrokken partijen.

Voor de Bijzondere Collecties van de UBL waren meerdere sessies en presentaties relevant, vooral die die ingingen op de rol van instellingen in het gebruik en beheer van digitaal materiaal. In het bijzonder relevant was de presentatie van Katrina Fenlon (University of Maryland) waarin zij aangaf welke rol instellingen zouden moeten spelen in het beheer van Digital Humanities Collections. In veel gevallen is bij de totstandkoming daarvan geen beherende instelling betrokken, met grote gevolgen voor de duurzame opslag. Instellingen moeten zich daarbij niet opstellen als laatste rustplaats, maar als actieve deelnemer. Vanuit de National Library of Ireland werd een lezing gegeven door directeur Sandra Collins. Zij benaderde het beheer van digitaal materiaal vanuit een historisch perspectief en benadrukte de rol die de bibliotheek van oudsher heeft en die ook in digitale tijden voortgezet dient te worden. Daarbij ging ze voornamelijk in op gedigitaliseerd materiaal en bleef born digital helaas onderbelicht. Dat instellingen elders op dezelfde manier geconfronteerd worden met born digital materiaal en dezelfde ontwikkeling doorgaan als de UBL, werd goed duidelijk in de posterpresentatie van Emma Yan en Clare Paterson, getiteld University of Glasgow: Our Digital Transformation (https://zenodo.org/record/3664615#.XmDqQ6TvKUk).

Born digital zal een van de speerpunten zijn in het beleidsplan voor de periode 2021-2025. Dan moeten er grote stappen gezet worden in het acquireren en duurzaam beheren van dergelijk materiaal. De sessies en presentaties tijdens het IDCC in Dublin hebben duidelijk gemaakt dat de UBL kan aansluiten bij ontwikkelingen en expertise elders, maar dat zij geenszins tot de achterhoede behoort.

Mart van Duijn

Fleeceware

Hoe vaak gebeurt het niet? Je downloadt uit de Google Play Store een app die je een paar dagen gratis mag proberen, je ziet al snel dat je er niets aan hebt en je verwijdert hem weer. Niets aan de hand. Maar sinds enige tijd gebeurt het regelmatig dat mensen tot hun schrik merken dat er geld, soms zelfs aanzienlijke bedragen, van hun rekening is afgeschreven omdat ze zich abonneerden op een app zonder dat ze zich daar bewust van waren.

Wat is er aan de hand? Wanneer iemand  een app verwijdert tijdens de proefperiode mag je er van uit gaan dat hij die app niet wil aanschaffen. Maar een officiële afmelding is het niet. Slimme jongens, je mag ze geen criminelen noemen, maken hier gebruik van. Wanneer de klant vóór het verstrijken van de proefperiode geen expliciete afmelding verstuurt, brengen ze een bedrag in rekening voor het gebruik van de app, óók als die zich niet meer op het toestel van de ongelukkige klant bevindt. Soms gaat het daarbij om flinke bedragen. Medewerkers van het Engelse IT-beveiligingsbedrijf Sophos ontdekten afgelopen september dat sommige bedrijfjes meer dan $200 per jaar in rekening brachten voor rekenmachines, QR-lezers en andere simpele apps.  De  term die Sophos voor deze vorm van legale zwendel bedacht, is fleeceware (to fleece betekent geld uit de zak kloppen). Google heeft dit najaar al een aantal fleeceware-apps verwijderd uit Play Store, maar onlangs doken er weer nieuwe exemplaren op.

De mensen achter de apps hebben inmiddels weer een nieuw slimmigheidje bedacht: in een aantal gevallen vragen ze geen jaarlijks bedrag meer, maar een bedrag per week, want dan lijkt het minder. Zo schrijft het brein achter Fortunemirror, een app die de toekomst voorspelt, wekelijks €69,99 af. Inmiddels hebben enkele tienduizenden mensen deze app gedownload. Afgaand op de recensies beleefden ze er weinig plezier aan.

Dus als een voorspellende app u binnenkort vertelt dat u een financieel debacle te wachten staat, weet u wat er gaat gebeuren. U bent gewaarschuwd!

(Eerder verschenen in IP-Vakblad voor informatiespecialisten 2020-2)