+ Svara på ämne
Resultat 1 till 6 av 6

Ämne: RGD - Prototyp

  1. #1

    RGD - Prototyp

    Som nämnts i andra sammanhang har Projektgruppen tagit fram en prototyp för RGDs databas. Den huvudsakliga inriktningen med prototypen har varit att identifiera och eliminera felaktigheter i de Gedcom-filer från medlemmar, som legat till grund för bearbetningen samt att identifiera när samma individ förekommer hos flera medlemmar.

    Vad gäller valideringskontrollerna har de exempelvis avsett ej önskvärd information i namnfältet, identifiering av förekommande dubbletter, identifiering av felaktigt kön, förväxling mellan för- och efternamn. Det är samma typ av kontroller, som är tänkt att ingå i en eventuellt framtida produkt: Egenkontroll av forskningsdatabasen.

    Det viktigaste och mest komplicerade momentet är att identifiera om samma individ förekommer i flera medlemmars material. Kontrollerna görs här över flera generationer för att stämma av familjerelationer och även fånga upp avvikelser i uppgifter avseende enskilda personer. Genom att hela familjen i första steget granskas maskinellt upptäcks avvikelser beträffande namn, datum eller ort liksom barn som saknas i inrapporteringsfilen eller i databasen (nytillkommande individ). Avvíkelserna bearbetas därefter manuellt och individerna kan sammanföras även om exempelvis födelsedatum ej skulle stämma överens.

    Kontroll av förnamn/efternamn sker mot en central namndatabas (produktionsmässig version), som också beskrivits i ett separat ämne. Kontroll av orter mot ”Sveriges församlingar genom tiderna – Skatteverket 1989”. I prototypen har ingen kontroll skett om uppgiften faller inom den tid församlingen existerat eller ej. Detta planeras i en senare version av ortsdatabasen.

    Avgörande för prototypens funktionalitet är att kunna identifiera och sammanföra individerna (”matchning”). Möjligheterna att exempelvis rätta felaktigheter eller att kunna avgöra vilken medlems uppgift, som är korrekt, har haft underordnad betydelse i prototypen. Detta och även ett flertal andra funktioner kommer självfallet att byggas in i en slutlig version av databasen.

    Bearbetningen i Prototypen har baserats på autentiska Gedcom-filer från ett flertal medlemmar. Filerna har ofta uppgått till 10.000-tals individer. Vidare har material valts ut så att filer med mycket stora överlappningar (flera tusen individer, som förekommer hos två eller flera medlemmar) för att få en relevant test på att funktionaliteten för identifiering av samma individ förlöper på önskvärt sätt.
    Projektgruppen är av den uppfattningen att funktionaliteten i Prototypen motsvarar de krav/förväntningar som ställts upp. Samtidigt har ett flertal punkter på komplettering av funktionalitet identifierats för att ingå i en slutlig version (förutsatt att Styrelsen fattar beslut om RGDs genomförande).

  2. #2
    Bearbetning och utvärdering av prototypen har nu avslutats med rapportering till Styrgrupp och Styrelse. Projektgruppen anser att förutsättningarna för prototypen väl infriats.

    Fokusering har varit på tre delområden:
    - valideringskontroller av de ingående GEDCOM-filerna avseende formella fel, dubbletter, kön med mera
    - identifiering av identiska personer i flera ingående filer
    - sammanläggning ("matchning") av identiska individer till en "aggregerad" individ med de "bästa" uppgifterna från respektive indatafil

    En avsevärd mängd formella fel upptäcktes och i förekommande fall korrigerades i samband med indatakontrollerna. Som även nämnts tidigare kommer de flesta av dessa kontroller att ingå i det "Verktyg för egenkontroll" som planeras. Därmed kan varje medlem själv validera sin egen forskningsdatabas på samma sätt.

    Det avgjort viktigaste momentet har varit att identifiera identiska personer i flera forskares material. Genom att värdera mängden av samstämmiga uppgifter dels i indatafilen och dels i RGDs databas kan potentiellt identiska personer markeras. När en kandidat identifierats jämförs hela familjebilden (föräldrar/syskon) med motsvarande familjebild i databasen. Till allra största delen kan familjebilderna behandlas maskinellt genom att de är helt identiska. De familjebilder, som till vissa delar stämmer överens granskas och behandlas manuellt. Även här går det med en snabb visuell granskning att avgöra att det rör sig om samma familj men att vissa uppgifter avviker. Exempel kan vara enkla datumavvikelser, skillnad i ortsangivelser, olika detaljeringsgrad av uppgifter avseende en av individerna, tillkommande syskon/föräldrar jämfört med RGDs databas. Mera komplicerat att reda ut är relationsavvikelser; fel förälder/föräldrar, ett felaktigt syskon. Vid bearbetningen i prototypen har vi stannat med att konstatera förekommande avvikelser. I den slutliga produkten tillkommer rättningsrutiner antingen hos den inrapporterande medlemmen eller där det är lämpligt i RGDs databas.

    Jämförelserutinerna har visat sig vara så effektiva att rimligtvis alla förekommande differenser upptäcks. Har två medlemmar gjort exakt samma fel är det självfallet fortsatt fel i databasen, men där kanske den tredje eller fjärde medlemmen som lämnar bidrag kring just den individen har gjort rätt och då kommer avvikelsen automatiskt upp för granskning och behandling.

    Det bör i detta sammanhang bli möjligt att den medlem, som lämnat ett bidrag kan analysera sina egna avvikelser mot databasen och dels korrigera i sin egen forskning om felen ligger där och dels rapportera ett fel i databasen för korrigering i denna. Vid analys av ett större antal överlappande poster visar det sig att de allra flesta avvikelserna avser olikheter i tidsangivelsen - felläsningar eller felinmatningar.

    När väl familjebilderna granskats och i förekommande fall korrigerats skapas en "aggregerad individ" i RGDs databas. Denna individ bygger på de mest preciserade uppgifterna från respektive uppgiftslämnare. Det är denna aggregerade individ som blir det som visas utåt i databasen. De ingående uppgifterna från respektive uppgiftslämnare finns kvar i databasen för att kunna spåra uppgiftslämnaren men blir sannolikt endast tillgängliga för databasens administratörer.

  3. #3
    Phryxes avatar
    C-G Magnusson
    Medlemsnr
    13088
    Inlägg
    995
    Kan du säga nåt om vilken teknik (programspråk, databashanterare etc) ni använt för att bygga prototypen? Kommer den skarpa applikationen att bygga på samma teknik?

  4. #4

    Carl-Johan Gustafsson
    Medlemsnr
    19138
    Ort
    Nykvarn
    Inlägg
    532
    För validering och preparering av GEDCOM filer har vi använt relativt enkla php program och MySql tabeller. I matchningen användes Python och lite mer avancerade metoder.
    Men detta är enbart en prototyp och styr egentligen inte alls vilken produktionsmiljö, som eventuellt kommer att användas. Det blir ett senare beslut.
    Senast redigerad av C-J Gustafsson den 2013-11-27 klockan 17:49.

  5. #5

    Anders Ardö
    Medlemsnr
    49324
    Ort
    Lund
    Inlägg
    49
    Citat Ursprungligen postat av Phryxe Visa inlägg
    Kan du säga nåt om vilken teknik (programspråk, databashanterare etc) ni använt för att bygga prototypen? Kommer den skarpa applikationen att bygga på samma teknik?
    Matchningen av Gedcom-filer är kodad i Python och använder MySQL som databas-motor. Användargräns-snittet är Web-baserat och använder HTML, JavaScript (jQuery) och Python. Det är inte bestämt hur den skarpa versionen ska implementeras, det beror väldigt mycket på vem som är intresserad av att hjälpa till att bygga den.
    Jag menar t.ex. att databasmotorn ska isoleras med ett eget lager mellan den och applikationen (så det är lätt att byta databasmotor).

  6. #6
    Phryxes avatar
    C-G Magnusson
    Medlemsnr
    13088
    Inlägg
    995
    Tack för svaren!

+ Svara på ämne

Behörigheter för att posta

  • Du får inte posta nya ämnen
  • Du får inte posta svar
  • Du får inte posta bifogade filer
  • Du får inte redigera dina inlägg