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.