Nummer på Giften?

[m05143]

I DG8.2d hade Giftena nummer precis som personerna. Är så fallet i DG2016?

[ollfa]

Internt i programmet finns en identitet, men den visas aldrig för användaren.

[m05143]

Tack!

[C-J Gustafsson]

Olle, om relationerna har en identitet skulle inte den då kunna användas i GEDCOM filer i stället för dessa påhittade löpnummer?

[Rolf Carlsson]

I brist på kontrollverktyg i Disgen2016 matchade jag en Gedcomfil mot RGD/Släkttrims indatakontroller. Jag fick då felnotering om ett antal dubbla giften. Nu tror jag inte att jag har några dubbla giften (däremot en del med barn före/under äktenskap). Eftersom det inte finns någon ID-koppling till dessa relationer i Disgen kan jag heller inte kolla upp vilka relationer det avser.

Ett annat fel, som jag fick var att Faddrar saknar könsangivelse (detta kan jag förstå eftersom de är konverterade som en textsträng) - här finns sökbara ID-begrepp.

Just som Kalle säger ovan - om det finns ett internt ID-begrepp i systemet, varför inte använda det och göra det sökbart i Disgen2016. Vad jag kan minnas har jag aldrig sett något skäl till varför relationernas ID-begrepp togs bort. Om det är önskvärt/nödvändigt kan de ju visuellt skiljas från person-ID.

Olle, är det inte användaren, som kan behöva se ID-begreppet? Varför dölja något som kan vara till nytta för användaren? :confused:

[C-J Gustafsson]

I openRGD får man meddelande om dubbla giften om samma par registrerats i flera relationer. Så effekten blir som du misstänker när man har gemensamma barn före och under äktenskap. openRGD kan inte skilja på avsiktlig och oavsiktlig dubbelregistrering.

I och med att familje/relations identiteter i Disgen 2016 bara finns som "tillfälliga löpnummer" så blir enda möjligheten att identifiera en relation genom att läsa GEDCOM filen och få personidentiteter på relationsmedlemmarna. Det kräver dessutom att man har bra kunskaper om hur en GEDCOM fil är uppbyggd och hur man hittar informationen.

Så tyvärr blir en del av testerna i openRGD svårhanterade för användaren.

Vi får hoppas att familjeidentiteter dyker upp i kommande versioner av Disgen.

En annan effekt som gör openRGD användare förvirrade är de skapade faddrarna, (utan relation och utan kön) ger en massa "felsignaler".
Lämpligen bör man därför exkludera faddrarna när GEDCOM filen skapas.

[Rolf Carlsson]

Vi skall inte gå in i en RGD-diskussion i denna tråd. Vill bara konstatera - som Kalle också anger - att förändringar i Disgen2016 skapar "tvetydigheter" i RGD. Vad gäller före/under äktenskap hanteras väl detta i Family mergers i loglistan normalt utan problem. Vad jag nu fått ut är ett mindre antal "dubbla giften" (långt mindre antal än antalet relationer före/under) i de inledande varningarna från indatakontrollen. Denna varning har jag aldrig sett tidigare. Om nu detta är en varning som behöver analyseras, har jag inget användbart ID.

Som jag tagit upp i en annan tråd finns det några punkter, som varit föremål för rätt intensiv debatt (såsom ID-nummer, import av faddrar och nu relationers ID-begrepp. Det upplevs som svaren går i riktningen: Så är det. Kanske det är kloka/genomtänkta synpunkter, som kommer fram. Kanske man skall medge att vi tänkte inte fullt ut - detta skall vi "rätta till".

Vad gäller faddrar (jag tar upp det här även om faddrar har en egen tråd) så skulle det kanske finnas två kategorier - a) faddrar med egen identitet, b) faddrar, som tidigare enbart med textsträng. Säg till en födelsenotis för Sven den 3 april 1702 står Johan i Snårskogen och Anna i Lingonriset som faddrar. Jag kan inte identifiera dem men vill ändå notera detta. Alla importerade faddrar borde falla under b) tills jag gör en ändring till a).

[Rolf Carlsson]

Finns det något ställningstagande till ett eventuellt återinförande av ID-begrepp för relationer - de existerar ju uppenbarligen i det fördolda.
Det är alltid bra med ett besked - ja eller nej.

[DanielBerglund]

Interna databasidentiteter kommer aldrig att synas utifrån just eftersom de är interna och kan komma att ändras i framtida versioner.

Om någon extra, synlig, identitet för relationer ska införas får produktrådet fundera på (förutsatt att de får ett förbättringsförslag). Men av det du skriver i inlägg #7 verkar det ju som att RGD skulle kunna göra tydligare utskrifter som gör det enklare att hitta rätt relation? RGD ska ju ändå kunna hantera gedcomfiler från olika källor, inte bara Disgen.

[Rolf Carlsson]

Tack för ditt svar men det är något oklart vem som gör vad.
Om det är så, att Dis har för avsikt att gå vidare med RGD-produkten, synes det som om Dis får två produkter - Disgen och RGD -, som inte är fullt kompatibla med varandra. Om nu Produktrådet gjort detta fatala förbiseende bör väl frågan tas upp till omprövningsbeslut och genomförande så snart som möjligt.

RGD gör vissa indatakontroller avseende relationer och rapporterar eventuella avvikelser med hänvisning till relationsnumret. Detta fungerar problemfritt med Disgen 8 och de där existerande ID-begreppen för Relationer (Giften). Dessa är ju, som vi vet, sökbara i Disgen för utredning och i förekommande fall korrigering i den egna forskningsdatabasen

Om RGD införes måste det väl vara Dis förhoppning att indata till övervägande del utgöres av Gedcom-filer från Disgen. Då torde det också ligga i Dis intresse att dessa två produkter är fullt kompatibla.

Huruvida det utåt använda begreppet är lika med det som finns i systemet eller konstrueras på annat sätt är inget för mig eller någon annan användare att ta ställning till. Det viktiga, som Olle Fåk nämner, är dock att det faktiskt existerar.

[C-J Gustafsson]

Nu finns ju inget beslut som RGD så det finns väl inga ambitioner att synka produkterna.

Att MinSläkt användare irriterats över detta identitets problem har varit känt för projektledaren för openRGD sedan de första testerna gjordes. Då fungerade det bra för Disgen användare.
Några försökte även övertala Dannberg om att hans användare skulle bli mycket nöjdare om individer och familjer fick "riktiga" identiteter.

Att nu Disgen 2016 användare skall drabbas av detta kända irritationsmoment är verkligen ett stort steg i fel riktning.

[DanielBerglund]

Att MinSläkt användare irriterats över detta identitets problem har varit känt för projektledaren för openRGD sedan de första testerna gjordes. Då fungerade det bra för Disgen användare.
Några försökte även övertala Dannberg om att hans användare skulle bli mycket nöjdare om individer och familjer fick "riktiga" identiteter.


Kan inte openRGD helt enkelt skriva ut den information som finns i gedcomfilen angående kontrahenterna i relationen? Kombinationen namn+ort+datum för två personer borde vara enkel att söka fram i de flesta databaser oavsett om det är MinSläkt eller Disgen eller något annat, så om den informationen skrivs ut i meddelandena borde användaren bli nöjd.

Det är ju också värt att notera att Gedcomstandarden inte säger något om familjeidentifierarna (och personidentifierarna) annat än att de ska vara unika i filen. openRGD kan alltså inte gärna förutsätta att @F1234@ refererar till en familj med id 1234 i indatafilen.

[BrJohan]

Interna databasidentiteter kommer aldrig att synas utifrån just eftersom de är interna och kan komma att ändras i framtida versioner.


Tre databaspragmatiska - eller möjligen databassemantiska - reflexioner:

Även om jag inte är alldeles obekant med databaser eller databasteori tror jag mig inte ha stött på "intern databasidentitet" som något definierat begrepp.

Eftersom i Disgen såväl individidentiteter som familjeidentiteter har kunnat eller kommer att kunna ändras mellan versioner, och följaktligen i båda fallen skall betraktas som "interna", så kan man fråga sig varför individidentiteter, men inte familjeidentiteter, är 'synliga'.

Om de "interna" familjeidentiteterna inte får 'synas', så kan man likaledes fråga sig vilka värden för XREF:FAM som används i de GEDCOM-transmissioner som genereras av Disgen.

[C-J Gustafsson]

I ett eventuellt kommande RGD skall indatakontrollen troligen göras mot en databas, som ger helt andra möjligheter till bättre information.

I openRGD sker indatakontrollen direkt mot GEDCOM filen, vilket därmed innebär mindre möjligheter till information tillbaka till användaren.
I relations posten finns inte tillgång till namn, ort och datum på individerna, bara identiteter.

För Disgen 8 kunde vi förutsätta att familj 1234 också var familj 1234 och att det gick att söka på familj 1234.
Det var den största orsaken till att felsignalen kunde begränsas till Familj 1234. När vi på försök la till identiteterna på HUSB/WIFE upplevdes det förvirrande om var felet fanns, men det kanske skulle varit bästa alternativet i alla fall.

openRGD gjordes efter de förutsättningar som fanns då, men det ger väl en vink till eventuellt framtida RGD att bli bättre förberett på oväntade förändringar.

[DanielBerglund]

Även om jag inte är alldeles obekant med databaser eller databasteori tror jag mig inte ha stött på "intern databasidentitet" som något definierat begrepp.
Jag tror nog att du ändå begrep vad jag menade ;)



Eftersom i Disgen såväl individidentiteter som familjeidentiteter har kunnat eller kommer att kunna ändras mellan versioner, och följaktligen i båda fallen skall betraktas som "interna", så kan man fråga sig varför individidentiteter, men inte familjeidentiteter, är 'synliga'.
Någon (jag minns inte turerna exakt) ställde krav på att det skulle synas en identitet, och i första varvet visades den interna identiteten. Denna bedömdes som svårläslig eftersom den innehåller för många siffror. Då infördes en extra kolumn som innehåller ett annat löpnummer som börjar på ett. Det är det numret som visas.



Om de "interna" familjeidentiteterna inte får 'synas', så kan man likaledes fråga sig vilka värden för XREF:FAM som används i de GEDCOM-transmissioner som genereras av Disgen.
Det är (just nu) ett löpnummer, som tidigare nämnts i denna tråd.

[DanielBerglund]

openRGD gjordes efter de förutsättningar som fanns då, men det ger väl en vink till eventuellt framtida RGD att bli bättre förberett på oväntade förändringar.
Något vi kan diskutera för Disgens del är ju privata taggar i gedcomfilerna, och att vi då kommer överens mellan RGD och Disgen vad dessa ska innehålla för information.

[Rolf Carlsson]

Alla ni som gjort inlägg på denna tråd är ytterst kompetenta IT-experter. Själv är jag knappast någon sådan, då min erfarenhet under flera decennier snarast ligger inom internationell managemet upp till koncernledningsnivå i mindre och större företag.

Jag tycker ni tassar som katten kring den heta gröten utan att riktigt ta tag i kärnproblemet (go to the root cause). Situationen - i all enkelhet - är ju den att i Disgen8 genererades identiteter avseende individer och relationer, när en Gedcom-fil skapades. En sådan generell Gedcom-fil utgör indatafil till den version av RGD, som f n föreligger. När nu i Disgen2016 en generell Gedcom-fil skapas för samma ändamål, saknas sökbara identiteter för relationer, vilket näst intill omöjliggör att gå tillbaka till Disgen2016 och korrigera eventuella felaktigheter påvisade i RGDs indatakontroller.

Det är fullt mänskligt för Produktrådet att förbise ett sådant förhållande. När detta nu påvisats kommer allehanda avledande synpunkter och eventuella lösningar längre fram i kedjan utan att gå direkt till kärnproblemet. Hade detta förekommit inom ett område, där jag var ansvarig, hade jag nog givit en klar instruktion: Här har vi missat något - just fix it - no more talk.

Av diskussionen idag får jag närmast den motsatta uppfattningen - no fixing - continue to talk.

[DanielBerglund]

Jag går rakt på sak: nej, du har fattat fel. Det är inte kärnproblemet. Det är ett symptom men inte orsaken.

Du får ursäkta, men även högre chefer bör begripa vad de talar om - och om de inte gör det, bör de överlåta till sina kompetenta underställda att föreslå en lösning.

Jag tror du ska läsa tråden igen från början, och istället för att leta efter vad du tror är ursäkter, så försök förstå grundproblemet. Jag ska gärna förklara igen, men läs på först.

[BrJohan]

Inför vem eller vad är Produktrådet - som ju beslutar om utvecklingen av Disgen - ansvarigt?

Dokumenteras och arkiveras Produktrådets beslut?

[DanielBerglund]

Inför vem eller vad är Produktrådet - som ju beslutar om utvecklingen av Disgen - ansvarigt?
Dokumenteras och arkiveras Produktrådets beslut?
Styrelsen.

Dokumentationen är nog på nivå "minnesanteckningar" men Christer har bättre koll på det än jag.

[Christer]

Produktrådet hanterar både stort och smått som rör Disgen-utvecklingen. De större frågorna har dokumenterats bättre i minnesanteckningar och e-post än de mindre. Vi beslutar oftare i frågor som rör vad och när än hur. Men även det senare förekommer. Vi är dessutom mitt i en övergång från en traditionell utvecklingsmodell (vattenfall) till en mer "lättrörligt " arbetssätt (agil utveckling). Vilket nog kommer att innebära mindre dokumentation och mer dialog.

[Rolf Carlsson]

Jo, jag har läst och också försökt förstå innebörden av vad som skrivits. Emellertid saknas än så länge det enkla svaret på mitt inlägg under #7.

Grundfrågan är att Disgen2016 saknar sökbara identitetsbegrepp beträffande relationer, vilket finns i Disgen8. Denna relationsidentitet fanns med i den Gedcom-fil, som låg till grund för inläsning i RGD.

En konsekvens är att vid inläsning/validering i RGD refereras vid vissa avvikelsetyper till en familj (relationsidentiteten). Orsaken till avvikelserapporten analyseras sedan i den egna forskningsdatabasen (Disgen eller annat släktforskningsprogram) för korrigering där i förekommande fall. Härvidlag fanns i Disgen8 möjligheten att kunna söka på den refererade identiteten. Detta är inte längre möjligt. Om sökbara identitetsbegrepp i samma situation saknas i andra släktforskningsprogram är inget som Dis kan lösa. Det är bara att konstatera att i detta avseende har Disgen8 en klar (konkurrens)fördel jämfört med exempelvis MinSläkt.

I allt det som skrivits hittills i denna tråd har jag inte ens i en bisats sett de sex orden: Då inför vi relationsidentiteter i Disgen2016. Därigenom uppnås status quo med Disgen8 och den i denna tråd beskrivna konsekvensen vore därmed löst. Hur denna identitet rent tekniskt skapas är något för er IT-experter.

[DanielBerglund]

Jo, jag har läst och också försökt förstå innebörden av vad som skrivits. Emellertid saknas än så länge det enkla svaret på mitt inlägg under #7.

[...]

En konsekvens är att vid inläsning/validering i RGD refereras vid vissa avvikelsetyper till en familj (relationsidentiteten). Orsaken till avvikelserapporten analyseras sedan i den egna forskningsdatabasen (Disgen eller annat släktforskningsprogram) för korrigering där i förekommande fall. Härvidlag fanns i Disgen8 möjligheten att kunna söka på den refererade identiteten. Detta är inte längre möjligt. Om sökbara identitetsbegrepp i samma situation saknas i andra släktforskningsprogram är inget som Dis kan lösa. Det är bara att konstatera att i detta avseende har Disgen8 en klar (konkurrens)fördel jämfört med exempelvis MinSläkt.

I allt det som skrivits hittills i denna tråd har jag inte ens i en bisats sett de sex orden: Då inför vi relationsidentiteter i Disgen2016. Därigenom uppnås status quo med Disgen8 och den i denna tråd beskrivna konsekvensen vore därmed löst. Hur denna identitet rent tekniskt skapas är något för er IT-experter.

OK. Fel bör lösas på de lämpligaste ställena och därför brukar det behövas lite diskuterande innan man kommer överens om vad som ska göras och hur.



Grundfrågan är att Disgen2016 saknar sökbara identitetsbegrepp beträffande relationer, vilket finns i Disgen8.

Ja, det är ostridigt.


Denna relationsidentitet fanns med [i Disgen 8] i den Gedcom-fil, som låg till grund för inläsning i RGD.

Ja, men i form av en raggarlösning. Gedcomstandarden säger inget om innehållet i relationsidentifierarna i en gedcomfil. Disgen 8 råkade använda de relationsidentifierare som användes i den databaslösningen som användes då.

I Disgen 2016 ändrade vi som sagt på det viset att det inte längre finns någon sökbar relationsidentiet. Gedcomfilerna konstrueras därför på annat sätt. Efter detta kan inte längre openRGD leverera bra felmeddelanden.

Gör openRGD rätt i sin nuvarande utformning? Nej, eftersom gedcomstandarden inte anger att relationsidentifierarna ska ha något meningsfullt innehåll. openRGD kan alltså inte förutsätta detta. Det bara "råkade" fungera med Disgen 8. Det "råkade" inte fungera med MinSläkt.

Så vad göra? Jag anser att openRGD borde lagas så att personinformationen skrivs ut för resp tveksam relation. Enligt vad Kalle skriver tidigare går det inte idag, men eftersom all information faktiskt finns i gedcomfilen handlar det om att "någon" ska göra det jobbet. Min poäng är att detta ändå behöver göras eftersom vi vill stödja gedcom-filer från andra program.

Kan inte Disgen 2016 införa samma slags sökbara identiteter som redan finns för personer? Jo, det skulle gå, men kräver en databasändring och bör därför vänta till 2017. Men är det en bra lösning? Nej, jag tycker inte att det är bra att koda lite extra information i relationsidentifierarna i en gedcomfil. Bättre att införa en s.k. privat tagg i så fall, och komma överens internt med openRGD-utvecklarna vad denna ska bära för information.

Då har vi tre möjliga arbetspaket:
1) Disgen inför en synlig sökbar relationsidentitet. Det får vägas mot andra tänkbara förbättringar eftersom vi inte har obegränsat med utvecklare.
2) openRGD förbättrar tolkningen av gedcomfilerna och därefter felmeddelandena.
3) Disgen-utvecklarna och openRGD-utvecklarna kommer överens om en eller flera privata taggar och hur dessa ska användas.

Tyvärr är inget av detta direkt snutet ur näsan, så nästa fråga blir att se vem av de frivilliga utvecklarna som vill ta upp arbetet.

[BrJohan]

Vad som ibland - och oegentligt - kallas för identifierare i GEDCOM 5.5.1, är korsreferenser utan definierad semantik, men som har en precis pragmatik, innebärande att 'records' inom GEDCOM-transmissionen kan pekas på och/eller peka ut andra 'records'.

Inget i GEDCOM standarden hindrar emellertid programvaruapplikationer från att låta även semantik förekomma i korsreferenserna. Avsikten med GEDCOM är dock att på ett flexibelt och likformigt sätt kunna transferera genealogiska data mellan olika programvaruapplikationer. Därför bör man helst avstå från att tillföra semantik där sådan inte förväntas finnas.

Detr förekommer sju olika typer av sådana korsreferenser. För detta forumämne är de korsreferenser som avser familjer och individer relevanta.

Av Disgen 8 gavs båda dessa korsreferenstyper semantik.

Av Disgen2016 ges - vilket visas av diskussionen - korsreferenser som berör familjer däremot inte någon semantik. Jag antar att individkorsreferenser fortfarande - och i så fall inkonsekvent - får värden med semantiskt innehåll.

Något beslut angående denna förändring måste ha fattats och då rimligen av Produktrådet.

Produktrådet borde, för Disgenanvändande medlemmar, kunna redovisa grunderna för detta beslut.

openRGD skall givetvis inte förutsätta att korsreferenser bär semantik. Dock skulle openRGD, om det av GEDCOM-'headern' framgår att transmissionen genererats av Disgen och i så fall också vilken version av Disgen som använts, möjligen kunna tillåtas tolka och använda korsreferensers - eventuellt förekommande - semantiska värden.

Jag har inte använt openRGD och vet alltså inte om individkorsreferenser där tolkas semantiskt.

Principiellt borde självfallet openRGD behandla alla korsreferenser enbart pragmatiskt. All erforderlig information som behövs för att generera praktiskt användbara rapporter finns, som Daniel skriver, i GEDCOM-transmissionen.

Jag använder själv inte Disgen och avstår därför ifrån att ha konkreta synpunkter på hur programmet vidareutvecklas.

[Christer]

openRGD är en beta för att testa olika lösningar och vi planerar inte att utveckla den vidare. Erfarenheterna ska ligga till grund för den fortsatta utvecklingen av RGD och ett tänkt Släkttrim. Så det finns alla möjligheter att hitta en väg framåt för RGD genom fortsatta diskussioner, förslagsvis på höstens funktionärsträff i DIS.

[Rolf Carlsson]

Jag vill ge några avslutande synpunkter utan krav på att förlänga diskussionen.

Som lekman vad beträffar IT-området hade jag inte i min vildaste fantasi kunnat föreställa mig att det skulle vara så komplicerat att medföra en i ursprungsprodukten (Disgen2016) sökbar relationsidentitet (för individidentiteter är det möjligt och fungerar det utan problem). Det finns ett talesätt att det är lättare att göra en fisksoppa av ett akvarium än att göra ett akvarium av en fisksoppa - kanske det är tillämpligt här.

Den version av RGD, som nu föreligger, har för tillfället ett mervärde, då verktygslådan i Disgen2016 ännu inte är fullt utvecklad. Jag har nu använt mig av RGD för att kvalitetskontrollera de uppgifter i Disgen2016, som inmatats efter konverteringen från Disgen 8. RGD har flera kompletterande kontrollparametrar även till de som förekommer i Disgen8. Min ambition är att ha en så felfri forskningsdatabas, som är möjligt att åstadkomma med lätt tillgängliga och praktiska verktyg.

Syftet med relationsidentiteten är att kunna gå tillbaka till den egna forskningsdatabasen för att kontrollera de varnings- och avvikelserapporter som framkommer i samband med inläsning av Gedom-filen i RGD. Därefter har denna identitet sannolikt en begränsad användning i RGDs fortsatta bearbetningar.

Jag har full respekt för era kunskaper inom IT-området och är helt övertygad att den lösning, som Daniel beskriver, är såväl exellent som ytterst sofistikerad. Min allmänna erfarenhet säger dock att det i de flesta situationer även kan finnas pragmatiska och enklare lösningar (raggarlösningar eller vad de nu må benämnas), som är tillräckligt sofistikerade för de krav, som ställs i ett specifikt fall; nämligen att just här på ett enkelt sätt återfinna ursprungsnotisen i Disgen2016 för att sedan kunna analysera den förekommande varningssignalen och i förekommande fall göra erforderliga korrigeringar.

Huruvuda RGD är en beta-version eller inte är en närmast semantisk fråga. Den föreliggande versionen uppfyller fullt ut den funktionalitet den var avsedd att innehålla.