WP4 - Demonstratieplatform

WP4 - Demonstratieplatform D4.5 Shared Repository

Authors

Kris Buytaert , Dimitri Vanoverbeke, Stijn Beauprez, Matthias Vandermaesen, Eline Van de Voorde, Filip Borloo, Bart Janssens, Gert Goossens

Document

WP4 D4 5 Shared Repository v1.doc

Date created

September 21, 2010

Inhoud 1

Documentstructuur ..................................................................................... 4

2

Management samenvatting ......................................................................... 4

3

Shared Repository, historiek ....................................................................... 5

4

MediaMosa .................................................................................................. 7

4.1

Installation .................................................................................................... 7

4.1.1 4.1.2 4.1.3 4.1.4 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2

Prerequisites ........................................................................................... 7 Installation steps ..................................................................................... 7 Features ................................................................................................. 8 Architecture ............................................................................................ 8 MediaMosa admin ........................................................................................... 9 Test overview.......................................................................................... 9 Server overview .....................................................................................10 Transcoding profiles ................................................................................10 MediaMosa frontend ................................................................................11 Pro‟s and Contra's .........................................................................................11 Pro .......................................................................................................11 Contra...................................................................................................12

5

Omeka ....................................................................................................... 13

5.1

Installation experiences..................................................................................13

5.1.1 5.1.2 5.2 5.2.1 5.2.2 5.3 5.3.1 5.4 5.4.1 5.4.2

Prerequisites ..........................................................................................13 Effective installation ................................................................................13 User experiences ...........................................................................................13 Admin Website user experience ................................................................14 Conclusion .............................................................................................15 Public Website user experiences ......................................................................16 Conclusion .............................................................................................16 Pro‟s and Contra's .........................................................................................17 Pro .......................................................................................................17 Contra...................................................................................................17

6

MediaMosa en Omeka gebruiken ............................................................... 18

6.1

Wat ? ...........................................................................................................18

6.2

Omeka .........................................................................................................18

6.3

MediaMosa ...................................................................................................18

7

Schaalbaarheid Omeka en MediaMosa ....................................................... 19

7.1

Omeka .........................................................................................................19

7.2

MediaMosa ...................................................................................................19

7.2.1 7.2.2 7.2.3 7.2.4 8

Overzicht ...............................................................................................20 ServerTypes...........................................................................................20 Metatag definities ...................................................................................20 Management Applicatie ...........................................................................20 Conclusie ................................................................................................... 21

Archipel – WP4 D4.4 Cloud Storage

Pagina 2 van 23

8.1

Situatieschets ...............................................................................................21

8.2

Probleemstelling ............................................................................................21

8.3

Oplossingen ..................................................................................................21

8.4

Gekozen oplossing .........................................................................................22


Pagina 3 van 23

1

Documentstructuur

Dit document behandelt de deliverable D.4.5: Shared Repository binnen werkpakket 4 (Demonstratieplatform) van het Archipel project. De tekst is als volgt onderverdeeld:

2

-

Hoofdstuk 2 bevat de management samenvatting.

-

Hoofdstuk 3 beschrijft het doorlopen onderzoekstraject en hoe tot de uiteindelijke oplossing werd gekomen.

-

Hoofdstukken 4 en 5 beschrijven vanuit technisch standpunt de twee softwareproducten die in aanmerking kwamen voor de shared repository: MediaMosa en Omeka. Daarbij wordt zowel de server als de front end geëvalueerd, en worden de pro‟s en contra‟s opgesomd.

-

Hoofdstuk 6 behandelt de gebruikerservaring. Hiervoor werd de Toneelstofcase bij VTi gebruikt.

-

In hoofdstuk 7 wordt de schaalbaarheid van beide oplossingen bekeken.

-

Hoofdstuk 8 omvat de conclusie.

Management samenvatting

Binnen het demonstratieplatform is er nood aan een eenvoudige oplossing om content op te nemen voor archivering en/of disseminatie. Deze oplossing is vooral bedoeld voor instellingen die zelf niet over de middelen en kennis beschikken om content digitaal op te slaan zodat deze ter disseminatie/archivering kan worden aangeboden. Daarom zijn we binnen WP4 op zoek gegaan naar een oplossing die ons in staat stelt om voor dergelijke partijen een oplossing aan te bieden. Die oplossing hoort bovendien op eenvoudige manier te kunnen worden „gedeeld‟ zodat instellingen zeer eenvoudig kunnen aansluiten. Tijdens de looptijd van het WP4 werkpakket zijn er een aantal mogelijke oplossingen uit de bus gekomen, met name Islandora, Hydra, Omeka en MediaMosa. Uiteindelijk is er geopteerd om met de laatste 2 verder onderzoek te verrichten op basis van een praktische casestudy, namelijk de VTi Toneelstof content. Na deze testen met Toneelstof ging onze voorkeur uit naar MediaMosa, een platform dat kan mee groeien met het Archipel platform maar ook onafhankelijk verder kan blijven bestaan na het project. Bovendien gaat het om een Open Source project waarop/rond verder kan worden gebouwd. MediaMosa werd verder ook getest door Kennisnet en Schoolnet in Nederland. De volgende stappen bestaan erin het business model verder uit te werken en MediaMosa te integreren in een gebruikersgericht platform.


Pagina 4 van 23

3

Shared Repository, historiek

Binnen het gemeenschappelijke platform wordt een shared repository opgezet. De bedoeling is dat kleine bewaarinstellingen die zelf geen eigen repositories onderhouden, hun digitale/gedigitaliseerde assets in de shared repository kunnen onderbrengen. Het digital asset management systeem dat de shared repository draagt is Fedora Commons. Via verschillende toegangspunten zouden instellingen materiaal kunnen transfereren naar de shared repository. Eén van die modi is een webbased toegang voor objecten met een beperkte omvang. Via een website zouden instellingen hun materiaal kunnen uploaden en beschrijven. Het onderzoek concentreerde zich voornamelijk op de mogelijkheden die bestaande software biedt, om snel een oplossing te realiseren. Een mogelijke kandidaat was het Islandora project (http://islandora.ca/) Dit is een set van modules die Fedora Commons integreert met Drupal. Binnen de Islandora context wordt Drupal niet beschouwd als een op zichzelf staand content management framework maar louter als een webbased I/O interface tot Fedora Commons. In deze aanpak liggen een aantal sterktes en zwaktes. Dankzij de goede ondersteuning (documentatie, fexibele API's,...) van Drupal was het voor Islandora mogelijk om het project snel te realiseren. Drupal is een project met een grote visibiliteit wat erfgoedinstellingen sneller over de streep zal trekken om voor Islandora te kiezen. De Drupal API's zijn echter gebouwd bovenop de premise dat de (inhoudelijke) data bewaard wordt in een database waarvan de structuur opgebouwd is op basis van een vooraf door Drupal gedefnieerd relationeel datamodel. Fedora Commons werkt eerder op basis van een object georiënteerd, flexibel model. Door de conceptuele verschillen tussen beide modellen, is het zeer moeilijk om de Drupal API's toe te passen buiten het relationele referentiekader. Drupal's Node API is nauw verweven met Drupal's database abstractie laag. Contributed modules zoals CCK, Views, Panels, Display Suite,... zijn juist rond deze API's opgebouwd maar bevatten geen of onvoldoende ondersteuning om met externe databronnen om te gaan. Ook andere API's en subsystemen binnen Drupal die bovenop de Node API zijn gebouwd kunnen niet zonder meer worden gebruikt om externe data te verwerken. Dit blijkt ook in de manier waarop de Islandora modules zijn opgebouwd. Er wordt geen gebruik gemaakt van de drupal API's die met inhoudelijke data omgaan. Fedora Commons wordt door Islandora benaderd via een aantal hard coded SPARQL queries om data op te halen. In plaats van gebruik te maken van Drupal's native Theme API om de resultatenset vorm te geven, wordt er gebruik gemaakt van XSLT. De XSLT stylesheets worden bijgehouden in Fedora. Deze XSLT's zelf aanpassen om tegemoet te komen aan de specifeke vereisten voor de shared repository kost meer tijd en moeite. Voor de opbouw van de invoerformulieren gebruik gemaakt van de Form API. Op basis van de objectdefinities in Fedora worden deze formulieren dynamisch gegenereerd, maar de mapping zelf gebeurt op een weinig flexibele wijze.

De Islandora module voorziet onvoldoende hooks die third party developers toe laten bovenop Islandora verder kunnen bouwen. Zo is het bijvoorbeeld onmogelijk om de SPARQL queries aan te passen zonder de Islandora module zelf te veranderen. De Islandora modules zijn echter ook kwalitatief niet zeer leesbaar. De code is nauwelijks gedocumenteerd en er worden verschillende coding styles gehanteerd. De conclusie van het onderzoek was dat Islandora een goede oplossing is voor projecten waarvan de requirements binnen de featureset van de modules vallen, maar dat het aanpassen van Islandora project voor specifeke vereisten niet aangewezen is.


Pagina 5 van 23

Islandora bleek uiteindelijk niet geschikt voor de shared repository. Er werd besloten om een alternatieve oplossing te zoeken. Het Hydra project was één van de pistes, maar voor implementatie hiervan ontbrak de kennis bij de technologiepartners. Daarom zijn we op zoek gegaan naar bestaande oplossingen waaruit Omeka en MediaMosa de meest valabele kandidaten leken. Op basis van een concrete case werden beide producten met elkaar vergeleken.


Pagina 6 van 23

4

MediaMosa

MediaMosa is software to build a Full Featured, Webservice Oriented Media Management and Distribution platform. With MediaMosa you can build a state-of-the-art, scalable Middleware Media Distribution Platform which facilitates access to, and usage of (shared) storage capacity, metadata databases, transcoding- and streaming servers. A MediaMosa platform offers functionality for searching, playing, uploading, transcoding, as well as a fine granularity media access control system towards its users. MediaMosa is based on the Representational State Transfer (REST) architecture and is designed to support content streaming applications by providing a back-end-, audio- and video-infrastructure.

4.1

Installation

Installation of the MediaMosa backend is quite straightforward. You can download a .tar.gz package from the MediaMosa website. The current stable version is 1.7.4 which has been build on drupal 6. The 2.1 release which is currently in alpha will use drupal 7.

4.1.1 Prerequisites ● ● ● ● ● ● ●

Linux Apache2 (mod_rewrite enabled) Mysql-server PHP5 PHP5 extensions: 'bcmath', 'gd', 'mcrypt', 'curl', 'mysql', 'mysqli', 'SimpleXML' FFMPEG: 'php5-ffmpeg' LUA: 'lua5.1', 'liblua5.1-lpeg1', 'liblua'

4.1.2 Installation steps ● ●

Create an apache vhost or copy the package contents to the apache documentroot. MediaMosa comes with a drupal installation profile which will guide you trough the installation. You will need to create 3 databases and a mysql user:

CREATE USER memo@'%' IDENTIFIED BY 'yourpasswd'; CREATE USER memo@'localhost' IDENTIFIED BY 'yourpasswd'; GRANT USAGE ON * . * TO 'memo'@'%' IDENTIFIED BY 'yourpasswd' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ; CREATE DATABASE memo DEFAULT CHARSET=utf8; CREATE DATABASE memo_data DEFAULT CHARSET=utf8; CREATE DATABASE memo_jobserver DEFAULT CHARSET=utf8; GRANT ALL ON `memo`.* TO 'memo'@'%'; GRANT ALL ON `memo\_data`.* TO 'memo'@'%'; GRANT ALL ON `memo\_jobserver`.* TO 'memo'@'%';

● ● ●

Move sites/default/default.settings.php to sites/default/settings.php and make it writable. Also make a directory sites/default/files and make it writable. For the database configuration use the memo database and the created mysql user. Configure the Drupal website by giving a site name, email-address and user account to create.


Pagina 7 van 23

●

It is possible that MediaMosa can't find LUA. MediaMosa currently checks for version 5.1.4. It is possible that you have 5.1.3 installed. You can trick MediaMosa by changing profiles/MediaMosa.profile: define('MEDIAMOSA_TEST_LUA', 'Lua 5.1.4 Rio');

Copyright (C) 1994-2008 Lua.org, PUC-

into define('MEDIAMOSA_TEST_LUA', 'Lua 5.1.3 Rio');

●

Copyright (C) 1994-2008 Lua.org, PUC-

Update the php5 settings with the settings provided by the wizard. PHP error_reporting should be set at E_ALL & ~E_NOTICE. upload_max_filesize should be at least 100M. Currently: 2M post_max_size should be at least 100M. Currently: 8M max_input_time should be at least 7200. Currently: 60 max_execution_time should be at least 7200. Currently: 30

● ● ●

Create a directory /srv/MediaMosa which will serve all the media files and make it writable by the apache user. The wizard should now give you instructions on how to setup cron. And how to configure apache for the mediafiles directory. MediaMosa is now installed

4.1.3 Features ● ● ● ●

Provides a storage platform for any type of content Streams Flash, H.264 MPEG-4 and Windows Media Transcoding based on FFmpeg Flexible Metadata Element Sets

4.1.4 Architecture MediaMosa is built on a SOA(Service Oriented Architecture).

The most important part of the backend are the web services. A little overview:

● ● ● ● ● ● ● ● ●

Video playback (PlayProxy HTML wrapper) Authentication (D-Bus for EGA) Authorisation (domain, realm, group or a combination) Upload (PUT, POST, FTP) Transcoding (converting media files from one format to another) Media Management Search function: Contextual Query Language (CQL), level 2 OAI-PMH: DC, QDC, LOM, CZP Logging and statistics


Pagina 8 van 23

●

4.2

Automatically generates stills

MediaMosa admin

4.2.1 Test overview Here you can see a small set of important tests. These tests are run each minute using the cron job.


Pagina 9 van 23

4.2.2 Server overview At the server overview you can add extra servers for streaming, transcoding, download, upload and stills.

4.2.3 Transcoding profiles With MediaMosa it is possible to create different transcoding profiles and assign them to a certain application.


Pagina 10 van 23

4.2.4 MediaMosa frontend Normally MediaMosa doesn't come with a real frontend application. For testing or as a template you can use the WLE (White Label End-user application). This can be downloaded from the MediaMosa website. The WLE is also build on top of drupal. Making it easy to install and easy to use as a template for another End-user application. There are two main features: 

Uploading media



Browsing and watching media

When you upload media you can give extra meta information, which then can be used to search mediafiles.

4.3

Pro’s and Contra's

4.3.1 Pro 

Easy to install with a nicely guided installation



Service Oriented Architecture(SOA) using REST this makes MediaMosa usable in a lot of different applications and programming languages


Pagina 11 van 23



It is possible to create extra webservices using drupal modules



Many configuration options



Actively developed



Each functionality has tests making MediaMosa very reliable



Streaming



Scalable

4.3.2 Contra 

Because of the many options, lot's of configuration has to be done.



Still some small bugs


Pagina 12 van 23

5

Omeka

Omeka is a professional free/opensource media publishing project. The core is based on php and linked to a mysql database. Omeka is currently used in several organizations:

● ● ●

Yaddo, New York Public Library Lincoln at 200, Newberry Library and Chicago History Museum Inventing Europe, European Science Foundation and the Foundation for the History of Technology

Omeka is working on this project based on the Dublin Core Metadata standard.

5.1

Installation experiences

Installation of Omeka is quite straightforward. It consists of a .tar.gz which needs to be unpacked in the document root of the Apache webserver.

5.1.1 Prerequisites Several applications need to be ready before we can go further in the installation path.

● ● ● ● ●

“Your favorite Linux blend” Apache2 (mod_rewrite has to be installed) PHP Mail system MySQL

Postfix is not 100 % necessary. It is although very important that the system is able to send mail out.

5.1.2 Effective installation The installation itself is based on a wizard. Of course it will request you for some system settings, please remember that you will need to modify some system variables (e.g. php.ini) and permissions. The installer will though point you to all different settings that are needed. Further on you need to fill in details regarding admin users, sitenames and etc.

Plugins and Themes Omeka can be modified using several Plugins and themes.

5.2

User experiences

For the test of Omeka at Archipel, we tried to setup several mediafiles to see what the exact look and feel is of the environments installed. It is very important to understand what kind of useraccounts exist.

● ● ● ●

Admin: The ring bearer Super: Can create content and provide users with access Contributor: Can create content Researcher: Can browse content and modify content

Depending on what users you have, you have fully predefined rules. Below I will describe some of the tests I did.


Pagina 13 van 23

5.2.1

Admin Website user experience

You have a different login page on the Omeka website: (http://Youromekaserver.country/admin/). The login page is not modifiable.

After login you will find several possibility in the sidebars and upper bars:

These give you the possibility‟s to add items, and other functions you have Installed (plugins). Next to this you have a very clear and usable dashboard which can give you links to the important parts of the application. The problem with the dashboard is that it has no user functionality to change the dashboard in any way.

You have several types of content:

● ● ●

Exhibitions (Exhibition plugin is standard but deactivated) Collections (A collection can have several items) Items (An item can be in only one collection or can be a separate entity)

As this application is based on a the Dublin Core Metadata convention you will need to provide quite some information regarding the data you are plugging in. Every item has to be declared fully.

You can choose between following formats to add data: ac,aif,aiff,asf,asx,avi,bmp,c,cc,class,css,divx,doc,docx,exe,gif,gz,gzip,h,ico,j2k,jp2,jpe,jpeg, jpg,m4a,mdb,mid,midi,mov,mp2,mp3,mp4,mpa,mpe,mpeg,mpg,mpp,odb,odc,odf,odg,odp, ods,odt,ogg, pdf,png,pot,pps,ppt,pptx,qt,ra,ram,rtf,rtx,swf,tar,tif,tiff,txt, wav,wax,wma,wmv,wmx,wri,xla,xls,xlsx,xlt,xlw,zip

Adding data is quite easy, as is creating a new item. See the screenshots below:


Pagina 14 van 23

5.2.2 Conclusion In all, the user experience on the admin page is adequate. The simplicity in design gives you a possibility to let users upload and manage files. Through some plugins a lot of extra functionality is possible.


Pagina 15 van 23

5.3

Public Website user experiences

The public does not require any authentication. The exhibits and items that are publicly shared are viewable on the website.

Every public user can browse through collections and items that are public. Featured items and collections will be visualized in the mainpage. If you visit an Item you will see that your browser will visualize the files if it is video or music media, in the other perspective it will show a link for text or pdf files. It will use your browser and computer functionality it has no streaming server or technology provided.

5.3.1 Conclusion The public interfaces are a bit too simple in regards to the functionality required. Although it can provide all sorts of mediafiles, it is one big issue that the file functionality is limited to the users computer infrastructure. This means that actually the user can download the provided files without any authentication and can retrieve the files provided quite easily.


Pagina 16 van 23

5.4

Pro’s and Contra's

5.4.1 Pro ● ● ● ●

Very easy to install and manage: The installation requires a standard LAMP environment. In the end installation is moving the files in the document root. Installation will be completed by filling out the parameters forms. Dublin core metadata standards:This metadata is a standard used in library and other official institutions for identifying and archiving data. Nice plugin functionality and easy install of plugins and themes Several plugins are available for extra functionality

5.4.2 Contra ● ● ● ● ●

Very limited user interface, not modifiable: Additional programming is necessary to modify the source. No streaming server: The data on the server is provided as a file. No other functionality is provided by default. Limited user experiences Limited admin experiences Some php settings need to be tweaked without it being mentioned in documentation

The installation is quite simple but when using the application it is quickly visible that some of the php.ini parameters need to be modified just to be able to upload normal filesizes.


Pagina 17 van 23

6 6.1

MediaMosa en Omeka gebruiken Wat ?

Concreet werd het gebruik van MediaMosa en Omeka afgetoetst aan de hand van een concrete case, met name de Toneelstof content. Vanuit Vti heeft men zijn ervaring gebundeld en hier weergegeven. Zowel in MediaMosa als Omeka werden 10 fragmenten van Toneelstof interviews ingevoerd. Deze fragmenten werden opgeladen in 3 formaten: quicktime, flash, MP4.

6.2

Omeka

Op zich is Omeka gemakkelijk in gebruik. Je hebt wat uitleg nodig voor je eraan begint, om te weten waar je bepaalde informatie moet invullen. Het enige probleem met Omeka is dat je verschillende onderdelen hebt bij een file: Dublin Core, Item Type Metadata, Collection, Files, Tags. Je moet elk onderdeel apart invullen en apart opslaan. Dit betekent dat je telkens terug moet naar het bestand om het juiste onderdeel te kiezen en dat te bewaren. Hierdoor verlies je veel tijd. Het opladen zelf lijkt ook erg traag te gaan.

6.3

MediaMosa

De gebruiksvriendelijkheid van MediaMosa is beter dan die van Omeka. Zaken opladen bij Omeka is tamelijk omslachtig en neemt meer tijd in beslag. MediaMosa is duidelijker en je moet niet elke keer terugkeren naar het resultaat. Je kan alle informatie meteen invullen en dan een bestand toevoegen, om een tweede bestand toe te voegen moet je dan terug naar het resultaat zoals ook bij Omeka. Aangezien we op VTi met Drupal werken, is de manier van werken van MediaMosa me niet vreemd. In het geheel lijkt het invullen van data en het opladen van fragmenten me minder omslachtig bij MediaMosa en het lijkt ook sneller te gaan. Het uiteindelijke resultaat bij MediaMosa is ook veel overzichtelijker. Je ziet goed wat je hebt opgeladen (welk formaten en dergelijke), alle info staat in een overzicht naast het fragment. Bij Omeka is de layout wat slordiger, zodat je minder snel kan zien of alles wat er moet opstaan er ook werkelijk staat.


Pagina 18 van 23

7 7.1

Schaalbaarheid Omeka en MediaMosa Omeka

Currently Omeka has no built-in functionality providing the ability to split up instances. The procedure is currently still not existant. Also currently no examples can be portrayed. It is in this case very difficult/almost impossible to split up instances and link the uploader and other metadata to the appropriate files. The current DB is difficult to modify as it has not yet been clearly investigated by the Omeka developers, how to extract this sort of information. A multi site version of Omeka is in the process of being developed, although no timeframe is available yet. Currently Omeka won't support application scaling. The inability to split up or merge isolated instances makes it in our perspective not a good solution for the Archipel project.

7.2

MediaMosa

Omdat Mediamosa een service is maakt het gebruik van app id's om verschillende clients te authenticeren. Elke client kan meerdere collections hebben met meerdere assets. In Mediamosa is het mogelijk om meerdere servers toe te voegen om de capaciteit te verhogen. De service calls passeren wel eerst nog langs de Mediamosa server. Standaard wordt dezelfde Mediamosa server gebruikt voor meerdere clients.


Pagina 19 van 23

7.2.1 Overzicht

7.2.2 ServerTypes ● ● ● ●

Streaming Server Download Server Upload Server Transcoding Server

7.2.3 Metatag definities Om globale metatags te hebben tussen de verschillende clients kan er gebruik gemaakt worden van globale metatag sets. Standaard zijn dublin core, qualified dublin core en CZP aanwezig als metatag definities. Het is mogelijk zelf metatag definities toe te voegen maar dit moet wel gebeuren in de database. Het is ook aan te raden deze te maken onmiddelijk na de installatie van MediaMosa.

7.2.4 Management Applicatie Het is mogelijk om voor MediaMosa een management applicatie te maken. Deze kan dan toegang hebben tot meerdere collections van meerdere clients.


Pagina 20 van 23

8 8.1

Conclusie Situatieschets

Archipel vertrekt vanuit de vaststelling dat in Vlaanderen een duurzame digitale archiefinfrastructuur nodig is om de problematiek van digitale archivering structureel aan te pakken. Daarenboven veronderstelt dit project dat in de ontwikkeling van deze infrastructuur een belangrijke rol is weggelegd voor actoren in het domein van de kunsten, het cultureel en wetenschappelijk erfgoed en het onderwijs. In dit onderzoeksproject willen we nagaan wat het concreet betekent om binnen een gedecentraliseerde Vlaamse digitale archiefinfrastructuur een duurzaam digitaal archief van diverse (complexe) digitale en multimediale objecten te implementeren.

8.2

Probleemstelling

Hoe meer inhoud we krijgen vanuit de sector hoe waardevoller het aanbod vanuit Archipel wordt. In zeker zin kan je Metcalfs law toepassen die poneert dat de waarde van een netwerk kwadratisch toeneemt met het aantal aangesloten nodes. In het kader van Archipel betekent dit dus dat hoe meer partners hun archief digitaliseren en aansluiten op onze architectuur, des te waardevoller ons platform wordt. Maar in de context van de Vlaamse cultuursector is het niet realistisch te veronderstellen dat de verschillende instellingen zelf de nodige infrastructuur kunnen uitbouwen om dit te doen. Vandaar het idee om een “shared repository” aan te bieden. Deze centraal beheerde oplossing moet kleinere organisaties toelaten zelf een archief aan te maken en te beheren, zonder de kost en complexiteit die daar typisch mee geassocieerd wordt. Om te verzekeren dat we verder in het project de nodige inhoud zouden hebben om ons platform te testen werd dit deel van het project naar voor geschoven.

8.3

Oplossingen

Tijdens de voorbereiding van het project werden een aantal technologieën gekozen op basis van de kennis van de verschillende partners en compatibiliteit met Fedora Commons, één van de toonaangevende technologieën rond archivering. Fedora zou worden gebruikt voor de opslag en bewaring van de collecties maar moest worden gecombineerd met een meer gebruiksvriendelijke front-end oplossing. Onze eerste keuze was Islandora, een op Drupal gebaseerde oplossing die ontwikkeld werd door de University of Prince Edwards Island in Canada. Jammer genoeg bleek deze oplossing reeds bij installatie niet te voldoen. De technologie werd ontwikkeld voor onderzoeksdoelstellingen maar was nog lang niet klaar voor eindgebruikers. De volgende optie was om zelf een aantal van de concepten en ideeën uit Islandora uit te werken. Deze optie was niet haalbaar binnen de voorziene middelen zonder andere delen van het project in gevaar te brengen. Een ander veelbesproken platform binnen de sector is Hydra. Door hun modulaire aanpak en architectuur leek het de meest geavanceerde oplossing op basis van Fedora. Jammer genoeg hadden zij gekozen voor Ruby on Rails, een technologie waarvan geen van de partners in het consortium de nodige expertise in huis had. Verschillende scenario's werden geëvalueerd maar uiteindelijk was de concensus binnen het team dat we een oplossing moesten zoeken waarin we allemaal thuis waren. Daarnaast werd ook besloten om de link met Fedora niet meer als absolute voorwaarde te stellen. Het voordeel van Fedora was haar flexibiliteit om over de verschillende collecties heen te kunnen werken, maar dit was niet van toepassing in onze architectuur omdat al dat soort taken door de middleware zouden worden opgevangen. Ondertussen gebruiken we Fedora Commons als deel van deze middleware.


Pagina 21 van 23

Eens verlost van Fedora Commons konden we meerdere oplossingen overwegen, wat leidde tot een shortlist met MediaMosa en Omeka. Tijdens het afgelopen traject hebben we deze twee oplossingen geëvalueerd op technische betrouwbaarheid en gebruiksgemak voor wat betreft het beheer en het dagelijks gebruik.

8.4

Gekozen oplossing

Uiteindelijk ging onze voorkeur uit naar MediaMosa, een platform dat kan meegroeien met het Archipel platform, maar ook onafhankelijk verder kan blijven bestaan na het project. Bovendien is het een Open Source basis waarop/rond verder kan gebouwd worden en is het “tried and tested” door Kennisnet en Schoolnet in Nederland. Dit was ook de conclusie van de testen met Toneelstof bij VTi. De volgende stappen zijn de verdere uitwerking van het business model en de integratie van MediaMosa in een gebruikersgericht platform.


Pagina 22 van 23

Bronvermelding Nr

Naam

URL

1

Omeka Site

http://www.omeka.org

2

MediaMosa Site

http://www.mediamosa.org

3

MediaMosa Documentation

http://www.mediamosa.org/sites/default/files/Mediamosa_an_introduction. pdf

4

MediaMosa Installation Presentation

http://www.slideshare.net/MediaMosa/mediamosa-installatie-configuratie

5

Omeka Mailinglist

http://groups.google.com/group/omeka-dev


Pagina 23 van 23

WP4 - Demonstratieplatform

Recommend Documents