Toestemming tot het archiveren en beschischikbaarstellen van websites. Wat is het waard?
Het valt me op dat al veel collega's lid zijn geworden van deze groep, maar dat er nog geen discussies...
Databasearchivering naast Crawling
- sep 2017
- Wouter Brunner
- ·
- Aangepast 27 jun
- 4
- 76
Wij archiveren de gemeentelijke website sinds een aantal jaar met behulp van crawling.
Nu is vrij recent de gemeentelijke website weer eens helemaal vervangen door een nieuw ontwerp en komt vanuit de contentorganisatie de vraag of we de data van de oude site nog moeten bewaren.
Ja, goede vraag. Het voordeel zou kunnen zijn dat je hiermee ook de data vastlegt die je met crawling niet te pakken krijgt (bijvoorbeeld dynamische content en niet-openbare informatie). Het nadeel is dat je alleen de data hebt en geen mogelijkheid om die te ontsluiten. Ik vraag me af of je als organisatie/archiefbewaarplaats op een later moment nog een flinke effort gaat steken in het alsnog ontsluitbaar maken van dit soort informatie. Het lijkt me eigenlijk sterk.
Kortom, de vraag: als je al aan archivering middels crawling doet, moet je dan ook nog eens de database archiveren? Wat vinden jullie?
Verken
Ervaringen met het matchen van plaatsnamen in GeoNames
Hoi Allemaal, ik ben momenteel pogingen aan het wagen om een grote set aan plaatsnamen te linken aan ...
Enkelvoudige opslag, meervoudig gebruik in een E-depot
Hoi allemaal, in een reactie over de metadatering van bouwvergunningen gaf P. van den Bosch het ...
Reacties
Als een database enkel een onderdeel vormt van je CMS en alle data via de pagina's van de site gearchiveerd worden dan zou ik de database niet apart archiveren.
Als het gaat om niet-openbare informatie, ik neem dan aan een intranet, dan zou dat deel door webarchivering van het intranet ook goed bewaard kunnen worden.
Het wordt lastiger als sommige data uit de database alleen via zoekformulieren beschikbaar is. Soms kan je forceren dat die data ook met je webarchivering mee komt (ik denk aan een sitemap of vergelijkbare technieken). Soms lukt dat niet om technische redenen (alleen 'POST' mogelijk) of omdat de database eenvoudigweg te omvangrijk is. Als dat speelt dan ben je waarschijnlijk ook geïnteresseerd in het bewaren van de database al op zich, en dus niet enkel omdat die 'toevallig' onderdeel uitmaakte van de website.
Groet, René
Met 'niet openbare informatie' doel ik eigenlijk vooral op het gedeelte van de website dat achter een inlog zit.
Het gaat - voor zover mij bekend - inderdaad alleen om de database die bij het CMS hoort.
Als het gaat om data 'achter een inlog' dan zou er mogelijk voor gezorgd kunnen worden dat dit inloggen voor de archiveersoftware niet nodig is. De crawler heritrix kan in sommige gevallen ook zelf inloggen (bij gebruik van zgn. 'basic authentication').
Het verhaal wordt natuurlijk wel erg lastig als de content die op een pagina getoond wordt afhankelijk is van wie er ingelogd is. Als het belangrijk is om ook die pagina's te archiveren dan kan er gedacht worden aan een oplossing als https://mementoweb.github.io/SiteStory/ (een zeer elegante en interessante aanpak voor archiefvormers, wmb).
het gaat inderdaad om een gepersonaliseerde inlog.
Overigens, als je dit dus wel zou kunnen crawlen, dan heb je vervolgens het probleem dat een deel van je webarchief openbaar is en een deel niet. Ik weet niet of dat beheerstechnisch te doen is.