Twitter
MailinglistChallenge vragen
 De Vereniging van Letterkundigen tijdens een buitengewone ledenvergadering. Nationaal Archief, Den Haag, Anefo, 1986, nummer toegang 2.24.01.05, bestanddeelnummer 933-6301, licentie CC-BY-SA. De afgelopen weken zijn er vragen binnengekomen over de eisen voor een succesvolle pitch voor de Challenge. Aan welke eisen moet een prototype voldoen en moet de Open Cultuur Data API in dit prototype al gekoppeld zijn? Het antwoord hierop is tweeledig, maar alvorens in te gaan op wat er wel en niet verwacht wordt, eerst een toelichting op de criteria uit de spelregels…
Een prototype is een bewijs dat iets technisch te implementeren is en maakt duidelijk op welke manier een eindgebruiker de applicatie kan gebruiken (de beoordeling hiervan is natuurlijk wel afhankelijk van de expertise van de beoordelaars!). De reden dat we een werkend prototype als criterium gesteld hebben, is dat een prototype een aantal belangrijke signalen voor de jury bevat: 1) het inzendende team of de ontwikkelaar laat zien op welk technisch niveau er gewerkt gaat worden, 2) het voorkomt inzendingen die in de praktijk niet realiseerbaar zijn. a) Geen droomdata. In je voorstel dient er gewerkt te worden op basis van data aanwezig in de API. Betreft het data die nu nog niet in de API zitten, maar wel open beschikbaar zijn, dien dan via het contactformulier een verzoek tot inladen in. b) Geen droomalgoritmen. De API bevat voor jouw applicatie relevante en minder relevante content. Je basiscontent dient op een herhaalbare manier uit de API gehaald te worden. Het met de hand selecteren van een aantal mooie afbeeldingen in je prototype kan niet, want dit proces is niet schaalbaar en kan niet worden geautomatiseerd. Het simpelste is om een geschikte ‘query’ te vinden op search.opencultuurdata.nl (let op: enkel plaatjes, geen tiffs). Zo geeft ‘rembrandt+olieverf’ hele mooie resultaten. Een andere route is om een algoritme te beschrijven welke op basis van data in de API een selectie maakt. Een voorbeeld van zo’n omschrijving zou zijn: Op basis van OpenDover wordt metadata semantisch gemaakt. Op dit semantische netwerk wordt gefilterd op historisch bekende personen. Dit matchen we in de metadata op basis van het keywoord ‘portret’. c) Gelijke monniken, gelijke kappen. Je mag verder borduren op basis van een oude of bestaande applicatie. Wees transparant over je beginpunt. De jury let op het eindresultaat, maar kijkt ook naar je ambitities. Beiden zijn van belang voor het succes en de continuïteit van je applicatie. Dus, moet je in je prototype een koppeling met de API maken? Het antwoord daarop is ja en nee. Je kunt op basis van een query (echte data, echt algoritme) een aantal afbeeldingen downloaden (of de links pakken natuurlijk) en die hergebruiken in je prototype. Wel dient het prototype een belangrijk deel van het gebruik te beschrijven. Wat zijn de primaire frontend functies? Voor welk platform (mobiel, ipad, web etcetera) ontwikkel je? Wat ziet de gebruiker als deze interesse heeft? Hoe vindt het gebruik uiteindelijk plaats? Deadline voor het indienen van een voorstel voor de Challenge is 1 september. De beste vier toepassingen winnen €5.000 en een begeleidingstraject. Meer informatie over de Challenge kun je hier vinden. Heb je vragen, stel ze via @OpenCultuurData of stuur een berichtje via het contactformulier.
 |
