Integratie van Kunstenpunt databanken: schema’s en API
Enkele weken geleden ben ik begonnen bij Kunstenpunt. Een van de uitdagingen ligt in het integreren van drie “legacy” databanken, die de artistieke activiteiten van podiumkunstenaars, beeldend kunstenaars en muzikanten beschrijven. De artistieke activiteiten die nu in focus zijn, zijn binnenlandse premières en buitenlandse vertoningen van podium producties, CD/Vinyl/… releases en buitenlandse concerten voor de muzieksector, en tentoonstellingen, residenties, kunstopdrachten en opleidingen van beeldend kunstenaars.
Databank integratie is nooit gemakkelijk. Een tijdje geleden publiceerde ik, in het kader van mijn vorige job bij Sirris, met een aantal andere mensen een artikel over dit probleem. In dat artikel gaat het niet over kunst, maar over foutmeldingen van zonnepanelen. Hoe soms industrie en kunst dicht bij elkaar kunnen liggen…
Oplossingen
Grof gezegd zijn er twee mogelijke oplossingen. De eerste oplossing is om een standaard af te dwingen: vanaf dan moet iedereen zijn gegevens op dezelfde manier verzamelen, geen discussie. De tweede oplossing is om een zogenaamd mediërend schema te gebruiken dat alle data modellen omvat, en om dan een mapping van elk onderliggende data model naar het mediërende schema te definiëren.
De eerste oplossing is duurzaam, maar is moeilijk door te voeren en kost veel ontwikkelingstijd. Je moet bovendien de al bestaande data ook gaan omzetten naar het nieuwe standaardschema. De tweede oplossing is sneller te implementeren, maar is minder duurzaam omdat bij elke verandering in de onderliggende datamodellen de mapping moet geherdefinieerd worden. Bovendien is het mogelijk dat je in het mediërende schema een aantal beperkingen hebt ingebouwd, waardoor je niet de hele functionaliteit van je databank kan halen.
Bij het Kunstenpunt heb ik voorgesteld om een soort van hybride oplossing na te volgen. De gegevens van de beeldende kunsten (tentoonstellingen, kunstopdrachten, residenties, etc.) waren vrij gemakkelijk onder te brengen in het bestaande datamodel van een podiumproductie. En buitenlandse concerten van muziekmakers passen ook in dat model. Voor die gegevens vervolgen we daarom de “standaard” oplossing, waarbij alle datapunten volgens hetzelfde datamodel in dezelfde databank komen.
De gegevens van de “releases” (CDs, platen, vinyl, etc.) van muzikanten zijn echter veel moeilijker te vatten door het podiumkunsten data model. Om die integratie te doen volgens de eerste oplossing is er nog veel werk aan het definiëren van een standaard data model. Daarom gaan we voor dit laatste stuk aan de slag met de tweede oplossing: een mediërend schema.
Van mediërend schema tot API
Het boeiende aan dit mediërende schema is dat het tegelijkertijd ook de specificatie kan zijn van een API die de gegevens van podiumkunstenaars, beeldend kunstenaars en muzikanten tegelijk ontsluit. In een ander artikel zal ik dieper ingaan op de structuur van de API en het mediërende schema.
Geïnteresseerden kunnen alvast een kijkje nemen naar de specificatie (work in progress!) van de API (nog niet volledig geïmplementeerd) op GitHub (je kan deze file mooi visualiseren in editor.swagger.com. Commentaar altijd welkom.
De API specificatie volgt de Swagger specificatie, die tegenwoordig bekend staat als de openAPI specificatie van het open API initiatief. Het is een genot om de API specificatie te schrijven in de swagger editor, om dan onmiddellijk de documentatie te zien.
Ben je geïnteresseerd in de boeiende technologische uitdagingen die we bij het Kunstenpunt aangaan? Volg me op twitter!
