Gamle lenker til DA - Redirect?

[Jan-Thore Solem]

Noe er nylig endret på DA?

 

Jeg har ti-tusenvis med kildehenvisninger i min slektsdatabase, noen riktig gamle (og noen av siste 'datoer'/versjoner).

Dette har ikke vært noe stort problem, før nå! Gamle lenker har blitt 're-directed' til korrekt side hos DA uansett. Er det slutt på dette nå, eller er det en feil at dette ikke lenger skjer?

 

Problemet jeg oppdaget i går gjelder spesifikt lenker til transskriberte folketellinger. Her er eksempel på gammel kildehenvisning:

 

FT1900, 1934 Tromsøysund herred, Personliste: 26, Herad: Tromsøysund, Krets: 13, Gardnr: 89, Bruksnr.: 1, Gard: Blaamandsvik ytre (Smaabakken)
http://digitalarkivet.arkivverket.no/ft/bosted_land/bf01037562000526

 

Lenken fungerer ikke!

(Heldigvis er kildehenvisningene min lenket til både hendelsen og personnavnene (skrivemåte), slik at jeg kan finne tilbake og korrigere henvisningen til ny standard (nå bruker jeg lenke til både den transskriberte posten og den skannede siden:

https://www.digitalarkivet.no/census/rural-residence/bf01037562000526
https://www.digitalarkivet.no/ft20101129341182

 

Spørsmål:

Er dette en permanent endring (ikke lenger noe redirect), eller en teknisk glipp hos DA?

 

Jeg kan, med noe innsats, sette meg selv i teknisk modus og se om jeg kan kjøre en 'search-and-replace' i MySQL-databasen min. For folketellingen burde jo det gå, siden det kun er den første delen av lenken (URL'en) som skal endres, mens ID-nummeret er det samme.

(En noe skremmende affære, husk bækkøpp, bækkøpp og enda en bækkøpp...)

 

 

 

 

Edited February 28 by Jan-Thore Solem

[Arkivverket - Kristian Hunskaar]

Så vidt jeg vet, har Arkivverket aldri annonsert URLene til dataposter (søkbare data / transkriberte data) som permanente. Ikke desto mindre er hver dataposts id med to bokstaver og fjorten siffer, i dette tilfellet bf01037562000526, ment å være permanent. At datapostenes id er permanente, er bl.a. en forutsetning for Historisk befolkningsregister. Det er f.eks. derfor korrekturarbeidet på AMF-transkripsjonene må følge fastsatte rutiner som sørger for at id-ene ikke endres i forbindelse med korrekturarbeidet.

 

En URL med digitalarkivet.no/ + id, altså f.eks. http://digitalarkivet.no/bf01037562000526, vil omdirigere til https://www.digitalarkivet.no/census/rural-residence/bf01037562000526. Jeg betrakter derfor http://digitalarkivet.no/bf01037562000526 som det nærmeste man kommer en permanent URL.

[Jan-Thore Solem]

Takk for klargjørende info, Kristian.

 

Mitt spørsmål kom som et resultat av at denne ('ikke annonserte redirect') har virket helt til for et par dager siden.

 

Jeg forstår at denne 'nye funksjonaliteten' altså er kommet for å bli, og at jeg må gå for min 'opsjon 2' (search-and-replace) i min database. Med din informasjon (i siste setning), blir det faktisk enklere (kortere URL). Jeg regner med at det likevel vil være best å bruke https hele veien...

 

 

[Arkivverket - Kristian Hunskaar]

Det er leddet digitalarkivet.arkivverket.no som "skaper problemet", for http://digitalarkivet.no/ft/bosted_land/bf01037562000526 fungerer.

 

Jeg har ikke hørt om noen nylige endringer, og etter hva jeg vet er Arkivverkets utviklere dypt inne i andre oppgaver, så jeg tror i alle fall ikke dette handler om at det er utviklet noen nye løsning. Nå er det ganske mange år siden digitalarkivet.arkivverket.no ble forenkla til digitalarkivet.no, og jeg tror også det er lang tid siden kodeverket for øvrig ble standardisert med engelske termer (ft > census og bosted_land > rural-residence). Men jeg tipper altså at dette kan ha noe med domenet digitalarkivet.arkivverket.no å gjøre.

[Jan-Thore Solem]

Ja, jeg har nok mange 'generasjoner' av domener og diverse URL-utgaver, som viser Digitalarkivets utvikling gjennom mange år.

 

Frem til nå har jeg manuelt endret kildehenvisninger (til nyere tekniske versjoner), når jeg har 'sirklet tilbake' til personer, familier, slekter og bygder, jeg har jobbet med tidligere.

 

Nå er jeg igang med MySQL søk/erstatt, så det løser seg der kilder ender med et ID-nummer (over 40 tusen henvisninger unnagjort til nå...)

 

Jeg håper bare DA vil fortsette med 'redirect' av gamle lenker med formen:

http://www.arkivverket.no/URN:kb_read?idx_kildeid=9701&idx_id=9701&uid=ny&idx_side=-48

 

Den formen er definitivt ikke lett å endre med skript (hvis der ikke finnes en 'konverteringsnøkkel' til ID-nummer?), så jeg endrer når jeg ser dem i databasen min.

 

 

 

 

[Torbjørn Igelkjøn]

Eg har tidlegare limt inn ein del lenker av typen digitalarkivet.arkivverket.no på Geni, og desse må då endrast manuelt for kvar gong ein kjem over desse.

 

Det ville heilt klart ha vore ein fordel om ein sytte for at desse lenkene kunne fungere ei stund til.

[Jan-Thore Solem]

Takk Frederic!

 

(Innlegget til Frederic (Administrator) ble slettet, før jeg fikk kopiert koden, hmmm...

Kan du sende meg koden som privat melding, så jeg har den i en 'nødsituasjon'?)

 

 

Jeg noterer dette som en nødhjelp hvis det skulle bli nødvendig (DA slutter å redirecte).

 

Jeg er selv ikke i stand til direkte å kunne bruke det du her tilbyr, litt over mitt nivå.

Jeg bruker TNG som program (PHP / MySQL), så i en krise kan jeg be om hjelp i miljøet der.

 

Jeg har endret (search/replace) "ID-lenker" ved å kjøre SQL-script i phpMyAdmin, direkte mot navngitt db, tabell og kolonne, etter "monkey see, monkey do" metoden: (Google, finn, prøv).

 

 

Om andre leser dette, og er i samme situasjon, her er oppskriften min for søk/erstatt (i prinsippet):

MySQL:

UPDATE table_name
SET column_name = REPLACE(column_name, 'old_text', 'new_text')
WHERE column_name LIKE '%old_text%';

 

Eksempel:

1: Åpne (velg) database i phpMyAdmin

2: Ta bækkøpp av databasen (export). Bækkøpp! Bækkøpp! Bækkøpp!

3: Søk etter 'gammel tekst' (som du ønsker å endre)

4: Noter navn på tabell og kolonne (for der du finner 'gammel tekst')

5: Bruk script-malen her og komponer et tilpasset script ved å erstatte tabell-navn (her 'tng_citations'), kolonne-navn (her 'note'), samt 'gammel tekst' og 'ny tekst'

6: Kopier script inn i SQL-fanen i phpMyAdmin, og kjør!

UPDATE tng_citations
SET note = REPLACE(note, 'http://digitalarkivet.arkivverket.no/ft/bosted_land/', 'https://www.digitalarkivet.no/census/rural-residence/')
WHERE note LIKE '%http://digitalarkivet.arkivverket.no/ft/bosted_land/%';

 

 

 

Edited March 6 by Jan-Thore Solem

[Torbjørn Igelkjøn]

Svaret til @Frederic G. Østby gjaldt vel desse lenkene:

 

På 28.2.2025 den 18.12, Jan-Thore Solem skrev:

http://www.arkivverket.no/URN:kb_read?idx_kildeid=9701&idx_id=9701&uid=ny&idx_side=-48

 

som ved hjelp av koden kan konverterast til

https://media.digitalarkivet.no/view/9701/48

[Jan-Thore Solem]

Ja, det stemmer, men han slettet meldingen (med koden) før jeg fikk kopiert den...

[Arkivverket - Kristian Hunskaar]

1 time siden, Torbjørn Igelkjøn skrev:

som ved hjelp av koden kan konverterast til

https://media.digitalarkivet.no/view/9701/48

 

1 time siden, Jan-Thore Solem skrev:

Ja, det stemmer, men han slettet meldingen (med koden) før jeg fikk kopiert den...

 

Min kollegas svar ble slettet, fordi konverteringa ikke er universelt riktig. Jeg skal kommentere dette ytterligere - i arbeidstiden.

[Arkivverket - Kristian Hunskaar]

Da vil jeg først kommentere problemet med URLer av typen http://digitalarkivet.arkivverket.no/ft/bosted_land/bf01037562000526 :

Dette viser seg å være relatert til driftsmessige oppdateringer i Arkivverket; det vil si at det ikke har med utvikling av Digitalarkivet å gjøre. En kollega i Arkivverkets avdeling for IT-drift forteller at dette er en bug som er identifisert, og som har å gjøre med nyeste versjon av Kubernetes Ingress Controller (https://www.solo.io/topics/kubernetes-api-gateway/kubernetes-ingress-controller). Dette er en ekstern løsning som Arkivverket bruker, og det begrenser kanskje mulighetene for feilretting, men IT-drift skulle i alle fall se på saken.

Uansett bør man være klar over at det er objektnavnet, her bf01037562000526, som altså er det permanente elementet.

 

Dernest har tråden også kommet inn på URLene som benyttes for skanna arkivmateriale.

 

Det er for så vidt riktig at de gamle URLene av typen http://www.arkivverket.no/URN:kb_read?idx_kildeid=9701&idx_id=9701&uid=ny&idx_side=-48 kan konverteres til nåværende URLer av type https://media.digitalarkivet.no/view/9701/48, og da ser man formodentlig hvordan man eventuelt kan bruke søk/erstatt for å konvertere. Disse URLene inneholder to viktige parametere:

• 9701 er kildens id i Digitalarkivets database.
• 48 refererer til post nr. 48 i en tabell over bildefiler knytta til en bestemt kilde, og som avgjør blarekkefølgen mellom bildefilene.

Men det er ikke gitt at post nr. 48 knytta til kilde nr. 9701 over tid vil peke til det samme objektet (les: den samme bildefila). Pr. nå peker denne posten til bildefila kb20070606650348, som viser oppslaget s. 218-219 (https://www.digitalarkivet.no/kb20070606650348). La oss nå si at det skulle bli påvist at noen beskrevne oppslag i kirkeboka ikke har blitt skanna, f.eks. mellom post nr. 20 (s. 36-37: https://media.digitalarkivet.no/view/9701/20) og post nr. 21 (s. 164-165: https://media.digitalarkivet.no/view/9701/21). Setter vi inn to nye poster / to nye bildefiler her, vil det nå være post nr. 50 som viser til bildefila kb20070606650348 med oppslaget s. 218-219.

 

Det forekommer også endringer i kildenes id. For eksempel ønsker vi på sikt å få slått sammen kirkebøkene som er publisert sokn for sokn, slik at ei fysisk kirkebok svarer til ei digital kirkebok. Da vil to eller flere av disse kildenes id-er bli til én (og postnummereringa vil også bli helt annerledes).

 

De "permanente lenkene" fra de første åra med skanna arkivmateriale var altså ikke permanente lenker til bildefiler, men permanente lenker til poster i en databasetabell. Man hadde tydeligvis ikke sett for seg behovene for å legge til eller fjerne bildefiler, eller andre endringer som kan ha betydning for hvilken bildefil en post peker til. I mange år måtte derfor legge bånd på oss, i den forstand at vi ikke kunne sette inn nye bildefiler, selv om vi visste at det manglet sider i de digitale kirkebøkene.

Heldigvis er vi forbi det stadiet; en URL av typen http://www.arkivverket.no/URN:kb_read?idx_kildeid=9701&idx_id=9701&uid=ny&idx_side=-48 vil nå utløse et oppslag i en historisk tabell for å finne ut hvilken bildefil disse parametrene i sin tid henviste til, og så blir du og jeg omdirigert i henhold til det. (Dette fungerer for alt skanna arkivmateriale, bortsett fra lensregnskapene og stiftamtstueregnskapene, som i sin tid hadde en helt særegen databasemodell.)

 

Oppsummert: Både for transkriberte data og for skanna arkivmateriale er det objektnavnene (som består av to bokstaver og fjorten siffer) som er permanente. Man kan danne en URL av https://digitalarkivet.no/ + objektnavnet, f.eks. https://digitalarkivet.no/kb20070606650348 eller https://digitalarkivet.no/bf01037562000526. URLer av denne typen kan betraktes som permanente URLer for objektene; riktignok kan man se for seg at leddet https://digitalarkivet.no/ kan bli endret i framtida, men i så fall bør det være forholdsvis greit for Arkivverket å lage omdirigeringer.

[Jan-Thore Solem]

Takk for utførlig forklaring!

 

[Torbjørn Igelkjøn]

Så for å oppsummere:

 

Kjeldeid og postnummer var "permanente" fram til ca. 2016(?), og gamle lenker kan dermed samanliknast mot ein "fryst" versjon av Digitalarkivet frå 2016.

 

Lenker av typen view tilsvarar dei gamle lenkene, men kjeldeid og postnummer kan ha endra seg sidan 2016, og vil gjere det i framtida. Lenkene er ikkje lenger permanente.

[Finn Karlsen]

Takk for god forklaring. Etter det jeg forstår så skyldes problemene med at lenker som inneholder www.digitalarkivet.arkivverket.no ikke lenger fungerer, skyldes en bug i et eksternt system som Arkivverket bruker. Får håpe at man finner ut av det.

 

Men forklaringen inneholder en del som gjør meg litt alvorlig skremt. Jeg holder på med en oppdatering av mitt hjertebarn Trondheimsbasen som en god del hundre slektsforskere har funnet nytte i som et supplement til de offisielle hjelpekildene. Jeg er såpass gammel nå og systemet bruker en forholdsvis foreldet teknologi, at dette blir den siste oppdateringen.

 

Trondheimsbasen inneholder imidlertid noen hundre tusener med lenker til Digitalarkivet. Hovedmengden går på lenke til original kilde i kirkebøker etc. Lenkene er i mange tilfeller av en litt eldre type som idag automatisk blir konvertert til en gyldig lenke. Men etter det jeg skjønner har man ingen garanti for at dette vil fungere over tid. Det jeg derfor lurer på om det finnes konverteringstabeller som gjør at jeg nå kan endre lenker av typen https://media.digitalarkivet.no/view/2544/247  eller http://www.arkivverket.no/URN:kb_read?idx_kildeid=2544&idx_=2544&uid=ny&idx_side=-247 til media.digitalarkivet.no/kb20050429010571 og som jeg kan få tilgang til, slik at det er noenlunde sikkerhet for at lenkene mine vil fungere en stund etter at jeg har sluttet med dette?

 

Finn K

[Arkivverket - Kristian Hunskaar]

På 7.3.2025 den 19.36, Torbjørn Igelkjøn skrev:

Kjeldeid og postnummer var "permanente" fram til ca. 2016(?), og gamle lenker kan dermed samanliknast mot ein "fryst" versjon av Digitalarkivet frå 2016.

 

Vi unngikk å gjøre endringer i kildeid og postnummer, inntil det gamle grensesnittet ble fjernet. Det var vel i 2015, eller kanskje i 2016. Jeg vet faktisk ikke konkret hvordan det fungerer, men Digitalarkivets database må inneholde en tabell (med kilde-id, postnummer og bilde-id pr. 2015/2016) som finner ut at http://www.arkivverket.no/URN:kb_read?idx_kildeid=2544&idx_=2544&uid=ny&idx_side=-247 spør etter objektet (bildefila) med bilde-id kb20050429010571.

 

På 7.3.2025 den 19.36, Torbjørn Igelkjøn skrev:

Lenker av typen view tilsvarar dei gamle lenkene, men kjeldeid og postnummer kan ha endra seg sidan 2016, og vil gjere det i framtida. Lenkene er ikkje lenger permanente.

 

Ja. Kildeid og postnummer kan ha endret seg siden 2016 og vil kunne endre seg i framtida.

 

Man må bruke henvisning som inneholder bilde-id, enten bilde-id alene (kb20050429010571) eller bilde-id i URL (https://www.digitalarkivet.no/kb20050429010571 eller https://digitalarkivet.no/kb20050429010571 eller https://media.digitalarkivet.no/kb20050429010571).

[Arkivverket - Kristian Hunskaar]

På 8.3.2025 den 9.19, Finn Karlsen skrev:

Men forklaringen inneholder en del som gjør meg litt alvorlig skremt. Jeg holder på med en oppdatering av mitt hjertebarn Trondheimsbasen som en god del hundre slektsforskere har funnet nytte i som et supplement til de offisielle hjelpekildene. Jeg er såpass gammel nå og systemet bruker en forholdsvis foreldet teknologi, at dette blir den siste oppdateringen.

 

Trondheimsbasen inneholder imidlertid noen hundre tusener med lenker til Digitalarkivet. Hovedmengden går på lenke til original kilde i kirkebøker etc. Lenkene er i mange tilfeller av en litt eldre type som idag automatisk blir konvertert til en gyldig lenke. Men etter det jeg skjønner har man ingen garanti for at dette vil fungere over tid. Det jeg derfor lurer på om det finnes konverteringstabeller som gjør at jeg nå kan endre lenker av typen https://media.digitalarkivet.no/view/2544/247  eller http://www.arkivverket.no/URN:kb_read?idx_kildeid=2544&idx_=2544&uid=ny&idx_side=-247 til media.digitalarkivet.no/kb20050429010571 og som jeg kan få tilgang til, slik at det er noenlunde sikkerhet for at lenkene mine vil fungere en stund etter at jeg har sluttet med dette?

 

Jf. forrige svar finnes det en tabell (med kilde-id, postnummer og bilde-id pr. 2015/2016) som Digitalarkivets visning kontinuerlig benytter, når en bruker "spør systemet" om en URL av typen http://www.arkivverket.no/URN:kb_read?idx_kildeid=2544&idx_=2544&uid=ny&idx_side=-247.

 

Etter innføring av permanente URLer av typen https://digitalarkivet.no/kb20050429010571 har vi ingen loggføring over endringer, så hvis man har registrert en URL av typen https://media.digitalarkivet.no/view/2544/247, kan vi ikke med sikkerhet si hvilken bilde-id disse parameterne viste til på det tidspunktet URLen ble registrert.

[Finn Karlsen]

Nei, livet skal ikke være enkelt og jeg er glad for at det er siste gang jeg trenger å bekymre meg for dette.

 

Så da blir spørsmålet mitt om det går an å få tilgang til den aktuelle tabellen slik at jeg kan kjøre en konvertering av det jeg har. Og så får jeg gjøre en del manuelle kontroller i ettertid for å sjekke om det er avvik. De fleste lenkene tror jeg nok er fra tiden før 2016.

 

Ha en fin dag, Finn