Publicatie:Opzetten van een Collective Access systeem om digitale collecties te laten harvesten

Uit Meemoo Kennisbank
Naar navigatie springen Naar zoeken springen


Samenvatting

In deze use case wil ik het traject toelichten dat binnen Amsab-ISG doorlopen werd bij de keuze voor een Collective Access installatie voor het online toegankelijk maken van digitale collecties voor Europeana.

Dit omvat de keuze van de geschikte software, en het aanpassen van een (opensource) pakket naar de noden van een instelling. De uitkomst van dit traject zal een CollectiveAccess database zijn die de metadata van de digitale bibliotheek- en archiefcollecties bevat.

Begin 2012 was de import van de collectie gedigitaliseerde tijdschriften voltooid. Deze metadata is geëxporteerd en aangeleverd aan de HOPE-aggregator. De HOPE-aggregator geeft deze data op zijn beurt door aan Europeana. Tegelijk wordt er een front-end op deze database ontwikkeld.


Referentie
Titel Opzetten van een Collective Access systeem om digitale collecties te laten harvesten (Voorkeurstitel)
Locatie [ ]
Uitgever
Jaar van uitgave 2012
Rechten CC-BY-SA
Persistent ID


Trefwoorden

gevalstudie | archiefcollecties | toegankelijkheid | digitaal archiveren | toegang en hergebruik | rasterbeelden | tekst |

Auteur(s)

Joris Janssens (auteur)

Probleemstelling

Aanleiding

In 2010 stapte Amsab-ISG in het Europese HOPE (Heritage of the People's Europe) project. Dit aggregatieproject loopt nog tot mei 2013 en bestaat uit een consortium van 13 instellingen uit 10 landen. Eén van de doelstellingen van dit project is 880.000 gedigitaliseerde objecten naar Europeana brengen. [1] De deelname aan dit project stelde bepaalde eisen aan de metadata van Amsab-ISG. Zo vraagt Europeana dat er voor elk record een link naar een thumbnail van het gedigitaliseerde object wordt meegegeven, en een directe link naar het gedigitaliseerde object of naar een landing page waar dit object gepresenteerd wordt. Specifiek voor HOPE is de eis dat aan elk metadatarecord ook een Persistent Identifier (PID) moet worden toegekend.

Het probleem dat zich hier stelde voor Amsab-ISG was dat de bestaande metadata voor de digitale objecten niet tegemoet kwam aan deze eisen. Amsab-ISG gebruikt het collectieregistratiepakket Adlib voor het beheren van zijn archief- , museum- en bibliotheekcollecties. Eén van de zwaktes van Adlib ligt bij het beheren van digitale collecties. Zeker met het oog op het aanleveren van de data naar Europeana, waar een mooie presentatie en contextualisering van de digitale objecten belangrijk is, schiet Adlib tekort. De online catalogus van Amsab ([2]) heeft zo bijvoorbeeld geen viewer voor pdf-bestanden, en kan niet full text zoeken in OCR layers[2].

Vanwege het grote aantal digitale objecten waar nog geen metadata voor bestond moesten deze metadatarecords ook op (semi-)automatische wijze geimporteerd kunnen worden. Ook het geautomatiseerd aanmaken van records op basis van de bestandsnamen is niet vanzelfsprekend in Adlib.

Er werd uitgekeken naar een systeem dat de sterke kanten van Adlib kon behouden, maar ook deze gebreken betreffende het beheer van digitale objecten wist te overkomen.

Concrete doelstellingen

Na afloop van het project moet er een werkende CollectiveAccess database opgezet zijn die de metadata van de digitale collecties bevat en deze kan exporteren.

Op de langere termijn wil Amsab-ISG door gebruik te maken van open-source software meer controle hebben over de eigen collectieregistratiesoftware en de afhankelijkheid van commerciële organisaties afbouwen.

Methode

Planning

  1. Keuze pakket
    1. Opstellen van criteria
    2. Testen van software
  2. Opstellen datamodel
  3. Datamodel implementeren in CollectiveAccess
  4. Genereren van metadata
    1. Import
  5. Ontsluiten van Collecties
    1. Export
    2. Front-end

1 Keuze pakket

1.1 Opstellen van criteria

Hoewel de aanleiding voor dit project de aanlevering van data aan Europeana was, was het al langer duidelijk dat digitale bronnen door de huidige registratiesoftware (Adlib) niet zo goed ontsloten kunnen worden (enkel een link mogelijk): er is geen full text search mogelijk, hiërarchieën worden erg beperkt weergegeven, en er is geen viewer om in het digitale object te bladeren of zoomen. De nieuwe software moest deze gebreken kunnen opvangen.

De voorkeur werd gegeven aan een open-source programma. De belangrijkste motieven voor deze keuze zijn:

  • Geen aanschafkosten en geen jaarlijks terugkerende licentiekosten
  • De ervaring met Adlib, waar de database niet zonder meer te benaderen is, toonde de nood om een database te gebruiken die meer open is. Door gebruik te maken van software die een courante open source databasetechnologie ondersteunt, zijn er heel wat meer mogelijkheden om toegang te krijgen tot de data.

De belangrijkste eisen die gesteld werden aan het pakket zijn de volgende:

  • In staat zijn objecten van verschillende domeinen te beschrijven: Bibliotheek, Archief (en eventueel Museum)
  • Open source
  • Geoptimaliseerd voor digitale collecties (bijvoorbeeld de mogelijkheid afgeleide bestanden te creëren, ...)
  • Aangezien de digitale collecties voor een groot deel uit gedigitaliseerd tekstmateriaal bestaan (PDF met een OCR-layer) zou deze tekst ook doorzoekbaar gemaakt moeten kunnen worden binnen het systeem. Full-text indexering is dus een noodzaak.

De meeste functionaliteiten zouden standaard al in het pakket moeten zitten. Amsab-ISG gaat geen bijkomende functionaliteiten ontwikkelen.

1.2 testen software

Na een online zoektocht naar opensource collectieregistratiesoftware werd er een eerste selectie gemaakt op basis van de functionaliteiten die vermeld stonden op de website van de ontwikkelaars. Drie pakketten werden getest om te zien of ze deze beloftes ook konden waarmaken: OMEKA, ICA-AToM en CollectiveAccess . Deze applicaties werden op een lokale server geinstalleerd.

Eind vorig jaar werd binnen CEST dezelfde oefening uitgebreider gedaan. Zie hiervoor .

1.2.1 OMEKA

OMEKA valt onmiddellijk op door zijn eenvoud. Dit is het soort programma waar alles zeer intuïtief aanvoelt en documentatie een beetje overbodig blijkt. Maar die eenvoud is ook haar zwakte. OMEKA is eerder geschikt als publicatietool, voor het beheren van een collectie is ze een beetje te beperkt. Het datamodel is beperkt tot Dublin Core (via een plug-in weliswaar uitbreidbaar naar Dublin Core qualified), en vele van de meer geavanceerde mogelijkheden die je verwacht van een collectieregistratiesoftwarepakket ontbreken. Natuurlijk kan je voorbij deze beperkingen als je beslist zelf de code in te duiken en plug-ins te schrijven. Hier heb je wel de tijd en de expertise voor nodig. [3]

1.2.2 ICA-AtoM

ICA-AtoM is een softwarepakket ontwikkeld op initiatief van de ICA (International Council on Archives). Het is specifiek gericht op archieven en dat weerspiegelt zich ook in de mogelijkheden (en beperkingen) van de software. Het blinkt uit in het strikt volgen van de ISAD(G) beschrijvingsregels en de hiërarchische presentatie van een archiefbeschrijving. Het datamodel aanpassen was echter niet zo vanzelfsprekend. Er is een versie van ICA-AtoM beschikbaar die zich richt op bibliotheekmateriaal en hiervoor de bibliotheekstandaard MODS gebruikt, maar ook deze ademt nog teveel de geest van de archivalische structuur uit. [4] Het was tevens niet mogelijk een onderscheid te maken tussen types van objecten, bibliotheek- en museummateriaal zou binnen dezelfde installatie moeten beschreven worden met dezelfde elementen. Twee installaties naast elkaar opzetten was omwille van voor de handliggende redenen ook geen optie. Full-text indexering vonden we hier niet terug.

1.3.3 CollectiveAccess

Hoewel CollectiveAccess out-of-the-box minder geschikt is voor archivalisch materiaal kwam deze software toch als beste oplossing voor de digitale collecties van Amsab-ISG uit de hoek. Hiërarchieën worden minder mooi gepresenteerd als in ICA-AtoM, en het is lastiger de ISAD-G regels strikt op te volgen. Dit werd echter gecompenseerd door de flexibiliteit van het datamodel. CollectiveAccess gaat uit van het idee dat elke instelling andere noden heeft inzake de structuur van hun metadata. Geen enkele metadatastandaard op zich is in staat de eigenheid van elke collectie te vatten. Dit wil niet zeggen dat CollectiveAccess aanspoort om een idiosynchratische metadatamodel te gebruiken. Wel kan je van een standaard die delen gebruiken die je nodig hebt, eventueel aangevuld met elementen uit een andere standaard of zelf gedefinieerde elementen. Het is zo ook mogelijk binnen één CollectiveAccess installatie bibliotheekobjecten te beschrijven volgens bibliotheekstandaarden en archivalische stukken volgens een archiefstandaard. CollectiveAccess ondersteunt wel full-text indexering.

2. Opstellen datamodel

Amsab-ISG wilde een metadatamodel gebruiken dat vertrekt van het HOPE metadatamodel [5]. Dit datamodel werd ontwikkeld binnen het HOPE-project, en is zeer goed in staat metadata van verschillende domeinen te combineren. Het is echter in de eerste plaats opgesteld als een model voor de uitwisseling van data, en niet alle metadata die instellingen bewaren over hun objecten kan men hierin kwijt. Zo houdt ook Amsab-ISG metadata bij waar binnen dit model geen plaats voor is. Er moesten dus enkele elementen aan dit model worden toegevoegd. Deze elementen werden echter steeds aan bestaande beschrijvings- of metadatastandaarden ontleend (o.a ISBD en MODS en ISAD(G)).

3. Datamodel implementeren in CollectiveAccess

CollectiveAccess op maat van je organisatie maken doe je via een installatieprofiel. Een installatieprofiel is een bestand geschreven in XML dat wordt ingeladen tijdens de installatie van CollectiveAccess. Zo'n installatieprofiel definiëert onder andere:

  • De types van objecten die je kan beschrijven (bvb. tijdschrift, jaar(gang), nummer, archief, reeks, ...)
  • De elementen die je gebruikt bij de registratie van een object, alsook het type van de gekozen elementen. Voorbeelden van dergelijke types zijn: vrij tekst veld, een datum, waarde uit een gecontroleerde lijst ...
  • De mogelijke relaties tussen objecten en andere entiteiten (bvb. personen, organisaties, plaatsen ...)

Het geschreven XML-profiel kan slechts tijdens de installatie worden ingeladen, wil je nadien nog aanpassingen aan het datamodel doen, gebeurt dit via de GUI van CollectiveAccess.

4. Genereren van metadata

4.1 Import

Zoals reeds vermeld was er geen metadata voor alle gedigitaliseerde objecten aanwezig. In de meeste gevallen was er enkel een moederrecord in Adlib beschikbaar. Voor de tijdschriften wil dit zeggen één record op tijdschriftniveau, voor de archieven één record op fonds-niveau. Wel zat er heel wat informatie in de bestands- en mapnamen van de bestanden. Er werd een script geschreven dat de informatie uit de bestanden onttrok, en met deze informatie gecombineerd met de informatie uit het moederrecord in Adlib een record voor elk digitaal object aanmaakte in CollectiveAccess. Het script verwerkte ook de digitale objecten (pdf's) gelinkt aan het metadatarecord: Het indexeerde de geOCRde tekstlaag van de pdf waardoor records full text doorzoekbaar werden. Ook werden er lagere kwaliteitsversie (o.a. thumbnails) aangemaakt die gebruikt kunnen worden voor de presentatie en de doorgifte naar Europeana en andere aggregatoren.

Een bijkomende moeilijkheid was de eis binnen het HOPE systeem dat elk metadatarecord en digitaal object uniek geïdentificeerd moeten worden door een Glossarium:Persistent Identifier (PID) (PID). Een PID binnen de context van HOPE is een unieke resolvable URL die aan een digitaal object of metadatarecord wordt gegeven. Technisch wordt hiervoor binnen HOPE gebruik gemaakt van de handle.net HDS resolver service . Er werd een webservice [6] ontwikkeld die via SOAP-requests PIDs aan een object toekent. Een voorbeeld van hoe zo'n PID eruitziet: http://hdl.handle.net/10796/A400000627_1 . Het importscript moest hier dus ook rekening mee houden. Voor elk record wordt er bij import een nieuwe PID aangevraagd die wordt opgeslagen in CollectiveAccess. Deze PIDs zijn resolvable: dit wil zeggen dat als ik deze PID in mijn browser ingeef ik naar een pagina wordt doorverwezen die mij een presentatie geeft van het record/object in kwestie.

5. Ontsluiting

5.1 Export

Aangezien de standaard exportmogelijkheden van CollectiveAccess nog niet functioneel zouden zijn op het moment van ingest in Europeana hebben we zelf een exportscript ontwikkeld dat valide MODS XML records creëert voor de geïmporteerde collecties.

5.2 Front-end

Aangezien er vooraf beslist werd dat er pas in een later stadium een front-end ontwikkeld zou worden, werd er een voorlopige Pawtucket front-end opgezet. Pawtucket ( [3] ) is een apart te installeren module van CollectiveAccess die het mogelijk maakt op zeer korte tijd een simpele front-end op je CollectiveAccess back-end (de providence module) te bouwen. Wanneer de nieuwe front-end online gaat kunnen via de PID webservice de nieuwe resolve urls gekoppeld worden aan de PIDs die reeds gecreëerd werden bij import.

De ontwikkeling van een front-end in Drupal staat nog in de planning. Hiervoor zal gebruik gemaakt worden van de Sarnia-module en een SOLR index server

Resultaten

Op dit moment is er een CollectiveAccess database in gebruik die in staat is een export van de metadata te voorzien.

Hindernissen

Het aanpassen van CollectiveAccess was op papier een stukje eenvoudiger. Dit kwam vooral door gebrekkige documentatie, die zichzelf af en toe zelfs tegensprak. Hierdoor verliep het schrijven van het importscript vaak stroef. Er werd door de ontwikkelaar van de software wel steeds gereageerd op vragen maar vaak met enige vertraging aangezien er nog geen echte community rond CA bestaat, en support vooral afhankelijk is van één persoon. Ook het implementeren van het datamodel via de XML installatieprofielen kon door beperkingen in CA niet één-op-één worden doorgevoerd.

Wat zou je een volgende keer anders doen?

Bij de selectie van de softwarepakketten ook kijken naar minder voor de hand liggende mogelijkheden zoals Drupal. Een aangepaste Drupal installatie biedt veel van de mogelijkheden van een registratiesoftware, maar biedt daarnaast ook een grotere actieve community en nog meer flexibiliteit. Wel zal je hier en daar aan functionaliteit moeten inboeten.

Welke lessen heb je uit dit proces/project geleerd?

Onderschatting van het werk voor de aanpassing van de software. Kleine handelingen kunnen door gebrekkige documentatie soms heel wat tijd kosten.

Bronnen

  1. ↑ Voor meer informatie zie: http://www.peoplesheritage.eu
  2. ↑ ftp://digital.amsab.be/pubs_serials/ voor de tijschriften, ftp://digital.amsab.be/archives voor de archieven
  3. ↑ Libis heeft een systeem ontwikkeld waar OMEKA gebruikt wordt als front-end op een CollectiveAccess database. Zie [1]
  4. ↑ Zie Digital Collection Builder.
  5. ↑ zie: http://peoplesheritage.eu/pdf/D2_2_Metadata%20Structure.pdf
  6. ↑ Beschikbaar als opensource software op https://github.com/IISH/PID-webservice


Contactgegevens

Donald Weber
ICT-coördinator

Amsab-Instituut voor Sociale Geschiedenis
T: +32 (0)9 224 00 79
E: donald.weber@amsab.be


Tecle Zere
ICT medewerker

Amsab-Instituut voor Sociale Geschiedenis
T: +32 (0)9 224 00 79
E: tecle.zere@amsab.be


Joris Janssens
inhoudelijk medewerker

PACKED vzw - Expertisecentrum Digitaal Erfgoed
T: ++32 (0)2 217 14 05
E: joris@packed.be

Overgenomen van "https://www.projectcest.be/w/index.php?title=Publicatie:Opzetten_van_een_Collective_Access_systeem_om_digitale_collecties_te_laten_harvesten&oldid=51346"