Bruk Historisk befolkningsregister, HBR, histreg.no som felles plattform!

[Lars Holden]

1 hour ago, Kjell Inge Tomren said:

Hvis jeg forstår dette rett: Når vi observerer feilaktige relasjoner som ikke er toveis/gjensidig, så skyldes det mest sannsynlig denne feilen (bug). Og da er det pr nå ikke mulig å korrigere dette, men vi må vente på neste versjon av visning av komplekse familier. Og når den nye versjonen kommer, så blir disse falske relasjonene borte?

Familierelasjoner skal alltid være begge veier. Hvis dette ikke er tilfelle, er det en bug. Det vil bli rettet opp i en ny versjon. Vi har valgt å skrive om hele denne delen av programmet istedenfor å rette opp bugen.

[Kjell Inge Tomren]

Denne karen her ser ut til å ha fire koner for mye: https://histreg.no/index.php/person/pv00000006781820

Profilene bygger for det meste på opplysninger fra folketellingene, og så vidt jeg kan se, er alle familiene enkle og greie. Jeg klarer ikke å finne ut hvorfor det har blitt ekstra relasjoner. Hans Olai var riktig nok registrert som fostersønn i en sammensatt husholdning i FT1865, men jeg kan ikke se at det skulle være forklaringen på fire ekstra feilaktige partnere. For meg ser det også ut til at relasjonen er toveis. I alle fall for tre av de fire feilaktige partnerne. Jeg tror derfor ikke at det er "buggen" som viser seg på denne måten, men jeg kan selvsagt ta feil. 

Jeg har lenket mange familer i dette området nå i det siste, så det er mulig jeg har laget feilen. Men, jeg klarer altså ikke å rydde opp i disse feilene. I tillegg til opprydding, hadde det vært fint om noen kunne forklare hva som har blitt feil og hva vi evt kan gjøre for å unngå at det blir feil på nytt. 

Endret Desember 30, 2024 av Kjell Inge Tomren

[Hanne Astad]

Jeg tror en del kan forhindres ved at man får muligheten til å låse gjennomarbeidede profiler.

Det begynner å bli en del år som jeg har holdt på med histreg nå, og på disse årene er det forsvinnende lite nytt som har tilkommet via autolenking på de profilene jeg kjenner godt og som det ville ha vært aktuelt å låse. (Flere av disse har også referanser og tekst i biografi/merknadsfeltet som det har vært utrolig surt å miste!)
Den stadig økende arbeidsmengden jeg legger ned i å rydde i feillenking og sammenblandede navn (og feilaktige dødsdatoer!) tror jeg er mye mer omfattende enn det ville ha vært for meg å manuelt gå gjennom de profilene jeg har låst én gang i året for å sjekke om noe nytt er tilkommet. 

Om noen allikevel vil endre en slik låst profil, kan man jo ha et ekstra steg der man «signerer» med brukernavnet sitt for at opplysninger stemmer overens.

 

Senest i dag var det en av de profilene jeg har gått gjennom nøye og har fulgt opp i åresvis som hadde blitt splittet opp.

Denne profilen kjenner jeg godt ettersom han er min tippoldefar, så her er jeg så sikker som jeg kan få vært på at det ikke er noe jeg i tidligere lenking har oversett. 

 

Tillegg:

Det er jo ikke arbeidsmengde i lenking/retting man blir lei av, det er at man ikke kan stole på at noe som man har arbeidet med og nøye kontrollert vil fortsette å være riktig framover. 

Som tidligere nevnt i ett av mine innlegg, vil mye av nytteverdien med å kunne lenke til en personside falle bort når man ikke kan stole på at det man deler fremdeles har verdi.

Endret Desember 30, 2024 av Hanne Astad

[Lars Holden]

Da har jeg rettet opp personen som Kjell Inge Tomren viste til. Her var det nødvendig å bruke feilhåndtering på hver av konene og barna som var feil. Hver enkelt av disse var ganske lette og rett frem. Det er vanskelig å se hva som er årsaken til feilkoblingene. Jeg vil gjette at det er resultat av mange forskjellige ting. Familierollene var beskrevet litt uvanlig i 1891-folketellingen. I tilfelle er det en feil som har vært der i flere år. Det kan forklare noen av feilene.

 

Jeg skjønner at det er irriterende når man mister lenkede personer og tekster man har skrevet. Håper det ikke skjer for ofte. Forsøk å være mest mulig robust ved å markere lenker som sikre og ta noen egne notater som man har kontroll over.

 

Jeg skjønner ikke hvordan man skal låse personer og er redd det vil kreve mye arbeid å implementere. Vi har allerede at lenker markert som sikre ikke kan endres ved automatisk lenking. Noen problemstillinger: Hvem skal ha rett til å låse og å låse opp? Skal andre kunne varsle feil? Skal det begrense både lenking og delenking? Skal det automatiske også gjelde alle familiemedlemmer man er koblet til? I dataprogrammet vil det også medføre en ny relasjon mellom personer og bidragsytere som vil kreve en del tid å implementere. Vi tenker imidlertid på hvordan man kan ta denne ideen og andre foreslåtte ideer til å bedre histreg.

[Kjell Inge Tomren]

Jeg kom over en profil der koden EMIP hadde blitt lagt inn i feltet for dato for dødsfall. Det ser bra ut i oversikten og viser at en person sannsynligvis har emigrert og at dødsfallet derfor ikke finnes i Digitalarkivet. Jeg gjorde det samme i en familie der minst tre av søskeflokken emigrerte: https://histreg.no/index.php/person/pv00000002084579

I personprofilene er emigrasjon er viktig informasjon. I de tilfellene det er permanent emigrasjon, så er det jo siste hendelse i profilen og en forklaring på hvorfor det ikke finnes nyere hendelser om denne personen. 

Hva bør være anbefalt måte for å markere det i profilen?

Men å bruke dato for dødsfallet er jo en slags misbruk av databasen, så det er kanskje en uønsket praksis?

Hva er ulempene ved å "misbruke" et felt på denne måten? 

Bør vi holde oss til kommetarer og lenker for tilleggsinformasjon som ikke finnes i Digitalarkivet. 

Noen mulighet for at emigrasjon vil bli innarbeidet i løsningen for histreg.no?

 

 

[Lars Holden]

18 minutes ago, Kjell Inge Tomren said:

Jeg kom over en profil der koden EMIP hadde blitt lagt inn i feltet for dato for dødsfall. Det ser bra ut i oversikten og viser at en person sannsynligvis har emigrert og at dødsfallet derfor ikke finnes i Digitalarkivet. Jeg gjorde det samme i en familie der minst tre av søskeflokken emigrerte: https://histreg.no/index.php/person/pv00000002084579

I personprofilene er emigrasjon er viktig informasjon. I de tilfellene det er permanent emigrasjon, så er det jo siste hendelse i profilen og en forklaring på hvorfor det ikke finnes nyere hendelser om denne personen. 

Hva bør være anbefalt måte for å markere det i profilen?

Men å bruke dato for dødsfallet er jo en slags misbruk av databasen, så det er kanskje en uønsket praksis?

Hva er ulempene ved å "misbruke" et felt på denne måten? 

Bør vi holde oss til kommetarer og lenker for tilleggsinformasjon som ikke finnes i Digitalarkivet. 

Noen mulighet for at emigrasjon vil bli innarbeidet i løsningen for histreg.no?

 

 

Jeg har ikke tenkt over denne muligheten før. Jeg synes det så bra ut og det ga en god oversikt. Jeg har dermed ingen innvendinger. Men er åpen for andre synspunkter. Teknisk ser det ut til å fungere.

 

Emigrantmaterialet er i Digitalarkivet og kan lenkes som alle andre kilder i Digitalarkivet. Arkivverket holder på med en opprydding i disse kildene. Transkriberingen skal gjøres komplett og fjerne der det er dubletter av samme kilde. Når kildene er ferdige, vil jeg forsøke automatisk lenking. Men jeg tror ikke det går siden kildene er så sparsomme med informasjon. Vi har vurdert å ha en markering av personer med kategorier født i utlandet, vært i utlandet, emigrert permanent til utlandet. Men usiker på hvor nyttig det vil være. Jeg vet ikke hva som ellers ligger i å innarbeide i histreg.no.

[Arkivverket - Kristian Hunskaar]

Nå er EMIP en kode i Digitalarkivet for kildetypen "Emigrantprotokoll". Slik sett gir det ingen mening å angi "EMIP" i årstallsfeltet for død. Ville det ikke være bedre å angi "etter ÅÅÅÅ", hvor "ÅÅÅÅ" er årstallet for emigrasjonen, eller et annet (senere) årstall, om man vet at personen var i live på et senere tidspunkt? Når man angir "USA" i stedsfeltet for død, indikerer det jo allerede at dødsfallet ikke vil kunne dokumenteres av "norske kilder" i Digitalarkivet.

[Lars Holden]

35 minutes ago, Arkivverket - Kristian Hunskaar said:

Nå er EMIP en kode i Digitalarkivet for kildetypen "Emigrantprotokoll". Slik sett gir det ingen mening å angi "EMIP" i årstallsfeltet for død. Ville det ikke være bedre å angi "etter ÅÅÅÅ", hvor "ÅÅÅÅ" er årstallet for emigrasjonen, eller et annet (senere) årstall, om man vet at personen var i live på et senere tidspunkt? Når man angir "USA" i stedsfeltet for død, indikerer det jo allerede at dødsfallet ikke vil kunne dokumenteres av "norske kilder" i Digitalarkivet.

Jeg er enig med Kristian her, dvs bedre å fylle ut feltet med "etter ÅÅÅÅ". Dette er et tekstfelt i databasen, slik at det ikke skaper problemer med tekst. Når det skrives tekst, bør den være standardisert som "etter ÅÅÅÅ" slik at den er lett å tolke maskinelt.

[Kjell Inge Tomren]

På 1.1.2025 den 17.20, Lars Holden skrev:

Jeg vet ikke hva som ellers ligger i å innarbeide i histreg.no.

Det jeg tenkte på var om hendelsen emigrasjon også kunne bli fremhevet på tilsvarende måte som fødsel og død slik at det kom tydelig fram at emigrasjonen var siste hendelsen i livsløpstabellen. 

[Kjell Inge Tomren]

5 timer siden, Lars Holden skrev:

Jeg er enig med Kristian her, dvs bedre å fylle ut feltet med "etter ÅÅÅÅ". Dette er et tekstfelt i databasen, slik at det ikke skaper problemer med tekst. Når det skrives tekst, bør den være standardisert som "etter ÅÅÅÅ" slik at den er lett å tolke maskinelt.

Når jeg skriver "etter 1924" så er det "1924" som blir synlig i listenene med søsken i familien, og det syns jeg er ganske misvisende. Hvis dette er et tekstfelt, så burde hele feltet vises slik at det blir tydelig at nøyaktig år ikke er kjent. Jeg vil også foreslå å standardisere på noe bedre enn det norske ordet "etter". Hva med "> 1924" som jeg ser er brukt i noen slektsprogrammer? Et brukervennlig programsystem burde ellers være tolerant for variasjon ved innlesing og standardisere det som programmet viser. 

[Lars Holden]

14 hours ago, Kjell Inge Tomren said:

Når jeg skriver "etter 1924" så er det "1924" som blir synlig i listenene med søsken i familien, og det syns jeg er ganske misvisende. Hvis dette er et tekstfelt, så burde hele feltet vises slik at det blir tydelig at nøyaktig år ikke er kjent. Jeg vil også foreslå å standardisere på noe bedre enn det norske ordet "etter". Hva med "> 1924" som jeg ser er brukt i noen slektsprogrammer? Et brukervennlig programsystem burde ellers være tolerant for variasjon ved innlesing og standardisere det som programmet viser. 

Fødsels- og dødsdato er tekstfelt. Når det står andre tegn enn tall, forsøker vi å tolke innholdet til en dato eller årstall. Det gjør at "etter 1924" blir til "1924". Vi kan endre dette slik at "etter 1924" og ">1924" blir til ">1924" i familietabellen på personsiden. Når vi gjør denne endringen, endrer vi også fødselsdato "før 1924" og "<1924" til "<1924" i familietabellen. Jeg håper dette er på plass i neste uke.

[Kjell_Kjenstad]

38 minutter siden, Lars Holden skrev:

Fødsels- og dødsdato er tekstfelt. Når det står andre tegn enn tall, forsøker vi å tolke innholdet til en dato eller årstall. Det gjør at "etter 1924" blir til "1924". Vi kan endre dette slik at "etter 1924" og ">1924" blir til ">1924" i familietabellen på personsiden. Når vi gjør denne endringen, endrer vi også fødselsdato "før 1924" og "<1924" til "<1924" i familietabellen. Jeg håper dette er på plass i neste uke.

 

Her synes jeg at dere går litt for fort fram. Jeg er en av de som har brukt "EMIP" systematisk slik som beskrevet i denne tråden i mange hundre tilfeller. Jeg fikk ideen fra en personprofil fra Leksvik kommune tidlig i 2024. Jeg syns det har vært svært nyttig i mange sammenhenger og jeg har derfor noen motargumenter.

1. "EMIP" som 4 bokstavers kode passer inn i en formateringen av et tall med 4 siffer. Vi endrer altså ikke formateringen.
2. "EMIP" med store bokstaver skiller seg tydelig visuelt fra et årstall, og det gjør at det er lett å se hvem i familien som har emigrert. En løsning med ">åååå" ville på lang nær være like visuelt tydelig.
3. "EMIP" med store bokstaver gjør også at vi umiddelbart ser at det dreier seg om en kode for et unntakstilfelle, og ikke et årstall.
4. En løsning med ">åååå" er semantisk tvetydig. Hvis vi velger betydningen "å emigrere permanent", så er årstallet redundant ettersom EMIP-kilden gir årstallet for emigrasjonen. Hvis vi velger betydningen "å med sikkerhet ha dødd etter det angitte tidspunktet", så kan det brukes på alle som har ukjent dødsdato uavhengig av hvor dødsfallet har blitt registrert. Jeg er svært usikker på om en tilfeldig bruker av histreg vil være klar over denne forskjellen.
5. I valget mellom "EMIP" og ">åååå" så er EMIP mer intuitivt ettersom det er en enumerert kode. Dette er grunnen til at vi foretrekker enumererte koder framfor tall-koder i programmering.
6. Argumentet om at "EMIP" er brukt som kode for en kilde i Digitalarkivet og derfor ikke kan brukes som kode for et årstall er litt søkt. Jeg kan ikke se noen systemtekniske konflikter i det. En parser for dato-formatering vil lett kunne håndtere predefinerte enumererte koder for unntak.
7. "EMIP" som kode for et årstall er entydig (og intuitiv) i den betydningen at vedkommende person har en EMIP-kilde som siste kilde i livsløpstabellen og derfor med stor sannsynlighet har forlatt Norge som bostedsland for alltid. For EMIP-kilder fra 1900-tallet har jeg ofte valgt å ikke bruke "EMIP" ettersom vi ikke kan vite om vedkommende har kommet tilbake i en periode hvor vi mangler åpne kilder.
8. "EMIP"-konseptet har vist seg å være spesielt nyttig ifm. med en systematisk histreg-registering for en hel kommune. Da har jeg brukt følgende strategi etter at de fleste koblingene var etablert i den aktuelle kommunen: Jeg har først gått systematisk gjennom dødsfallsregistrene i Digitalarkivet for den aktuelle bostedskommunen. Deretter har jeg gått systematisk gjennom EMIP-kildene i Digitalarkivet for den aktuelle bostedskommunen. På den måten har jeg fått med alle EMIP-kildene i livsløpstabellen samtidig som jeg har fått lagt inn "EMIP" etter prinsippene beskrevet i pkt. 7. En slik strategi viste seg å være svært nyttig i den påfølgende systematiske kvalitetssikringen ettersom jeg derfor slapp å gjøre et ekstra søk på manglene dødsårstall for personer som allerede var kodet med "EMIP". I en slik kontekst kan en alternativt oppfatte "EMIP" som en temporær merkelapp under registreringsarbeidet.

PS 1: I de tilfeller hvor jeg har registrert "EMIP" som dødsdato, så har jeg samtidig lagt i navnet på destinasjonen i EMIP-kilden som "sted for dødsfall".

PS 2: I mine registreringer har jeg mange som flytter over grensen til og fra Sverige. Kilden er her kirkeboken. Dette tilfellet er analogt med "EMIP", men her er det unaturlig å benytte koden "EMIP".  Hvis jeg skal følge mine egen argumentasjon, så ville det være naturlig å benytte Digitalarkivets kilde-kode på vedkommende kirkebok.

 

[Lars Holden]

55 minutes ago, Kjell_Kjenstad said:

 

Her synes jeg at dere går litt for fort fram. Jeg er en av de som har brukt "EMIP" systematisk slik som beskrevet i denne tråden i mange hundre tilfeller. Jeg fikk ideen fra en personprofil fra Leksvik kommune tidlig i 2024. Jeg syns det har vært svært nyttig i mange sammenhenger og jeg har derfor noen motargumenter.

1. "EMIP" som 4 bokstavers kode passer inn i en formateringen av et tall med 4 siffer. Vi endrer altså ikke formateringen.
2. "EMIP" med store bokstaver skiller seg tydelig visuelt fra et årstall, og det gjør at det er lett å se hvem i familien som har emigrert. En løsning med ">åååå" ville på lang nær være like visuelt tydelig.
3. "EMIP" med store bokstaver gjør også at vi umiddelbart ser at det dreier seg om en kode for et unntakstilfelle, og ikke et årstall.
4. En løsning med ">åååå" er semantisk tvetydig. Hvis vi velger betydningen "å emigrere permanent", så er årstallet redundant ettersom EMIP-kilden gir årstallet for emigrasjonen. Hvis vi velger betydningen "å med sikkerhet ha dødd etter det angitte tidspunktet", så kan det brukes på alle som har ukjent dødsdato uavhengig av hvor dødsfallet har blitt registrert. Jeg er svært usikker på om en tilfeldig bruker av histreg vil være klar over denne forskjellen.
5. I valget mellom "EMIP" og ">åååå" så er EMIP mer intuitivt ettersom det er en enumerert kode. Dette er grunnen til at vi foretrekker enumererte koder framfor tall-koder i programmering.
6. Argumentet om at "EMIP" er brukt som kode for en kilde i Digitalarkivet og derfor ikke kan brukes som kode for et årstall er litt søkt. Jeg kan ikke se noen systemtekniske konflikter i det. En parser for dato-formatering vil lett kunne håndtere predefinerte enumererte koder for unntak.
7. "EMIP" som kode for et årstall er entydig (og intuitiv) i den betydningen at vedkommende person har en EMIP-kilde som siste kilde i livsløpstabellen og derfor med stor sannsynlighet har forlatt Norge som bostedsland for alltid. For EMIP-kilder fra 1900-tallet har jeg ofte valgt å ikke bruke "EMIP" ettersom vi ikke kan vite om vedkommende har kommet tilbake i en periode hvor vi mangler åpne kilder.
8. "EMIP"-konseptet har vist seg å være spesielt nyttig ifm. med en systematisk histreg-registering for en hel kommune. Da har jeg brukt følgende strategi etter at de fleste koblingene var etablert i den aktuelle kommunen: Jeg har først gått systematisk gjennom dødsfallsregistrene i Digitalarkivet for den aktuelle bostedskommunen. Deretter har jeg gått systematisk gjennom EMIP-kildene i Digitalarkivet for den aktuelle bostedskommunen. På den måten har jeg fått med alle EMIP-kildene i livsløpstabellen samtidig som jeg har fått lagt inn "EMIP" etter prinsippene beskrevet i pkt. 7. En slik strategi viste seg å være svært nyttig i den påfølgende systematiske kvalitetssikringen ettersom jeg derfor slapp å gjøre et ekstra søk på manglene dødsårstall for personer som allerede var kodet med "EMIP". I en slik kontekst kan en alternativt oppfatte "EMIP" som en temporær merkelapp under registreringsarbeidet.

PS 1: I de tilfeller hvor jeg har registrert "EMIP" som dødsdato, så har jeg samtidig lagt i navnet på destinasjonen i EMIP-kilden som "sted for dødsfall".

PS 2: I mine registreringer har jeg mange som flytter over grensen til og fra Sverige. Kilden er her kirkeboken. Dette tilfellet er analogt med "EMIP", men her er det unaturlig å benytte koden "EMIP".  Hvis jeg skal følge mine egen argumentasjon, så ville det være naturlig å benytte Digitalarkivets kilde-kode på vedkommende kirkebok.

 

Takk for gode argumenter. Vi er åpne for flere synspunkter.

Jeg har følgende kommentar:
Det er mange gode argumenter for både «EMIP» og «>åååå». Selv om vi skulle bestemme oss for en av disse, vil vi ikke kunne hindre at begge blir brukt. Mange bidragsytere følger denne debatten, men de fleste gjør ikke det. Jeg synes ikke det er aktuelt å hindre en av variantene. Det er dermed greit at begge varianter brukes. Brukerne får velge hvilken som vil være dominerende.  

Det er lett å håndtere ulik praksis selv om det ville være penere om alle fulgte lik praksis. Bidragsyterne er frivillige, og det er viktig at de har noen friheter i hvordan de arbeider.

Men det er en fordel om vi har mest mulig lik tolkning. Mitt forslag er:

EMIP, emigrert utenfor Norden og høyst sannsynlig ikke registrert i norsk kilde etter dette.

Tilsvarende kan man bruke tilsvarende koder for kilder der det f.eks. flyttes til Sverige.

>åååå  Dødsfall senere enn åååå. Det kan brukes ved emigrasjon, men også i spesielle tilfeller der det er viktig å påpeke dette. Kan være f.eks. at personen er funnet i en skifteprotokoll i en høy alder. IKKE tenkt at det skal brukes på alle personer der vi ikke finner årstall for dødsfall.

Angående å følge retningslinjer. Vi har klare retningslinjer for hvordan referanser skal skrives. Men det er veldig mange som bare skriver «dåp» eller «begravelse».

[Arkivverket - Kristian Hunskaar]

Hva dere bestemmer dere for, er i og for seg likegyldig for meg, men jeg vil bare minne om hva jeg skrev forleden dag: EMIP er i Digitalarkivets database en kode for "Emigrantprotokoll". Jeg ville i det minste valgt en firebokstavs forkortelse som gir mening, f.eks. EMIG(rert), UTVA(ndret) e.l.

[Kjell Inge Tomren]

På 3.1.2025 den 15.58, Arkivverket - Kristian Hunskaar skrev:

... EMIP er i Digitalarkivets database en kode for "Emigrantprotokoll". Jeg ville i det minste valgt en firebokstavs forkortelse som gir mening, f.eks. EMIG(rert), UTVA(ndret) e.l.

Når jeg arbeider med personprofiler i histreg.no så forsøker jeg så tidlig som mulig å "ramme inn" livsløpet ved å finne dåpen og begravelsen/dødsfallet. I de tilfellene jeg ikke klarer å finne begravelse eller dødsfall så er det alltid et lite mysterium som jeg forsøker å finne ut. Emigrasjon er en foreløpig konklusjon og en pekepinn på hvor vi kan søke etter opplysninger om personens videre livsløp, og jeg syns det er svært nyttig at emigrasjonen blir godt synlig for andre brukere.

Status er at noen brukere har funnet det formålstjenelig å bruke en kode for de som har emigrert og som derfor ikke er registrert med begravelse eller dødsfall i Norge. Det ser ut til at disse brukerne har tatt i bruk koden EMIP. Sannsynligvis fordi det er den koden som assosieres med emigrasjon. Jeg antar at ingen har sjekket omfanget av denne praksisen, men @Kjell_Kjenstadskrev at han alene har lagt inn mange hundre EMIP. Jeg tror det ville være interessant nå å vite omfanget og om EMIP er eneste kode som har blitt lagt inn i datofeltet for død.

Jeg er positiv til at vi skal endre praksis og bruke EMIG i steden for EMIP, men det vil i første omgang bare medføre at vi får (minst) to ulike koder i bruk. Jeg regner med at alle forekomster av EMIP maskinelt kan endres til EMIG og det vil bidra til overgangen, men noen brukere vil nok fortsette sin praksis med å bruke EMIP.

Så noen konkrete spørsmål:

1. Kan det produseres statistikk for koder som pr nå ligger i datofeltet for død?

2. Er en maskinell endring av EMIP til EMIG noe som kan gies prioritet?

3. Ser dere noen andre ulemper med å bruke EMIG heller enn EMIP?

 

[Lars Holden]

On 1/6/2025 at 8:49 AM, Kjell Inge Tomren said:

Når jeg arbeider med personprofiler i histreg.no så forsøker jeg så tidlig som mulig å "ramme inn" livsløpet ved å finne dåpen og begravelsen/dødsfallet. I de tilfellene jeg ikke klarer å finne begravelse eller dødsfall så er det alltid et lite mysterium som jeg forsøker å finne ut. Emigrasjon er en foreløpig konklusjon og en pekepinn på hvor vi kan søke etter opplysninger om personens videre livsløp, og jeg syns det er svært nyttig at emigrasjonen blir godt synlig for andre brukere.

Status er at noen brukere har funnet det formålstjenelig å bruke en kode for de som har emigrert og som derfor ikke er registrert med begravelse eller dødsfall i Norge. Det ser ut til at disse brukerne har tatt i bruk koden EMIP. Sannsynligvis fordi det er den koden som assosieres med emigrasjon. Jeg antar at ingen har sjekket omfanget av denne praksisen, men @Kjell_Kjenstadskrev at han alene har lagt inn mange hundre EMIP. Jeg tror det ville være interessant nå å vite omfanget og om EMIP er eneste kode som har blitt lagt inn i datofeltet for død.

Jeg er positiv til at vi skal endre praksis og bruke EMIG i steden for EMIP, men det vil i første omgang bare medføre at vi får (minst) to ulike koder i bruk. Jeg regner med at alle forekomster av EMIP maskinelt kan endres til EMIG og det vil bidra til overgangen, men noen brukere vil nok fortsette sin praksis med å bruke EMIP.

Så noen konkrete spørsmål:

1. Kan det produseres statistikk for koder som pr nå ligger i datofeltet for død?

2. Er en maskinell endring av EMIP til EMIG noe som kan gies prioritet?

3. Ser dere noen andre ulemper med å bruke EMIG heller enn EMIP?

 

1. Vi kan lage slik statistikk, men foreløpig har jeg ikke fått noe tall for det.

2 og 3 Jeg har ikke noen sterke preferanser for EMIP eller EMIG.

 

Generelt vil det være fint om alle bidragsytere følger samme praksis i markering. Det er dessverre ikke realistisk å få til. Vi kan heller ikke prioritere å endre hele databasen med å erstatte et ord skrevet inn manuelt med et annet ord hvis det ikke er noe helst spesielt. Men som et skritt i denne retning planlegger vi følgende:

- det er ingen kontroll/sperre med hva som skrives inn i feltet for dato for dødsfall.

- men hvis det skrives inn et ord som begynner på "em" og så står det et årstall, vises dette som f.eks"> 1880" i familietabellen

- hvis det skrives inn et ord som begynner med "em" så vises det som "EMIG" i familietabellen.

[Kjell_Kjenstad]

På 7.1.2025 den 10.58, Lars Holden skrev:

1. Vi kan lage slik statistikk, men foreløpig har jeg ikke fått noe tall for det.

2 og 3 Jeg har ikke noen sterke preferanser for EMIP eller EMIG.

 

Generelt vil det være fint om alle bidragsytere følger samme praksis i markering. Det er dessverre ikke realistisk å få til. Vi kan heller ikke prioritere å endre hele databasen med å erstatte et ord skrevet inn manuelt med et annet ord hvis det ikke er noe helst spesielt. Men som et skritt i denne retning planlegger vi følgende:

- det er ingen kontroll/sperre med hva som skrives inn i feltet for dato for dødsfall.

- men hvis det skrives inn et ord som begynner på "em" og så står det et årstall, vises dette som f.eks"> 1880" i familietabellen

- hvis det skrives inn et ord som begynner med "em" så vises det som "EMIG" i familietabellen.

 

Jeg har heller ingen sterke preferanser for EMIP eller EMIG.

 

Jeg ser imidlertid at det har blitt referert til mitt forrige innlegg og min formulering "mange hundre tilfeller". Det er riktig at det er tilfelle, men jeg ser ikke at dette alene skal være et argument mot å bli enige om å bruke "EMIG" som standard eller preferert anbefaling. Jeg skal greie å endre mine registeringer fra "EMIP" til "EMIG" manuelt på i størrelsesorden 3-5 timer. Denne typen strafferunder kan noen ganger være prisen å betale for å være tidlig ute med å teste ut forslag til løsninger som ennå ikke er godt nok forankret i prosjektet. Hvis det derimot er mange andre som har brukt "EMIP" i mange tilfeller, så kan saken være en annen. Jeg vil derfor uansett ikke gjøre en slik endring før vi har en endelig konklusjon.

Grunnen til at jeg valgte å bruke "EMIP" som kode var mangel på et bedre alternativ, og da var det naturlig å velge det som allerede var brukt av andre. Jeg vurderte andre løsninger slik som landskoder, men konkluderte med at  det var bedre å følge det som på det tidspunktet sannsynligvis kunne bli en standardisert løsning.

 

Mitt forrige innlegg i saken handlet først og fremst om mine positive erfaringer med bruk av en enumerert kode (i.e. "EMIP") kontra alternativene ">ÅÅÅÅ" eller tomt felt. I ettertid har imidlertid Lars Holden argumentert på en god måte for behovet for å tillate ">ÅÅÅÅ" i visse tilfeller. Å tillate begge alternativene er derfor en fornuftig konklusjon.

 

Vi må også være klar over muligheten for at en "EMIP/EMIG"-registrering ikke nødvendigvis behøver å være endelig. Slektsforskere har i mange tilfeller kunnskap om dato og sted for en emigrants dødsfall. I slike tilfeller må vi tillate at registreringen endres. Jeg har selv opplevd at en av mine "EMIP"-registreringer har blitt endret og dokumentert i merknadsfeltet.

 

Hvis vi konvergerer mot "EMIG" som standard enumerert kode for emigrasjon, så kan det allerede nå være nyttig å vurdere analoge kandidater som også kan ha behov for en standard enumerert kode. Da er det nyttig å bestemme endelig navn på koden slik at vi slipper framtidige strafferunder. Lars og jeg har allerede nevnt kandidaten "flyttet utenlands innenfor Norden". Jeg supplerer her med kandidatene "dødfødt" og "flyttet til ukjent sted innenlands".

 

En standard eller en preferert anbefaling for registrering av enumererte koder må dokumenteres slik at den er synlig for brukerne under registreringen. Dokumentasjonen (i vårt tilfelle en liste av enumererte koder) må ligge tett opp til registreringsskjemaet (i vårt tilfelle personredigeringssiden). I vårt tilfelle vil en nedtrekksmeny til høyre for dødsdatoen, og med default verdi "dato", kunne være en enkel og god løsning.

[Bodil Hørlück Berg]

36 minutter siden, Kjell_Kjenstad skrev:

 

Jeg har heller ingen sterke preferanser for EMIP eller EMIG.

 

Jeg ser imidlertid at det har blitt referert til mitt forrige innlegg og min formulering "mange hundre tilfeller". Det er riktig at det er tilfelle, men jeg ser ikke at dette alene skal være et argument mot å bli enige om å bruke "EMIG" som standard eller preferert anbefaling. Jeg skal greie å endre mine registeringer fra "EMIP" til "EMIG" manuelt på i størrelsesorden 3-5 timer. Denne typen strafferunder kan noen ganger være prisen å betale for å være tidlig ute med å teste ut forslag til løsninger som ennå ikke er godt nok forankret i prosjektet. Hvis det derimot er mange andre som har brukt "EMIP" i mange tilfeller, så kan saken være en annen. Jeg vil derfor uansett ikke gjøre en slik endring før vi har en endelig konklusjon.

Grunnen til at jeg valgte å bruke "EMIP" som kode var mangel på et bedre alternativ, og da var det naturlig å velge det som allerede var brukt av andre. Jeg vurderte andre løsninger slik som landskoder, men konkluderte med at  det var bedre å følge det som på det tidspunktet sannsynligvis kunne bli en standardisert løsning.

 

Mitt forrige innlegg i saken handlet først og fremst om mine positive erfaringer med bruk av en enumerert kode (i.e. "EMIP") kontra alternativene ">ÅÅÅÅ" eller tomt felt. I ettertid har imidlertid Lars Holden argumentert på en god måte for behovet for å tillate ">ÅÅÅÅ" i visse tilfeller. Å tillate begge alternativene er derfor en fornuftig konklusjon.

 

Vi må også være klar over muligheten for at en "EMIP/EMIG"-registrering ikke nødvendigvis behøver å være endelig. Slektsforskere har i mange tilfeller kunnskap om dato og sted for en emigrants dødsfall. I slike tilfeller må vi tillate at registreringen endres. Jeg har selv opplevd at en av mine "EMIP"-registreringer har blitt endret og dokumentert i merknadsfeltet.

 

Hvis vi konvergerer mot "EMIG" som standard enumerert kode for emigrasjon, så kan det allerede nå være nyttig å vurdere analoge kandidater som også kan ha behov for en standard enumerert kode. Da er det nyttig å bestemme endelig navn på koden slik at vi slipper framtidige strafferunder. Lars og jeg har allerede nevnt kandidaten "flyttet utenlands innenfor Norden". Jeg supplerer her med kandidatene "dødfødt" og "flyttet til ukjent sted innenlands".

 

En standard eller en preferert anbefaling for registrering av enumererte koder må dokumenteres slik at den er synlig for brukerne under registreringen. Dokumentasjonen (i vårt tilfelle en liste av enumererte koder) må ligge tett opp til registreringsskjemaet (i vårt tilfelle personredigeringssiden). I vårt tilfelle vil en nedtrekksmeny til høyre for dødsdatoen, og med default verdi "dato", kunne være en enkel og god løsning.

Jeg har også registret en god del kandidater med EMIP etter at jeg så det registret på et par personprofiler i Trøndelagsområdet. Jeg synes en slik kode gir en god visning, men kan godt bytte til EMIG hvis det er viktig.  Det kan godt ha blitt et par hundre på meg og, uten at jeg har tall på det. Og jeg tror ikke jeg har like lett for å finne tilbake til dem som det blir tilbudt i innlegget fra Kjell Kjerstad her.

 

Jeg har egentlig vært mer bekymret for tolkning av stedsnavnsangivelse og hvordan data der skal rettes eller kunne tolkes maskinelt, f.eks når det står gårdsnavn, men ikke kommune. Skal det være skilletegn eller ikke osv. Tar gjerne imot tips på hva som er ideelt.

[Lars Holden]

Da legger vi inn en veiledning ved feltet slik at man skriver på formatet  dd.mm.åååå, åååå, EMIG, etter åååå.

Vi kom til at "1820 - > 1880" kunne oppfattes som en pil og valgte å bruke "etter"

I tillegg omformulerer vi denne teksten i familieoversikten og søkesiden slik at hvis det står et ord som begynner med "em" eller "utv" så skriver vi "EMIG". Tilsvarende hvis det i tillegg er et årstall, skriver vi "etter åååå" i feltet. 

[Arild Maka]

På 10.12.2024 den 8.58, Lars Holden skrev:

Jeg illustrerer med et eksempel. Anta en person som har 10 personforekomster skal splittes i to personer som har hhv 4 og 6 personforekomster. Man kan da velge å splitte ut de 4 personforekomstene eller de 6 personforekomstene. Etter oppsplittingen vil man uansett ha to personer med hhv 4 og 6 personforekomster og hver sin HP. Hvis man skiller ut den personen som har HP (uansett om dette er personene med 4 eller 6 personforekomster), vil navnene oppdateres slik at man slipper å oppdatere dette etter splittingen.

Det burde være en enkel måte å finne igjen den personen som splittes ut. F. eks. kunne denne komme opp i en ny arkfane. Da kan en rydde litt opp i denne før den glemmes. Slik det er nå kan det være vanskelig å finne den igjen. En må nesten kopiere en ID før splitting og søke den opp etterpå.

[Kjell Inge Tomren]

På 8.1.2025 den 23.53, Bodil Hørlück Berg skrev:

Jeg har egentlig vært mer bekymret for tolkning av stedsnavnsangivelse og hvordan data der skal rettes eller kunne tolkes maskinelt, f.eks når det står gårdsnavn, men ikke kommune. Skal det være skilletegn eller ikke osv. Tar gjerne imot tips på hva som er ideelt.

Jeg har også tenkt på hva som er beste måten å angi sted på. Jeg har ikke kommet fram til noen konsistent praksis, men jeg forsøker å angi stedet så presist som jeg kan i forhold til det jeg finner i kildene. Men, det er varierende presisjon i kildene. En opplysning i en kirkebok vil som regel angi et gårdsnavn i tillegg til at prestegjeld og sogn er implisitt ut fra hvilken bok vi snakker om. Tilsvarende for en folketelling som går helt ned til bruk og familie på bygdene og til gateadresse og familie i byene. Nyere dødsfall vil derimot bare angi hvilken kommune eller herred personen bodde ved dødsfallet. I noen tilfeller finner vi både kommune for dødsfall og bostedskommune. 

Jeg pleier å starte med gårdsnavn (hvis kjent) og så de større enhetene med komma som skilletegn. F.eks Kjerstad, Lepsøy, Haram prgj. 

Jeg tenker at min praksis vil være nyttig for andre som søker manuelt, men den ligger definitivt ikke tilrette for maskinell analyse. Hva kan vi se for oss av framtidige behov?

[Arild Maka]

På 9.1.2025 den 10.31, Lars Holden skrev:

Da legger vi inn en veiledning ved feltet slik at man skriver på formatet  dd.mm.åååå, åååå, EMIG, etter åååå.

Vi kom til at "1820 - > 1880" kunne oppfattes som en pil og valgte å bruke "etter"

I tillegg omformulerer vi denne teksten i familieoversikten og søkesiden slik at hvis det står et ord som begynner med "em" eller "utv" så skriver vi "EMIG". Tilsvarende hvis det i tillegg er et årstall, skriver vi "etter åååå" i feltet. 

Jeg har i lang tid tatt meg den frihet å skrive "Utv." i feltet for død for de som har utvandret/emigrert, men kun i de tilfeller jeg har funnet utvandringen. Dette har gitt meg store fordeler. Først og fremst ser jeg at feltet er fylt ut slik at jeg slipper å åpne personen på nytt for å prøve å finne vedkommendes dødstidspunkt. Men jeg vet også at jeg har funnet utvandringen. For det tredje så får jeg gjerne opp en lang liste med personer når jeg søker etter en som har emigrert. Da vet jeg at de med "Utv." allerede er knyttet opp til en person og jeg kan således hoppe over disse. For meg kan jeg gjerne skrive "EMIG" i stedet, men det er umulig å søke frem info som er lagt inn i Histreg og da klarer jeg ikke å søke dem opp og endre innholdet.

[Arild Maka]

Et lite eksempel:

[Lars Holden]

Emigrert. Når vi får lagt ut den siste endringen, vil det stå EMIG istedenfor Utv. i søkelisten. På personsiden i feltet for dødsdato, vil det stå det som er fylt ut i dette feltet. Vi lever fint med at det står Utv. en del steder.

 

Vise tidligere lenker. Vi har funnet ut hvordan vi generelt kan vise tidligere lenker, men det er dessverre mye programmering som skal til for å vise dette. Det vil derfor ikke bli prioritert på en stund.

 

Stednavn. Jeg synes det er et godt forslag ang. stedsnavn. Fint med flere nivåer med komma mellom. Hvis man har gård eller gateadresse, kan det være første navn. Hvis siste navn er brukt flere steder i landet som Bø, kan det være fint med fylke til slutt.

[Kjell Inge Tomren]

På 7.1.2025 den 10.58, Lars Holden skrev:

- hvis det skrives inn et ord som begynner med "em" så vises det som "EMIG" i familietabellen.

Akkurat nå ser det ut som om EMIG vises som EMIP: 

Fra https://www.histreg.no/index.php/person/pv00000006640381

Partner og barn

Partner: Jørgine Sofie Georgsdatter Ansok, f. Ous , 1866 - 1953
Barn: Johanne Olivia Marie Ansok , 1888 - 1964
Barn: Ole Jørgen Rasmussen Ansok , 1890 - 1969
Barn: Julianne Rasmusdatter Ansok , 1891 - EMIP
Barn: Johan Hilmar Rasmusson Ansok , 1893 - 1982