CEST Expertmeeting registratiesoftware 27 februari 2012

Transcriptie

1 CEST Expertmeeting registratiesoftware 27 februari 2012 Author: Date: Subject: Henk Vanstappen Version Date Changes Author Henk Aanvullingen Bert

2 2/10 1 Inleiding Bewaarinstellingen worden regelmatig geconfronteerd met de nood om hun collectiebeheerssoftware te evalueren of te vervangen. Afgelopen jaar hebben een aantal organisaties een traject doorlopen waarbij ze een nieuw collectiebeheerssysteem aangeschaft/ontwikkeld hebben. Op de website van CEST werden recent de belangrijkste kenmerken van een aantal registratiepakketten in kaart gebracht. De intentie is om dit overzicht verder uit te breiden en aan te vullen. In dit verband organiseerde PACKED een expert meeting met vertegenwoordigers van erfgoedorganisaties die hun ervaringen willen delen in het selecteren en gebruiken van registratiesoftware. We willen daarbij ingaan op zowel functionele en technische aspecten als op gebruiksvriendelijkheid en beschikbaarheid van expertise en ondersteuning bij het gebruik. De resultaten van de rondetafel bieden voor PACKED input om de analyse van de registratiesoftware in CEST verder te verfijnen. 2 Voorstelronde Aan de deelnemers wordt gevraagd zich voor te stellen, het type collectie dat in de organisatie wordt bewaard, de gebruikte software en de beste/slechtste ervaring daarmee. Els Angenon, KMKG: KMKG gebruikt MuseumPlus van Zetcom, Zwitserland, sinds KMKG heeft zeer diverse collecties (museaal). Keuze voor MuseumPlus omdat het ook in andere, gelijkaardige musea in gebruik was in tegenstelling tot de vorige applicatie, die helemaal op eigen gebruik was afgestemd en ontwikkeld. Zetcom had ervaring en goede reputatie met betrekking tot meertaligheid. Museumplus wordt vooral gebruikt voor registratie op objectniveau en voor publicatie en ontsluiting van de gegevens (emuseumplus, sinds 2010). Er is goede ondersteuning, maar door de geografische afstand en technische complexiteit loopt het soms moeilijk. Meertaligheid is ook niet volledig uitgewerkt. Dries Moreels, BAM: Heeft zelf een systeem ontwikkeld voor VTi dat allerlei objecten (bibliotheek, documentatie, multimedia, ) geïntegreerd ontsluit. Het systeem is volledig maatwerk, maar integreert een aantal standaarden. Het systeem is meertalig en open source, waardoor ook andere organisaties het kunnen gebruiken.. BAM zelf heeft geen collectie in huis en ook geen beheerssysteem. Kunstenorganisaties hebben wel een 'collectie' en BAM heeft al een aantal spelers uit het veld rond de tafel gezet om op zoek te gaan naar behoeften en hiaten, maar dit project is nog (lang) lopend. Ook kunstenorganisaties hebben in ieder geval wel interesse en zijn bezorgd om de 'collectie' die in de loop der jaren werd opgebouwd. Donald Weber, Amsab- ISG: Amsab- ISG is een archiefinstelling en heeft dus andere behoeften qua registratie. Het archief wordt beschreven met behulp van de ISAD(G) beschrijvingsregels. Daarnaast heeft AMSAB ook een bibliotheek en een uitgebreide collectie objecten en beeldmateriaal. AMSAB is daarom lang op zoek geweest naar een systeem dat al deze objecttypes tegelijk kon beheren. In 1997 werd VUBIS in gebruik genomen. Dit systeem was enkel voor bibliotheekmateriaal geschikt. Vanaf 2000 werd Pallas ontwikkeld, in samenwerking met SOMA. Pallas was uitermate geschikt voor archief, maar niet voor museale collecties en bibliotheek. Daarom nam men Adlib in gebruik voor de museale collectie, waardoor er twee verschillende systemen moesten beheerd worden. Uiteindelijk werd beslist naar één systeem over te schakelen. De keuze viel op Adlib (CBF versie), dat intussen ook over een archiefmodule beschikte

3 3/10 (2004). Later werd de OPAC- versie in gebruik genomen die toeliet om de collectie toegankelijk te maken via het web. Handig aan Adlib is de gebruiksvriendelijkheid: installatie is zeer eenvoudig, het werkt in alle mogelijke netwerken, heeft een goede zoekfunctionaliteit, en ondersteunt standaarden (ISBD, ISAD(G), Spectrum, ). Het pakket levert wel moeilijkheden op bij de integreerde ontsluiting van de verschillende collecties: koppelen van boeken of foto's met een archief waarvan het deel uitmaakt, is moeilijk. Doordat de 'authorities' (namen van personen en organisaties) gedeeld worden, is er ook veel onderhoud nodig: bibliotheekmedewerkers voeren immers anders in dan archivarissen, met veel vervuiling tot gevolg. Ook bleek de software vanaf het begin erg veel bugs te bevatten, die door de ontwikkelaar niet snel worden opgelost. Ook bleek er een probleem met de compatibiliteit tussen een nieuwere versie van de software en de (meest recente) gebruikte OPAC- software die nochtans van dezelfde leverancier komen. Daardoor kunnen de meest recente gegevens niet gepubliceerd worden. Jeroen de Meester, Musea en Erfgoed Antwerpen: de Antwerpse stedelijke musea gebruiken Adlib als registratiesoftware (MS SQL versie). Adlib is zeer flexibel: met het hulpprogramma Designer kan zowat alles aangepast worden; je kan de toepassing zelfs vanaf nul weer opbouwen. Alle velden, schermen, indexen etc. kunnen aangepast worden. Mindere ervaring was de ontwikkeling van de verhuismodule, die zeer moeizaam verliep. Bij Adlib lijkt het erop dat je beter enkele jaren wacht voor je een nieuwe module in gebruik neemt. In de eerste jaren moeten vaak nog heel wat kinderziektes overwonnen worden. Dirk Derom, BNA- BBOT: BNA- BBOT heeft geen typische erfgoedcollectie, maar beheert wel een archief dat bestaat uit een grote verzameling opnames van interviews. Hiervoor werd een tiental jaren geleden database ontwikkeld (gebaseerd op Sushi). Toen was er nog weinig sprake van metadatastandaarden, waardoor de database zeer idiosyncratisch is opgebouwd. Nu de visie en missie van de organisatie veranderd is, blijkt de datastructuur echter niet meer te voldoen. Een eerder initiatief om de database te laten herschrijven (StoriesMatter) was niet succesvol. De datastructuur was te beperkt; een gevolg van de samenwerking met een Canadese partnerorganisatie die een heel eigen visie had op wat de database moest zijn. Vervolgens werd een samenwerking opgestart met AMVB om samen een systeem uit te bouwen, maar hiervoor waren onvoldoende middelen beschikbaar. De uitkomst was een onderzoek naar wat de minimum standaarden moeten zijn om data te bewaren. Op dit moment is men nog steeds op zoek naar een goede vervanger van het huidige systeem. Het probleem is dat er ook een office management systeem aan gekoppeld is. Dit van elkaar loskoppelen is niet gemakkelijk en riskant. Er is bovendien niet veel animo om (alweer) een ander systeem in gebruik te nemen. Voordeel van Sushi is de flexibiliteit en het gemak waarmee nieuwe functies in gebruik kunnen worden genomen. Nadeel is dat de leverancier zelf weinig expertise heeft in archiveren en dergelijke: alle instructies voor aanpassingen moeten dus grondig worden voorbereid en gedetailleerd uitgeschreven. Voordeel is dat de partner in Brussel zelf gevestigd is, wat de communicatie bevordert. De vrees bestaat wel dat alles van een persoon in het bedrijf afhangt. Tijl Vereenooghe, Heemkunde Vlaanderen: HKV biedt ondersteuning aan organisaties die met heemkunde bezig zijn: heemkundige kringen, lokale musea etc. HKV heeft zelf geen collectie, maar geeft vaak advies over inventarisatie en de keuze van software. Kleinere organisaties zijn vaak op zoek naar een pakket dat 'alles kan' (en liefst zo goedkoop mogelijk is). De doelgroep van HK is vaak nog in de fase dat steekkaartcatalogi worden omgezet naar een database. Ze willen graag een antwoord op de vraag wat de 'beste' software is een systematisch overzicht is daarom wel handig. HKV maakte een vijftal jaren geleden een rapport waarin een aantal pakketten werden vergeleken. Hoewel die vergelijking al wat verouderd is, wordt ze nog steeds gebruikt.

4 4/10 Joris Janssens, PACKED/AMSAB: In het kader van Europeana werden een aantal tekortkomingen vastgesteld aan Adlib: de link naar de landing page (isshownat- element van het Europeana ESE- schema) werkt niet goed, integratie van pdf- bestanden is onvoldoende (enkel als koppeling, niet fulltext doorzoekbaar), data zijn niet open tenzij de duurdere SQL- versie wordt aangeschaft. Daarom heeft AMSAB een aantal open source pakketten onderzocht (CollectiveAccess, ICA- ATOM, Omeka). Er werd besloten CollectiveAccess verder in te zetten om een geïntegreerde ontsluiting van de collecties te realiseren. Dit verliep niet zonder problemen: CA is vooral gericht op museale collecties, maar kan niet goed overweg met de hiërarchische beschrijvingen van archiefcollecties. De documentatie van CA is onvoldoende: Men moet zelf veel uitzoeken. Normaal is het voordeel van een open source pakket dat je kan gebruik maken van een grote actieve community, maar bij CA is dat veel minder het geval. Het is vooral de ontwikkelaar zelf die voor ondersteuning zorgt. Intussen zijn er al wel enkele (commerciële) bedrijfjes die CA ondersteunen en ontwikkelen. Bij PACKED worden intussen een aantal standaard profielen [metadata schema's] ontwikkeld voor de registratie van verschillende collectietypes, gebaseerd op de 'grote' standaarden. Bij wijze van test werden deze profielen vertaald naar een profiel voor CollectiveAccess. Ook hier blijkt het lastig om de standaarden behoorlijk te implementeren. [discussie]: Open source software (OSS) mag niet vanuit de positie van een klant worden bekeken: als je zo'n pakket in gebruik wil nemen en een probleem vaststelt, wordt je verondersteld het zelf op te lossen. Er moet een afweging gemaakt worden: ofwel betaal je voor een onderhoudscontract, ofwel huur je iemand in die met de open source software kan werken. Het uitgangspunt We hebben geen geld, dus werken we met open source, is verkeerd. Door de keuze van open source, verandert ook je positie: Je bent je eigen support. 3 Bespreking huidig overzicht registratiesoftware op CEST- wiki Het huidige overzicht ( is gebaseerd op deskresearch. Waar kan dit verbeterd/aangevuld worden? Het overzicht is nog vrij beperkt en biedt niet veel nieuwe informatie [maar is vooral bestemd voor kleine organisaties]. Er moet vooreerst de overweging gemaakt worden wie zo'n pakket nodig heeft: een organisatie die maar 200 objecten bezit, hoeft misschien geen registratiepakket in gebruik te nemen. Het zou handig zijn als er meer verwijzingen naar praktijkvoorbeelden werden opgenomen, waarin ervaringen met gebruikte software en toegepaste standaarden worden opgesomd. De indeling naar toepassingsgebied (archieven, bibliotheken, musea ) is op zich handig, maar wat ontbreekt is een indeling naar de organisatieprocessen waarin bepaalde software wordt gebruikt. De opgesomde pakketten verschillen hierin zeer sterk: Gaat het om het beschrijven van wat in de collectie zit? Depotbeheer? Verhuisoperaties? Ontlenen? (op de wijze van bibliotheken of op die van musea) Etc. Het zou ook handig zijn de verschillende modules in kaart te brengen die een pakket biedt. Aansluitend stelt zich de vraag of elk van die organisatieprocessen of use cases met een en hetzelfde pakket moeten worden beheerd. Dat is een vraag waar ook softwareleveranciers mee worstelen: De geïntegreerde systemen staan onder druk en het is de vraag of er in de toekomst niet meer gebruik zal worden gemaakt van samengestelde modules van verschillende leveranciers. Bij het VTi werd deze denkpiste gevolgd: Er

5 5/10 werd een pakket op maat ontwikkeld dat de specificiteit van de collectie goed benadert, maar er wordt van uitgegaan dat 'standaard' processen zoals uitlenen of beheer van contactpersonen met bestaande software kunnen worden beheerd. Als je vanuit een CRM (Customer Relationship Management) naar een object in je registratiesysteem kan linken, werkt dit ook. Een reden om toch bij dezelfde leverancier te blijven is de overweging dat deze zijn software het beste kent en daarop ook het beste nieuwe of bestaande modules kan laten aansluiten. Om die reden besloten de Antwerpse Stedelijke Musea de verhuismodule door Antwerpen te laten ontwikkelen. 4 Bespreking stellingen 4.1 Collectiebeheerssoftware moet zich aanpassen aan de collectie en niet omgekeerd. Bij VTi werd deze stelling gevolgd: software moet de business case volgen. Een kenmerk van veel software is dat die gemodelleerd wordt naar een gemiddelde situatie, die je in een museum of archief inderdaad wel kan tegenkomen. Software die voor een specifieke situatie in een specifieke collectie is ontwikkeld, is dan ook niet inzetbaar in een andere organisatie. Zo had KMKG aanvankelijk besloten een systeem op maat te laten ontwikkelen, maar besliste later voor een standaard pakket te gaan. Bij het registratieproces houdt men zich ook zoveel mogelijk aan de standaarden. Het aanpassen gebeurt pas op het moment dat de collectie wordt ontsloten. Dat heeft vooral te maken met de eis van tweetaligheid bij de ontsluiting, waardoor vooral veel regels aan het registratieproces moesten worden toegevoegd. Ook AMSAB koos uitdrukkelijk voor een pakket dat registratiestandaarden goed ondersteunde. Een belangrijke reden hiervoor was het feit dat men bij omschakeling naar een ander pakket steeds geconfronteerd werd met conversieproblemen. Ook bij samenwerking in netwerken zoals MovE bleek de nood aan het volgen van registratiestandaarden. Een belangrijk probleem daarbij is dat het personeel ook overtuigd moet worden om op een andere manier te gaan werken en strikter volgens (bijvoorbeeld) ISAD(G) te gaan werken. Gebruik van een systeem die een bepaalde standaard ondersteunt, impliceert dus zeker niet dat die standaard ook gevolgd wordt. Soms leidt dit tot slechte, zelfs onbruikbare beschrijvingen. Gedeeltelijk kan dit opgevangen worden door rechten op verschillend niveau toe te kennen, waarbij bijvoorbeeld de toegang tot de thesaurusmodule beperkt is. Bij op maat gemaakte systemen kan het niet- volgen van beschrijvingsstandaarden voor problemen zorgen. Vaak wordt het systeem volgens een bepaalde use case ontwikkeld, maar wanneer men enkele jaren later een andere use case heeft (o.a. omdat de strategie van de organisatie verandert), moet de software en de data zelf weer aangepast worden. Als je dan geen partner hebt die hier de nodige ondersteuning kan bieden, heb je een probleem. Zolang de data gestandaardiseerd zijn, ben je wel veilig. Problemen met data (en standaarden) zijn echter vooral een probleem van kwaliteitsvolle invoer, minder dan van de gebruikte metadatastructuur. VTi heeft in dat verband gekozen om als standaard MODS te gebruiken, maar eigenlijk is dat niet heel zichtbaar. Het belangrijkste is dat de gegevens consistent zijn

6 6/10 ingevoerd. De naam van de velden (labels) zijn niet zo belangrijk. Als de data goed zijn ingevoerd, kan je er bijvoorbeeld ook MODS of Dublin Core uithalen. Anderzijds betekent een keuze voor MODS ook dat je geen MARC kan exporteren, maar dit is ook een bewuste keuze: bibliotheekbeschrijvingen zijn voor VTi niet het belangrijkste, maar anderzijds was Dublin Core te beperkt. MODS is dan een logische middenweg. Een belangrijk hulpmiddel om voor consistente data te zorgen, is softwarematige en handmatige controle. Het is handig om een aantal to- do lijstjes op te (laten) maken die de invoerder wijzen op mogelijke fouten of onvolledigheden bij de invoer. Dat is soms handiger dan vooraf softwarematig de invoer aan te sturen. 4.2 Het beheer van collectiebeheerssoftware besteed je best zoveel mogelijk uit. softwarebeheer kan je helemaal zelf beheren, maar je kan ook erg ver gaan in het uitbesteden, tot en met software as a service. (SaaS) Vooral voor kleinere organisaties is SaaS interessant, omdat zij vaak nog geen uitgebouwde ICT- infrastructuur hebben. Voor heemkundige kringen zou dit interessant zijn, wanneer bijvoorbeeld Heemkunde Vlaanderen een overkoepelende overeenkomst zou afsluiten met een SaaS- aanbieder voor alle 400 kringen samen. Het is minder waarschijnlijk dat al deze organisaties individueel naar een leverancier zouden stappen: de technische en financiële drempels zijn daarvoor nog te groot. Vraag is of HKV daar op dit moment toe in staat is. Maar op zich is het idee van SaaS een erg aantrekkelijk idee of zelfs de enige mogelijkheid, omwille van de eenvoud waar dit soort organisaties naar op zoek zijn. Met het feit dat gegevens elders staan, hebben heemkundige kringen doorgaans geen problemen. Vaak willen ze wel digitaal gaan werken en standaarden volgen, maar ze moeten ook over de nodige infrastructuur kunnen beschikken. Laagdrempelige, praktische oplossingen zijn beter dan complexe uiteenzettingen over standaarden etc. Behalve puur economische overwegingen gelden bij SaaS nog een andere overweging, namelijk de shift van off line naar online: een belangrijke meerwaarde is dat je database meteen online staat. Want wie wil er nog off line aan collectiebeheer doen 'in het verborgene'? Volledige multimediabestanden kan je niet allemaal online zetten, maar de metadata natuurlijk wel. Ook administratieve metadata zoals juridische gegevens plaats je natuurlijk niet zomaar online. Een overweging is ook dat ICT niet de core business van een erfgoedbeherende organisatie is. In AMSAB wordt gepoogd de ICT- afdeling zo klein mogelijk te houden, maar dit blijkt steeds ontzettend moeilijk vol te houden: binnen de erfgoedsector komt men steeds in aanraking met ICT- gerelateerd processen: omgaan met multimedia, doorzoekbaarheid op Google, etc. Telkens weer wordt je ICT- afdeling daarop bevraagd. De grens is hier erg moeilijk te trekken: telkens probeer je dingen uit te besteden, maar toch blijk je veel zelf te moeten kunnen. Het is dan ook weer gewoon economischer om zelf personeel aan te werven en met open source software aan de slag te gaan. Een probleem met SaaS is niet zozeer dat je de data niet 'bij je hebt', maar wel dat het soms moeilijk is de data weg te halen en te gebruiken in een andere omgeving, bijvoorbeeld wanneer je van software (of provider) verandert. Het is belangrijk om het contract met je aanbieder goed te (kunnen) lezen. SaaS hoeft ook niet altijd commercieel te zijn: zo biedt ook Erfgoedplus een vorm van SaaS aan.

7 7/ Alle collectiebeheerstaken worden liefst met één softwarepakket uitgevoerd. Vraag is of je een geïntegreerd pakket wil dat alles aankan, of niet. Eerder werd al gewezen op de verschillende keuzes van VTi (zelf gebouwd systeem, aangevuld met bestaande, standaard componenten) en AMSAB: een systeem waarmee je verschillende collecties kan beschrijven. Met één druk op de knop alles vinden over Edward Anseele: Bij AMSAB was dit vijftien jaar lang de droom en het leidende paradigma, maar dit paradigma staat nu onder druk: het is niet omdat de gebruiker met een druk op de knop alles moet vinden, dat de achterliggende data uit hetzelfde systeem moeten komen. Bovendien maakt men de bedenking wat een gebruiker er eigenlijk aan heeft. In heel veel gevallen is die op zoek naar ofwel archieven, ofwel objecten of beeldmateriaal, maar hebben ze geen boodschap aan een geïntegreerde zoekomgeving. Hij moet minstens de mogelijkheid krijgen niet alles tegelijk te doorzoeken. Het is echter ook een financiële kwestie: Hoe meer pakketten je in huis hebt, hoe meer kans dat je dubbel betaalt voor overlappende functionaliteiten. Maar ook en vooral: Hoe moeilijker het intern wordt om alles te beheersen. Of: hoe simpeler, hoe beter. Bij VTi valt het met die complexiteit nog wel mee. Belangrijk is dat het 'kernsysteem', dat de collectie beschrijft, helemaal open is. Met alle andere systemen kan je dan verwijzen naar records in het kernsysteem. Ook het VTi had de ambitie om alles over Jan Fabre met een druk op de knop te kunnen vinden. Dat bleek overigens redelijk eenvoudig te ontwikkelen. Bij een pakket als Adlib is het niet eenvoudig om de ontsluiting (de webinterface) te integreren met een andere software (zoals CollectiveAccess). Bij AMSAB wordt nu de vraag gesteld of je digitaal materiaal met een andere software beschrijft en beheert dan analoog materiaal. Digital materiaal gedraagt zich immers anders: Zo wil je full- text kunnen zoeken in een tekstbestand, wat met Adlib niet echt mogelijk is. Om het dan toch te integreren zou je dan een soort van portaal moeten gaan bouwen. Integratie van verschillende modules (voor verschillende workflows) is mogelijk, maar de Antwerpse musea verkiezen toch één geïntegreerd systeem waarmee bruiklenen, tentoonstellingen, standplaatsen etc. worden beheerd. Ook MuseumPlus biedt dergelijke modules aan, maar ze worden niet allemaal gebruikt. Een bezwaar tegen een geïntegreerd systeem is dat het veel moeilijker is om dit volledig te migreren naar een ander pakket: Het is vrij eenvoudig om enkel object- of archiefbeschrijvingen in een nieuw systeem te importeren, maar alle bijkomende gegevens (bruiklenen e.d.) zijn moeilijker te migreren. Hetzelfde geldt voor gegevens die bij de objectbeschrijving horen, maar geen deel uitmaken van de beschrijvingsstandaard, zoals datum van creatie van het record, of de naam van de registrator. Bij de Antwerpse Musea wordt gedacht aan een nog verdere integratie: niet alleen de registratie zelf moet binnen hetzelfde pakket gebeuren, ook de opvolging van de werkprocessen moet door de software worden aangestuurd. Adlib zou dus zelf opdrachten geven aan de registrator wanneer een bepaalde procedure wordt uitgevoerd, zoals bruikleen. Dit zou er ook toe moeten bijdragen dat alle Antwerpse stedelijke musea op dezelfde manier met bruiklenen omgaan. Als je volgens het principe van een blokkendoos werkt, moeten de blokken uiteraard bij elkaar passen. Ook daar komt een reeks standaarden bij te pas. Het eerste wat je moet onderzoeken wanneer je een systeem

8 8/10 beoordeelt, is hoe er uitkomt wat erin gestoken wordt, met andere woorden: alle metadata moeten er uit kunnen gehaald worden ook administratieve of technische gegevens zoals de laatste wijziging. Een blokkendoos is dus ook kwetsbaar als een kaartenhuis: Als er bepaalde componenten niet goed werken, kan je problemen verwachten. Het grote verkoopsargument van geïntegreerde systemen is dat je dat probleem niet hebt. Het feit dat een softwarepakket open source is, betekent overigens niet automatisch dat het linked open data garandeert. Uiteindelijk is het aan de instelling om te beslissen wat belangrijk is voor het VTi was openheid in ieder geval een breekpunt. Ook CollectiveAccess zit nog sterk in dezelfde logica als een pakket zoals Adlib (eigenlijk is het een kloon ervan). Om werkelijk open data te realiseren, is er andere technologie nodig. 4.4 Collectiebeheerssoftware maakt bij voorkeur enkel gebruik van open softwarecomponenten en - technologieën. Registratiesoftware kan op dit vlak sterk verschillen: iets als CollectiveAccess heeft een database die vrij gemakkelijk rechtstreeks te benaderen is. Adlib heeft ofwel een CBF database, waar je rechtstreeks moeilijk verbinding mee kan maken, ofwel een SQL database, waarin de records echter nog gecodeerd opgeslagen zijn. je hebt dan extra modules nodig om de gegevens op een andere manier te benaderen dan via de grafische interface. Adlib werkt de laatste jaren echter wel aan het meer 'open' maken van het systeem. Uit een pakket als Adlib kan je natuurlijk wel eenvoudig exporteren (in XML of het eigen tekstformaat). Maar dit is ook weer een off line proces, waarbij je dus geen rechtstreekse (live) verbinding met de database hebt. Als dat belangrijk is, is een exportfunctie niet voldoende. Ook een standaard als OAI- PMH is eigenlijk een off line verbinding: je maakt daarmee een kopie van de database. In de erfgoedsector worden metadata echter beschouwd als het kapitaal van de organisatie. Open data of open access zijn daarom niet zo'n dwingende eis: men is niet geneigd data volledig open te gooien. Vraag is of de sector bereid is die stap te zetten. Zolang de erfgoedinstellingen niet klaar zijn om de stap naar open data (access) te zetten, zullen de verkopers van software ook niet geneigd zijn dit verder te ontwikkelen maar ze staan er wel klaar voor. Maar eigenlijk moet je die afgeschermde metadata beschouwen als kapitaal dat niet werkt. Je moet dit kapitaal echter inzetten in servicemodellen: Data moeten aanwezig zijn op het web en daar werken. Ook de erfgoedsector moet zich klaarmaken voor deze paradigmashift. Enerzijds leeft de angst voor de 'lege leeszaal': veel erfgoedorganisaties beschouwen het beschikbaar stellen als hun belangrijkste taak. Wanneer dit niet meer via de leeszaal, maar via het web gaat, lijkt hun functie te worden uitgehold. Anderzijds biedt een paradigma als open data de kans om meer efficiënt om te gaan met de data: Erfgoedorganisaties moeten aan onderzoekers de faciliteiten leveren om metadata als basismateriaal te gebruiken, én ervoor zorgen dat de resultaten ervan weer opnieuw beschikbaar kunnen worden gesteld. Er wordt dan op een heel andere manier geïnterageerd met het publiek of de bezoeker. Organisaties moeten vooral proberen de expertise die buiten de organisatie aanwezig is, in te zetten.

9 9/10 Organisaties die meegaan in die paradigmashift, kunnen hun database ook naar een open systeem migreren. Dat gebeurde onder meer bij een organisatie als Contredanse, die met weinig middelen het systeem van het VTi overnam. Er begint wel een verandering in de geesten te komen, in de zin dat men data niet langer opsluit. Het is vooral een kwestie van goede voorbeelden te zien, zoals de inventaris onroerend erfgoed die nu helemaal on line staat. Het is niet per se zo dat men dan ook open software moet gaan gebruiken. Voor grotere organisaties is een eerste stap dat men afstapt van de eilandjes van de eigen afdeling en op organisatieniveau al gaat samenwerken. Men ziet dan de voordelen daarvan, en ook het feit dat dit maar kan door gebruik van standaarden. Een stap verder is het breder ontsluiten, opnieuw met toepassing van standaarden. Gebruik van OSS biedt zowel nieuwe mogelijkheden als nieuwe problemen. Waar je zeker op moet letten wanneer je dit wil gebruiken, is de activiteit van de gebruikersgemeenschap (user community). Om die reden is een pakket als Drupal zo aantrekkelijk: Rond deze software is een grote gemeenschap actief, waar je gemakkelijk beroep op kan doen voor ondersteuning. Wanneer je voor upgrades en aanpassingen moet wachten tot de (oorspronkelijke) ontwikkelaar een nieuwe versie heeft uitgebracht, is het gebruik van OSS al veel minder aantrekkelijk. Dit probleem doet zich onder meer voor bij CollectiveAccess. De vraag die je moet beantwoorden is in welke mate je een pakket kan aanpassen in functie van je behoeften dan wel of het beter is een ander pakket te nemen of er zelf een te ontwikkelen. Bij open source kan je effectief in de code gaan kijken, en zie je meteen in hoeverre dat die nog werd aangepast en onderhouden. Dit doet zich onder meer voor bij ICA- Atom, waar je dan merkt dat de code de laatste zes jaar niet meer wezenlijk is aangepast. Met het budget dat je uitspaart op licenties, kan je wel enkele jaren in support voorzien. Dat is in ieder geval beter dan het programma te installeren en er dan verder niet veel meer aan te doen. Het is dan ook nodig dat er voor een software als CollectiveAccess een markt gecreëerd wordt, waardoor een aantal bedrijven tijd investeren om zich het pakket eigen te maken. Vraag is hoe succesvol CollectiveAccess nu is. Volstaan twee of drie bedrijven om voldoende support of community te bieden? Een reden om CollectiveAccess te kiezen was voor AMSAB het feit dat FARO dit ook aan de sector aanbood. Een ander pakket kiezen zou betekenen dat men dan 'naast de sector' zou gaan werken. Om aan de sector te adviseren CollectiveAccess te gebruiken, is er echter meer nodig dan wat FARO in dit dossier aanbiedt: Eigenlijk bevat dit te weinig positieve argumenten om die keuze te motiveren. Een aanbeveling is dus dat er een uitgebreider dossier wordt opgesteld, voor PACKED zich achter die keuze schaart. De vraag is natuurlijk ook of PACKED effectief bepaalde softwarepakketten moet promoten als the way to go. Openheid staat niet gelijk met open source: bij elke bouwsteen (module) moet je je afvragen of die open genoeg is om mee verder te bouwen. Dat kan even goed proprietary software zijn en overigens bestaat er ook veel gesloten software die met open source componenten is opgebouwd. Je collectiebeheerssysteem is vaak de eerste steen die je legt, en waarop je andere modules bouwt. Als die goed is, ben je vertrokken. Kies

10 10/10 dus een goed fundament, want pas blijkt pas veel later of dit goed genoeg is om met je architectuur een flexibel om te gaan. 5 Evaluatiecriteria [Aan de groep wordt een lijst met functionaliteiten voorgelegd, die als selectiecriteria kunnen gelden bij de keuze van een systeem. Vraag is wat de relevantie ervan is, en in welke mate er dit verder moet worden onderzocht.] Zoektalen: booleaans zoeken: is misschien verouderd. Ook aandacht voor faceted search en SQL zoektaal; Het gebruik van thesauri ook in de zoekomgeving voor gebruikers. Gebruik van codesystemen is minder relevant, want eigenlijk verouderd. Copy cataloguing (het kopiëren van bestaande beschrijvingen uit andere databases) is belangrijk voor bibliotheeksystemen (zie ook webservices). De mogelijkheid om meerdere mediabestanden aan één record te hangen. Full text doorzoeken van gekoppelde tekstbestanden wordt steeds belangrijker. De mogelijkheid media te beheren met een extern pakket. Import/export: het belangrijkste is of een pakket in staat is om in XML te exporteren. Verder ook aandacht schenken aan andere API's, waarmee je ook een record kan wijzigen buiten de grafische interface om. Er moet opgesomd worden welke soorten API's er zijn, en wat ze precies kunnen. Geavanceerd rechtenbeheer, loggen van wijzigingen aan records. Rapportfunctie: is eigenlijk overbodig geworden als er een goede exportfunctie is. Het snel kunnen maken van meer eenvoudige lijstjes is wel belangrijk, maar voor geavanceerde rapporten is het misschien beter de mogelijkheid om andere software te koppelen die specifiek ontworpen is voor het genereren van rapporten. Ondersteunen van werkprocessen als restauratie en depotbeheer (maar dit laatste is heel breed). Ondersteunen van meertaligheid (zie hoger). Mogelijkheid allerlei administratieve en juridische gegevens te registreren. Mogelijkheid om in batch records te wijzigen (bijvoorbeeld een groot aantal records van plaats veranderen).