Släkttrim - Frågor/synpunkter

[Rolf Carlsson]

Kom gärna här med synpunkter och frågor avseende "Släkttrim

Projektgruppen för RGD

[Gestblom]

Släkttrim är ett utmärkt komplement till Disbyt.
Jag laddade upp min GEDCOM-fil som gäst och fick ett antal förslag på felaktigheter och dublettpersoner.
Vad gäller socken- församlingsnamn tycker jag att ni kan jämställa (AB) och (A) så blir den listan kortare.

[C-J Gustafsson]

Hej Janåke
Vi har försökt göra tolkningen av församling så "tolerant" som möjligt och alldeles före helgerna kompletterade vi funktionerna ytterligare.
Det är tanken att släktforskaren skall fortsätta använda sitt eget sätt att registrera, och att anpassningen av det skall göras i programmen i samband med valideringen av data.

Ni som haft problem med stor församlingslista vid tidigare körning kan gärna göra ett nytt försök.

Jag skall kolla upp varför (A) inte tolereras. Hittar ni andra saker som ni tycker vi bör ändra så hör av er. Det är viktigt för oss att vi får in era synpunkter.

Om det är mer omfattande, är vi tacksamma att få en GEDCOM fil, så vi har ett bra underlag att arbeta med. Ni kan gärna skicka till mig på 08.55245912@telia.com

[m06015]

Om RGD bara ska innehålla personer som inte längre är i livet, så borde nu levande personer sorteras bort före granskningen. Med en stor databas blir anmärkningslistan onödigt lång. Varför listas par som har ett gemensamt barn före äktenskapet?
Hälsningar Runar

[C-J Gustafsson]

Hej Runar, tack för synpunkter.

Längre fram när vi pratar om RGD så kommer regler för sekretess att finnas. Eftersom ingen annan än du själv kan se dina uppgifter, så finns ingen anledning till begränsningar.
Egenkontrollen i web-funktion är avsedd att hitta eventuella felaktigheter i det egna släktforskningsdatat, och det är lika lätt att göra fel på levande personer.

Har man stora volymer kan det vara fördel att först skapa sin GEDCOM fil med lämpligt urval av sitt data.

Par med gemensamt barn före äktenskapet skall inte påverka. Den nya informationslistan som tillkom nyligen skall bara upplysa om familjerelationer som inte är kompletta.
Enligt en regel vi skapat, skall en familjerelation ha minst två individer. Dessa och individer som saknar relation listas, inte som ett fel utan som en information.

Familjer som inte är kompletta kan orsakas av avgränsningar när man skapar GEDCOM filen, t.ex. om man gör begränsning till utvalda flockar.
Ett tips kan då vara att skapa GEDCOM filen från en söklista med de flockar man önskar. Därefter gör man utöka söklista, först med föräldrar, sen barn och sist partners.
Då blir familjerna i GEDCOM filen kompletta och de poster som fortfarande kommer upp i informationslistan är då faktiskt saknade kopplingar.

[Rolf Carlsson]

Hej Jan-Åke och Gott Nytt År

Om jag förstår dig rätt har du genomfört Indatavalideringen i Släkttrim. So far so good!

En fråga: Har du kontakt med någon annan forskare med likartad forskningsinriktning? Om ni båda laddar in era filer på samma Användarkonto (erfordras) kan ni göra helt andra former av kontroller.

Rolf

[Rolf Carlsson]

Om RGD bara ska innehålla personer som inte längre är i livet, så borde nu levande personer sorteras bort före granskningen.

Runar, denna jämförelse kan bara göras med två Gedcomfiler. Senare vid jämförelse med RGDs databas blir det självfallet inga träffar.

Rolf

[C-J Gustafsson]

Janåke

Att länsbokstav A inte godkändes berodde på en bug i programmet, men det är rättat nu.
Nu kan du göra ett nytt försök att köra din GEDCOM fil.

[dis41263]

Hej
Har nu provat Släkttrim genom att indatavalidera min GEDCOM-fil.
1. jag får en felrapport på att Jeppa inte är ett mansnamn, vilket jag tycker att det är.
2. fick ett par felrapport på saknade relationskopplingar ex "Id 1-573 - Familj ". Jag har inte hittat något sätt att söka dessa "familjer" eftersom det inte finns något person-id kopplat till familje-id:et. Använder senaste Disgen. I mina fall är det giftemål som inte har raderats när personerna har raderats. Nu löste jag detta genom att granska GEDCOM-filen. Vore bar om man fick ett person-id, barn eller förälder, som är kopplat till familje-id:et
Bortsett från detta tycker jag att det fungerade utmärkt

Anders Dahlin

[C-J Gustafsson]

Hej Anders
Tycker du låter positiv även om du haft en del problem.

Namndatabasen är fortfarande i pilotnivå, så den är på intet sätt komplett. De vanliga namnen täcks nog upp men lite udda namn kommer att ge lite tveksamma svar ibland. Så se det inte om en "felrapport".

När det gäller ditt andra problem så är vi väl medvetna om det men inte kunnat göra något åt det. Vissa program, t.ex MinSläkt lagrar inte individdata, dessa skapas bara när GEDCOM filen skapas och endast för att GEDCOM standarden kräver detta för att kunna skapa en datastruktur.
För personer försöker vi alltid komplettera med hela namnfältet, så att det skall finnas något sökbart begrepp.
För familjer har vi inte den möjligheten.

Så din lösning att läsa GEDCOM filen och på så sätt kunna spåra någon information att gå vidare på är tyvärr den enda möjligheten.

Kan säga också att vi haft kontakt när det gäller MinSläkt, men vi har inte fått några löften om programändringar.

[Joel Vogler]

Anders, jag hade också problem med att söka på Id-nr som syftar på en familj. Rolf Carlsson gav mig följande lösning, som fungerar enkelt och bra, både för familj- och personsökning:
"Det finns ett sätt att söka giftermål i Disgen (lärde mig detta för två veckor sedan): Markera "Glada gubben"/gå till fliken "Med nummer"/mata in nummer och Disgen hanterar då såväl individer som giften."

[walgot]

Jag har gjort ett (första) prov av Släkttrim. Några iakttagelser:

1. PLAC.FORM-strukturen förefaller inte tas omhand.
2. DATE.PERIOD-strukturen förefaller inte tas omhand.
3. Det verkar som platsvärden i annan form än <svenska församlingsnamn> <svensk länsbokstav inom parentes> betraktas som 'suspekta'. Varför inte acceptera syntaktiskt korrekt GEDCOM? (Jag använder en 'egen' platsdatabas där hierarkin tillåts grena sig under socken.)

I en av de genererade filerna visades en Python-stack-'dump' som åtföljdes av info om i vilken GEDCOM-filrad undantaget togs omhand. I den raden finns definitivt inget syntaxfel. Varför inte låta undantagshanteringen skriva ut den rad som ger upphov till undantaget?

(Finns parsern åtkomlig för läsning via GitHub? GLR??)

Vad menas egentligen med 'indatavalidering'? Jag är van vid att 'indata' skall betraktas som sanna eller godkända. Däremot kan/skall behandlingen av dessa data valideras.

För övrigt så verkar Släkttrim kunna bli ett bra hjälpmedel och i synnerhet om man ges möjlighet att konfigurera egenskaperna.

[C-J Gustafsson]

Hej Wilhelm
Vi betraktar inte några uppgifter som suspekta och vi försöker vara så toleranta vi kan. Vårt testmaterial är ännu inte så omfattande men vi försöker lära oss hantera de varianter vi kommer på.

Vi skulle nog gärna vilja ha din GEDCOM fil för att kunna studera den närmare, tacksam om du skickar den till mig på mail 08.55245912@telia.com

När det gäller svenska församlingar är vår kontrolltabell skapad efter Skatteverkets övergripande församlingstabell och med länsbokstav inom parentes. Men innan vi kontrollerar mot tabellen försöker vi konvertera olika sätt att ange församling. Så det är inte det enda skrivsättet som accepteras men tydligen har vi inte täckt upp ditt sätt att ange församlingar.

Syftet i slutändan är att kunna identifiera unika personer och familjer och det sker i det vi kallar matchning. För att kvaliteten skall kunna innehållas måste vi jobba med ganska strikta data för att jämförelserna skall bli möjliga. Att försöka maskinellt jämföra händelsetidpunkter angivna med tidsintervaller fungerar inte, därför använder vi bara årtal eller datum.

Vi tror och hoppas att detta skall bli ett bra verktyg och vi är en bra bit på väg, men vi kan säkerligen bli ännu bättre och med mer synpunkter och exempel kommer vi också att bli det.

[tommypeters]

Om man för ett barn anger en person som dennes biologiske fader och sedan, när modern gift om sig, den nya mannen som styvfar så får man varning om att GEDCOM-filen är formellt fel då barnet finns i två familjer. Nu vet jag inte om Family Tree Maker tillåter inmatning som sedan inte kan skapa en korrekt GEDCOM eller om kontrollen larmar om något som ska fungera?

[tommypeters]

En annan sak som jag inte vet vem som "bär skulden" till - jag, FTM, GEDCOM-standarden eller Släkttrim... ;-)

I FTM kan jag lägga in alternativa personer. Man kanske inte kunna avgöra säkert (ännu) vem som är fader till en person, man lägger då in bägge de möjlig fäderna och sätter den mest troliga som "Preferred". Jag vet inte om GEDCOM-standarden kan hantera detta, om inte borde ju FTM bara ta med den som är "Preferred". Om standarden kan hantera detta borde inte Släkttrim klaga på det som att barnet hör till två olika familjer.

[tommypeters]

Samma sak som med styvfar gäller ju en person där jag har både biologiska och fosterföräldrar. Där känns det väl, som med styvfar, som om man vill kunna ha med den informationen i sitt släktforskningsporogram men den borde kanske inte komma med i GEDCOM-filen... I vilket fall som helst blir det ju också larm om dubbla familjer, men "var sitter felet"? Ska det vara tillåtet, eller kan det inte finnas med i en GEDCOM-fil och jag måste ta bort det då FTM inte klarar av att sortera bort fosterföräldrarna när GEDCOM-filen skapas...?

[dis49324]

I en av de genererade filerna visades en Python-stack-'dump' som åtföljdes av info om i vilken GEDCOM-filrad undantaget togs omhand. I den raden finns definitivt inget syntaxfel. Varför inte låta undantagshanteringen skriva ut den rad som ger upphov till undantaget?


Problemet ligger mest sannolikt på vår sida. I inläsningsprocessen läggs lite RGD-intern information till i Gedcom-filen innan den läses in i databasen och i samband med det kan syntaxfel uppstå.. Det är inte riktigt meningen att sådana fel ska synas utan dom borde tas hand om internt. Men än så länge är det det beta-system under kraftig utveckling och UI är ganska primitivt.

Har lagt till ett förbättringsförslag i vårt fel-hanteringssystem Redmine



(Finns parsern åtkomlig för läsning via GitHub? GLR??)

Vi använder en mycket lätt modifierad variant av en GPL licensierad parser - simplepyged, som finns på github
http://github.com/dijxtra/simplepyged

Hela vår kod kommer också att finnas på github - har bara inte kommit fram till att lägga upp den där.

[C-J Gustafsson]

Hej Tommy
Att ett barn bara kan vara barn i en familj är en grundregel och några alternativa pappor kan vi heller inte hantera.
Däremot kan vuxna personer finnas i många familjer.

Vi kan väl försöka identifiera hur vi på bästa sätt kan hantera din GEDCOM fil, skicka en kopia till mig på mail, 08.55245912@telia.com

Varningslistorna och informationslisan är ju inga "fellistor" i egentlig mening, de är till för att det kan finnas anledning att kolla om det är en medveten registrering eller en felregistrering.

[tommypeters]

Det jag undrar är ju lite om någon vet ifall alternativa personer och både biologiska och fosterföräldrar är något som är definierat i GEDCOM-standarden och som normalt hanteras av olika program. Jag kan inte se att det i GEDCOM-filen skiljs på alternativa personer eller olika typer av föräldrar (men det är svårt att följa i en stor GEDCOM-fil) och är det så finns det ju inget den här rutinen kan göra. Då är det ju bättre att jag låter fosterföräldrar finnas kvar i släktträdet, men tar bort kopplingen till dem och istället anger deras data i ett litet dokument - då finns det kvar i FTM men påverkar inte GEDCOM-filen.

Det finns ändå ett antal saker som är felaktiga i GEDCOM-filen, så jag jobbar vidare med den :-) Nästa steg är dubblett-kontroll med Dubbelgångaren (och även i den här rutinen ska det väl finnas) - det är förberedelser för nytt Disbyt-inskick.

[C-J Gustafsson]

Hej Tommy
Det är klart att du skall ha kvar fosterföräldrarna i ditt eget data.
I den version vi nu jobbar med klarar vi bara föräldrar i en roll, underförstått biologiska föräldrar. I kommande versioner finns planer för föräldrar i flera roller. Men det är inte helt lätt att fixa, för det uppstår en hel del problem om man skall kunna bygga antavlor och släkttavlor så det kommer inte med i de första versionerna.
I det flöde vi planerat för RGD finns manuell bearbetning, som bland annat skulle ta hand om detta tillsammans med släktforskaren.
Men ni i det automatiska flödet har vi inte hittat något sätt att "välja rätt".

Om du skapar GEDCOM filen baserad på antavlor eller släkttavlor försvinner dessa problem för då måste du eller ditt program välja ett av alternativen.

När jag bad om din GEDCOM fil var det inte för att kolla vilka eventuella fel du har, utan för att se strukturen på GEDCOM filen.
Vi har nämligen inte haft någon FTM fil med i våra tester och varje program brukar ha sina egenheter av GEDCOM "standarden".

[tommypeters]

Den är skickad.

[walgot]

Att ett barn bara kan vara barn i en familj är en grundregel och några alternativa pappor kan vi heller inte hantera.


GEDCOM tillåter användandet av en tag 'ADOP' för att möjliggöra skapandet av en barn-föräldrarelation som inte är biologisk! Via en TYPE-tag kan man rimligen ange om det handlar om adoption eller om ett fosterbarn. Tillhörande tidpunkter och annat relevant kan placeras i EVENT-struktur(er).

[tommypeters]

Ja, när det är en adoption så skapar Family Tree maker en ADOP-tagg, däremot verkar inte styv- och fosterföräldrar kunna skiljas ut.

[tommypeters]

En "inkompatibilitet" mellan FTM och denna testrutin är att FTM tydligen regelmässigt lägger "/" runt efternamn, vilket i kombination med annat i GEDCOM-filen som t.ex. ett släktnamn inom parentes gör att jag får mängder med larmrapporter.

[tommypeters]

Även dubbla efternamn verkar ge problem, den här raden gillas inte:

1 NAME Jon /Andersson/ Sten

[C-J Gustafsson]

Hej Wilhelm
Helt rätt, GEDCOM tillåter olika typer av relationer.
Men den databasstruktur vi använder kan för närvarande bara handskas med en relationstyp, därav begränsningen för oss.

Skall man kunna bygga anträd och släktträd kan man inte ha alternativa grenar samtidigt. Man måste välja stig, manuellt eller maskinellt, och det har vi inte funktioner för ännu.

Maskinellt skulle vi kunna "klippa av" barn från relationer av typen "ADOP" eller "STEP", men det är egentligen ett var som släktforskaren själv bör avgöra.
Så vårt tips är att skapa GEDCOM filen från anträd eller släktträd.
Egenkontrollen kan man fortfarande göra på sitt kompletta data.

[C-J Gustafsson]

Hej Tommy
Alla släktforskningsprogram lägger slash i början och slutet av det som registreras som efternamn, det är GEDCOM standard.
Då blir det fel om man själv också lagt slash i namnfältet, därför har vi lagt ut denna varning.
Det är dock en sak som skulle gå att "fixa" maskinellt, jag kan lägga in det som ett ändringsönskemål.

Däremot ditt exempel med Jon /Andersson/ Sten förstår jag inte. Om jag tolkar det normalt så är Jon registrerat som förnamn och Andersson som efternamn.
Frågan är hur du registrerat Sten.

Din kommentar om parenteser i namnfältet måste jag kolla upp. Det är inte meningen att de skall påverka varken för eller efternamn.

[tommypeters]

Jag ska kolla upp mer så jag inte missuppfattar vad det är som är gemensamt med de larmrapporterna. När det gäller Jon /Andersson/ Sten så såg jag i släktträdet att Sten råkat hamna som suffix och inte som att andra efternamn, så den korrigeringen kanske fixar det problemet. Som jag skrev så har jag många felaktigheter att rätta. En hel del har uppkommit med Sverigeättlingar i USA. Man kan ha hela familjer korrekt och sedan får man tips om att personer finns med i olika census - är man då inte riktigt noggrann kan dessa Residence-inlägg med källor ställa till det och lägga till ett nytt barn i familjen eller (vanligast) ge ett alternativt namn på ett barn i familjen. Och alternativa namn verkar FTM inte hantera bra när sedan en GEDCOM skapas, då har jag fått barn till dessa "alternativa personligheter" markerade som att finnas i två familjer. Där verkar testrutinen göra helt rätt medan FTM skapar två familjer i GEDCOM med deolika alternativa namnen i varsitt...

[tommypeters]

I FTM kan man ju välja att antingen ta med alla personer eller göra urval via ancestors, descendants, filter samt manuellt plocka med/ta bort personer. Detta hjälper dock inte om man inte kan filtrera bort själva fosterförälder-relationen när någons farbror är fosterförälder och han ändå ska tas med i GEDCOM-filen...

[Fredricn]

Hej.
Ett mycket bra verktyg, speciellt namnkollen för min del.
Hittade många som hade fått fel kön.
Blir bättre när namndatabasen är utökad, då jag har väldigt många Jeppa som är män i min forsknng.

Det som jag däremot inte riktigt gillade var ortkontrollen, i allafall inte i nuvarande utförande, såvida jag inte riktigt förstår den.
Jag är intresserad i vilket format som ni kontrollerar emot.
Själv lägger jag upp placeringen i följande ordning: Gård/ställe/by, Församling, (Län), Land

Ett exempel på vad Släkttrim uppfattade som ej identifierbart
* Ystads Sankta Maria, (M) - - alternativ:
- - Ystads Sankta Maria (M)

Hittar ej heller
Ullstorp 10, Ullstorp, (L)

I Disbyt avdelas församlingen och länet med , .

MVH
Fredricn

[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.

[tommypeters]

Jo, men som jag skrev skulle det vara värdefullt att veta vilka larm som Släkttrim ger som indikerar något som troligen skulle ge ett fel i Disbyt och vilka som inte märks där. Då kan man börja med dessa så att jag får in min Disbyt-uppdatering någon gång... ...och efter det kan man ta itu med de andra.

[Gestblom]

Att anpassa Släkttrim till egenheter i dagens Disbyt är inte meningsfullt för närvarande.
Bidragen till Disbyt går igenom både en maskinell och en manuell kontroll och som du vet får du bl.a. en fellista tillbaka.
Du kan alltid skicka in ditt bidrag på nytt efter korrigering.

[tommypeters]

...och det är ju precis det jag ett par gånger nu skrivit att man inte ska göra, släkttrim ska fungera som det gör - det enda jag har efterfrågat är information om vilka larm som släkttrim ger som påverkar hur slutresultatet blir i Disbyt. Är det för betungande kan man ju ge den informationen i den här tråden och hoppas på att alla som ska ladda upp till Disbyt läser den här tråden först...

[Gestblom]

Bidrag till Disbyt körs maskinellt och ger en lista med fel som Disbytombudet kan åtgärda manuellt.

De meddelanden från Släkttrim som absolut bör rättas före inskick till Disbyt är

- Individ med okänt kön
- SEX-taggen saknas
Effekten av dessa blir att personer försvinner från familjesidan, men kan dyka upp i antavlan.

- NAME taggen saknas eller är tom
Personen försvinner i Disbyt

- Ej korrekt kalenderdatum
Slinker igenom

Några meddelanden t.ex. mansnamn på kvinna visas för ombudet för manuell korrigering.
Andra slinker igenom disbytkontrollen, men resulterar som värst i att vissa personer inte blir sökbara.

[tommypeters]

Tack, de larm som jag mest fått beror på hur Ancestry hanterar när man godtar en "hint" de ger om en källa. Dubbla födelsenotiser, vigselnotiser, dödsnotiser och namnförekomster.

Till exempel kan en person ha en födelsenotis på "18 Jan 1867, Torhamn, Blekinge" och när jag sedan kollat i Arkiv Digital är det "18 Jan 1867, Hästholmen, Tohamn, Blekinge län" och den sista blir "Preferred". Vad händer om denna dubblett lämnas kvar, från tidigare svar antar jag att det då blir två (likadana) dödsuppgifter för personen, men bara en person? Hur blir det med dubbletter för vigsel, död och namn?

[Gestblom]

Det beror på hur den genererade Gedcom-filen ser ut.
Om två BIRT finns för samma person kommer båda med till Disbyt och kommer att visas som två separata händelser.
En av dem kommer att gälla som födelse i familj- resp. antavla.
Samma gäller antagligen för vigsel och död.
För namn kommer bara en att synas (gissar jag).

[tommypeters]

0 @P5162@ INDI
1 OCCU Torpare
2 PLAC Svanhalla 37, Torhamn, Blekinge län
1 BIRT
2 DATE 3 Sep 1810
2 PLAC Jämjö, Blekinge län
1 DEAT
1 NAME Johannes /Jonasson/
1 BIRT
2 DATE 3 Sep 1810
2 PLAC Jämjö, Blekinge län
1 SEX M
1 FAMS @F1919@
1 FAMS @F1920@

[Gestblom]

Tommy,
sökning på Johannes Jonasson i Disbyt kommer att ge två identiska rader pga. 2 st. BIRT.
DEAT ger inget eftersom ort och datum saknas.
Han hittas också med sökning på Jämjö.

[Rolf Carlsson]

kan vi flytta Disbyt till en egen tråd - tack

[tommypeters]

Ja, jag fortsätter att plocka bort dem...

Skulle ju inte vara så svårt att göra ett skript eller program där jag plockade bort sådant här från GEDCOM-filen, men det är förstås bättre (men tråkigare) att får bort det från släktforskningen "på riktigt".

[Gestblom]

Rolf,
Släkttrim är ett utmärkt hjälpmedel för att hitta fel innan man skickar in till Disbyt.
Frågan (#63) gällde vilka meddelanden från Släkttrim är som är kritiska för Disbyt och alltså relevant här.

[m06015]

Släkttrim saknar tydligen möjlighet att söka dubblerade personer med hjälp av vigseldatum. Två personer gifta med varandra utan andra kända datum än deras vigseldatum går att använda i Dubbelgångaren 2013 när man söker dubbletter.

[C-J Gustafsson]

Hej Runar
Den dubblettkontroll som ligger i egenkontrollen av GEDCOM filen jämför bara individdata.
Alla dubblettsökningsprogram, som Disgen, Släkttrim och Dubbelgångaren arbetar på lite olika sätt, därför är det bra att använda flera program när man söker dubbletter.
Dubbelgångaren är ett utmärkt komplement, som ni dessutom tillhandahåller utan kostnad.

Men nu lite reklam för Släkttrim. Den första dubblettkontrollen, som bara bearbetar GEDCOM filen, gör en grov bedömning av likheter och skillnader i individernas data.
En svårighet är att hitta en bra balans mellan antalet dubbletter och falsklarm. Blir falsklarmen för många blir det svårt att få användaren att seriöst arbeta sig igenom listan.
Här finns en variant med XL-lista, som vi inte vågat släppa ut ännu, då antalet falsklarm ökar dramatiskt, men å andra sidan hittar man en och annan okänd dubblett.

Nästa steg i Släkttrim är att använda alternativa dubblettkontrollen 2A. Den arbetar helt annorlunda då den använder matchningstekniken för att hitta dubbletter.
Här har vi dock inte lyckats hitta en bra balans på dubbletter och falsklarm. Det har blir ibland en alldeles för lång lista, som vi överlämnar till användaren att bestämma hur långt man orkar gå.

Nästa steg är i själva matchningen, där konflikter i matchningen ibland kan bero på dubbletter, som på så sätt upptäcks.
När det gäller matchningsfunktionerna så jämförs där hela familjer, så där kommer även vigseldatum med i avvägningen.

Varför lägga ner så har mycket energi på dubbletter?
Bakgrunden är kravet att RGD, som de här funktionerna är framtagna för, enbart skall innehålla unika individer.
Matchningstekniken för att identifiera unika individer i två olika databaser har skapats och testats med gott resultat.
Men dubbletter i de enskilda databaserna fångas bara i undantagsfall upp.
Därför är det viktigt för oss, att så långt som möjligt, eliminera dubbletter i det data som skall användas till RGD.

[tommypeters]

När dubblettkontrollen som nu sorteras i ordningen "troligast" till "minst troligt" så spelar det ju mindre roll om listan blir mycket lång. Mängden falsklarm bör öka kraftigt när man kommer ner till ett läge motsvarande "mindre troligt" och där skulle antagligen annars listan klippts av om ni ville begränsa antalet falsklarm. Det vore ju värre om listan presenterades i bokstavsordning eller datumordning, då kunde man helt klart riskera att missa en hel del dubbletter pga utmattning...

[tommypeters]

Dubbelgångaren fungerar för övrigt mycket bra, det vore inte dumt om Runar kunde inkorporera funktionen i Släkttrim... ;-)

[Rolf Carlsson]

Runar har varit involverad i RGDs projektarbete och vi utvärderar de funktioner, som täcks in av Dubbelgångaren.

Dubblettsökningen, som Kalle beskriver, sker i flera steg. Självfallet är det så, att om de dubbletter, som signalerats i indatavalideringen inte korrigerats, kommer dessa även upp i samband med matchning. Vi vill först göra grovgallring och senare "finliret" med matchningsoperationerna.

Det unika med RGD är att i samband med matchningen jämförs hela familjebilder. I detta sammanhang dyker ett antal varianter på relationsdubbletter/relationsfel upp, vilka inte kan upptäckas vid granskning av enskilda individer.

Exempel är:
- Dubbla föräldrapar när syskon registreras vid olika tidpunkter
- Fel partner
- Barn har hamnat i fel äktenskap - ofta på grund av snarlikhet

Observera att de upptäckta relationskonflikterna kan finnas såväl i indatafilen som i RGDs databas, då familjen tidigare saknat matchning eller samma fel har funnits i två indatafiler. När en indatafil med avvikande matchning avseende relationer jämförs med databasen sker en analys var avvikelsen ligger och i förekommande fall kommer databasen att korrigeras av "RGD-funktionär" och medlemmen bör korrigera i sin egen forskning.

Jag vill också betona att i det pilotprojekt vi bedrivit har ett avsevärt antal relationskonflikter uppkommit i samband med matchning. Denna företeelse är mycket vanligare än vad de erfarna släktforskare, som deltagit i pilotprojekt, kunde föreställa sig. Flera av dem blev "brutalt" överraskade.

Det är just av den anledningen jag så många gånger upprepat värdet av att kunna jämföra den egna forskningen redan nu i Beta-versionen. Rättade fel är rättade fel. Ett tips är att ta kontakt med den eller de personer, som har störst antal "lika-poster" i Disbyt-rapporten. Utbyt Gedcomfiler med varandra och genomför matchningsmomentet.

[tommypeters]

Hur är det med namn till namndatabasen, vill ni ha in namn som saknas? Jag har ju också rätt många "Jeppa-män" som det klagas på, liksom alla kvinnor som heter Bothil/Botill/Bothel/Botel, Una, Tove, Ingiar, Holmfrid (var kvinnonamn innan det blev mansnamn...), Gotthild och Kristen samt en del kvinnonamn som blivit ändrade efter emigrering som Fran och Jean...

[tommypeters]

Jag får en del falsklarm på kön, texten: "Mansnamnet saknas men finns som kvinnonamn, kolla" - men om jag kollar i GEDCOM-filen så är det markerat "1 SEX F" på henne.

[C-J Gustafsson]

Hej Tommy
Vilken identitet gäller det? Finns hon i de fil jag fått från dig?

[tommypeters]

Det är flera identiteter, vet inte om de fanns i filen från mig, här är en av dem:

0 @P6396@ INDI
1 BIRT
2 DATE 9 Mar 1897
2 PLAC Torhamn, Blekinge län
2 SOUR @S-1097635058@
3 PAGE The National Archives at Atlanta; Atlanta, Georgia, USA.; Petitions for Naturalization, compiled 1913 - 1991; National Archives Publication: 578688; Record Group Title: Records of District Courts of t
4 CONC he United States
3 _APID 1,1850::429135
2 SOUR @S-1775714630@
3 PAGE Year: 1930; Census Place: Miami, Dade, Florida; Roll: 311; Page: 29B; Enumeration District: 68; Image: 60.0; FHL microfilm: 2340046
3 _APID 1,6224::102646534
2 SOUR @S-1775431762@
3 PAGE Year: 1940; Census Place: Miami, Dade, Florida; Roll: T627_631; Page: 10B; Enumeration District: 69-89A
3 _APID 1,2442::134242316
2 SOUR @S-1729515124@
3 PAGE Number: 263-26-7357; Issue State: Florida; Issue Date: Before 1951
3 _APID 1,3693::61989390
1 DEAT Age at Death: 70
2 DATE Dec 1967
2 PLAC Miami, Dade, Florida, USA
2 SOUR @S-1727965705@
3 _APID 1,7338::1210646
2 SOUR @S-1729515124@
3 PAGE Number: 263-26-7357; Issue State: Florida; Issue Date: Before 1951
3 _APID 1,3693::61989390
1 NAME Madelin Gunhild Elizabeth /Södergren/
2 SOUR @S-1097635058@
3 PAGE The National Archives at Atlanta; Atlanta, Georgia, USA.; Petitions for Naturalization, compiled 1913 - 1991; National Archives Publication: 578688; Record Group Title: Records of District Courts of t
4 CONC he United States
3 _APID 1,1850::429135
2 SOUR @S-1729515124@
3 PAGE Number: 263-26-7357; Issue State: Florida; Issue Date: Before 1951
3 _APID 1,3693::61989390
2 SOUR @S-1703992271@
3 _APID 1,2469::674366259
1 RESI
2 DATE 1938
2 PLAC Miami, Florida, USA
2 SOUR @S-1703992271@
3 _APID 1,2469::674366259
1 EVEN
2 TYPE Civil
2 PLAC Florida, USA
2 SOUR @S-1729515124@
3 PAGE Number: 263-26-7357; Issue State: Florida; Issue Date: Before 1951
3 _APID 1,3693::61989390
1 RESI
2 DATE 1935
2 PLAC Miami, Dade, Florida, USA
2 SOUR @S-1775431762@
3 PAGE Year: 1940; Census Place: Miami, Dade, Florida; Roll: T627_631; Page: 10B; Enumeration District: 69-89A
3 _APID 1,2442::134242316
1 RESI Age: 43Marital Status: Widowed; Relation to Head of House: Head
2 DATE 1 Apr 1940
2 PLAC Miami, Dade, Florida, USA
2 SOUR @S-1775431762@
3 PAGE Year: 1940; Census Place: Miami, Dade, Florida; Roll: T627_631; Page: 10B; Enumeration District: 69-89A
3 _APID 1,2442::134242316
1 RESI Age: 33Marital Status: Married; Relation to Head of House: Wife
2 DATE 1930
2 PLAC Miami, Dade, Florida, USA
2 SOUR @S-1775714630@
3 PAGE Year: 1930; Census Place: Miami, Dade, Florida; Roll: 311; Page: 29B; Enumeration District: 68; Image: 60.0; FHL microfilm: 2340046
3 _APID 1,6224::102646534
1 EVEN Age: 16
2 TYPE Arrival
2 DATE 1913
2 SOUR @S-1775714630@
3 PAGE Year: 1930; Census Place: Miami, Dade, Florida; Roll: 311; Page: 29B; Enumeration District: 68; Image: 60.0; FHL microfilm: 2340046
3 _APID 1,6224::102646534
1 EVEN
2 TYPE Civil
2 DATE 7 May 1936
2 PLAC Miami, Florida, USA
2 SOUR @S-1097635058@
3 PAGE The National Archives at Atlanta; Atlanta, Georgia, USA.; Naturalization Certificate Stubs, compiled 1921 - 1991; National Archives Publication: 2887109; Record Group Title: Records of District Court
4 CONC s of the United States; Record Group Number: 21
3 _APID 1,1850::2439828
1 MARR
2 DATE 28 Dec 1925
2 PLAC Miami, Florida, USA
2 SOUR @S-1097635058@
3 PAGE The National Archives at Atlanta; Atlanta, Georgia, USA.; Petitions for Naturalization, compiled 1913 - 1991; National Archives Publication: 578688; Record Group Title: Records of District Courts of t
4 CONC he United States
3 _APID 1,1850::429135
1 EVEN Age: 38
2 TYPE Civil
2 DATE 5 Feb 1936
2 PLAC Miami, Florida, USA
2 SOUR @S-1097635058@
3 PAGE The National Archives at Atlanta; Atlanta, Georgia, USA.; Petitions for Naturalization, compiled 1913 - 1991; National Archives Publication: 578688; Record Group Title: Records of District Courts of t
4 CONC he United States
3 _APID 1,1850::429135
2 OBJE
3 FILE http://trees.ancestry.com/rd?f=image&guid=446c504c-e55f-4502-98ea-8065f7a6e21c&tid=45191483&pid=6396
3 FORM jpg
3 TITL FloridaNaturalizationRecords1847-1995ForElizabethTheophilos
1 SEX F
1 SOUR @S-1731048031@
2 PAGE Ancestry Family Tree
2 DATA
3 TEXT http://trees.ancestry.com/pt/AMTCitationRedir.aspx?tid=45191483&pid=6396
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=document&guid=944977da-3a0c-4502-ad06-51f54fa2def7&tid=45191483&pid=6396
2 FORM htm
2 TITL Biografi
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image&guid=44a1897a-6873-4b71-81cc-69e73c7c18f2&tid=45191483&pid=6396
2 FORM jpg
2 TITL Jeanette and Elizabeth Theophilos
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image&guid=446c504c-e55f-4502-98ea-8065f7a6e21c&tid=45191483&pid=6396
2 FORM jpg
2 TITL FloridaNaturalizationRecords1847-1995ForElizabethTheophilos
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=document&guid=10e97f07-ef28-468c-ad1d-86a7273c666a&tid=45191483&pid=6396
2 FORM pdf
2 TITL Jeannette and Elisabeth (1)
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image&guid=27f27a51-36a8-4e45-b165-f9c15abf4152&tid=45191483&pid=6396
2 FORM jpg
2 TITL Elizabeth Sodergren Front right
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image&guid=446c504c-e55f-4502-98ea-8065f7a6e21c&tid=45191483&pid=6396
2 FORM jpg
2 TITL FloridaNaturalizationRecords1847-1995ForElizabethTheophilos
1 FAMC @F1803@
1 FAMS @F8284@

[C-J Gustafsson]

Hon fanns med i den filen jag hade med då hade hon ett helt annat utseende.
Jag kan inte köra några tester med bara ett urklipp av en enskild post, jag måste ha en ny fil från dig för att kunna få fram vad problemet är.
FTM filerna har varit ett problem, men jag trodde att vi lyckats fixa till det.

[tommypeters]

Det är en Ancestry-fil, FTM är lite annorlunda...

[Rolf Carlsson]

Vi är medvetna om att många namn fortfarande saknas i Namndatabasen. Vi tar fram listor över namn, som saknas i Databasen och gör till och från uppdateringar/grupperingar. Det är och förblir manuella bedömningar för varje enskilt namn; för förnamnen söker vi ursprungsnamn för gruppering (Kerstin hör till Christina) och för efternamn likartade/likljudande kombinationer Källberg - Tjellbärgh).

Av samma skäl kan ett specifikt förnamn vara grupperat med kön M, men kan även förekomma som kvinnonamn. Tekniskt sett är detta även ett saknat namn.

Tills vidare tar vi fram namnlistor över saknade namn i Gedcom-filer i den takt vi hinner att bearbeta. Eftersom samma saknade namn kan finnas i flera Indatafiler är det ingen större mening med att ha ett större lager av listor att bearbeta.

När vi har uppnått en högre täckningsgrad av grupperade namn, blir det även relevant att visa alla saknade namn i Indatavalideringen. I det läget upptäcks även rena felstavningar; Kartina, Andesr och liknande.

[tommypeters]

Fil skickad.

[BrJohan]

Jag såge gärna att utdatafilerna från en exekvering av RGD Web-service kunde hämtas i en .zip- eller .tar-fil innehållande textfiler.

Bra vore också om utdatafilernas innehåll ges en reguljär och beskriven form - för att underlätta/möjliggöra maskinell efterbearbetning.

[C-J Gustafsson]

Han som kan svara på frågorna är på resande fot och kan inte svara just nu. Men jag lägger in det som två ärenden i vårt system.

När det gäller utdatafilernas utformning går det att skapa alternativ. Vi har väl inte bedömt att det skulle vara vanligt att de bearbetas maskinellt.
De får ju inte bli svårlästa för manuell behandling heller. Där vi internt haft liknande behov har vi helt enkelt skapat två olika varianter, då kan man också anpassa dom maximalt.

Vi är tacksamma för förslag och bra exempel.

[tommypeters]

Sedan finns det ju personer som man alltid kommer att få "personnamnslarm" på... :-) - som Carl Eugen Desiré Ählström, som inte tyckte det var nog utan döpte sonen till Ernst Desiré...

[C-J Gustafsson]

Hej Bror
Stort tack för dina förslag, vi går igenom dom när vi börjar jobba med ärendet.

[Mogenealogen]

Jag har människor födda i Göteborg och Stockholm registrerade i mitt program, alltså ingen närmare uppgift om församling där.
På Disbyt har detta accepterats men i Släkttrim får jag påpekande. Kommer detta att bli problem sedan vid den kommande uppladdningen till RGD?

[Rolf Carlsson]

Hej Lars

Vi är medvetna om att det för Stockholm och Göteborg frekvent förekommer att enbart stadsnamnet anges. Det står exempelvis född i Göteborg, flyttar till Stockholm eller liknande. Även landskapsnamnen används på samma sätt. Att du får en varning är ju bara till för att följa upp och ev. korrigera.
Vad gäller din egen forskning anger du de mest preciserade uppgifterna du har tillgängliga. Detta kommer även att fungera i RGD. Om familjerelationer saknas kan svårigheter uppstå att finna individen hos en annan forskare. Finns en familjebild och ett annat inrapporterat bidrag/databasen bättre preciserar orten för just den familjen kommer familjen att identifieras genom andra familjemedlemmar.

Om du använder Disgen och i ortsträdet under utskrifter för Stockholm <Kommun> anger tillägget (AB) resp. för Göteborg (O) bör det fungera utan anmärkning.

[Mogenealogen]

Tackar!

/ Lars

[dis49324]

Jag såge gärna att utdatafilerna från en exekvering av RGD Web-service kunde hämtas i en .zip- eller .tar-fil innehållande textfiler.


Det borde ju inte vara helt omöjligt - ska kika på det.
Jag utgår från att du menar de filer man ser i listan 'Visa aktuella log-filer' för en viss databas?

[Mogenealogen]

Från Släkttrim får jag tillbaka en lista som heter Informationslista med saknade relationskopplingar. Den innehåller ett antal individnummer som jag inte får träff på vid sökning i databasen. Vad betyder denna lista?

[tommypeters]

Den ska innehålla väldigt ensamstående personer... :-) - och de numren ska hittas i din GEDCOM-fil och där ser du sedan namnet på personen och kan hitta denne i databasen.

[Mogenealogen]

Tack för svar - men dessa ensamstående personer redovisas sedan längst ned i listan med rubriken "Individ som saknar familjekoppling" och det är ett fåtal bara, listan i övrigt är ganska lång med enbart individnummer som ej hittas. Mystiskt tycker jag.

[tommypeters]

Aha, då vet jag inte riktigt - verkar som du har en mängd individer som skapats av någon bugg och varken har kopplingar eller namn...?

[C-J Gustafsson]

Hej Lars
Det är tänkt att fungera så att om individ saknar familjekoppling så anges identitet och namn. Är det familj med enbart en individ, d.v.s. det går inte att bygga familjekopplingar, så anges bara identitetsnummer och att det är en familj.
Med Disgen kan man söka direkt, både på individ och på familj, men det är inte alla släktforskningsprogram som har lagrade identiteter.

Har du väldigt många familjer med bara en individ kan det vara så att du har gjort avgränsningar som inte får med hela familjebilden.

Men eftersom vi gjort en hel del programändringar nyligen vore det bra att få kolla att det inte är någon typ av bugg i programmen.
Har du lust får du gärna skicka den aktuella GEDCOM filen per mail till mig på 08.55245912@telia.com

[Mogenealogen]

Tack för svaren, jag återkommer med mejl till C-J

[dis49324]

Jag såge gärna att utdatafilerna från en exekvering av RGD Web-service kunde hämtas i en .zip- eller .tar-fil innehållande textfiler.

Den funktionen finns nu.

[BrJohan]

Tacknämligt!

Innan jag - för att pröva den 'nya' funktionen - laddade upp en GEDCOM-fil som 'guest', observerade jag att:

Det skrivs: "OBS filer för "guest" sparas inte mellan sessioner.", men också - och möjligen kontradiktoriskt - "Däremot kan de GEDCOM-filer som bearbetas i version 0.5 komma att användas för interna tester (som t.ex. sammanslagning med andra filer) i RGD-systemet".

I avvaktan på info om vad som gäller för "guest"-GEDCOM-filer, avstår jag från GEDCOM-uppladdning.

[dis49324]

Det skrivs: "OBS filer för "guest" sparas inte mellan sessioner.", men också - och möjligen kontradiktoriskt - "Däremot kan de GEDCOM-filer som bearbetas i version 0.5 komma att användas för interna tester (som t.ex. sammanslagning med andra filer) i RGD-systemet".


Filer som man laddar upp som GUEST sparas inte mellan sessioner.
Under utvecklingstiden (fram till system 1.0) kan filer, som råkar ligga på systemet när tester körs, komma att användas för interna tester av programvaran. Filer som skapas av eller används under dessa tester sparas inte och lämnar inte systemet.

Det skulle nog inte stått "RGD-systemet" - ska ändra det så att det framgår mera tydligt att detta bara gäller under utvecklingen fram till system 1.0.



I avvaktan på info om vad som gäller för "guest"-GEDCOM-filer, avstår jag från GEDCOM-uppladdning.

Eftersom det som utvecklas nu, i samarbete med Internetfonden .SE, är ett open source projekt kan du ju alltid ladda hem programet och köra den lokalt på din egen dator. Då har du också full kontroll över dina GEDCOM-filer och kan dessutom ändra programet så att det passar dina behov.

Hoppas bara att du bidrar med dina program-ändringar så att vi får ett bättre system som fler kan ha nytta av.

[BrJohan]

Bra, då råder tillräcklig klarhet!

I vilket GitHub-'repository' finns programvaran?

[dis49324]

I vilket GitHub-'repository' finns programvaran?

Jag håller på med det och räknar med att ha det klart i denna månaden.

Vill du (och andra) ha koden snabbare kan jag lägga upp ett temporärt tar-arkiv på servern.
Säg till i så fall.

[Rolf Carlsson]

Bror, eftersom du är DIS-medlem kan du ju registrera dig som användare (kontakta Anders) och därigenom erhåller du automatiskt möjlighet att spara ditt material mellan arbetstillfällena. Du behöver då inte vänta på någon lansering av produkten.

Rolf

[tommypeters]

Det han vill är ju tvärt om - garanti att *inget* sparas, ente ens för någon anonym test...

[dis49324]

I vilket GitHub-'repository' finns programvaran?

https://github.com/andersardo/gedMerge

[akno]

Släkttrim.
Jag har nu testat Släkttrim på en större släktfil till både stor nytta och en del funderingar. Jag fann några dubbletter som jag inte hittat med Disgen och namnfel "Avvikande Kön". Ortnamn som inte kunde identifieras, men där var nog 98% orter i Norge. Jag önskar att det funnes en ortdabas för Norge liknande den för Sverige som man kunde importera till Disgen. Datum ej godkända hade ja några stycken,
det var sådana med intervall och dito ungefärliga. där borde det kanske göras något. Åtminstone Disgen tillåter det, och jag antar även andra släktprogram har den möjligheten. I övrigt är det en funktion jag kommer att utnyttja på mina övriga flockar längre fram för en kommande Disbytsändning.

[C-J Gustafsson]

Hej Åke
Trevligt att du tycker testen varit till viss nytta, det är det vi hoppas på.

Web-sidan är ju enbart en egenkontroll och inget "rätt eller fel", det är helt upp till dig om du tycker att du bör ändra några uppgifter eller inte. Det har heller inget med om Disgen tillåter eller inte.

När det gäller församlingsdatabas har vi ännu inte en komplett tidsorienterad församlingsdatabas för Sverige, så någon motsvarande för Norge kommer inte att finnas här. Däremot kan Disgens ortdatabas utökas med orter i Norge eller med vilket land som helst.

Syftet i RGD är att händelserna född, vigd och död skall referera till en Svensk församling eller ett land. Så alla orter i Norge blir bara identifierade med Norge.

Sen en kommentar som också gäller dina synpunkter på datum. Listorna med kommentarer är inga "fellistor" utan bara kommentarer. Finns ingen exakt församling så är det ändå helt OK och finns det inget exakt datum är det också OK att ange intervall eller ungefär.

Funktionerna i web-sidan kommer från ett pilotprojekt för RGD (Rikstäckande Genealogisk Databas) så denna web-sida kunde då skapas, som en biprodukt av pilotprojektet.
Syftet och ideologin bakom RGD är:
Alla släktforskares data skall läsas in till RGD helt i original, utan att göra några ändringar i uppgifterna.
När RGD fått in "samma individ" från flera släktforskare skall RGD välja de kvalitetsmässigt bästa händerna som finns tillgängliga.

Den gemensamma individen, som vi brukar kalla RGD-individ, kan alltså vara ett hopplock från olika släktforskare.
Det är den RGD-individen som sen kommer att presenteras i RGD.
Varje släktforskares uppgifter finns i bakgrunden för att kunna spåra ursprunget till en uppgift i RGD.

Funktionerna i RGD är ännu inte framtagna för beslut, så hur det slutligen kommer att fungera vet vi ännu inte.

[dis28026]

Jag har just startat med min första Släkttrim som verkar mycket intressant!
Men, en första detalj som jag tror kan förbättras är förnamnslistan. Jag får väldigt många ifrågasatta namn som är korrekta, tex Töre, Una, Ali och Ahli alla kvinnonamn. Kan jag bidra med en lista från mitt material eller är ni redan i färd med åtgärd?

[Rolf Carlsson]

Hej Göran

Intressant att du testar. Vad gäller namndatabasen är den långt ifrån fullständig och den kommer att byggas ut ytterligare, när vi startar med arbetet med att bygga upp RGD.

Det du kan kolla är om det exempelvis finns felstavningar som Kartina, Lasr och liknande, som bör rättas till i din egen forskning. Alla korrekta namn kommer att uppdateras.

[C-J Gustafsson]

Namnkontrollen i Släkttrim är avsedd att försöka hitta personer med fel kön. Finns det något kvinnligt namn på personen, så blir det ingen "felsignal". Om det finns bara ett förnamn eller om samtliga namn finns i databasen med avvikande kön, så skrivs raden ut. Listade poster skall inte ses som fel, utan bara som en indikation på vad som kan kontrolleras lite extra.

Just de exempel som anges finns i databasen som mansnamn, därför hamnar de i listan. Databasen är avsedd att hantera tvåkönade namn, men är som Rolf påpekat långt ifrån fullständig.
Vi har därför inte heller med funktionen att söka felstavade namn ännu, den kommer först i nästa generation av namndatabas.

Skulle vi inväntat 100%-iga kontrolltabeller skulle förmodligen web-sidan inte kunnat läggas ut inom rimlig tidsrymd. Varken namnkontrollen och församlingskontrollen har produktionsstatus, utan vi använder de tabeller, som togs fram i RGD pilotprojekt. Beslut finns att skapa produktionsversioner av dessa två tabeller, men det arbetet har ännu inte aktivt startas.

[C-J Gustafsson]

Alternativ dubblettkontroll, 2A
Det har inte kommit några kommentarer eller frågor på den alternativa dubblettkontrollen. Betyder det att den inte används?

För ett tänkt RGD, är dubbletter i indata den allvarligaste felkällan till att få in dubbletter i RGD databasen. Därför har vi olika kompletterande program för att kunna hitta dessa.
Inget dubblettsökningsprogram är 100-procentigt, dubblettsökningsprogram skapas med någon viss utgångspunkt och ger därför olika resultat.

Det är därför fördelaktigt att använda flera program, det ett program missar kanske ett annat hittar. Så är ni Disgen eller MinSläkt användare, kan det finnas själ för att komplettera era dubblettkontroller via Släkttrim. Gärna också andra dubblettsökningsprogram som t.ex. Dubbelgångaren.

Den ordinarie dubblettkontrollen i Släkttrim, där listan med kandidater har begränsats för att falsklarmen inte skall bli för många, bör därför kompletteras med den alternativa dubblettkontrollen 2A.

Den listan är inte begränsad, så det är inte meningen att man skall gå igenom hela den. Sorteringen (finns två olika) skall lägga de troligaste kandidaterna överst.

Fördelen med den tekniken för att söka dubbletter är att den tar med jämförda personer med få händelseuppgifter. Dessa kommer normalt inte upp till den "minimipoäng" som andra program kräver.

Förutom de personer som sorteras först i listan kommer det med många Erik Eriksson, Per Persson och liknande som saknar händelseuppgifter.
Dessa är näst intill omöjliga att angöra om de är dubbletter eller inte.

Mitt tips är att skumma av den långa kandidatlistan efter lite ovanliga förnamn och/eller efternamn, då kan man ibland hitta dubbletter där någon av kandidaterna helt saknar händelser.

Vi skulle vilja ha era synpunkter på dubblettkontrollerna i Släkttrim och kanske tips på vad som skulle kunna förbättras.

[tommypeters]

Har inte blivit att använda den ännu, kommer.

Kanske namnet ska ändras till "Kompletterande dubblettkontroll" eller "Dubblettkontroll, steg 2"? Nu låter det mest som något man ska ta till om man är missnöjd med vanliga dubblettkontrollen...

[C-J Gustafsson]

Det är inte någon kompletterade kontroll eller något steg 2.

Det är helt enkelt bara två alternativa metoder att söka dubbletter. De kan precis som andra dubblettsökningsprogram ge lite olika resultat, det ett program missar kan ett annat program hitta.
Men bättre namnförslag mottages tacksamt.

[Rolf Carlsson]

Den ultimata dubblettkontrollen utförs i Matchningsförfarandet då en familjebild i indata jämförs med en potentiellt matchande familjebild i Databasen eller en annan Gedcomfil.

[tommypeters]

Nu har jag hunnit testa/Använda "Alternativ dubblettkontroll, 2A" en del och det är både avancerat, snyggt och användbart :-)

Hittade några "bra" dubbletter som var lätta att fixa till. Som exempel en person som var ingift man till mammas fyrmänning (fanns där med fru och barn) var samma person som en son till farfars syssling (fanns där med föräldrar och syskon) - bara att göra "merge" på en person.

[dis28026]

Även jag är i full färd med att testa min stora databas. Trots att jag skickat material till DISBYT många gånger, alltid med kontroll och korrigeringar både före och efter, hittar jag många dubbletter. MinSläkt har en allt för grov listning av "misstänkta" dubbletter och en genomgång är därför både tidsödande och ger relativt få verkliga träffar. Trots det hittar Släkttrim ett betydande antal verkliga träffar. Jag vill framhålla, trots det sagda, att jag är mycket nöjd med MinSläkt.
Returfilerna som jag fått via Släkttrim har jag kopierat över i Word-arbetsfil som jag succesivt betar av. Rangordningen med de högsta poängen först är bra. Hittills har jag betat av ned till 7 (+) med näst in till 100 % relevans. Genomgången leder till många nya kopplingar mellan olika släktlinjer och därmed följande behov av komplettering. Efter fullständig genomgång av första omgångens svarsfiler avser jag att testa en ny GEDCOM. Förmodligen har kvaliteten förbättrats avsevärt men behöver säkert SLÄKTTRIMas igen.
Tack för ett mycket bra initiativ och jag ser fram emot det slutliga resultatet med en nationell databas.

[C-J Gustafsson]

Släkttrim kommer att vara stängt i morgon, tisdag den 12/5 men vi hoppas att allt skall fungera igen till onsdagen.

Släkttrim flyttas under tisdagen till en server hos Dis och kommer att nås via länk på - https://rgd.dis.se/ -

Så från och med onsdag 13/5 använder ni - https://rgd.dis.se/ -

Fortsätt att bearbeta era GEDCOM filer och fortsätt att höra av er med synpunkter.

[C-J Gustafsson]

Hej Göran

Tack för ditt beröm, det är alltid trevligt att få.

Vi är tacksamma för alla synpunkter och förslag. Vi tål även kritik (i alla fall befogad och i små doser), det är viktigt med andras tankar och synvinklar för att funktionerna skall utvecklas och förbättras.

[C-J Gustafsson]

Nu är Släkttrim igång igen via den nya länken https://rgd.dis.se/

Från denna sidan klickar ni er vidare till inloggningssidan för Släkttrim. Där är allt som tidigare, eller nästan i alla fall.

Har ni bråttom kanske ni missar denna raden:
Nu borde allt gå att använda som vanligt - kom ihåg att inga databaser har flyttats med från den tidigare test-servern - ni får ladda upp de GEDCOM-filer som ni vill använda på nytt.

Det gäller er som har personligt konto, där databaserna lagras tills ni själva tar bort dem. De tidigare databaser ni hade är inte flyttade, utan måste nu skapas återigen via GEDCOM filen.

För användare som använder inloggning som guest innebär det ingen skillnad, för där lagras inga data efter utloggningen.

[tommypeters]

Error: 500 Internal Server Error

Sorry, the requested URL 'http://rgd.dis.se:8085/listDubl?workDB=' caused an error:

Internal Server Error
Exception:

KeyError('workDB',)
Traceback:

Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/bottle-0.12.8-py2.7.egg/bottle.py", line 862, in _handle
return route.call(**args)
File "/usr/local/lib/python2.7/dist-packages/bottle-0.12.8-py2.7.egg/bottle.py", line 1732, in wrapper
rv = callback(*a, **ka)
File "/usr/local/lib/python2.7/dist-packages/bottle_cork-0.11.1-py2.7.egg/cork/cork.py", line 545, in wrapper
return func(*a, **ka)
File "UI.py", line 368, in listdubl
bottle.request.query.workDB = bottle.request.session['workDB']
File "/usr/local/lib/python2.7/dist-packages/Beaker-1.7.0dev-py2.7.egg/beaker/session.py", line 672, in __getitem__
return self._session()[key]
KeyError: 'workDB'

[tommypeters]

Har inte skapats någon databas...

[C-J Gustafsson]

Hej Tommy

Vi skall ta reda på vad som är problemet och informera.

[C-J Gustafsson]

Hej Tommy
Det verkar som om du försökt kört den Alternativa dubblettkontrollen 2A utan att först skapat en databas genom inläsning av en GEDCOM fil.
Eller så har du bara inte pekat ut din databas när du startade 2A.

[tommypeters]

Jo, det verkar ju så. Men när så nu inte är fallet så behövs kanske lite felsökning, eventuellt upplysning att om man väntar till nästa dag så löser det sig...

Jag gjorde om GEDCOM-inläsningen ett par gånger men det skapades ingen databas att välja i 2A,

INFO importGedcom::180 - Using database tommy_Petersson importing from file ./files/tommy/Petersson/Petersson.Olsson.Cobel.Ancestry_2015-05-12.ged_UTF8
INFO importGedcom::196 - Reading and parsing gedcom
INFO importGedcom::205 - Time 28.4157209396
INFO importGedcom::250 - Persons
INFO importGedcom::276 - Time 80.0669500828
INFO importGedcom::295 - Cleaning by applying patterns and rules
INFO importGedcom::300 - Merge families where husb and wife are same persons
INFO importGedcom::336 - Time 95.6541559696
INFO importGedcom::354 - Indexing tommy_Petersson in Lucene
INFO importGedcom::358 - Time 152.908850908

Den finns där nu, kanske det tar några timmar innan den "visar sig"?

[C-J Gustafsson]

Hej Tommy
Man skall inte behöva vänta till nästa dag, men du hade kanske inte tillräckligt tålamod att låta bearbetningen gå färdigt.

Du har stor databas så det tar lite tid att läsa in filen, göra testerna och skapa en databas.
Vi har inte klockat servern vi ligger på nu men min känsla är att den inte är lika snabb som den tidigare servern.
Du körde under natten så det kan tänkas att servern jobbade med backup tagning eller liknande serviceåtgärder.

Körningen av en GEDCOM fil i din storlek kan nog variera mellan 30 minuter och 1 timme beroende på belastningen på servern.

[mrandress]

Hej,
Hur får jag inloggning till Släkttrim?

[C-J Gustafsson]

Hej Anders

Du kan skicka mail till Anders Ardö, anders.ardo@gmail.com
Han behöver Namn, Dis-id och en aktuell mailadress.

Anders är dock inte tillgänglig nu under helgen men kan fixa det i början på nästa vecka.

[mrandress]

Utmärkt. Tack!

[anders.malm@brevet.se]

Hej när jag forskar och hittar ett vigseldatum har jag för vana att lägga in detta som ett gifte i Disgen även om det vid tillfället inte är klart vem maken/makan är utan detta får utredas senare. När jag kör släkttrim kommer alla dessa ofullständiga giften upp i filen med INFORMATIONSLISTA MED SAKNADE RELATIONSKOPPLINGAR under rubriken "Familj med endast en individ". Är det möjligt att samla dessa under en mer informativ rubrik eller lägga till en förklaring. MVH Anders

[C-J Gustafsson]

Hej Anders
Ja, det skulle säkert kunna gå att använda en annan rubrik. Men det är inte anledningen till den okompletta familjen vi analyserar, bara att familjen inte är komplett.

Syftet med denna kontroll går tillbaka till grundreglerna som sattes upp i pilotprojektet för RGD, "En relation måste bestå av minst två individer".
Skall man bygga en databas med släktrelationer, måste det finnas två individer i en relation för att det skall gå att länka samman en släktkedja. Antingen make och maka eller barn med en förälder.

Så i det fall du relaterar till kan maken/makan bli ensam om barn eller föräldrar saknas.
Normal finns maken/makan med om han/hon har barn eller föräldrar. Vi tappar normalt inte några personer utan bara begreppet relation.
I det exempel du gav registreras inte vigseldatum förrän du tillför en make/maka.
Saknar personen helt andra kopplingar, dvs. en orelaterad person, då kommer den personen inte med.

Mycket text när du bara efterfrågar en bättre rubrik, men jag ville bara försöka ge en bild av varför "Familj med endast en individ" finns med.

[C-J Gustafsson]

Ny test har tillkommit i Check-listan där intervallen mellan född/döpt och död/begravd jämförs.
Vid onaturligt stora intervaller skapas en rad i Check-listan.

I de tester vi gjort har det visat att slarvfel vid datuminskrivningen ibland uppstår och att detta inte uppmärksammas på något annat sätt.

[jespon]

Hej!

Jag har nu testat Släkttrim ett antal gånger och är mycket nöjd då jag nu har "trimmat" min forskning. Har hittat ett flertal dubbletter, fel kön och fel tidsintervaller (blandade ofta ihop från - till och mellan - och).

Ett par saker är jag dock inte kompis med. Det är först och främst felanmärkningarna på ortnamn. Många anor har jag inte hittat den rätta församlingen p.g.a. att böcker saknats eller att jag inte lagt ned så mycket jobb på en ana i utkanten av forskningen. Jag har då t.ex. valt att markera rätt län eller rätt kommun t.ex. "Gotlands län". Ibland har jag även skrivit in en egen "församling" såsom t.ex. "Karlskrona (K)" när jag inte vetat exakt den rätta av följande alternativ Karlskrona Amiralitetsförsamling (K), Karlskrona fångförsamling (K), Karlskrona Fredrika Dorotea Vilhelmina (K), Karlskrona mosaiska (K), Karlskrona stadsförsamling (K), Karlskrona Storkyrkoförsamling (K), Karlskrona tyska (K). Jag har i min forskning en mängd av liknande "fel". Hur ska jag göra? Ska jag ändra och gissa en annan församling vilket kan bli fel eller kommer Släkttrim att överse dessa felskrivningar?

Nästa sak som irriterar mig lite. Är när man t.ex. skrivit in vigselnotisen för ett barn eller vid gränsen intill en annan, ej medtagen flock och där endast en partner är inskriven. Då blir det en felanmärkning "Familj med endast en individ". För att slippa mycket av detta har jag vid tomma personer skrivit "Oforskad Person". Vad är meningen med denna information, vad ska det varna för? För mig är det ett medvetet val att inte forska på alla ingifta personer i släkten, trots att jag kanske hittat vigseldatum för något barn.

Jag förstår att Släkttrim är i en betaversion nu och kommer att förbättras en del. Jag tycker dock att det redan nu är mycket användbart och hoppas på mycket säkrare funktioner i framtiden, säkert mycket beroende på att vi användare berättar vad vi tycker.

Mvh Johnny

[tommypeters]

Släkttrim "godkänner" ingenting utan bara pekar på möjliga fel och du bestämmer själv vad/om du ska ändra.

[jespon]

Tommy, det var absolut inte något klagomål på Släkttrim utan jag förstår att jag själv bestämmer hur jag vill ha min forskning. Men har du läst mina frågor/synpunkter, vad har du för synpunkter på dessa och hur tycker DU att man bör göra i dessa fall.

[tommypeters]

Du skriver som du gjort bara det du vet, att gissa fel är sämre än att inte gissa alls.

[jespon]

Finns det kanske någon annan användare av Släkttrim som har åsikter och idéer hur man kan göra i de fall jag beskriver här ovan.

[C-J Gustafsson]

Hej Johnny

Det är fler som haft samma reaktion som du. Ser man listorna som "felanmärkningar" så är det lätt att man irriterar sig på vissa påpekanden.

Du skriver "eller kommer Släkttrim att överse dessa felskrivningar?". Släkttrim gör inget med uppgifterna, kontrollerna är bara till för den som kör kontrollen.
Det är helt upp till dig själv om du använder "felsignalen" för att komplettera ditt data. Kvalitetsmålet sätter du själv, det gäller församlingar och även övriga uppgifter som signaleras.

Gissar du på en "godkänd församling" eller skapa en "Oforskad Person", bara för att bli av med en rad i "fellistan", så gör du dig själv en otjänst.

När det gäller bakgrunden till "Familj med endast en individ" så har jag försökt beskriva bakgrunden i svar #131 här ovanför.

Det är bra när användare kommer med synpunkter, det är vi tacksamma för så fortsätt med det.
Vi har försökt få bort begreppet "fellistor" och använt lite mildare ord i vissa av rubrikerna.
Men betänk att detta enbart är rent maskinella kontroller, som inte kan skilja på medvetna eller omedvetna val.

[jespon]

Tack Carl-Johan för ditt svar!

Det jag försöker göra är att i Disgen skriva in mina forskningsresultat så standardiserat som möjligt så att detta kan passa även för att kanske vara med i det framtida RGD. Det är väl då så, som jag har förstått, att alla bör använda ett likvärdigt system och detta ska nu Släkttrim hjälpa till med. Mitt problem är nog kanske att jag inte riktigt har förstått hur jag bäst ska skriva in min forskning så att det på bästa sätt kan passa i någon gemensam databas, typ RGD. Kanske det vore bra om någon kunde skriva en tipsmanual hur man bäst ska standardisera sin egen forskning, säkert fler en jag som är osäkra.

Att jag använt betäckningen och skapat "Oforskad Person" är inte så dramatiskt, dessa kan med lätthet raderas om det behövs och jag vill.

Att däremot "gissa" till en godkänd församling är ett större fel som jag därför inte ännu har gjort, mer än att långt tidigare, själv lägga in t.ex. Karlskrona (K) istället för att gissa på någon av alla de andra Karlskrona-alternativen. Möjligen kanske därför Släkttrim "påpekar" (ej felanmäla) detta vilket säkert kan vara bra med tanke på standardiseringen. Ett alternativ för mig hade då kunna var att klicka på nivån ovanför som då heter Karlskrona Kommun, eller möjligen nivån ovanför denna som är Blekinge Län (K). Nu verkar det som att Släkttrim inte godkänner heller detta och gör ett "påpekande" när jag har valt "Gotlands län". Hur har ni tänkt där?

Jag vill göra så rätt och standardiserat som möjligt och tycker att Släkttrim är mycket bra för detta. Men jag vet inte hur jag ska göra överallt och hur ni har tänkt, det är därför jag skickar in detta inlägg på forumet, inte alls något klagomål som ni behöver försvara. Toppenbra med dubblettkontrollen, rätt kön och datumkontrollen som jag har hittat flera fel med hjälp av Släkttrim.

[C-J Gustafsson]

Hej Johnny
Visst vore det bra och tacksamt med en "standard". Vi som jobbat med piloten i RGD har dock tyckt att den skall bestämmas på en "högre nivå".

Vi har valt en typ av standard som förslag till RGD. Samtidigt har vi sagt att det inte skall låsa upp släktforskaren utan det är RGD som skall anpassa data så att det passar det som blir RGD standard.
Därför har vi inte framfört några "krav" i den riktningen.

Då målsättningen i RGD är att inte registrera samma individ mer än en gång har det utvecklats funktioner för matchning av individer.
Det förutsätter att uppgifter är jämförbara och det är t.ex. inte församling / ort / län. Vi grupperar också namn för att olika stavningsformer inte skall försvåra jämförelser.

Den form vi föreslagit för angivelse av församling är att namnet skall följas av länsbokstav inom parentes.
Men om vi skulle begära att alla skulle ändra sina registreringar till det skrivsättet, så skulle nog huvudparten av Sveriges släktforskare protestera.
Det är naturligt att var och en tycker att "sin" metod är den rätta.

När det gäller ortangivelser som inte är församlingar, så hoppas vi ju inom RGD att någon annan släktforskare har samma person med församling angiven.

[jespon]

Ja ok Carl-Johan och tack för ditt svar!
Jag kan nog då fortsätta som tidigare utan några större förändringar med både mina orter och oforskade personer. Släkttrim har dock hjälpt mig att hitta dubletter och ändrat mina datumformat till det bättre.

Mvh Johnny

[tommypeters]

När det gäller datumkontrollen skulle jag absolut vilja ha rapporteringen uppdelad i två delar: "Felaktiga datum" och "Inexakta datum". '24fFeb 1912' är ett felaktigt datum, '14/14/1855' likaså. Men 'Abt 1535' är ett inexakt datum och kanske är det bästa som någonsin går att få fram. Inexakta datum ska bara ändras om man funnit mer exakta uppgifter, felaktiga datum ska alltid ändras.

[C-J Gustafsson]

Det är en bra synpunkt, det borde nog varit så. Lite knepigare att identifiera inexakta datum, så programmeraren tog väl den enklaste vägen.

Ungefärliga datum enligt GEDCOM standard borde gå att fånga upp, men ibland är tidpunkterna angivna som vanliga texter och då är det svårt att tolka det rätt.

[C-J Gustafsson]

Släkttrim är nu kompletterad med ytterligare en dubblettkontroll, 2 Dubblettkontroll XL (X-tra Large kandidatlista).

Denna är samma typ av dubblettkontroll, som den ordinarie kontrollen men lite annorlunda och har lite mindre begränsningar. Den kan ge dubbletter som ordinarie kontroll inte hittat, men ger givetvis då också fler falsklarm. Den skall därför ses som ett komplement, varför det är viktigt att spara falsklarmen från den ursprungliga genomgången efter som det är stor risk att de dyker upp igen.

Den tidigare alternativa dubblettkontrollen 2A finns också kvar men lite modifierad. Den bygger matchningsteknik för att hitta dubblettkandidater, varför urvalet av kandidater blir ett helt annat.
Modifieringen består i att resultatet från XL-kontrollen sorteras in tillsammans med resultatet från matchningskontrollen. Det ger tre olika sorteringar, dels matchningsresultatet, dels XL resultatet och sedan dessa två sammanvägda. Att växla mellan de olika värderingarna underlättar att få ögonen på kandidatpar som känns relevanta att kontrollera vidare.

Det är viktigt att man ser dessa funktioner som ett paket. Det skall stegvis och ur olika synvinklar hjälpa till att hitta dubbletter som enskilda dubblettsökningsprogram ibland missar.

Den största utmaningen för ett kommande RGD är kravet att databasen inte skall innehålla dubbletter, samma person skall bara finnas en gång. Att minimera dubbletter blir därmed en kvalitetsstämpel. Därför har mycket av kontrollfunktionerna i Släkttrim koncentrerats just till att söka dubbletter.

Bästa möjligheten att bedöma och avgöra om två personer är dubbletter eller inte, är givetvis släktforskaren själv (med lite hjälp från Släkttrim).

[dis49324]

Den tidigare alternativa dubblettkontrollen 2A finns också kvar men lite modifierad.

Om du har använt den alternativa dubblettkontrollen 2A på en databas tidigare så måste du ladda in den databasen på nytt och köra alternativ dubblettkontrol omigen.

[C-J Gustafsson]

Hej Tommy
Nu är datumkollen uppdelad så att inexakta datum fått en egen punkt i Check-listan. Vi hoppas det blir mer informativt och lättare att koncentrera på viktigare.
Tack för förslaget.

[tommypeters]

...och en bra funktion blir bara bättre... :-)

[BrJohan]

En fråga:

Betraktas "Exakt 1756" som mer exakt än "Mellan 17560820 och 17560822"?

[C-J Gustafsson]

Hej Bror
Ja, på grund av det regelverk programmet går efter blir det så.
Det skall helst vara exakta datum, men eftersom det i mycket stor utsträckning saknas, så är även ett exakt angivet årtal "godkänt".

Ur kvalitetssynpunkt är din intervallangivelse bättre, helt klart.

Om/när RGD blir aktuell så småningom, får vi även en mänsklig bedömning och då bör tidpunktsangivelser bli hanterade mer individuellt.

[C-J Gustafsson]

Ändringen av inexakta datum har tyvärr påverkat dubblettkontrollen negativt.
Om vi inte kan få till kombinationen av dessa funktioner korrekt blir vi kanske tvungna att backa ändringen.

Dubblettsökningen ger nu felaktigt stor kandidatlista.

[C-J Gustafsson]

Nu finns en ändrad programversion på plats, som ger uppdelade Check-listor utan att dubblettkontrollen skall påverkas.

[C-J Gustafsson]

Nu vill vi testa en ny funktion med en liten annorlunda teknik.

Valalternativ har tillkommit där händelser, som saknar angiven källa listas.

Listan skapas som en csv-fil och är avsedd att hämtas hem till den lokala datorn och bearbetas vidare i ett matrisprogram, t.ex, Excel.
Klicka på listan och spara ner filen (normalt i mappen Hämtade filer). Därefter kan ett matrisprogram öppna filen och ladda matrisen.

[tommypeters]

Jag skulle *verkligen* vilja ha en specifik förbättring/utökning... :-)

T.ex. får man ett sådant här meddelande:
"Dubbla födelsenotiser för individ - P2797 - Ola /Andersson/"

Det är ju inte i GEDCOM-filen jag ska göra rättningen, utan i släktforskningsprogrammet eller på en webbsida som Ancestry. Där hittar jag inte "P2797". Däremot tiotals Ola Andersson.
Så jag måste söka fram P2797 i GEDCOM-filen och där få fram sådant som kan hjälpa mig hitta rätt Ola Andersson, som födelse-/dödsår. Det är sådant som är känt när fellistan skapas, så det skulle lika gärna kunna stå:
"Dubbla födelsenotiser för individ - P2797 - Ola /Andersson/ (1787-1850)"

Tiden för att korrigera uppgifterna skulle minska avsevärt.

[tommypeters]

En mer generell fråga, men den dök ändå upp vid körningen:
"Individen saknar angiven könstillhörighet - Id => P18773 - /Persson/"

Vad ska man göra i ett sånt läge när kyrkboken inte anger kön?
"24 oktober (1754) föddes Per Anderssons barn i Torslunda dödfödd."

Enklast är ju att plocka bort de två dödfödda jag har där kön inte anges, men det är ju inte korrekt - vilket det inte heller är att singla slant om vilket kön man ska ge barnet...

[C-J Gustafsson]

Ditt första önskemål är inte orimligt, men det är väldigt många ställen där koden behöver ändras i så fall.
Men identifieringen av personer är knepig i MinSkläkt, det vet vi och det kanske gäller även andra program där identitet inte lagras utan bara skapas för att GEDCOM så kräver.

Det andra påpekandet är precis som de flesta påpekanden, kolla om det är något du missat.
Vet du inte könet så skall du bara lämna det som det är.

[tommypeters]

Man kan ju ta de viktigaste platserna - bara för att man inte kan lägga till infon överallt behöver man ju inte låta bli att göra det på de platser de gör stor nytta.
Tar man "Dubbla födelsenotiser", "Dubbla dödsnotiser" och "Dubbla namnförekomster" täcker det en stor del av behovet.

[C-J Gustafsson]

Det är nog ganska personligt vad som känns viktigast, troligen beroende på vad man just då rättar.

Dubbla födelsenotiser och dubbla dödsnotiser är två mycket ovanliga meddelanden.
Dubbla namn förekommer från vissa släktforskningsprogram där men använder olika typer av namn, som när GEDCOM filen skapas blir dubbla förekomster.

Det går inte för oss att prioritera vissa feltyper, så det får nog ligga som ett ärende tills vi gör någon större genomarbetning av systemet.

[tommypeters]

Ja får aldrig dubblettkontroll XL att fungera, den avslutar på mindre än en sekund och resultatfilen finns sedan inte. Har testat att starta upp den alternativa dubblettkontrollen och den håller på. Och håller på... :-)

Vad kan vara orsaken till att XL-kontrollen inte alls fungerar för mig?

[dis49324]

Ja får aldrig dubblettkontroll XL att fungera, den avslutar på mindre än en sekund och resultatfilen finns sedan inte. Har testat att starta upp den alternativa dubblettkontrollen och den håller på. Och håller på... :-)

Vad kan vara orsaken till att XL-kontrollen inte alls fungerar för mig?

En bug som gör att systemet städar bort temporära filer lite väl effektivt - en av dom används av XL-kontrollen - är fixat nu - men tyvärr måste du ladda in din Gedcom-fil på nytt för att filen ska skapas :-( och du ska kunna köra dubblettkontroll XL.

Och den alternativa dubblettkontrollen kan köra länge om du har en stor fil - hur länge har du väntat och hur stor är din fil?

[tommypeters]

Den alternativa kontrollen tar nog inte *för* lång tid - det var mer en positiv observation att den inte direkt bröt/krashade :-)
Det var dags att stänga av datorn och gå och lägga sig, så jag lät den inte fullfölja. Har drygt 40000 personer i GEDCOM-filen.

[tommypeters]

Ganska exakt en halvtimme tog den alternativa kontrollen när jag körde den ikväll.

[akno]

Jag har testat med några GEDCOM-filer och känner behov av lite klarlägganden beträffande fellistorna jag får ut.

Fel: Ej def tidsangivelse.
Det får jag på datum där jag använt lampan för att få "omkring årtal", i och för sig ett riktigt påpekande. Använder jag inte lampan men skriver i kommentarrutan för levnadsnotisen "omkring" får jag ingen felnotis i RGD-test, och i utskrifter ser allt ändå korrekt ut. Samma händer om ett tidsintervall har angetts.

Fel: Ej korrekt kalenderdatum.
Det felet har jag fått på nästan alla i en mottagen GEDCOM-fil jag hade i en särskild flock. Går jag in och kollar levnadsnotisen ser allt rätt ut i mina ögon, men även där är lampan inblandad. Går jag in och plockar bort den blir det ingen felnotis på den posten.

Nu kommer jag inte att ändra på något förrän jag vet vad som är rätt. Det kan inte vara lätt att få till en bra RGD med alla varianter av födelse- dödsnotiser som finns.

[C-J Gustafsson]

Listorna i openRGD skall inte tolkas som "Fellistor".
De innehåller diverse kommentarer av olika typer. Det finns vissa saker som betraktas som fel men också sånt som bara är information.

Datum behandlas lite olika så jag skulle behöva lite bra exempel för att riktigt kunna svara.

Ej definitiv tidsangivelse är en typiskt sådan information. Man vet ju inte någon definitiv tidpunkt för då hade man ju skrivit in det.
Tanken med den listan är mest att man ögnar igenom den för att se om det kanske är något men skulle kunna kolla upp på nytt, kanske främst på de lite modernare tidpunkterna.

Ej korrekt kalenderdatum som du upplever som korrekta bör inte komma med i listningen. Om dom kommer från en särskild flock kan det vara så att datum är skrivet som texter.
Ett datum i GEDCOM format skall bestå av en/två siffror från 1-31, månad i engelsk trebokstavsform, t.ex. JAN följt av årtal med 4 siffror.
Sen ytterligare då dessa ungefärliga datum och datumintervaller som också skall hålla ett visst GEDCOM format.

När det gäller ej definitiva datum har vi numera tagit bort dessa ur Check-listan därför att den ibland tenderade till att bli väldigt stor.
Därför återfinns dessa nu i en egen lista som heter Note.txt.

[akno]

................
Ej definitiv tidsangivelse är en typiskt sådan information. Man vet ju inte någon definitiv tidpunkt för då hade man ju skrivit in det.
Tanken med den listan är mest att man ögnar igenom den för att se om det kanske är något men skulle kunna kolla upp på nytt, kanske främst på de lite modernare tidpunkterna.

Ej korrekt kalenderdatum som du upplever som korrekta bör inte komma med i listningen. Om dom kommer från en särskild flock kan det vara så att datum är skrivet som texter.
Ett datum i GEDCOM format skall bestå av en/två siffror från 1-31, månad i engelsk trebokstavsform, t.ex. JAN följt av årtal med 4 siffror.
Sen ytterligare då dessa ungefärliga datum och datumintervaller som också skall hålla ett visst GEDCOM format.

När det gäller ej definitiva datum har vi numera tagit bort dessa ur Check-listan därför att den ibland tenderade till att bli väldigt stor.
Därför återfinns dessa nu i en egen lista som heter Note.txt.[/QUOTE]
.............

Jag har gjort en koll för att försöka utröna orsaken. Vid koll av tända lampan ser jag att "Fras" är markerat och det antar jag tolkas som text. Ändrar jag till "Exakt" slocknar lampan och det blir korrekt i GEDCOM-filen. Tyvärr har jag inte den ursprungliga GEDCOM-filen kvar för att kunna se hur den såg ut.
Det blir väl ändå att ta ett bett i det sura äpplet och ändra. Det är trots allt inte så många. Nedan klipp ur GEDCOM med ändrad och icke ändrad.

0 @I6195@ INDI
1 SEX M
1 NAME Anders /Andersson/
1 BIRT
2 DATE 14 DEC 1783
2 PLAC Hög S:a, Huggenäs (S)
1 CHR
2 DATE 24 DEC 1783
2 PLAC Huggenäs (S)
1 DEAT
2 DATE 24 DEC 1783
2 PLAC Hög S:a, Huggenäs (S)
2 CAUS "Förqvaft"
1 BURI
2 DATE 28 DEC 1783
2 PLAC Huggenäs (S)
1 FAMC @F05@
1 CHAN
2 DATE 29 FEB 2016
3 TIME 14:57:00

0 @I6198@ INDI
1 SEX F
1 NAME Lisbet /Olofsdotter/
1 BIRT
2 DATE (1745-12-05)
2 PLAC Högstorpet, Huggenäs
1 EVEN
2 TYPE Dop
2 DATE (1745-12-05)
2 PLAC Huggenäs
2 NOTE Notering i födelseboken: död och begraven
1 FAMC @F06@
1 CHAN
2 DATE 9 APR 2009

[C-J Gustafsson]

Det skulle inte vara så svårt att tolka (1745-12-05) maskinellt om alla datum i textformat hade sett ut på det sättet.
Men i praktiken visar det säg att det finns många sätt som man tycker ett datum bör se ut.

Släktforskningsprogram som får datum som inte direkt kan tolkas har ofta en nödlösning, som att kalla det "Fras" för då kan det se ut hur som helst.
openRGD vill visa att datum inte kunde tolkas genom att lägga ut det i listan.

Men det är bra om man använder det format det egna släktforskningsprogrammet använder. Då blir oftast exporten till andra medier, t.ex. GEDCOM korrekt.

[dis08468]

Hej! Vid körning nyligen fick jag följande felmeddelande från RDG:
*** F E L L I S T A (II) Strukturfel
Formellt fel i GEDCOM filen: Barn I72206, som finns i familj F15007, finns även i familjen F14990
* * * GEDCOM filen skall inte användas innan formella felaktigheter är korrigerade.
Barnet i fråga har fosterföräldrar OCH biologiska föräldrar i Disgen 2016. Jag antar att det är det som RDG protesterar mot.
Hur ska det hanteras i RDG? Det lär ju dyka upp mera liknande i och med nya funktionerna i 2016.
/Anders

[C-J Gustafsson]

Detta är ett "nytt" fenomen som kom till i samband med Disgen 2016, att man kan ha mer än en uppsättning föräldrar.
När openRGD/Släkttrim byggdes uppfattades detta som ett fel.

Rent strukturellt kan en relation ha olika status, t.ex. biologisk, adoptiv eller foster. Detta skall då framgå i GEDCOM filen via taggen TYPE som kompletterar relationen.
Ett barn är ju alltid biologiskt, men även barn kan i vissa fall få avvikande status beroende på att men ser på familjen från föräldrarnas sida.

Jag har tyckt att Disgen gör fel när båda relationerna presenteras i GEDCOM filen och önskat att bara den föräldrarelation som vid tillfället är överst skall gå till GEDCOM filen. Egentligen på samma sätt som vid presentation i familjeöversikten.
Men det är tydligen delade meningar därom.

Den skarpt formulerade felsignalen i openRGD kom till egentligen därför att vi hittat GEDCOM filer skapade med gamla Disgen som hade dubblerade barn utan att nån kunde förklara hur det uppstått.

Oavsett bör man förvissa sig om att mottagaren av GEDCOM filen kan tolka status och behandla filen på rätt sätt. Om GEDCOM filen bara är avsedd för kontroll i openRGD kan man ignorera meddelandet om man är medveten om varför.

Flera andra släktforskningsprogram tillåter att relationer med olika status förekommer.

Den tänkta funktionen för RGD skulle baseras enbart på biologiska relationer, så där skulle då enbart det biologiska alternativet tas med.
Så i RGD skulle det bli mer problem om adoptiv/foster relationer registreras som biologiska. Detta skulle då troligen inte uppmärksammas förrän samma relation kom in från en annan släktforskare.

[dis08468]

Tack för snabbt o bra svar! Vi håller på att "tvätta av" några Disgen-databaser för att så småningom slå samman dom till en gemensam. Om jag förstår det rätt, så bör vi undvika att få med foster- och adoptiv-relationer i GEDCOM-filer till RDG, åtminstone ännu så länge. Även om det inte är så många sådana här fall, så bör dom ju undvikas inför en sammanslagning mha RDG.
Exporten har ju ingen sådan möjlighet, utan i så fall får man väl redigera bort dom i GEDCOM-filen innan den körs i RDG??

[C-J Gustafsson]

Hur detta kommer att hanteras i RGD vet ingen ännu.
Oavsett blir det RGD som skall hantera det, släktforskaren som lämnar GEDCOM filen skall inte behöva fundera över sådant.
Det samma gäller också t.ex. levande personer, alla begränsningsfunktioner måste hanteras i RGD.

[C-J Gustafsson]

En sak till, om ni inte för egen del har någon nytta av att slå samman GEDCOM filer till en gemensam databas, blir det ur RGD synpunkt bättre om varje enskilt bidrag kommer in var för sig.

[Gestblom]

Adoption hanteras inte heller i Disbyt.
Ett adopterat barn kan ha två uppsättningar föräldrar. Detta kräver att relationerna markeras så att RGD resp. Disbyt kan agera på grundval av den markeringen.

[C-J Gustafsson]

Disbyt innehåller troligen en hel del adoptiv- och fosterrelationer på grund av att Disgen 8 tolkade alla registrerade personer som biologiska.
Efter konverteringen uppfattar då även Disgen 2016 dessa personer som biologiska.

Ni som känner igen att ni tidigare i Dg8 registrerat adoptiv/foster relationer skulle behöva registrera om detta i Disgen 2016, nu när den möjligheten finns.

Då ökar ni kvaliteten på er egen forskning och genom att skicka ett nytt bidrag till Disbyt blir även den databasen "rättad".

En förbättring i Disgen skulle vara att även ge barn, som enbart är kopplad till icke-biologisk relation, också skulle få status satt på individposten.
Om program som läser GEDCOM filen exkluderar icke-biologiska relationer går annars dessa barn vidare och blir orelaterade personer, vilket heller inte är bra kvalitet.

[dis08468]

Jag noterade en ytterligare sak när det gäller foster- eller adoptivbarn. Hör kanske mera hemma under HTML-export, men jag upptäckte det vid tester med det här.

HTML-exporten (Disgen 2016) skapar antavla till fosterföräldrarna i stället för de biologiska! Vet just nu inte om det är slumpmässigt pga Id-nummer.
Jag sökte fram ett barn som har fosterföräldrar, gjorde Utöka söklistan med "Föräldrar". Fick då barn + två föräldrapar, alltså 5 personer. Gjorde HTML-export på dessa md mall 7. Barnet visas då under båda föräldraparen och noteras mycket riktigt som "Fosterbarn" under fosterföräldrarna, MEN antavlan för barnet visar fosterföräldrarna och deras anor - INTE de biologiska föräldrarna. Ska det vara så?

[dis08468]

I min kommentar ovan, hänger det uppenbarligen på vilket av föräldraskapet som lades in först. Om fosterföräldrarna lagts in först, så blir det dom som kommer som antavla i HTML-exporten och om biologiska lagts in först, så blir det dom.
Skulle vara bra med litet mera kontroll på detta.

[ollfa]

När vi införde möjligheten att registrera flera föräldrarelationer till ett barn i Disgen så valde vi att låta användaren välja vilken relation som skulle visas i alla utskrifter och exporter av barnets anor.
Den relation som visas i antavlan är alltid den relation som visas överst in listan över föräldarelationer. Genom att byta ordning där så kan alltså användaren välja om den biologiska eller någon annan föräldrarelation är den som skall visas i antavlor. Det är ju inte säkert att man alltid vill visa samma relation.

[Christer]

När vi införde möjligheten att registrera flera föräldrarelationer till ett barn i Disgen så valde vi att låta användaren välja vilken relation som skulle visas i alla utskrifter och exporter av barnets anor.
Den relation som visas i antavlan är alltid den relation som visas överst in listan över föräldarelationer. Genom att byta ordning där så kan alltså användaren välja om den biologiska eller någon annan föräldrarelation är den som skall visas i antavlor. Det är ju inte säkert att man alltid vill visa samma relation.

Det styr du genom att välja vilket föräldrapars om är överst i personöversiktens föräldrapanel.

[akno]

Jag har från en annan släktforskare fått en Gedcom som jag vill jämföra mot en egen men får inte till det. Hur gör man, kan jag få lite handledning.
Åke

[C-J Gustafsson]

Den enda dokumentation som finns ligger som ett klickbart pdf dokument på sidan.
Ett tips kan också vara att lära artikeln i Diskulogen 117.

Någon direkt dokumentation finns inte, mycket på grund av att hanteringen helt beror på det data som jämförs.

Jag föreslår att du tar kontakt med mig på telefon 08 55245912 så skall jag försöka svara på dina frågor och ge lite handledning.
Är du bara intresserad av resultatet kan jag göra matchningen åt er och meddela er resultatet.

Men var inte rädd för att testa och prova.

Tillägg: Artikeln från Diskulogen finns också tillgänglig på Dis hemsida under rubriken openRGD.

[akno]

Jag skall läsa och testa först så får jag se om jag klarar det.

[Lillen]

Om jag förstår saken rätt så ska man i princip kunna jämföra 2st backup om man lägger dem i olika databaser och gör Ged-comfil på respektive.

Bra om man råkat radera utan att tänka sig för två gånger.:rolleyes:

[C-J Gustafsson]

Ja, i alla fall i teorin. Är databaserna "stora" kommer resultatet av matchningen att bli omfattande och kanske därmed blir svårtolkad, eftersom nästan alla personer kommer att vara gemensamma. Matchningen i openRGD är gjord med avsikten att jämföra två olika släktträd för att hitta gemensamma personer och familjer.

Hamnar man i det läget att man av misstag raderat personer, kan det vara enklare att jämföra GEDCOM filerna direkt med varandra. GEDCOM filer är enkla text-filer som kan jämföras med relativt enkla program.

[Lillen]

Ok Tack :-D