Project MEE-KAARTEN: Een verslag van de doelstellingen, design, scenario's en user stories.

Transcriptie

1 Project MEE-KAARTEN: Een verslag van de doelstellingen, design, scenario's en user stories. Dirk Derom

2 Inhoudstafel Inleiding Design BBOT Doelstellingen Scenario's Kostprijs Planning en management Openstaande vragen...11 Appendices...12 Appendix A Lijst van bestaande archiveringssystemen...12 Appendix B Scenario's software ontwikkeling...13 B.1 Overzicht...21 Appendix C User Story...23 C.1 Overall scenario...23 C.2 Short data description...25 C.3 User story: Browser-based app (Drupal)...26 C.4 User story: Browser-based app (CollectiveAccess)...29 C.5 User story: Mobile App...29 C.6 User story: Other functionality...30 C.7 Deliverables...30

3 Inleiding Inleiding Dit document beschrijft de visie voor het project MEE-KAARTEN (hierna MK). Dit project, initieel het vervolg op voorgaand project Stories Matter, oriënteert zich naar de combinatie van een toegankelijk websysteem (in casu Drupal), gekoppeld aan een robuust archiveringssysteem (cf. CollectiveAccess). Dit document is bedoeld om de discussie aan te zwengelen voor zowel de haalbaarheid als de wenselijkheid van de scenario's. Dit document tracht de discussie tussen de potentiële partners te stimuleren met als doel tot een gezamenlijk project te komen afgestemd op de behoeftes van de partners. Dit document bevat een omschrijving van Doelstellingen Scenario's Kostprijs Planning en management Openstaande vragen i.v.m. het project Tot slot bevatten de appendices: Lijst van bestaande archiveringssystemen Detailbeschrijving van de scenario's Een voorbeeld van een user story 3 / 30 page(s)

4 1 Design BBOT 1 Design BBOT Het design zoals het momenteel wordt gedacht binnen bestaat uit de combinatie van 2 robuuste systemen in casu Drupal en CollectiveAccess. Drupal is gekozen voor de makkelijk aan te passen 'look&feel'. CollectiveAccess (hierna CA) is complementair aan Drupal gezien het expliciet gericht is op het archiveren van kleine tot middelgrote collecties. Drupal is een open source systeem gekend omwille van haar 'community building' features en de hoge graad van flexibiliteit. Dit systeem is gebruikt op websites met een hoge traffic (cf. een hoog aantal bezoekers en data verkeer) en wordt algemeen beschouwd als een van de beste open source 'content management systemen' momenteel beschikbaar. Bovendien is Drupal sterk betrokken bij de recente ontwikkelingen van metadata en is het erg actief in recente ontwikkelingen binnen het semantische web. CollectiveAccess is een systeem gebouwd als open source alternatief voor archivering zoals o.a. vereist voor musea en zelfs bibliotheken. Hoewel er vele andere systemen beschikbaar zijn voor de archivering van digitale en niet-digitale objecten (zie Appendix A Lijst van bestaande archiveringssystemen), groeit het enthousiasme voor CA meer en meer. Ook in België is dit het geval waar FARO CA expliciet in het vizier heeft (meer specifiek omtrent de cloud mogelijkheden van CA). De combinatie Drupal-CA is bovendien een beproefde combinatie in binnen- en buitenland. Waar o.a. de Vlaamse Kunstencollectie dit systeem reeds ontwikkeld voor enkele van haar collecties, is er ook een duidelijke oriëntering bij de ontwikkelaars van CA om Drupal te gebruiken als de 'web interface'. De keuze voor voorgaande systemen wordt meer in detail uitgelegd in volgende appendices (zie Appendices vanaf pagina 12). Gezien de vereiste robuustheid van het systeem in combinatie met een krap budget, is voorgaande combinatie zowel technisch als pragmatisch een haast logische keuze. In volgende paragraaf wordt uitgelegd wat voor de doelstellingen zijn voor de ontwikkeling van het systeem. Let wel, volgende paragrafen beschrijven geen definitieve stellingen. Onderstaande tekst is een verslag van wat er binnen leeft en wat als mogelijke pistes wordt aanzien. 4 / 30 page(s)

5 1 Design BBOT 1.1 Doelstellingen Open source met een grote poel van ontwikkelaars Open source is voor MK cruciaal waar het afgeleverde systeem vrij ter beschikking gesteld wordt in een erg permissieve licentie. Bovendien leidt open source tot minder afhankelijkheid van specifieke software bedrijven. Gesteld dat een systeem een grote poel aan relatief goedkope ontwikkelaars heeft (wat het geval is voor PHP systemen zoals Drupal en CA), is deze afhankelijkheid nog verder gereduceerd. In voorgaande ontwikkeling is zulke afhankelijkheid immers nefast gebleken voor de continuïteit van reeds ontwikkelde software (cf. Stories Matter). Combinatie eind-gebruikers en archivering focust met MK op die organisaties die weinig of geen technische kennis noch financiële middelen hebben om zelf een robuust systeem op te bouwen. Daar gelaten houden we ook de meer strikte eisen van archivering in het vizier. Het afleveren van software die zowel voor grote als kleinere partners nuttig blijkt, is een belangrijk doel voor MK. Gedeelde ontwikkeling als verbreding van het platform Binnen het veld van erfgoed, sociaal-artistiek en sociaal-cultureel werk zijn reeds verschillende software pakketten ontwikkeld. Deze systemen zijn in haast alle gevallen een combinatie tussen pragmatische eisen (vaak ten gevolge van financiële beperkingen) en erg specifieke doelstellingen van de organisaties. Dat leidt tot een uitermate versnipperd software landschap waarbij data moeilijk uit te wisselen valt. Bovendien leidt zulke ontwikkeling vaak tot onverwachte onderhoudskosten wanneer de software moet aangepast worden aan de steeds wisselende eisen. Het ontwikkelen van een gedeeld platform waarbij de broncode vrij wordt gegeven, biedt de mogelijkheid om het bestaande systeem aan te passen aan meer specifieke noden. Gedeelde ontwikkeling met een open broncode verhoogt eveneens de relevantie voor andere organisaties gesteld dat het systeem voldoende flexibel is. Integratie met missie heeft een erg specifieke missie waarbij rapportering en archivering belangrijke elementen zijn. MK wil hierop geënt zijn, waarbij rapportering en 5 / 30 page(s)

6 1 Design BBOT ondersteuning in rapportering centraal staan. Hierbij is de ontsluiting van de data zoals verzameld in erfgoed, sociaal-cultureel en socio-artistiek werk een richtlijn voor de ontwikkeling van het systeem. Flexibel en aanpasbaar systeem Het systeem voor MK wordt geacht flexibel te zijn, waarbij flexibel slaat zowel op de data structuur die opgeslagen dient te worden als de manier waarop de data aan het grote publiek digitaal getoond wordt. Dit is een belangrijk element in de keuze voor een combinatie tussen Drupal en CA. Waar CA toelaat om een brede waaier aan data op te slaan, is Drupal in staat om deze data op creatieve manieren te tonen. Integratie met andere software De integratie van dit systeem met andere systemen (cf. office management, wiki, document management...) is evenzeer een motivatie voor MK. De beproefde 10-jaar oude software momenteel gebruikt binnen, toonde dat zulke integratie de productiviteit verhoogt en management makkelijker maakt. Met integratie komt natuurlijk ook onderhoud kijken, wat de keuze voor een open source systeem versterkt. Beperkte kostprijs voor zowel ontwikkeling als gebruik Al te veel software biedt een massa aan functionaliteit gekoppeld aan erg hoge instapkosten. Dit is een onrealistisch scenario voor waar flexibiliteit niet kan samengaan met een hoge kostprijs. Wisselende noden van de verschillende projecten moeten binnen relatief makkelijk op te vangen zijn met dit systeem. Het systeem dient omwille daarvan aangepast te zijn aan deze noden in plaats van de noden aan te passen aan het systeem. De reductie van de kostprijs is niet onbelangrijk gezien het huidige budget en de verwachtingen wat betreft de overheidssteun voor zulke projecten. Snelle ontwikkeling en/of opvolging Voorgaande ontwikkeling binnen (cf. Stories Matter) was te langzaam om enthousiasme te kweken binnen de sectoren. Bovendien moet het systeem toelaten om zich snel aan te passen aan de steeds veranderende eisen ten aanzien van de software en is een termijn van 1 jaar ruim voldoende om zulke software te ontwikkelen. Deze variant van 'agile software development' laat toe om op korte termijn een accumulatie van functionaliteit op te bouwen. Tevens laat het toe om een steeds bredere waaier van 6 / 30 page(s)

7 1 Design BBOT partners te vinden die het systeem kunnen gebruiken. Evenzeer betekent dit een realistische visie waarbij er wordt uitgegaan dat de ontwikkeling van deze software op de schouders valt van de partners die momenteel in het project meestappen (de verwachtingen voor het creëren van een platform van gebruikers mag niet worden overschat). Het snel uitbrengen van versies kan echter de interesse enkel maar verhogen. Meestappen in tendensen binnen de sector(en) Waar mogelijk wordt er meegegaan in de tendensen zoals die binnen de sectoren hun intrede doen. Dit slaat dan op het integreren van sociale media, het uitbouwen van 'communities', het integreren van het semantische web en de cruciale rol van metadata voor de archivering. Realistische ontwikkeling met een brede insteek De ontwikkeling van MK is een pragmatisch project waarbij de functionaliteit duidelijk en a priori wordt aangepast aan de mogelijkheden van de ontwikkeling. Desondanks is de insteek niet beperkt tot het bewaren van data voor, maar worden allerlei sectoren in rekening gebracht. Hoewel er initieel geen versies voor specifieke doelgroepen worden ontwikkeld, is het relevant om deze data te kennen vooraleer er wordt overgegaan op de ontwikkeling van de software. 1.2 Scenario's Momenteel zijn er drie hoofdscenario's voor het project MK. Deze drie scenario's zijn niet noodzakelijk zo scherp afgelijnd, maar dienen als een grof onderscheid tussen de verschillende pistes. Het is evident dat variaties op deze scenario's mogelijk zijn. Meer specifiek is er de mogelijkheid om scenario 2 en scenario 3 in elkaar te laten overvloeien, waarbij de ontwikkeling van scenario 2 als testcase kan gebruikt worden vooraleer scenario 3 wordt opgevolgd. Anderzijds is scenario 3 het project met de grootste reikwijdte en is het potentiële doelpubliek merkelijk hoger dan het publiek voor scenario 2. Voor elk van deze scenario's moet er per partner een user story worden uitgeschreven. Ook dit kan verzorgd worden door (zie Appendix C User Story voor een voorbeeld). Scenario 1: project-specifiek 7 / 30 page(s)

8 1 Design BBOT Dit scenario is het minimum scenario voor waarbij een Drupal website wordt ontwikkeld om de data te bewaren en te tonen aan het bredere publiek. Een private server wordt ingehuurd en onderhouden door. Hoewel metadata hierin wordt geïntegreerd, is dit volledig afhankelijk van de expertise binnen. Ondersteuning voor andere organisaties is beperkt tot het afleveren van documentatie in verband met de ontwikkeling. Scenario 2: flexibel systeem gericht op experts Scenario 2 is de combinatie tussen een Drupal en een CA installatie. Hierbij wordt beroep gedaan op een bestaande module die de brug vormt tussen deze twee systemen (ontwikkeld door een bedrijf in Gent). Deze module importeert data van CA in Drupal waarbij de laatste gebruikt wordt om de data te ontsluiten. Het invoeren van data is met andere woorden beperkt tot CA en het tonen van data is verzorgd door Drupal. De ontwikkeling van deze combinatie is beperkt tot het beroep doen op de expertise van het bedrijf en het installeren van een systeem geënt op de partners van het project MK. Scenario 2 heeft als grootste beperking dat men een zekere expertise verlangt van degene die de data invoert (in CA). In scenario 2 is, hoewel mogelijk, geen externe service voor server maintenance ingerekend. Dit om de kostprijs onder controle te houden en een vlotte ontwikkeling toe te laten. Het doelpubliek van dit scenario is daarom beperkt tot expert organisaties (of semiexpert organisaties), waarbij minder technisch onderlegde en financieel krachtige partners niet worden opgenomen in de plannen. Scenario 3: flexibel systeem gericht op eindgebruikers Scenario 3 is de ontwikkeling van een uiterst flexibel systeem met data verkeer in beide richtingen. In casu is dit de verdere ontwikkeling van de reeds bestaande module (zie scenario 2). De verder ontwikkelde module laat toe om organisatie-specifieke Drupal websites te maken, waarbij haast alle metadata verborgen wordt voor die organisaties die technisch minder onderlegd zijn. Metadata wordt ingebed in Drupal forms, zoals uitgetekend door experten van het systeem. Dit verlaagt de drempel voor het invoeren van data aanzienlijk. 8 / 30 page(s)

9 1 Design BBOT Data invoer wordt op die manier ontnomen van de experts en uitgevoerd door een grotere poel van niet-experten. Het modereren van data blijft de verantwoordelijkheid van de experts. Semi-experts zijn vereist voor het ontwikkelen van Drupal forms die de data correct invoeren in CA. Er is de mogelijkheid om een onderscheid te maken tussen interne en externe data. CA laat immers toe om bepaalde data te beveiligen of verbergen voor het bredere publiek. Het doelpubliek is bijgevolg de niet-experten, semi-experten (voor het bouwen van Drupal forms) en experten (voor het modereren van de ingevoerde data in CA). De grootste beperking van dit scenario is de grotere ontwikkelingskost. De extra kost om de bestaande module te verbeteren heeft evenzeer een invloed op de timing die op die manier met enkele maanden verlengd wordt. Partners, zowel experten als niet-experten, worden beperkt (momenteel geschat op 5 partners) opdat de ontwikkeling niet te veel vertraging zou oplopen. Een grote verscheidenheid van de partners dient desondanks de ontwikkeling van het project zodanig te sturen dat een latere uitbreiding van de partners relatief makkelijk kan georganiseerd worden. Dit scenario voorziet evenzeer een robuuste organisatie van back-ups en server maintenance waarbij een extern bedrijf verantwoordelijk is voor het bewaren van de data. Dit zorgt voor een verhoogde professionele bewaring en zorgt voor een sterkere veiligheid van de data. 1.3 Kostprijs De kostprijs varieert en hangt af van volgende factoren: complexiteit initiële ontwikkeling complexiteit data van zowel partners als in huis gebruiksvriendelijkheid software betrokken partners en toegeleverde steun extra diensten zoals servers en theming Dit resulteert in volgende ruwe schatting van de kosten (inclusief data migratie en systeem 9 / 30 page(s)

10 1 Design BBOT ontwikkeling): Scenario 1: ± Scenario 2: ± Voor 1 combinatie Drupal-CA ± Voor elke extra combinatie ± Optioneel: grafisch werk (vormgeven van 1 website) ± Scenario 3: > Voor de ontwikkeling van een verbeterde module ± Voor 1 combinatie Drupal-CA ± Voor elke extra combinatie ± Ontwikkelen van de server is vooralsnog onbekend Het inhuren van onderhoud van de server ± Optioneel: grafisch werk (vormgeven van 1 website) ± Planning en management De huidige planning en management van MK is als volgt: MK heeft momenteel als doel om een gefaseerde ontwikkeling van de software in te lassen. Hierbij wordt op regelmatige tijdstippen software vrijgegeven (beta's en release candidates) opdat geïnteresseerden het project kunnen opvolgen en feedback geven. Het project wordt geschat op een jaar, afhankelijk van het gekozen scenario. Dit is inclusief het vrijgeven van de software, het migreren van de data en het bouwen aan een community. De gefaseerde ontwikkeling wordt begeleid door een website waarbij regelmatig updates worden gecommuniceerd aan de buitenwereld en geïntegreerd in sociale media. kan instaan voor de afhandeling van dagelijkse taken i.v.m. het management en de communicatie tussen de verschillende partners. Het staat uiteraard vrij voor partners om hier te ondersteunen indien gewenst. 10 / 30 page(s)

11 1 Design BBOT Partners die in het project meestappen worden verwacht een financiële bijdrage te leveren, gezien de integrale kostprijs niet kan dragen. Indien gewenst kunnen de partners meestappen in de dagelijkse afhandeling van het project management. Het is evident dat partners uitgenodigd worden om mee te stappen in de open discussie voorafgaand aan de ontwikkeling. 1.5 Openstaande vragen Zoals reeds geschreven, is bovenstaande een voorlopige visie op het project MK. Partners en mogelijks geïnteresseerden wordt gevraagd om hierop te reflecteren en bij te sturen waar nodig. Volgende vragen kunnen als richtlijn dienen: Is dit bedoeld als een langetermijnoplossing? Wat is de termijn van de ontwikkeling? Wat is de reikwijdte van dit project? Wie willen we als partner betrekken in de ontwikkeling? Wat is de financiële draagkracht van de partners? 11 / 30 page(s)

12 Appendices Appendix A Lijst van bestaande archiveringssystemen De volgende systemen zijn valabele systemen voor het bewaren van data en dienen te worden meegerekend in de beslissing voor de scenario's. Een uitstekende beschrijving van enkele van deze systemen is te vinden op volgende website: Volgende systemen zijn valabele kandidaten: Adlib AT Archon Calm Cuadra Eloq ICA-Atom M2A CollectiveAccess Past Perf MMBase 12 / 30 page(s)

13 Appendix B Scenario's software-ontwikkeling De ontwikkeling van het te kiezen systeem wordt hieronder verdeeld in drie scenario's. De beslissing welk scenario te volgen, kleurt de manier waarop het project gecoördineerd moet worden. De scenario's stijgen naar complexiteit (waarbij scenario 3 het meest complexe is), kosten (met scenario 3 het duurste), flexibiliteit (cf. toepasbaar voor verschillende soorten data) en ontwikkelingsduur (waar scenario 3 meer voorbereiding vraagt dan scenario 1). Elk van deze scenario's (met uitzondering van scenario 1) vraagt in min of meerdere mate ondersteuning van derden. Dit kan zowel financieel als logistiek zijn. De kostprijs voor het ontwikkelen van complexere systemen (cf. scenario 2 en scenario 3) is een tijdrovend proces en bijgevolg hogere kostprijs. In elk van onderstaande scenario's neemt een coördinerende dienende rol op zich. Het staat de verschillende partners vrij om te ondersteunen of een meer leidinggevende rol op te nemen. Scenario 1 is een scenario waarbij enkel een specifieke website wordt ontwikkeld samen met documentatie van dit proces. De ontwikkelde website is in staat om de data van te bewaren. De voornaamste kenmerken zijn de beperkte toepasbaarheid en een lage kostprijs. Dit minimale scenario wordt enkel uitgevoerd indien scenario 2 en scenario 3 (of varianten daarvan) onvoldoende draagvlak vinden.het systeem bestaat uit een enkele Drupal installatie en geen synchronisatie met robuuste archiveringssystemen. Scenario 2 is een combinatie tussen Drupal en CA (CollectiveAccess). Dit scenario laat toe om de data binnen te bewaren evenals de data van de partners. Het openstellen van dit systeem t.a.v. toekomstige partners is beperkt. Scenario 3 is evenzeer een combinatie tussen Drupal en CA met dit verschil dat de organisaties zelf geen technische achtergrond moeten hebben. Organisaties schrijven zich in en zijn in staat om op een makkelijke manier data te bewaren zonder zich te moeten toeleggen op het onderhoud van de data. Het systeem wordt onderhouden door een kerngroep van organisaties. 13 / 30 page(s)

14 Algemeen: project-specifiek vs. experten vs. niet-experten Scenario 1 De term 'project-specifiek' in scenario 1 verwijst naar de ontwikkeling van een website die gericht is op het bewaren van 1 specifiek project/organisatie. Hierbij wordt een specifieke data structuur ontwikkeld en geïmplementeerd in een Drupal website. Derden worden niet ondersteund voor het ontwikkelen van een systeem, het ontsluiten van data of het bewaren van data. Scenario 2 Scenario 2 heeft een bredere basis zowel voor de data als voor het systeem. Data van en partners worden in een data structuur gebracht, binnen een systeem dat een zekere expertise vereist om deze data in te voeren. Het design bestaat uit een Drupal installatie als front-end van het design en een CollectiveAccess (CA) als back-end archiveringssysteem. De combinatie Drupal-CA is een beproefde combinatie (cf. Vlaamse Kunstencollectie, Museum van Tervuren) en wordt ondersteund door de ontwikkelaars van CA. De beperking van dit scenario bestaat uit het feit dat dit design niet voldoende laagdrempelig is of kan gemaakt worden voor die organisaties en personen met een beperkte technische achtergrond. Dat is een gevolg van de beperktheid van CA om makkelijk en snel forms te bouwen die het bewaren van data vergemakkelijkt. Dit design is dan ook voornamelijk een robuust archiveringssysteem (CA) gekoppeld aan een systeem gericht op hoe de data te presenteren. Data in dit design wordt opgeladen binnen CA waarbij Drupal de data automatisch invoert en toont zoals door site admins vooraf bepaald is. Om data te bewaren en ontsluiten heeft men bijgevolg twee experten nodig: een CA expert dewelke forms kan bouwen en een Drupal expert die deze data op een aantrekkelijke manier kan tonen. In dit systeem is er geen data transfer van Drupal naar CA en worden alle metadata bewaard in CA. 14 / 30 page(s)

15 Scenario 3 Scenario 3 heeft de breedste basis waarbij het systeem toelaat om data in te voeren zowel in Drupal als in CA. Hierdoor zijn niet-experten in staat om data in te voeren waarbij metadata automatisch wordt toegevoegd aan de opgeladen data. Het verder verfijnen van een reeds bestaande module is de extra kost van dit scenario, net als het organiseren van de data bewaring. Data bewaring Data bewaring, wetenschappelijke ontsluiting en export van deze data is minder sterk uitgebouwd in scenario 1. Hoewel een Drupal website het toelaat data te annoteren (zowel met wetenschappelijke als persoonlijke thesauri), is het annoteren minder een prioriteit binnen de ontwikkeling van het systeem (cf. Drupal) als dusdanig. CA laat toe om deze data wetenschappelijk te bewaren dankzij ingebouwde metadata mogelijkheden. Data ontsluiting Voor elke Drupal website geldt dat de ontsluiting van de data een makkelijk en snel te ontwikkelen element is. Ontsluiting betekent dat de data makkelijk toonbaar is, dat het verbergen van velden en het verbergen van persoonlijke gegevens een evidentie is binnen het systeem. Let wel, een gescheiden systeem waarbij sommige data intern zijn (bv. gecomprimeerde bestanden), maar wel gelinkt zijn met extern te bezichtigen data (bv. thumbnails) is minder evident. Hoewel technisch mogelijk, is het systeem Drupal niet gebouwd voor zulke toepassingen. CA laat voorgaande wel toe. Ondersteuning derden De ondersteuning van derden (cf. partners, organisaties met soortgelijke data...) is voor scenario 1 beperkt tot een absoluut minimum: het uitschrijven van documentatie (developer's manual en user's manual). Dit is voldoende basis voor derden opdat ze kunnen evalueren of dergelijke ontwikkeling nuttig is. Dit betekent dat derden aangewezen zijn op de documentatie en dit voor zowel ontsluiting, archivering, webruimte als expertise. In essentie wordt hier een 'paper trail' georganiseerd van het proces van de 15 / 30 page(s)

16 website. Scenario 2 heeft een breder publiek, waarbij partners betrokken worden in de ontwikkeling van het systeem. Het systeem zal voor deze partners direct bruikbaar zijn. Scenario 3 laat toe, eens het systeem ontwikkeld, om andere organisaties directe toegang te verschaffen tot het systeem. Hoewel mogelijk, is het in scenario 3 niet langer noodzakelijk om de software zelf te installeren. Andere organisaties hebben met andere woorden de mogelijkheid om te leunen op de kerngroep die zowel het systeem als de data-bewaring organiseert. Data structuur De data structuur van het systeem beperkt zich in scenario 1 tot het bewaren van data zoals aanwezig binnen. Concreet betekent dit dat er per project (cf. categorieën) verschillende media (video, audio, beelden en tekst) bewaard worden, dewelke gekoppeld zijn aan profielen van personen en plaatsen. Deze vier data types (cf. categorieën, media, geo-locaties en personen) volstaan om de volledige database van uit te tekenen. Hierbij wordt op het vlak van beveiliging geen onderscheid gemaakt tussen interne/gevoelige data en externe data. Data die niet verondersteld wordt online te staan, wordt binnen Drupal afgesloten. Dit design laat eveneens toe om persoonlijke gegevens van individuen te beschermen. Dit is niet het geval voor scenario 2 en scenario 3, waarbij er partners met een divers profiel worden betrokken bij de ontwikkeling. Hierdoor wordt er een grote verscheidenheid aan data-structuren verzameld en is het systeem afgestemd op zulke verscheidenheid. Systeem De output van het systeem (cf. Drupal) is makkelijk te modificeren (theming) en dit met een beperkte technische achtergrond. Het systeem kan grote informatiestromen aan (cf. scalability) en is robuust genoeg om een hoog aantal bezoekers te verwerken. Het is echter beperkter in haar schaalvergroting voor het bewaren van data. Dit niet terwille van het systeem (cf. Drupal) als dusdanig maar terwille van onderhoudskosten van metadata dewelke vaak handmatig moeten worden onderhouden. Zoals voordien reeds vermeld, is metadata geen prioriteit binnen Drupal en het onderhouden van de standaarden is omwille van die redenen een struikelblok in schaalvergroting. Het mag duidelijk zijn dat Drupal een robuust en stabiel systeem is, met die nuance dat data-archivering geen kerntaak is van 16 / 30 page(s)

17 dit systeem. CA laat anderzijds toe om een volwaardig archiveringssysteem op poten te zetten. De nadruk op het scheiden van interne en externe data, het beveiligen van interne data, het wetenschappelijk archiveren van data staan hierbij hoog aangeschreven. Interoperability Het uitwisselen van data is binnen dit systeem robuust, waar het OAI PMH protocol (cf. een module in Drupal) een groot aantal gebruikers en ontwikkelaars achter zich staan heeft. Dat betekent dat, indien de metadata correct zijn, er exportmogelijkheden zijn die toelaten om de data zoals ze te vinden is in de DB te importeren via de standaard van OAI PMH. Bovendien is Drupal een vaak gebruikt systeem, wat betekent dat velen voldoende kennis hebben om de data te exporteren/importeren. Met CA komt daar een sterkere partner bij gezien het systeem niet enkel de export standaarden volgt, maar tevens een steeds groeiend aantal gebruikers krijgt. Een grotere poel aan gebruikers is, louter technisch, een groot voordeel gezien data-integratie moet afgestemd worden op slechts een enkel systeem. Open source Gezien Drupal een open source systeem is met een grote poel aan ontwikkelaars en gebruikers, is dit systeem uitermate geschikt om uit te breiden. De vele ontwikkelaars in binnen- en buitenland betekent dat men voor de ontwikkeling en opvolging niet afhankelijk is van slechts 1 firma met een expertise of licentie voor de software. De lage kostprijs is eveneens een pluspunt direct verbonden aan dit systeem. CA is evenzeer open source, maar heeft een duidelijk minder grote groep ontwikkelaars. De kostprijs en afhankelijkheid van specifieke ontwikkelaars is derhalve groter. Doelgroep De doelgroep van scenario 1 is beperkt tot (project-specifiek), waar er voor experts en wetenschappers slechts een beperkte relevantie is. Eind-gebruikers worden niet betrokken bij de ontwikkeling van het project. Scenario 2 richt zich op experten aangezien de gebruikers vertrouwd moeten worden met zowel Drupal als CA. Scenario 3 is gericht op eind-gebruikers, semi-experten en experten. Dit scenario laat toe om zowel wetenschappelijk te ontsluiten als om de eindgebruiker data te laten bewaren. Ontwikkeling systeem in functie van metadata 17 / 30 page(s)

18 Zoals voordien vermeld, slaat de ontwikkeling van metadata hier op het implementeren van metadata in het systeem. Drupal heeft standaard de Dublin Core, hoewel elke andere standaard relatief makkelijk kan toegevoegd worden aan individuele velden van de data. Drupal laat evenzeer toe om niet-standaarden toe te voegen. De robuuste module voor het OAI PMH protocol laat vervolgens toe om de data te exporteren. Nadeel van de constructie is echter dat deze metadata erg veel onderhoud vragen. Concreet betekent dit dat aanpassingen van de standaarden ertoe leidt dat deze handmatig (of semiautomatisch) moeten worden aangepast. Dit vergt een zekere expertise en is minder gebruiksvriendelijk dan andere constructies (cf. scenario 2 en scenario 3). CA aan de andere kant wordt afgeleverd met een sterke nadruk op metadata. Het invoeren van deze metadata via CA en het ontwijken van de implementatie in Drupal (door de standaarden in CA) verhoogt de metadata aanzienlijk. Onderhoud van het systeem Het systeem Drupal vergt slechts een beperkt onderhoud, met stabiele updates zoals gebouwd door de internationale community. Zoals hierboven reeds vermeld, vergt het onderhoud van de metadata meer tijd en geld. Ook CA heeft een poel van ontwikkelaars die op geregelde tijdstippen updates uitbrengen. Desondanks is CA een relatief jong project met enkele kinderziektes. Server Scenario 1 en 2 zijn niet gericht op derden om het systeem te ontwikkelen, data te bewaren of te ontsluiten. Dat betekent dat dit systeem slechts beperkte onderhoudskosten vergt. Set-up kosten beperken zich tot het aanmaken van een database op reeds aangekochte serverruimte. Onderhoud wordt door het hosting-bedrijf opgenomen en is deel van de service. Scenario 3 heeft dit wel opgenomen. Dit aangezien een gevoelige verbreding van de doelstellingen en doelpubliek een meer robuuste benadering vraagt voor het bewaren van data. Scenario 3 kan niet uitgevoerd worden zonder deze server-structuur aangezien de data te gevoelig en complex is. Het archiveren van het archiveringssysteem moet daarom door een groep van experten overzien worden. Extra features Drupal wordt vaak voorgesteld als een systeem uitermate geschikt om een user's community te bouwen. Evidente features als chat, mailinglists en mass- zijn omwille 18 / 30 page(s)

19 daarvan logischerwijze aanwezig. Hoewel document-management mogelijk is, is Drupal niet geschikt voor het beheren van documenten. De integratie van andere software is echter altijd mogelijk. Eindproduct Het eindproduct van scenario 1 is een website met een beperkte slagkracht, weliswaar stabiel en makkelijk aanpasbaar aan nieuwe noden. De aanwezigheid op het web is gegarandeerd voor ruwweg 4 jaar. Bovendien wordt het design gratis als een pakket aangeboden, samen met documentatie om het systeem aan te passen aan de noden van derden. Let wel, dit is een systeem met een beperkte 'scope' gezien een specifiek design. Noch hosting, noch directe ondersteuning is aangeboden in dit pakket. Scenario 2 levert als extra een systeem waarbij archivering een sterke nadruk krijgt. Scenario 3 ten slotte is de voorziening van een erg breed platform waarbij allerlei organisaties in staat zijn om met een minimum aan inspanning data te bewaren. Platform Het opbouwen van een breder platform is enkel van toepassing in scenario 3. Noch is er de intentie om een generisch systeem te bouwen dat direct kan gebruikt worden door derden. Ondersteuning sectoren Het systeem in scenario 1 is georiënteerd op en is daarom erg specifiek. Het enten van het systeem op de erfgoed-, sociaal-culturele of sociaal-artistieke sector is daarom niet van toepassing. Kosten Gezien de ontwikkeling louter voor relevant is, zijn er geen kosten voor derden tenzij deze het systeem willen aanpassen en dit zowel voor het grafische aspect (cf. theming) als voor extra features. Zie 1.3 Kostprijs voor een relatief gedetailleerd kostenplaatje. Planning Scenario 1 heeft een relatief makkelijke planning gezien de data structuur bekend is en er weinig tot geen moeilijke vereisten zijn voor het systeem. Het is evident dat dit scenario geen workshops, denktank noch consortium vereist. Scenario 2 en scenario 3 vragen meer voorbereiding. Desondanks is het realistisch om dit af te werken in 1 jaar tijd. 19 / 30 page(s)

20 Dependencies en uitbreidmogelijkheden Dit design steunt op het open source systeem Drupal. Uitbreiding is beperkt tot de mogelijkheden binnen Drupal, waarbij metadata veel tijd en aandacht zal vergen. In combinatie met CA wordt dit opgevangen en is de afhankelijkheid van ontwikkelaars van CA de voornaamste beperking. 20 / 30 page(s)