Op basis van gebruikersonderzoek en data-analyse (update 1) hebben we de ideale filters voor open.amsterdam (update 2) bepaald. Open.amsterdam draait volledig op de infrastructuur van het Stadsarchief. In hoeverre passen onze wensen daarin? En hebben we de benodigde metadata om de gewenste filters aan te bieden?
Documenten duurzaam bewaren, beheren en toegankelijk maken is de kracht van het Stadsarchief. Digitale documenten bewaren we in het e-depot (Archivematica), en door middel van metadata beheren we die documenten met het collectiebeheersysteem Memorix Nexus. Met behulp van deze infrastructuur en wat er al aan front-end voor de beeldbank stond, konden we heel snel een eerste versie van open.amsterdam neerzetten. De gemeente Amsterdam liep daardoor voorop in het publiceren van documenten uit de 11 wettelijk verplichte informatiecategorieën van de Wet open overheid (Woo).
Datamodel
Nu we 160.000+ documenten gepubliceerd hebben groeit de behoefte om uit te zoomen en je opnieuw af te vragen wat er nodig is om deze grote verzameling doorzoekbaar te houden. Dat zijn vragen waar het Stadsarchief ervaring mee heeft: de Woo-documenten worden op precies dezelfde manier bewaard en toegankelijk gemaakt als digitaal ontstaan archief dat het Stadsarchief beheert.
Wat je aan gegevens over je archief opslaat, welke data er zijn (en met welke relaties) leg je vast in een informatie- of datamodel. Het Stadsarchief heeft het eigen informatiemodel uitvoerig beschreven in de Blauwdruk. Daarbij was het streven om een generiek model te maken waar alle soorten informatie in past. Dus ook Woo-documenten. Maar in hoeverre passen ze ook daadwerkelijk in het datamodel van het Stadsarchief? Wat je in Memorix Nexus vast kunt leggen aan metadata wordt namelijk door dit datamodel bepaald.
Wensen vs. Werkelijkheid
Als je onze ideale filters afzet tegen wat nu mogelijk is in Memorix Nexus en het Woo-loket (zo noemen we de Sharepoint-module waarmee we Woo-documenten ter publicatie aanbieden) zie je dat er al veel kan. Op onderstaande afbeelding zie je in groen wat nu zonder aanpassingen al kan, in oranje waar aanpassingen in Memorix Nexus en het Woo-loket nodig zijn, in rood wat nu niet mogelijk is.
Het enige echte knelpunt is het vastleggen van de datum waarop een document aangemaakt is. Weten wanneer een document is aangemaakt is handig als je binnen een dossier wil zien in welke volgorde documenten ontstaan zijn. Welke e-mail is bijvoorbeeld het eerst geschreven, welke documenten volgden?
Sinds de gemeente Amsterdam met Sharepoint werkt wordt er een datum vastgelegd waarop een document is gemaakt. Hier doen we nog niets mee in het Woo-loket, als we dat wel doen moet het handmatig toegevoegd worden aan elk document dat je uploadt. Het zou beter zijn als dit geautomatiseerd gaat en goed ingericht wordt in de informatieketen. Tot die tijd hebben we alleen de datum waarop het document is vastgesteld (de creatiedatum/documentdatum).
Aanpassingen
Voor het grootste deel van onze ideale filters hebben we aan metadata wat we nodig hebben. Voor de volgende filters moeten we aanpassingen doen:
- Thema’s en tags: bij het aanleveren via het Woo-loket kun je idealiter een thema en verschillende tags aan een document toevoegen. Dit moet je vervolgens in Memorix Nexus kunnen vastleggen.
- Momenteel leggen we in Memorix Nexus op dossierniveau meer datums vast dan op documentniveau. De mogelijkheden om datums vast te leggen op documentniveau moeten we uitbreiden.
- De publicatiedatum van een document willen we geautomatiseerd meegeven vanuit het Woo-loket, maar ook dat vereist een technische aanpassing.
Behalve de aanmaakdatum van een document zijn al onze gewenste aanpassingen technisch uitvoerbaar. Maar zouden we onze ideale filters al eens uit kunnen proberen? En kunnen zien wat onze front-end verbeteringen opleveren? Daarover meer in een volgende update: een prototype van open.amsterdam.