Släkttrim - Frågor/synpunkter

[C-J Gustafsson]

Hej Fredric
Tänk om det funnits en standard, då skulle jag gärna se att ditt skrivsätt blev till standard. Tyvärr verkar vi ändå inte klara av att ta hand om det.

Det som ditt skrivsätt stupar på är kommatecknet mellan församling och länsbokstav och kanske också land om du angett det också på svenska församlingar.

Vi har fastnat för "Församling (länsbokstav), plus ev. någon text som kan vara vad som helt". Det har blivit vår "standard". Det innebär att vi inte betraktar län som en egen enhet utan bara som en identifierare av församlingen, eftersom enbart församlingsnamnet inte är unikt.
Men vi försöker vara så toleranta det bara går för olika skrivformer.

I vår förenklade standard har vi maximalt en avskiljare i form av kommatecken.
I din beskrivning kan det vara 0, 1, 2 eller 3 avskiljare. Det är där vi har svårigheten att maskinellt kunna förstå vad som vad i texten.

Jag har dock för mig att jag försökt trolla bort det där kommat före länsbokstaven, men det har tydligen inte lyckats.
Kan jag få din GEDCOM fil så skall kolla upp och försöka fixa till, skicka den i så fall till 08.55245912@telia.com

Det skrivsätt du använder skall vi absolut kunna klara av.

[tommypeters]

Länsbokstaven har ju många med mig "trollat bort" eftersom inga släktingar under 30 år som vill titta på ens forskning har en aning om vad det är.

Kan man inte skriva in adresser som "Hultåkra, Åseda, Kronobergs län" så blir det här projektet undan för undan mindre och mindre användbart för fler och fler...
Dessutom - att ändra standard för hur man skrivit in många tusen adressupgifter är är inget man gör utan vidare - man gör det snarare inte alls. Då skippar man i stället DisByt, RGD och liknande. Importrutiner och kontrollrutiner kan bli mycket krångliga om de ska vara flexibla - med de rutinerna görs en gång och kan sedan läsa in enligt flera olika skrivsätt.
Så rutinerna behöver kunna hantera "Hultåkra, Åseda, Kronobergs län" liksom "Hultåkra, Åseda" eller "Åseda, Hultåkra, Kronobergs län" eller "Hultåkra, Åseda (G)" eller "Hultåkra, Åseda, Kronobergs län, Sverige"...

[Fredricn]

Filen skickad

[walgot]

...
Tänk om det funnits en standard ...

Varför inte använda den 'standard' som råkar finnas i GEDCOM (i varje fall 5.5)? Med en PLAC.FORM-struktur i headern så kan man själv definiera vilken ortnamnsstruktur som används i den aktuella filen/transmissionen. Ett antal av de mera kompetenta genealogiprogrammen kan både tolka och generera sådan information.

Det är t.o.m. möjligt - om än inte rekommenderat - att använda PLAC.FORM-strukturen i enstaka EVENT för att där 'överrida' headerinformationen.

[Fredricn]

Hej.
Tanken med att ha landet definierat sist är att andra ej boende i Sverige ska kunna vet var i världen platsen finns.
Har även danska platser i min forskning.
Sen beror det på hur man ser det här med platangivelse, om man ska följa platsen tidsmässigt, eller skriva in den som den är just nu.
Hårddrar man det så tillhör det gamla området Skåneland Danmark innan 1658 (Ven St.Ibb 1660) och då borde landstillhörigheten vara just Danmark.

[Gestblom]

Om bidragsgivaren angett sina orter på ett konsekvent sätt, skulle det då gå att via gränssnittet kunna ange detta på något sätt?
T.ex. genom att välja från en lista.

[C-J Gustafsson]

Hej Wilhelm och Janåke

Jag har inte sett en enda GEDCOM fil där PLAC.FORM specificerats.

PLACE_STRUCTURE: =

n PLAC <PLACE_VALUE> {1:1}
+1 FORM <PLACE_HIERARCHY> {0:1}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}

Exemplet som visas ger inte heller mycket stöd, for example, "Cove, Cache, Utah, USA.
Så det är nog som mycket med GEDCOM, att det kan appliceras lite olika.

Jag bad dig tidigare om att få en GEDCOM fil med detta, men det har inte kommit.

Jag antar att det är något liknande som Janåke också har i tankarna.

Men frågan är om släktforskare i allmänhet har sådan strikt struktur på sitt data. De exempel vi sett visar mer på att man använder lite olika sätt beroende på situationen.

[C-J Gustafsson]

Det kanske är lättare att beskriva de skrivsätt vi har med i vår tolkning av församling.
Församlingslistan baseras helt på den av Skatteverket utgivna församlingsförteckningen.

Så flera av Tommys exempel finns med. Men det är ganska nyligen vi kompletterade med tolkning av län i textform.
Dessutom är ändring på gång för att klara av exemplet ovan, Ullstorp 10, Ullstorp, (L)

Det vi inte hanterar är det mixade exemplet ovan, Åseda, Hultåkra, Kronobergs län, då vi förutsätter en viss hierarki, t.ex. stor till liten eller liten till stor.

Finns det önskemål om fler tolkningar så skall vi försöka uppfylla det.

Mallar:
Församling (Länsbokstav)
Församling (Länsbokstav), Gård/text
Gård/text, Församling (Länsbokstav)

Församling (Länsnummer)
Församling (Länsnummer), Gård/text
Gård/text, Församling (Länsnummer)

Församling /Länsbokstav/
Församling /Länsbokstav/, Gård/text
Gård/text, Församling /Länsbokstav/

Församling /Länsbokstav
Gård/text, Församling /Länsbokstav

Församling, Länsbokstav
Gård/text, Församling, Länsbokstav

Församling /Länsnummer/
Församling /Länsnummer/, Gård/text
Gård/text, Församling /Länsnummer/

Församling, Län-i-textform
Församling, Län-i-textform, Gård/text
Gård/text, Församling, Län-i-textform

[tommypeters]

Ja, "Åseda, Hultåkra, Kronobergs län" då... :-) Liksom Blekinges löpande numrering som "Nr 105, Långören, Torhamn, Blekinge län".
Det är ju inte så extremt svårt att klara de olika kombinationerna och man prövar dem i prioritetsordning så att man inte förväxlar en socken med ett bynamn, om den risken nu finns.

[C-J Gustafsson]

Hej Tommy
Vi låter ditt förslag påbörja liten hög med önskemål för det kommer säkert flera.

Det blir mer praktiskt om låter frågorna ligga ute en tid, så att fler hinner testa och upptäcka våra svagheter. Det måste inte heller bara handla om församlingar.

Passar på att påpeka, att vi också är i stort behov av fler medhjälpare, som kan hjälpa till att göra produkten bättre och ta hand om de önskemål vi får in.

[walgot]

För att sammanfatta, konkretisera och avsluta mitt spontana 'inhopp' i detta DIS-forumämne, så borde 'Släkttrim':

1. kunna läsa och tolka allt (för programmets ändamål) relevant innehåll i varje fil som är syntaktiskt korrekt enligt GEDCOM 5.5 i dess helhet.

2. kunna exekveras för att ex.vis enbart rapportera individpar som kan misstänkas representera samma person, dvs. 'dubbletter'.

3. kunna göras tillgängligt i en offline-version för ett antal vanliga plattformar.

För övrigt förstår jag inte varför det behövs GEDCOM-exempel då det handlar enbart om syntax. I ett semantikfall hade förståelsen funnits.

Tack för mig.

[tommypeters]

Det är klart det behövs GEDCOM-exempel, då alla program har sin egen "standard". Ancestry har t.ex. sin webbsida och dessutom programmet Family Tree Maker. GEDCOM-filerna man får från webbsidan och Family Tree Maker har stora skillnader, det är naturligtvis minst lika stora skillnader mellan dem och andra företags GEDCOM. Företagen gör ju som Apple och Microsoft - följer en standard (hjälpligt) och "lägger till lite till" för att hålla kvar kunderna hos sig. Vilket program man än byter till så det första man märker är att man förlorar någon information (media eller notiser, t.ex) och då skyller man hellre på det nya programmet än det gamla.

[Gestblom]

Problemet är semantiskt eftersom en entydig syntax saknas.
Det gäller att tolka vad som är by och vad som är socken osv.
Tabellslagning verkar vara rimligaste angreppssättet.

[Rolf Carlsson]

Som Kalle skriver försöker vi att läsa/tyda flera olika skrivsätt av ortsnamn i Gedcomfiler, för att entydigt kunna identifiera församlingen och de därmed följande identifieringarna av identiska individer. Även rena felskrivningar skall aviseras här. Hur vi sedan presenterar ortsnamnet i utdata ur RGDs databas är en helt annan fråga. Era synpunkter är avgjort värdefulla.

Det kommer också att vara en viss skillnad mellan Släkttrim, som är planerat som en "Självbetjäningsbutik" och den definitiva indatakontrollen till RGDs framtida databas, där manuella steg även möjliggör vissa korrigeringar av systematiska avvikelser.

Det har även framförts synpunkter på namnkontroll och här finns planer på en förbättrad version av namndatabasen, som kan möjliggöra bättre varningar. Syftet är i första hand att avisera potentiella felaktigheter (könsfel/förväxling för-efternamn med flera).

Vi kan inte och vill inte påtvinga medlemmarna ett givet format/skrivsätt eller liknande utan har ambitionen att försöka tyda den information som finns i Gedcomfilen på ett korrekt sätt.

Vidare de listor som produceras i samband med Indatavalidering är "Varningslistor", som indikerar något som bör kollas upp (men kan mycket väl visa sig vara korrekt).

Det har varit intressant att följa era respektive diskussioner avseende förbättringar. Över till själva medlemsnyttan med Släkttrim, nämligen att få indikationer på potentiella felaktigheter i den egna eller jämförda forskningen:
Det skulle vara intressant att få höra om någon av har gått vidare till nästa steg - att jämföra två Gedcomfiler med överlappande individer med varandra. Min erfarenhet är att 20 % av nyttan ligger i Indatavalideringen och 80 % av nyttan i analys av Matchningsresultatet. Det är i denna analys, som relationskonflikter och andra svårupptäckta fel indikeras.

Rolf

[tommypeters]

Med en stor GEDCOM-fil tar steg ett rätt lång tid, dessutom behöver ni fixa lite i rutinen så den kan svälja det som kommer från Family Tree Maker så steg två ligger på framtiden om jag kommer åt någon lämplig andra GEDCOM.

[m40484]

Släkttrim klarar inte av att många socknar/församlingar har bytt länstillhörighet under årens lopp. I Socken Sök tas bara upp det aktuella länet, men i Arkiv Digital framgår båda två och ibland tre.

[C-J Gustafsson]

Hej Olle
Helt rätt att församlingar kan ha olika länstillhörighet över tiden.
I vår planerade församlingstabell kommer vi att tillföra tidsintervaller och kontrollera händelsernas tidpunkt mot rätt intervall.

I pilotversionen har vi begränsat oss till den länstillhörighet församlingen hade vid den tidpunkt som skatteverket utgått ifrån, vilket förövrigt också Disgen använder sig av.

I nuläget kan ni få varningssignal, även om ni registrerat församlingen formellt riktigt.
Så länge vi inte har tidsintervallen kommer det att vara problem, men om ni använder rätt län vid rätt tidpunkt skall ni absolut inte ändra på detta.

Vet ni att ni har rätt skall ni strunta i varningen.

[tommypeters]

Något som det behövs idéer - eller expertutlåtande - om är amerikanska sättet att "numrera" söner med samma namn som fäderna. Om Charles Johnsons son heter Charles Johnson, liksom sonsonen, så blir det "Charles Johnson III" för den siste. Amerikanerna registrerar det normalt som suffix, men det gillar inte testrutinen (och kanske inte GEDCOM-standarden heller...). Lägger man det i efternamnsfältet ("Johnson III") så blir det ju som att han hade ett annat efternamn, skriver man det i förnamnsfältet ("Charles III") Johnson så känns det som resultatet blir mer korrekt - men det är ju inte alls så amerikanerna säger det. De säger ju inte "Charles the Third Johnson" utan "Charles Johnson the Third".

[C-J Gustafsson]

Hej Tommy
Det är en ändring på gång som fixar så att suffix-namnet, som FTM lägger utanför ordinarie namnfält, inte orsakar felsignal.

Tills vidare är suffixet bara "instoppat" sist i namnfältet, vilket innebär att det blir ett tillägg till efternamnet.
I de exempel vi hade att tillgå skulle det ibland vara ett efternamn och ibland ett förnamn, så vi tyckte det var "minst fel" att lägga det sist i namnet.

Men idéer och expertutlåtande är alltid välkommet.

[tommypeters]

Det vore bra om ni i larmlistan gällande datum skilde på "felaktiga datum" och "oprecist datum" (eller vad man nu ska kalla det). Ett felaktigt datum är 30 Feb 1711 (men inte 30 Feb 1712...) medan ett "oprecist datum" kan var "Abt 1603". Sådana oprecisa datum blir det ju gott om i gamla tider, där personen endast hittas i dödboken där hans ungefärliga ålder angiven vid dödstillfället bara kan ge en ungefärlig födelsetid. Felaktiga datum måste man ändra, oprecisa datum kan man oftast inte göra något åt.

Sedan är jag intresserad av hur dubblettförekomsterna poängsätts. Den verkar fungera bra, utan det är mer intresse - speciellt varför den inbyggda kontrollen i många släktforskningsprogram är så usel på att sortera bort "felaktiga dubbletter". Normalt kör jag Runar Hortlunds Dubbelgångaren, vilken också är bra på att filtrera bort "false positives", den kommer nu att köras först efter att jag plockat bort de som den här kontrollen hittar. Hade kanske varit intressant att jämföra resultaten med samma indata, men för tidsödande. Det är rensning inför Disbyt-inskick som gäller...

Det ges ju en mängd olika larm och även om det sägs att det "bara är larm och inte behöver vara fel, det är något man bör titta på" så vore det intressant att veta vilka av larmen som pekar på saker som Disbyt kan få problem med. "Dubbla födelsenotiser", t.ex. Man kan ju ha följt en familj och när sonen gifter sig letar man data om hustrun. Man vet inte vilken socken hon kommer ifrån och i de olika notiserna där hon är med (kan vara vigselnotis, olika hfl, dödsnotis) kan man hitta två olika alternativa datum. Tills man kan avgöra vilket som är korrekt matar man in bägge uppgifterna och markera det mesta troliga som "Preferred" och det är det datumet som visas i programmet. Senare kanske man hittar vilken socken hon föddes i, men böckerna för de åren är brandskadade så man vet fortfarande inte födelsedatum som är korrekt. Från Ancestry kommer ju bägge datumen med i GEDCOM-filen och jag ser ingen speciell markering av dem, troligen läggs det datum som är "Preferred" först. Kommer detta att ställa till något problem för Disbyt?

Likaså, som jag tror jag nämnt tidigare, larmas ju om en person har registrerade både biologiska och fosterföräldrar (eller adoptivföräldrar). I vissa fall går det inte att "filtrera bort" personer då t.ex. en flickas farbror har adopterat henne då hennes föräldrar dött - han ska ju vara med i släktträdet. Kommer Disbyt när "den" hittar biologiska föräldrar att bortse från övriga föräldravarianter eller blir det problem?

[tommypeters]

Det larmas om möjlig dubblett mellan två namn på samma person i GEDCOM-filen, det är ju lite underligt larm...

[ingera]

Jag har kört igenom mina nästan 30000 personer.
Programmet hittade en del fel , några felaktiga datum ett antal dubbletter. Dessa är nu rättade.

Har några synpunkter på dop.
Endast ett dop godkännes. Det kan förekomma flera dop för en person.
1. Nöddöpt
2. Bekräftad dop
3. Döpt in i en Baptisförsamling.


Hur göra med begravningsplatser b.l.a. i Stockholm?
Jag har dessa under kommunen inte under en församling. Programmet rapporterar fel.

[C-J Gustafsson]

Hej Tommy
Det är bra att du kommer med synpunkter och frågor. Det var mycket på en gång så jag får ta det bit för bit.
Olika felsignaler på datum tror jag vi skall försöka få till. Det är ju framförallt rent felaktiga datum typ 30 FEB 1711, däremot tror jag inte du fått fel på 30 FEB 1712.

Poängen bakom dubblettkontrollen är ingen vetenskap, i princip räknas likheter och olikheter och sedan byggs det om till ett värde mellan 1 och 9.
Dubblettkontroller är svårt, att jämföra exakta värden går bra men när man skall jämföra uppgifter som "kanske är samma" blir det svårare.
Att hitta en balansgång mellan verkliga dubbletter och falsklarm är i princip omöjligt. Den nivå vi valt riskerar att missa dubbletter men blir listorna alltför långa orkar troligen ingen gå igenom dom.
Vi har haft funderingar på att göra en XL-lista för den som vill gå till botten med dubblettsökningen.

Det blir en mängd "larm", det blir det. Men det är svårt för oss att göra avgränsningar på vad vi skall ha i fellistor/larmlistor/varningslistor, så vi har i princip överlåtit till släktforskaren att avgöra allvaret i de listade meddelandena.

Dubbla värden på olika händelser har betydelse först om man går vidare med efterföljande bearbetning, t.ex. matchningen.

De här kontrollfunktionerna togs fram för ett tänkt RGD där var från början tanken att RGD bara skulle innehålla biologiska kopplingar.
Vi har dock sett hur olika släktforskare tänker kring sitt eget data. Så kan vi på säkert sätt identifiera och skilja på relationskopplingarna kan troligtvis dessa också kunna återspeglas i RGD.

Denna egenkontroll på webben har (tyvärr) ingen direkt koppling till kontrollerna för Disbyt. Där får man rätta och justera med de listor man får efter att Disbyt filen bearbetats.
Men en hel del skall väl ändå vara ganska generella regler används.

Din senare kommentar verkar intressant, finns dom/den personen med i den filen jag fick av dig? Har en person unik identitet i GEDCOM filen tycker jag inte detta borde kunna hända, exempel tacksamt.

[C-J Gustafsson]

Hej Inger
Det känns som egenkontrollen har gjort sitt syfte, det känns bra.

Dina funderingar kring dopdatum så får jag upprepa mig lite.
Det är inte frågan om att bara ett dop godkändes, det är en indikation på att du har mer än ett dop på en person. Ibland har det blivit dubbelt av misstag, ibland vill man registrera det på det sättet.
Det är alltså inte "fel" att ha dubbla dop.

Begravningsplatser och kommuner har vi inte haft anledning att fundera på, det är kanske något vi bör göra.
Det vi tycker är viktigast är dödförsamlingen, begravning har vi nog mer sett som en information.
Kommunala kyrkogårdar finns ju på flera orter.

[tommypeters]

Jag vet varför det verkade vara rapport på samma person... :-)

P21633, Hazel B /Johnson/, f. 20 Jan 1897, Wilcox, Pennsylvania, USA med:
P27308, Hazel Berdina /Swanson/, f. 20 Jan 1897, Wilcox, Pennsylvania, USA

P21633 har namnen Hazel B Johnson och Hazel Berdina Swanson, men rutinen hittade dubbletten Hazel Berdina Swanson som också fanns i filen - så det var en dubblett som doldes av att första personen hade just bägge de namnen.

[Gestblom]

Dubbla födelsenotiser syns i Disbyt och ger flera rader för samma person i sökresultatet.

[Rolf Carlsson]

Kommentarer till Tommy och Inger:

Det positiva är just, som Kalle skriver, att ni får ett antal indikationer att följa upp, vilket förbättrar tillförlitligheten i er ursprungsforskning. Emellertid, se på Indatavalideringen som ett förstadium till den efterföljande Matchningsanalysen, då ni för närvarande kan jämföra med en annan Gedcomfil (även upprepade Gedcomfiler) eller i ett senare skede mot RGDs databas.

Här uppstår möjligheten att i alla detaljer analysera jämförelsen av din forskning med den matchande databasen. Vid denna jämförelse av hela familjebilder indikeras framför allt relationskonflikter, som inte upptäcks vid kontroll av en enskild individ. Har ni tillgång till en annan forskares material, så kan ni genomföra matchningen även om vissa indikationer i Indatavalideringen återstår att följa upp.

Med ett eget användarkonto sparas filerna och ni gå tillbaka till denna analys när som helst, även upprepa den, när ursprungsforskningen ändrats. Se även den bild över arbetsflödet, som finns under ämnet Släkttrim.

[tommypeters]

Jo, jag har ett eget konto men kör fortfarande på gästkontot då det är en hel del saker att ändra - mest uppkomna pga buggar i tidigare versioner av Family Tree Maker - så det blir en ny GEDCOM varje dag.

"Det positiva är..." var väl defensivt skrivet - *allt* är väl positivt med den här egenkontrollen, men det går ibland kanske att göra det ännu mer positivt :-)

Tanken med att hellre missa några få dubbletter än att ge en sådan lång räcka med förslag där de flesta är falska dubbletter är helt rätt. Jag har inte testat kontrollen i FTM 2014, men den i FTM 2012 var usel på att sålla bort sådant som man enkelt kunde slutleda sig till inte var dubbletter. Och att poängsätta samt ange dubbletterna i poängordning gör ju att man får de mest troliga först i listan och sedan håller man på tills man till exempel får tio i rad i listan som är falska dubbletter - då är man nere någonstans på 1 poäng och kan anta att man inte kommer att missa några uppenbara dubbletter längre ner på listan.

På samma sätt kan det vara med flera övriga tester. Som jag redan nämnt går det ju enkelt att dela upp datumkontrollresultaten i uppenbart felaktiga datum och oprecisa datum, lägger man dem då i två grupper så har man en grupp man vet att man måste åtgärda och en grupp som man om man vill kan se om det går att hitta mer exakta datum. Och denna "oprecisa del" presenteras naturligtvis efter de uppenbart felaktiga.

Sedan tycker jag att eftersom Disbyt inte precis är ett konkurrerande företag går det ju att låta oss som använder egenkontrollen att få lite extra upplysningar som rör Disbyt. Det är ju om inte annat på lång sikt möjligt att RGD ersätter Disbyt - och varför ska man inte försöka hjälpa till att höja kvaliteten på Disbyt-datat om det inte ger något merarbete mer än att lägga till en kommentar när resultatet presenteras om vad som behöver ändras för att inte "ställa till det" i Disbyt. Som Janåke skrivit ovan ger bl.a. dubbla födelsedatum dubbla rader i Disbyt, men jag vet t.ex. inte om dubbla namnförekomster ger något problem där. Kanske det ibland är inläsningsrutinen i Disbyt som borde hantera en del fall lite bättre, det kommer alltid att vara så att mångas släktträd både innehåller säkrade uppgifter med källhänvisningar och personer som är "under utredning" där man har ett par olika uppgifter att välja mellan när motstridiga uppgifter finns i olika arkiv.

[Gestblom]

Det pågår ett arbete med att renovera Disbyt.
Fokus just nu ligger på att tolka och konvertera nuvarande Disbyt-databas till ett nytt format.
Ett samarbete med RGD-gruppen har inletts och indatakontrollen kommer troligen att vara gemensam för båda projekten.

[Rolf Carlsson]

Visst höjer Indatakontrollerna i Släkttrim indirekt även tillförlitligheten i Disbyt. Nästa gång du rapporterar till Disbyt påverkas ju detta av alla de rättningar/kompletteringar du företagit under tiden.

Förhoppningen från min sida är att vi så snart som möjligt (utan att här ange något mål) kan lansera Matchning/Uppdatering av RGDs databas. Själva matchningsanalysen blir ju då mera komplett och sker bara en gång. I nuläget med flera kollegors datafiler måste ju matchningen ske mot var och en av dessa filer.

Men, det är främst en resursfråga (se även senaste numret av Diskulogen) hur snabbt vi kan komma vidare.