Publicatie:Event-based objectbeschrijvingen

Uit Cultureel Erfgoed Standaardentoolbox
Naar navigatie springen Naar zoeken springen


Samenvatting

Dit deelproject concentreert zich op het concept van events: clusters van informatie over wie, waar, wanneer een bepaalde handeling heeft gesteld met betrekking tot een kunstwerk. Het doel van dit project was te onderzoeken hoe de brede waaier van contextuele informatie over kunstwerken geclusterd kan worden in een generieke datastructuur, gecodeerd op een machineleesbare manier en herbruikbaar gemaakt worden voor webapplicaties. Het project onderzoekt de nieuwe mogelijkheden ontstaan wanneer je met die rijke informatie de levensloop van een kunstwerk te visualiseert?

Dit deelproject werd uitgevoerd door PACKED-medewerkers Alina Saenko, Pieter De Praetere, Bert Lemmens en jobstudent Nils Van Geele.

Het hele project werd uitgevoerd in de periode maart 2015 - oktober 2015.


Referentie
Titel Event-based objectbeschrijvingen (Voorkeurstitel)

Events (Afkorting)

Locatie
Uitgever
Jaar van uitgave 2016
Rechten CC-BY-SA
Persistent ID


Auteur(s)

  • Bert Lemmens (PACKED)
  • Alina Saenko (PACKED)
  • Pieter De Praetere (PACKED)

Partners

  • VKC, KMSKA, MSK Gent, Groeningemuseum,
  • CAHF, M HKA, Middelheimmuseum, S.M.A.K., Mu.ZEE,
  • LUKAS,
  • Collectie Vlaamse Gemeenschap

Projectverloop

Dit project maakt deel uit van het Persistente identificatie en open cultuur data (2015). Het project werd gerealiseerd met steun van de Vlaamse overheid. De resultaten van dit deelproject werden gepresenteerd aan de partners in oktober 2015 en gedetailleerd beschreven in het eindrapport:

Dit deelproject concentreert zich op het concept van events: clusters van informatie over wie-waar-wanneer een bepaalde handeling heeft gesteld met betrekking tot een kunstwerk. Het doel van het project was onderzoeken hoe de brede waaier aan bestaande contextuele informatie over kunstwerken geclusterd kan worden in een generieke datastructuur, gecodeerd op een machine-leesbare manier en persistent geïdentificeerd. Welke nieuwe mogelijkheden ontstaan er wanneer je die informatie in webapplicaties kan gebruiken om de levensloop van een kunstwerk te visualiseren.

Doelstelling

Dit project verkent een deel van de collectiedata uit de zeven musea dat vooralsnog weinig aandacht kreeg: gegevens over de wijze waarop het kunstwerk in een museum terecht is gekomen, welke weg het werk voordien heeft afgelegd, wie over het werk geschreven heeft, waar het werk ooit getoond is geweest, de conditie van het werk, de waarde van het werk, wat het werk precies afbeeld, etc. Deze informatie werd beschouwd als te onvolledig, te vervuild, te complex om in aanmerking te komen voor hergebruik in applicaties. Dit project maakt een betrouwbare inschatting van de omvang en kwaliteit van dit reservoir aan contextuele data en test een strategie uit om ze toegankelijk te maken voor ontwikkelaars. Daarbij wordt gebruik gemaakt van een eigenschap van het LIDO uitwissellingsformaat, namelijk events. Een event is een generieke container waarin je uiteenlopende informatie op een voor computers gelijkaardige manier kan verpakken door ze te ontleden in:

  • Wie is betrokken in het event?
  • Waar vond het event plaats?
  • Wanneer vond het event plaats?
  • Om welk type event gaat het?
  • Hoe wordt het event omschreven?

Door uiteenlopende contextuele informatie op een eenvormige manier te coderen, kan de omvang en kwaliteit beter gemeten worden, en kan deze informatie ook door webapplicaties gevisualiseerd worden met behulp van tijdlijnen, kaarten en diagrammen. Dit project onderzoekt ook of op deze manier vernieuwende perspectieven op de collectiedata geopend kunnen worden.

Methodologie

Bestaande collectiedata: exports en analyse

Events worden niet als dusdanig gedocumenteerd in een collectiebeheersysteem, maar zitten verscholen in de informatie over productie, verwerving, bruikleen etc van het object. Daarom werd bij aanvang van dit project onderzocht welke contextuele data geregistreerd wordt in het collectiebeheersysteem. In de interviews met de collectieverantwoordelijken en analyse van de dataexports werden de volgende vaststellingen gemaakt:

  • Het is niet evident om velden te identificeren in het collectiebeheersysteem die relevante data bevatten voor events. De registratie verschilt naargelang het museum en het systeem dat ze gebruiken. De beschrijvingsregels voor contextuele data zijn ook minder strikt dan voor de identificatiedata, waardoor verschillende beschrijvingspraktijken circuleren. Bijgevolg moest voor elke instelling een volledige data-export gemaakt worden om daarin de relevante velden met wie-waar-wanneer data te identificeren.
  • De digitale registratie van contextuele informatie in het collectiebeheersysteem gebeurt slechts fragmentair. Veel contextuele informatie wordt beheerd buiten de collectiebeheersystemen en/of in een niet-gestructureerde vorm. Deze data was voor het project niet bruikbaar om events te maken.
  • In interviews met de collectieverantwoordelijken werd voor de volgende event types aangegeven dat er event-gegevens terug te vinden zijn in de data-exports: vervaardiging (creator, production enz), opschriften, verwerving, eigendomsgeschiedenis, tentoonstellingen, bruiklenen, bibliografie, onderzoek, waardebepaling, verzekering, rechtenoverdracht, iconogafie (content, association), locatiecontrole, verplaatsingen (location.history, movement, despatch), verpakking (package), reproductie, conditiecontrole, volledigheidscontrole, conservatie aanvraag, restauratie (treatment), verlies/beschadiging, afstoting (disposal).

De verdere analyse van de data exports heeft uitgewezen hoeveel reële data voor deze event types aanwezig is om betekenisvolle visualisaties te bouwen.

Structureren van event-clusters in LIDO xml

Mapping naar LIDO xml

Voorbeeld LIDO-record

De analyse van de omvang en kwaliteit van events-data (m.n. of de data exports voldoende ‘feiten’ bevatten zoals persoon, datering en plaats om er events-clusters van te maken) werd gemaakt door de contextuele data uit de data exports te mappen naar LIDO. LIDO is een uitwisselingsformaat voor het online toegankelijk maken van collectiedata uit musea. Omdat LIDO hierarchisch en flexibel is opgebouwd, is het zeer bruikbaar voor beschrijvingen van verschillende types objecten, bv. kunst, architectuur, culturele geschiedenis en technologische geschiedenis. Op het hoogste niveau vormen alle gegevens over een object een LIDO record. In elke LIDO record is er ruimte voorzien voor administratieve en beschrijvende gegevens in de vorm van zeven wrappers, waaronder ook een Event-wrapper. Die wrapper geeft een mogelijkheid om verschillende soorten feiten uit de levensloop van een object generiek te structureren en dus eenvoudig herbruikbaar te maken. Om de mapping van de oorspronkelijke dataexports naar LIDO uit te voeren werd er in dit project gewerkt met de XML-editor Oxygen XML. Per instelling werd een XSL-bestand werd ontwikkeld voor de vertaling van de oorspronkelijke dataformaat van een collectiebeheersysteem naar LIDO. In dit project werd vooral met de mappings van Adlib exportbestanden naar LIDO gewerkt. De resultaten van die mappings werden gepubliceerd op Github. Daar kan men ook een voorbeeld van een LIDO-record vinden. op De vertaling van de verschillende CSV-bestanden uit TMS naar LIDO werd niet voltooid in dit project omdat de export procedure te tijdrovend en te complex was. Maar de set CSV-bestanden bleek ook te complex om binnen een redelijke termijn om te zetten naar LIDO. Voor elke partner-museum werd er een dataset gecreëerd met de oorspronkelijke data in vorm van LIDO-records en werden geanalyseerd ahv twee criteria:

  • Voor welk aandeel (%) van de objecten zijn er bepaalde type events aanwezig?
  • Welke gegevens zijn er voor data event aanwezig?

Tabel 'Events-data statistieken' bevat een overzicht van het aantal gecreëerde events per collectie en aantal ‘feiten’ die per event gekoppeld werden. Van die getallen kan men afleiden welke gebeurtenissen er per collectie goed in kaart worden gebracht en welke meer aandacht en meer contextuele data nodig hebben.

Persistente identificatie van events en contextuele data

De analyse van de data-exports wees ook uit dat voor geen enkel event-type persistente URI’s gedocumenteerd worden. Meestal omdat die voor het betrokken event-type niet bestaan (cf. vervaardiging, eigendomsgeschiedenis). Het project ontwikkelde een visie over het identificeren van events. De persistente identificatie van events is een technische noodzaak bij het beschikbaar stellen van collectiedata als linked open data. Maar het kan ook het potentieel voor hergebruik van collectiedata via de datahub gevoelig vergroten. Er zijn drie mogelijke strategieën om events persistente te identificeren. :

  • niet identificeren in de data die ter beschikking wordt gesteld, maar op het niveau van de applicatie
  • zelf PIDs voor events maken die beheerd worden door de collectie (via de resolver)
  • PIDs ontlenen aan externe bronnen

De keuze voor een strategie is afhankelijk van het type event en de omvang van de data:

  • als de omvang van de event data beperkt is, wordt deze best eerst aangevuld vooraleer een identificatieschema wordt opgezet. Dit sluit niet uit dat al gemapt wordt naar event-wrappers. Dit vormt meteen ook een stimulans om de beschrijvingsregels voor event data te verfijnen.
  • production, provenance, condition… : Dit zijn events die uniek zijn voor het object in de collectie en dus niet voorkomen bij objecten in andere collecties: de vervaardigingen van een object is uniek voor een kunstwerk in jou collectie. In andere collecties bevinden zich geen kunstwerken die deel uitmaken van hetzelfde event. Voor deze events kan de collectie dus optreden als autoriteit en valt de strategie om zelf persistente URI’s te creeren te verantwoorden.
  • exhibition & publication: Publicaties en tentoonstellingen zijn events waarin meerdere kunstwerken in verschillende musea betrokken zijn. Het lijkt ons verstandig om voor deze events persistente URI’s te gebruiken die beheerd worden door een externe autoriteit.
    • exhibition: op dit moment bestaat er nog geen centrale standaardterminologie die alle tentoostellingen in kaart brengt. Centrale databank zoals deze beheerd door Cultuurnet of ODIS hebben het potentieel om uit te groeien tot zo een externe autoriteit.
    • publication: Voor publicaties zijn zowel op regionaal als internationaal niveau verschillende externe autoriteiten actief. Er is ook een groeiende trend tot het onderling linken van deze autoriteiten. Het lijkt ons verstandig om aan te sluiten bij de autoriteit die de grootste dekking van de publicaties in je collectiedata garandeert. Van daaruit kan op termijn gelinkt worden naar andere autoriteiten. Worldcat, ISBN etc

Voor contextuele informatie zoals personen en plaatsten gelinkt aan een gebeurtenis werd er in dit project gebruik gemaakt van externe standaardterminologieen:

  • Voor personen in hebben we gebruik gemaakt van de normalisering die in het voorgaande traject plaats heeft gevonden waar we persistente URI’s van VIAF, RKDartists, Wikidata en ODIS hebben gebruikt
  • Voor plaatsnamen hebben we in dit project de API van Geonames uitgetest, waarbij we Geonames ID’s en coördinaten van plaatsen hebben opgenomen in onze dataset. Die data hebben we kunnen gebruiken om kaarten aan te maken bij de visualisaties (zie deel ‘Visualisaties’).

Voor de gebruikte GRELfuncties in Open Refine zie Handout Open Refine workshop

Visualisaties

Levensloop (screenshot 1)

Het doel van de visualisaties is om te demonstreren hoe je contextuele data kan gebruiken om nieuwe aspecten van je collectie zichtbaar te maken op het web. En daarnaast bieden events ook nieuwe mogelijkheden, vaak visueler en intuïtiever dan de klassieke zoekvelden, om je collectie doorzoekbaar te maken. Deze demonstratie moet ook uitwijzen of het gebruik van LIDO events de ontwikkeling van zulke visualisaties eenvoudiger maakt.
De visualisatiesoftware die gebruikt werd om deze visualisaties te bouwen is opgebouwd uit twee componenten. Enerzijds is er de component die verantwoordelijk is voor het verwerken en masseren van de oorspronkelijke export. Dit onderdeel is geschreven in Python en maakt gebruik van voornamelijk de XML en CSV-bibliotheken. De andere component zet de aangepaste data om in grafische visualisaties. De code hiervoor is grotendeels in Javascript (sommige onderdelen ook in Python), met gebruik van de nvd3 en d3-bibliotheken voor visualisatie. De broncode is te vinden op Github.

Levensloop (screenshot 2)


Voor het maken van de visualisaties op basis van de vijf event types, werd de de relevante collectiedata gemapt naar LIDO en verrijkt met informatie uit externe standaardterminologieen. De collectiedata werd door de acht instellingen enkel ter beschikking gesteld voor de duur van het project. Bijgevolg is deze data dus niet opgenomen in dit eindrapport. Een voorbeeldrecord van een LIDO record zoals gebruikt in de demo is te vinden op Github.


Levensloop (screenshot 3)

De visualisaties werden ontwikkeld op basis van vijf use cases:

1. Levensloop


Vraag: Wat is er doorheen de tijd met het kunstwerk gebeurd en waar is het kunstwerk te zien geweest?

De visualisatie heeft een vorm gekregen van een ‘facebook’-tijdslijn waar alle gebeurtenissen elkaar chronologisch opvolgen van oud naar nieuw, en waar er ook een kaart aanwezig is die de gebeurtenissen geografisch plaatst. Deze tijdlijn wordt mogelijk gemaakt door verschillende types gebeurtenissen op een zelfde manier te coderen in een LIDO-event, waardoor de applicatie, op basis van de ‘wanneer’-informatie in elk event, verschillende types events chronologisch kan rangschikken.

2. Gespecialiseerde tijdlijn (eigendomsgeschiedenis)

Eigendomsgeschiedenis (screenshot 1)


Vraag: Hoe is het kunstwerk doorheen de tijd van eigenaar verwisseld?

Deze visualisatie is een tweede type tijdlijn die zichtbaar maakt over welke periodes in het leven van een kunstwerk je wel of niet iets weet. Ze visualiseert een heel traditioneel gegeven uit het kunsthistorisch onderzoek, m.n. de pedigree. Meestal is die enkel beschreven in lijsten en teksten, maar op deze manier wordt het visueel toegankelijk gemaakt voor niet-experten. De registratie van eigendomsgeschiedenis in collectiebeheersystemen vertoont grote hiaten. Gegevens over de verwerving van een kunstwerk door het museum zelf is vrijwel volledig, hoewel die vaak dubbel wordt geregistreerd in ‘verwerving’ en in ‘eigendomsgeschiedenis’. De eigendomsgeschiedenis vóór verwerving is slechts sporadisch gedocumenteerd.

3. Kaarten (tentoonstellingen)

Kaart voor tentoonstellingen (screenshot 1)


Vraag: In welke landen hangt vandaag kunst uit de betrokken musea in een tentoonstelling en waar in de wereld zijn kunstwerken in het verleden getoond?

Deze visualisatie maakt gebruik van de geregistreerde informatie over bruiklenen en tentoonstellingen en toont de landen waar een kunstwerk uit een collectie werd tentoongesteld. De visualisatie maakt tentoongestelde werken zichtbaar per jaar. Hoe meer kunstwerken in één land tentoongesteld worden, hoe donker het land kleurt op de kaart. De visualisatie maakt zo zichtbaar hoe kunstwerken uit museumcollecties in de wereld over de hele wereld te zien zijn.


Acquisition Event - per museum (screenshot)


4. Herkomst van de collecties

Acquisition Event - voor meerdere musea (screenshot)


Vraag: Welke verzamelaars vormen de belangrijkste bron voor een collectie?

Deze visualisatie heeft twee versies:

4.1 Per museum: Deze visualisatie maakt gebruik van ‘acquisition events’, met name de events die de verwerving van een kunstwerk door één specifiek museum identificeren. De visualisatie toont de verschillende bronnen waaruit kunstwerken verworven werden (bvb particulieren, overheden, galeries, de kunstenaar zelf, etc) en hoe die bronnen zich in omvang tot elkaar verhouden. Men kan ook verder inzoomen op een type om te zien over welke personen of instellingen het gaat.

4.2. Voor vijf collecties samen: Voor deze visualisatie werden ‘acquisition events’ uit vijf musea samengebracht om te tonen hoe data van alle musea nieuwe inzichten oplevert over Vlaamse kunstcollecties als geheel.

Streamgraph voor objectnamen (screenshot)

5. Streamgraph (objectnaam/iconografie)


Vraag: Hoe belangrijk is een objecttype of voorstellingstype voor een collectie doorheen de tijd?

Voor deze visualisatie werd gebruik gemaakt van andere contextuele data per kunstwerk die niet rond een ‘event’ werd geclusterd, maar ook in een LIDO-record werd opgenomen: objectnaam, iconografie en vervaardigingsdatum. Op die manier kon deze visualisatie tonen dat het structureren van eender welke data over een object in vorm van LIDO nieuwe mogelijkheden biedt tot hergebruik. Deze streamgraph combineert namelijk ‘feiten’ over een kunstwerk die normaal gezien zelden naast elkaar worden geanalyseerd: trefwoord en vervaardigingsdatum. De visualisatie geeft een beeld van de verhouding tussen types van kunstwerken van een collectie doorheen de tijd. Voor onderzoekers en het breder publiek is dit een interessante inzicht in een collectie. De combinatie van vervaardigingsdatum en iconografie werd ook uitgetest in het kader van dit project om de vaak voorkomende thema’s in kunstwerken te kunnen visualiseren, maar er was onvoldoende data in de oorspronkelijke data-exports om te kunnen structureren in LIDO en uitspraken te kunnen maken over de volledige collectie.

Kosten-baten analyse

Tijdsinvestering

Eén van de doelstellingen van dit project was om te onderzoeken of het coderen van contextuele gegevens in events de ontwikkeling van vernieuwende visualisaties van collecties eenvoudiger maakt. Een belangrijk aspect hiervan is de omvang van de tijd en middelen die nodig zijn om collectiedata om te zetten naar een webapplicatie.
Voor dit project werd het aantal mandagen geregistreerd om:

  • Een analyse te maken van de vijf visualisaties die het project heeft gemaakt. Dit omvat het uitschrijven van use cases en het oplijsten van de functionele en technische vereisten voor elke visualisatie.
  • De bewerking van de data. Dit omvat het selecteren van de nodige metadata-elementen en het maken van XSL-bestanden om de collectiedata om te zetten naar LIDO.
  • De ontwikkeling van de webapplicaties. Dit omvat het schrijven van een parser die LIDO omzet naar een formaat dat door de webapplicatie geanalyseerd kan worden, de nodige open source softwarecomponenten bij elkaar zoeken om de visualisatie te maken en te testen.

De visualisaties werden gemaakt door twee projectmedewerkers: één ontwikkelaar en één data-beheerder. Hieronder volgt een overzicht van het aantal mandagen die voor PACKED vzw nodig waren om voor de vijf use cases visualisaties te maken.

  • Analyse: 2 personen/12 dagen = 24 mandagen (brainstorm/overleg met collectiebeheerders, ideeën uitschrijven voor de ontwikkelaar)
  • Data bewerking: 2 personen/32 dagen = 64 mandagen (datasets selecteren, data naar LIDO mappen, LIDO-data verder verrijken)
  • Ontwikkeling: 2 personen/25 dagen = 50 mandagen (LIDO-parser schrijven op maat van de visualisatie, visualisatiesoftware zoeken en testen, de visualisatie maken)

De broncode die in dit project geschreven werd is vrij beschikbaar voor hergebruik, waardoor een gelijkaardig project gebruik kan maken van de resultaten van dit onderzoek.

Sterkte-zwakte analyse

Aan het eind van dit project werd een zelf-evaluatie gemaakt waarbij de projectmedewerkers een een analyse van de sterktes en zwaktes van het project vanuit het standpunt van de musea. Voor deze zelfevaluatie werd vertrokken vanuit het volgende standpunt: Als een museum in een nieuw project zijn collectiedata (zowel de contextuele als de identificatiedata) zou omzetten naar LIDO en op basis van deze dataset zijn collectie visueel zichtbaar en doorzoekbaar zou maken:

  • Welke nuttige effecten heeft dat voor de collectie?
  • Welke schadelijke effecten heeft dat voor de collectie?
  • Welke kansen biedt dit aan de collectie?
  • Welke bedreigingen vormt dit voor de collectie?
nuttig schadelijk
interne factoren sterkte:
Het project maakt het mogelijk om één visualisatie te maken voor verschillende datasets uit verschillende musea.
Het project maakt het mogelijk om de collectie op een visuelere en intuïtievere manier doorzoekbaar te maken.
Het project maakt de geschiedenis van de collectie beter zichtbaar.
Het project maakt de context en de keuzes die gemaakt werden bij de vorming van de collectie beter zichtbaar.
zwakte:

Het project maakt de hiaten in de collectieregistratie intern zichtbaar. Als er weinig gegevens over bijvoorbeeld tentoonstellingen beschikbaar zijn, zal dit ook duidelijk worden in de beperkte omvang van de visualisatie.

Het project vereist een investering in tijd en middelen om de technische expertise in huis te halen die nodig is om de collectiedata te mappen naar LIDO en ze beschikbaar te stellen aan ontwikkelaars.
externe factoren kans:
Het project biedt de mogelijkheid om inhaaloperaties in de registratie beter te plannen, zowel in tijd, focus als omvang.
Het project biedt de mogelijkheid om de beschrijvingsregels voor contextuele data fijner te stellen, in overleg met andere musea.
bedreiging:
Het project maakt de hiaten in de collectieregistratie publiek zichtbaar.


Het project creëert de verwachting dat het museum de contextuele data op lange termijn beschikbaar houdt en verder verbetert. Ontwikkellaars willen LIDO niet gebruiken omdat het formaat te complex is en te tijdrovend om het te parsen.

Conclusies en aanbevelingen

In dit deelproject hebben we de contextuele data uit zeven collecties gemapt naar LIDO-events, verrijkt en vervolgens gebruikt om vijf use cases te vertalen in visualisaties van de collectiedata. Het doel van dit project was te testen of het LIDO-formaat, en in het bijzonder de event-wrapper, een bruikbaar instrument is om uiteenlopende contextuele data in een generiek dataformaat te coderen dat eenvoudig ingezet kan worden om nieuwe inhoudelijke perspectieven op de collecties te openen.
Op basis van dit project werden de volgende algemene vaststellingen gedaan met betrekking tot het gebruik van events voor het coderen van contextuele data:

1. Contextuele data over kunstwerken dient vervolledigd te worden
Voor een vijftal type events (vervaardiging, verwerving, eigendomsgeschiedenis, tentoonstelling en publicatie) is voldoende data aanwezig in de collectiebeheersystemen om op een betekenisvolle en vernieuwende manier collecties te visualiseren. Echter een groot deel van contextuele data over kunstwerken bevindt zich spijtig genoeg nog buiten de systemen en vaak in een niet-gestructureerde vorm. Aanbeveling:

  • De business case voor het mappen van contextuele data naar LIDO kan nog aanzienlijk versterkt worden als ook deze ‘analoge’ data digitaal te registreren. Hoe vollediger de data in de collectiebeheersystemen, hoe groter de impact van de visualisatie op de eindgebruiker. Op basis van de gegevens uit dit project kunnen instellingen deelprojecten opzetten om voor specifieke event types de lacunes in collectiedata weg te werken. De visualisaties van deze event types vormen een nuttig instrument om het resultaat van zo een deelproject meteen zichtbaar te maken.


2. Nood aan betere beschrijvingsregels voor contextuele data
De mapping van Adlib xml naar LIDO xml is gelukt, maar was tijdrovend door de subtiele verschillen in de structuur van de oorspronkelijke Adlib-exportbestanden en door de verschillende registratiepraktijk die in de musea bestaat voor contextuele data. Aanbeveling:

  • Door de beschrijvingsregels voor contextuele data in het MovE-invulboek aan te scherpen kan de kwaliteit van de data gevoelig verbeteren en wordt de mapping ook eenvoudiger.


3. Nood aan betere tools voor de mapping van contextuele data naar LIDO
Voor de mapping van data exports werd gebruik gemaakt van XSL en XSLT. Het gebruik van XSL werd als tijdrovend en complex ervaren. Het omzetten van XML-bestanden met behulp van XSL-bestanden vraagt veel tijd en rekencapaciteit. Aanbeveling:

  • Voor de uitwerking van een mappingprocedure in de praktijk, wordt aanbevolen om alternatieve mappingmethodes te onderzoeken die minder tijdrovend zijn en minder belastend zijn voor de IT-infrastructuur.


4. Ontwikkeling van visualisaties
De tools die gebruikt werden voor het visualiseren van de data (kaarten, tijdlijnen en diagrammen) blijken in de praktijk allemaal hun eigen dataformaat te gebruiken. Bijgevolg was in alle gevallen, naast de mapping van collectiedata naar LIDO, nog een bijkomende mapping nodig van LIDO naar het datamodel van de specifieke visualisatie. (bv. van Adlib/xml naar LIDO/xml naar een specifiek CSV-formaat). De mapping van collectiedata naar LIDO op zich maakt de ontwikkeling van visualisaties niet eenvoudiger, maar zorgt wel dat data uit verschillende systemen samengebracht wordt in één dataset. Van daaruit hoeft slechts één mapping gemaakt te worden naar een applicatie-specifiek formaat. Aanbeveling:

  • Om de mapping van LIDO naar een applicatie-specifiek formaat zo eenvoudig mogelijk te maken is de ontwikkeling van een standaard LIDO-parser noodzakelijk die het volledige gamma aan data dat gedocumenteerd kan worden in LIDO toegankelijk maakt.

Contactgegevens

Bert Lemmens
meemoo
Kleindokkaai 9a, 9000 Gent
bert.lemmens@meemoo.be
+32 (0)9 298 05 01

Alina Saenko
meemoo
Kleindokkaai 9a, 9000 Gent
alina.saenko@meemoo.be
+32 (0)9 298 05 01