NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER
Tags:
Gemeenten zijn al eerder (in 2006 en 2010) door de rechter in het ongelijk gesteld doordat zij mensen beboet hadden terwijl de burgers zelf conform de tekst op de website hadden gehandeld, ondanks een disclaimer. Ik heb dit eerder aangehaald op LinkedIn. Toen werd er lacherig over gedaan omdat het parkeerboetes betrof, en wie ligt daar nu wakker van (geen mens die het over de service naar de burger had, maar goed). Om de bedragen gaat het echter niet, het gaat om de strekking van de rechterlijke uitspraak: een burger mag er van uitgaan dat de informatie die een gemeente op haar website heeft staan de juiste is. Dat het vooralsnog verkeersboetes betrof is toeval en was te verwachten, maar bij bestemmingsplannen, inspraakronden en wat dies meer zij kan eenzelfde reactie van de rechter verwacht worden. Het verplicht publiceren maakt een acuut probleem alleen maar acuter.
Één van de DIVers in onze gemeente kwam daar laatst ook mee. Mijn collega had een presentatie gehoord van een commercieel bedrijf die dit voor oa gemeenten kan doen. De methode die ze gebruiken is (voor zover ik het kan overzien) om periodiek (één maal per dag) een 'snapshot' te maken van alle pagina's binnen het te archiveren websitedomein en die dan (als afbeelding?) op te slaan. Volgens mij (maar ik ben een IT'er en geen DIV'er) volstaat die manier niet. Immers:
1) De website kan zo dynamisch zijn dat éénmaal per dag een snapshot nemen, onvoldoende is. Feitelijk moet je elke wijziging in content constateren en archiveren.
2) Statische documenten die achter links zitten, zou je wellicht ook moeten archiveren.
3) Als je een 'plaatje' van een webpagina maakt en archiveert, ben je dan niet met een soort substitutie bezig? Immers de oorspronkelijke verschijningsvorm (de webpagina die via http naar je browser wordt gestuurd) heb je niet gearchiveerd, maar alleen de grafische weerslag daarvan.
De 'mooiste' manier om het te doen is waarschijnlijk het probleem bij de bron aanpakken: het CMS. Als je hier zgn. 'tijdreis-functionaliteit' in bouwt, kun je alle pagina's uit het verleden oproepen.
Ik ben benieuwd welke gemeente ervaringen met het onderwerp heeft en wat DIV'ers als de 'juiste' weg zien om aan website-archivering te doen.
Wat je zegt klopt volledig. Je zou ook een snapshot kunnen maken na elke verandering, maar dan nog heb je te maken met het feit dat je inderdaad alleen een weergave maakt. voor zover ik weet is hier ook nog geen sluitende oplossing voor. De weergave is in elk geval (juridisch) heel belangrijk (immers, dat is wat de burger ziet als die de informatie 'ophaalt'). Een koppeling met het CMS heeft precies dat nadeel,nl. dat je de gegevens bewaart in een variant die de weergave doorgaans niet representeert.
Een van de bedrijven die zich hier mee bezig houdt is Capsis BV. Van hen heb ik ooit wel een presentatie gezien.
Er zijn nog veel meer bedrijven, al bieden veel van hen de opslag aan op internet zelf, iets dat mij om redenen van informatiebeheer weer onwenselijk lijkt. Verder dan die presentatie is mijn opdrachtgever destijds helaas niet gekomen. Ik meen me te herinneren dat er één of twee gemeenten in Brabant al wel hun website (online) laten archiveren.
Jaap de Jonge zei:
Één van de DIVers in onze gemeente kwam daar laatst ook mee. Mijn collega had een presentatie gehoord van een commercieel bedrijf die dit voor oa gemeenten kan doen. De methode die ze gebruiken is (voor zover ik het kan overzien) om periodiek (één maal per dag) een 'snapshot' te maken van alle pagina's binnen het te archiveren websitedomein en die dan (als afbeelding?) op te slaan. Volgens mij (maar ik ben een IT'er en geen DIV'er) volstaat die manier niet. Immers:
1) De website kan zo dynamisch zijn dat éénmaal per dag een snapshot nemen, onvoldoende is. Feitelijk moet je elke wijziging in content constateren en archiveren.
2) Statische documenten die achter links zitten, zou je wellicht ook moeten archiveren.
3) Als je een 'plaatje' van een webpagina maakt en archiveert, ben je dan niet met een soort substitutie bezig? Immers de oorspronkelijke verschijningsvorm (de webpagina die via http naar je browser wordt gestuurd) heb je niet gearchiveerd, maar alleen de grafische weerslag daarvan.
De 'mooiste' manier om het te doen is waarschijnlijk het probleem bij de bron aanpakken: het CMS. Als je hier zgn. 'tijdreis-functionaliteit' in bouwt, kun je alle pagina's uit het verleden oproepen.
Ik ben benieuwd welke gemeente ervaringen met het onderwerp heeft en wat DIV'ers als de 'juiste' weg zien om aan website-archivering te doen.
@Lourens en Jaap, Het bedrijf dat jullie bedoelen is archiefweb, zie deze link. Er zijn meerdere gemeenten in Brabant bij aangesloten zoals Bladel, Drimmelen, Gilze en Rijen en Nuenen. Bij de gemeente Tilburg heb ik vorig jaar ook een presentatie van deze firma bijgewoond.
Lourens zei:
Wat je zegt klopt volledig. Je zou ook een snapshot kunnen maken na elke verandering, maar dan nog heb je te maken met het feit dat je inderdaad alleen een weergave maakt. voor zover ik weet is hier ook nog geen sluitende oplossing voor. De weergave is in elk geval (juridisch) heel belangrijk (immers, dat is wat de burger ziet als die de informatie 'ophaalt'). Een koppeling met het CMS heeft precies dat nadeel,nl. dat je de gegevens bewaart in een variant die de weergave doorgaans niet representeert.
Een van de bedrijven die zich hier mee bezig houdt is Capsis BV. Van hen heb ik ooit wel een presentatie gezien.
Er zijn nog veel meer bedrijven, al bieden veel van hen de opslag aan op internet zelf, iets dat mij om redenen van informatiebeheer weer onwenselijk lijkt. Verder dan die presentatie is mijn opdrachtgever destijds helaas niet gekomen. Ik meen me te herinneren dat er één of twee gemeenten in Brabant al wel hun website (online) laten archiveren.
Jaap de Jonge zei:Één van de DIVers in onze gemeente kwam daar laatst ook mee. Mijn collega had een presentatie gehoord van een commercieel bedrijf die dit voor oa gemeenten kan doen. De methode die ze gebruiken is (voor zover ik het kan overzien) om periodiek (één maal per dag) een 'snapshot' te maken van alle pagina's binnen het te archiveren websitedomein en die dan (als afbeelding?) op te slaan. Volgens mij (maar ik ben een IT'er en geen DIV'er) volstaat die manier niet. Immers:
1) De website kan zo dynamisch zijn dat éénmaal per dag een snapshot nemen, onvoldoende is. Feitelijk moet je elke wijziging in content constateren en archiveren.
2) Statische documenten die achter links zitten, zou je wellicht ook moeten archiveren.
3) Als je een 'plaatje' van een webpagina maakt en archiveert, ben je dan niet met een soort substitutie bezig? Immers de oorspronkelijke verschijningsvorm (de webpagina die via http naar je browser wordt gestuurd) heb je niet gearchiveerd, maar alleen de grafische weerslag daarvan.
De 'mooiste' manier om het te doen is waarschijnlijk het probleem bij de bron aanpakken: het CMS. Als je hier zgn. 'tijdreis-functionaliteit' in bouwt, kun je alle pagina's uit het verleden oproepen.
Ik ben benieuwd welke gemeente ervaringen met het onderwerp heeft en wat DIV'ers als de 'juiste' weg zien om aan website-archivering te doen.
Onze welbekende Ton de Looijer heeft vorig jaar over dit onderwerp geblogd. Leestip!
Een koppeling met het CMS heeft precies dat nadeel,nl. dat je de gegevens bewaart in een variant die de weergave doorgaans niet representeert.:
Dag Jaap,
het klopt dat het CMS ook de weergave aanstuurt (en dat daarmee een reconstructie mogelijk moet zijn), ik heb alleen argumenten aangehaald die in de discussie naar voren zijn gekomen. Het is natuurlijk volledig afhankelijk van wat je verder archiveerd. Archiveer je het hele CMS, incluis het platform waar dat op draait, of alleen de gewijzigde content zoals die wordt ingevoerd in het CMS. Dan doet zich het eerder genoemde probleem zich voor.
De weergave wordt verder ook nog beinvloed door de browser, maar dat probleem doet zich voor bij zowel de CMS- als snapshot-methode. Mijns inziens zijn er meerdere wegen die naar Rome leiden. Als je in het proces van archivering met redelijke accuratesse kunt vaststellen wat er om enig moment op de website weergegeven werd is het prima. Ik neem aan dat een rechter net zo zal redeneren.
De duurzaamheid is met (gesloten) bestandsformaten natuurlijk altijd lastig en authenticiteit is digitaal altijd moeilijk vast te stellen. Wederom vermoed ik dat de procedure die gevolgd wordt, waarbij dit soort kenmerken in de beschrijving zijn meegenomen, de doorslag zullen geven. Misschien proberen we de boel wel accurater te bewaren dan de werkelijke weergave is.
Jaap de Jonge zei:
Lourens zeiEen koppeling met het CMS heeft precies dat nadeel,nl. dat je de gegevens bewaart in een variant die de weergave doorgaans niet representeert.:
Hallo Lourens,
Volgens mij maak je hier een denkfout: een CMS bevat niet alleen de content, maar stuurt juist ook layout/grafische weergave. Met een CMS met een 'geheugen' zou je de weergave van je pagina's in het verleden 100% accuraat moeten kunnen reconstrueren. Maar als je persé het dichtst tegen de weergave aan wilt zitten, zou je het probleem ook kunnen aanpakken bij de webserver. Als je die op nieuwe/gewijzigde weergave zou kunnen laten checken en op basis daarvan een nieuw archief-item laat maken, ben je er ook. Maar de discussie blijft vooralsnog een beetje theoretisch, want ik ken geen CMS of webserver die kan wat ik hier beschrijf.
Een hele interessante discussie, alleen klopt de aanleiding niet. Websites zouden al veel langer gearchiveerd moeten worden. Het CVDR draagt daar hooguit wat aan bij.
Er zijn m.i. een aantal problemen bij het archiveren van websites:
1. De CMS-methode wordt nergens aangeboden door CMS-leveranciers
2. De snap-shot methode wordt alleen door externe aanbieders aangeboden, met hoge kosten
3. De benodigde opslagcapaciteit om alle overheidswebsites continue op te slaan zal enorme opslagcapaciteit vragen (geldt voor beide methoden)
4. Overheidswebsites raken steeds meer verweven met elkaar en met niet-overheidswebsites: de website van onze gemeente heeft xml-koppelingen met het overheidsloket op www.overheid.nl (samenwerkende catalogi), de e-connectsite van SDU (PDC) en binnenkort ook de regelingenbank op www.overheid.nl (CVDR), waar we overigens al langer op publiceren. En dan zijn we nog erg voorzichtig met Google maps, youtube e.d. (webrichtlijnen...)
5. Het Nationaal Archief is al jaren aan het onderzoeken naar een digitaal depot, maar heeft nog steeds niets om overheden te ondersteunen.
6. en vast nog meer problemen waar ik nu niet aan denk..
We hebben 2 jaar geleden bekeken of we onze oude website konden laten archiveren. Het KB was bezig met een proef en het NA bleek zoals gezegd ook niets te hebben. We hebben het dan ook maar zo gelaten..
Tja, in hoeverre? Moeten we 20 jaar aan website-content continu extern opslaan? Want dat is de consequentie volgens mij. De kosten voor externe opslag zullen per jaar groeien, totdat we over 20 jaar mogen overdragen (als er dan een digitaal depot bestaat tenminste). Maar voor ieder jaar dat we overdragen, komt er een jaar bij. Dat betekent een structurele last op de begroting van 20 jaar website-content opslag. Nu wordt opslag wel steeds goedkoper, maar ik denk dat ik nog steeds hoofdpijn krijg als ik dat prijsplaatje probeer voor te stellen...
Tja, in hoeverre? Moeten we 20 jaar aan website-content continu extern opslaan? Want dat is de consequentie volgens mij. De kosten voor externe opslag zullen per jaar groeien, totdat we over 20 jaar mogen overdragen (als er dan een digitaal depot bestaat tenminste). Maar voor ieder jaar dat we overdragen, komt er een jaar bij. Dat betekent een structurele last op de begroting van 20 jaar website-content opslag. Nu wordt opslag wel steeds goedkoper, maar ik denk dat ik nog steeds hoofdpijn krijg als ik dat prijsplaatje probeer voor te stellen...
© 2024 Gemaakt door Marco Klerks. Verzorgd door