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 ...
Databasearchivering naast Crawling
- sep 2017
- Wouter Brunner
- ·
- Aangepast 27 jun
- 4
- 34
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
Vraag: wanneer is een verzameling WARC-files een goed webarchief
Weet iemand van jullie of er ergens kwaliteitseisen voor webarchieven in de vorm van WARC-files zijn g...
Concept Stappenplan webarchivering: reacties gevraagd
Beste leden, Hierbij het concept Stappenplan voor de archivering van overheidswebsites. Graag ontvange...
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.