Kom gärna här med synpunkter och frågor avseende "Släkttrim
Projektgruppen för RGD
Utskriftsvy
Kom gärna här med synpunkter och frågor avseende "Släkttrim
Projektgruppen för RGD
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.
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
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
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.
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
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.Citat:
Om RGD bara ska innehålla personer som inte längre är i livet, så borde nu levande personer sorteras bort före granskningen.
Rolf
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.
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
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.
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."
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.
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.
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?
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.
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...?
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.Citat:
Ursprungligen postat av walgot
Har lagt till ett förbättringsförslag i vårt fel-hanteringssystem Redmine
Vi använder en mycket lätt modifierad variant av en GPL licensierad parser - simplepyged, som finns på githubCitat:
Ursprungligen postat av walgot
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.
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.
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.
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".
Den är skickad.
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).Citat:
Ursprungligen postat av C-J Gustafsson
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.
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.
Även dubbla efternamn verkar ge problem, den här raden gillas inte:
1 NAME Jon /Andersson/ Sten
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.
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.
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...
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...
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
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.
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"...
Filen skickad
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.Citat:
Ursprungligen postat av C-J Gustafsson
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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".
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.
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?
Det larmas om möjlig dubblett mellan två namn på samma person i GEDCOM-filen, det är ju lite underligt larm...
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.
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.
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.
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.
Dubbla födelsenotiser syns i Disbyt och ger flera rader för samma person i sökresultatet.
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.
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.
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.
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.
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.
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.
...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...
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.
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?
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).
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@
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ö.
kan vi flytta Disbyt till en egen tråd - tack
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".
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.
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.
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.
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...
Dubbelgångaren fungerar för övrigt mycket bra, det vore inte dumt om Runar kunde inkorporera funktionen i Släkttrim... ;-)
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.
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...
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.
Hej Tommy
Vilken identitet gäller det? Finns hon i de fil jag fått från dig?
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...91483&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/AMTCita...91483&pid=6396
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=docum...91483&pid=6396
2 FORM htm
2 TITL Biografi
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image...91483&pid=6396
2 FORM jpg
2 TITL Jeanette and Elizabeth Theophilos
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image...91483&pid=6396
2 FORM jpg
2 TITL FloridaNaturalizationRecords1847-1995ForElizabethTheophilos
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=docum...91483&pid=6396
2 FORM pdf
2 TITL Jeannette and Elisabeth (1)
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image...91483&pid=6396
2 FORM jpg
2 TITL Elizabeth Sodergren Front right
1 OBJE
2 FILE http://trees.ancestry.com/rd?f=image...91483&pid=6396
2 FORM jpg
2 TITL FloridaNaturalizationRecords1847-1995ForElizabethTheophilos
1 FAMC @F1803@
1 FAMS @F8284@
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.
Det är en Ancestry-fil, FTM är lite annorlunda...
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.
Fil skickad.
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.
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.
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é...
Hej Bror
Stort tack för dina förslag, vi går igenom dom när vi börjar jobba med ärendet.
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?
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.
Tackar!
/ Lars
Det borde ju inte vara helt omöjligt - ska kika på det.Citat:
Ursprungligen postat av BrJohan
Jag utgår från att du menar de filer man ser i listan 'Visa aktuella log-filer' för en viss databas?
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?
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.
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.
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...?
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
Tack för svaren, jag återkommer med mejl till C-J
Den funktionen finns nu.Citat:
Ursprungligen postat av 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.