Släkttrim - Frågor/synpunkter

Citat:

---

Ursprungligen postat av BrJohan

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.

Citat:

---

Ursprungligen postat av BrJohan

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.

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

I vilket GitHub-'repository' finns programvaran?

Citat:

---

Ursprungligen postat av BrJohan

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.

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

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

Citat:

---

Ursprungligen postat av BrJohan

I vilket GitHub-'repository' finns programvaran?

---

https://github.com/andersardo/gedMerge

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.

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.

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?

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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'

Har inte skapats någon databas...

Hej Tommy

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

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.

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"?

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.

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

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.

Utmärkt. Tack!

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

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.

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.

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

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

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.

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

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.

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.

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.

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.

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

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.

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.

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

Citat:

---

Ursprungligen postat av C-J Gustafsson

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.

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.

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

En fråga:

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

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.

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

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

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.

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.

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

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.

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.

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.

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?

Citat:

---

Ursprungligen postat av 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?

---

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?

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.

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

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.

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.

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

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.

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

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.

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??

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.

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.

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.

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.

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å?

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.

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.

Citat:

---

Ursprungligen postat av 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.

---

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

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

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.

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

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:

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.

Ok Tack :-D