Problem med GEDCOM 5 import i Disgen

[DanielBerglund]

Intresse och kunskap, inklusive i Pascal, finns. Kanske svårare med tiden. Om jag fick ett ex av DiSGen för besväret skulle det kanske gå lättare att hitta tiden, utan en GEDCOM-masserare blir det ju ändå inget köp för mig. Ska programmet göras som ett fristående program kan jag ju göra det i C# eller VB.Net, har alla Microsofts program via MSDN-prenumeration.

Ett exemplar av Disgen till de som utvecklar på Disgen eller angränsande program är inget problem alls.

Finns det för övrigt något standardmässigt sätt att länka till foton i en GEDCOM-fil?

Nej, det är väl alltid lokala filsystemspather som följer med och därmed blir det problem på ett eller annat vis. Enda sättet är nog att placera alla foton i samma katalog som gedcomfilen och inte skicka med några pather alls.

Finns det något dokument som beskriver exakt den (subset/superset av) GEDCOM 5.5-standarden som DiSGen hanterar? ("Vi följer GEDCOM 5.5-standarden duger inte som svar... :-))

Det är källkoden som gäller här. Den är ganska lättläst men omfattande. 6k rader för importen. Exporten är dock bara 1,4k rader.

Efter lite funderande så behöver ju "GEDCOM-masseraren" vara en integrerad del av DiSGEN (försteg till importen) för att hjälpa till med försäljningen - annars går den ju att använda innan import till vilket program som helst...

Nja, vi kan nog ha fristående generalla program för specialuppgifter. Vi är ju inte "föreningen Disgen" så om det går att använda till andra program är det ingen nackdel. Disgen blir i sin tur ganska klumpigt om allt ska integreras där.

Däremot är det nog så att en gedcom->gedcom transformering inte kan lösa alla problem, utan en del begrepp behöver man skriva in direkt i Disgens databas. Det är ett argument för integrering av i alla fall vissa delar.

[tommypeters]

Nej, det är väl alltid lokala filsystemspather som följer med och därmed blir det problem på ett eller annat vis. Enda sättet är nog att placera alla foton i samma katalog som gedcomfilen och inte skicka med några pather alls.

Ska man kunna importera "extrainformation" måste man naturligtvis ställa krav på hur exporten från "det andra programmet" ska göras. T.ex. måste bilderna ligga i samma katalog som GEDCOM-filen, eller i en underkatalog direkt under som t.ex. heter "Photos".

Det är källkoden som gäller här. Den är ganska lättläst men omfattande. 6k rader för importen. Exporten är dock bara 1,4k rader.

Jag har kommit in som konsult i system (OK, mycket större) där "källkoden är dokumentationen" och också "lättförstådd". När vi sedan frågat dem om någon programdel och varför den gör som den gör så brukar de inte ha en aning...
Men jag tänkte mer på "Vilken GEDCOM 5.5-standard", speciellt angående avvikelser/tillägg, som följs.

Nja, vi kan nog ha fristående generalla program för specialuppgifter. Vi är ju inte "föreningen Disgen" så om det går att använda till andra program är det ingen nackdel. Disgen blir i sin tur ganska klumpigt om allt ska integreras där.
Däremot är det nog så att en gedcom->gedcom transformering inte kan lösa alla problem, utan en del begrepp behöver man skriva in direkt i Disgens databas. Det är ett argument för integrering av i alla fall vissa delar.

Förutom att rätta upp några felaktigheter från andra programs GEDCOM-->Standard GEDCOM så är ju huvudarbetet att göra en transformering från "Utökad GEDCOM" till "Utökad DiSGEN-GEDCOM". Dessa utökningar ska enbart vara sådant som sparar mycket arbete för användaren vid byte av program, som t.ex. att inte tappa länkarna till alla foton man har.

Man borde börja med att definiera detta "Utökade DiSGEN-GEDCOM-format" och då också tänka på om det finns finesser i DiSGEN som inte går att exportera via standard GEDCOM så bör dessa med i formatet. Om man sedan ska implementera valbar export från DiSGEN (Standard 5.5/Utökad) kan man bestämma senare, men man ska kunna importera dessa utökningar. Och "masseraren" ska kunna översätta från olika andra programs GEDCOM till detta utökade formatet. Som jag har fattat det kan i alla fall rätt många ickestandard-varianter som olika program producerar översättas till korrekt GEDCOM 5.5, det blir bara lite omständligare än programmens egna varianter, så detta utökade format behöver inte bli så omfattande.

Bra vore ju om man delvis kunde styra detta via en konfigurationsfil. Man kunde t.ex. definiera olika varianter på PHOTO-taggar och hur filnamnen skrivs, kommer det sedan ett nytt sätt det skriva i ett annat program behöver man bara lägga till den varianten i konigurationfilen. Programmet testar sedan allt som inte är standard GEDCOM 5.5 mot alla undantag i konfigurationsfilen, en körning kommer att ta ett tag men man ska ju inte köra det en gång i timmen...

[DanielBerglund]

Jag har kommit in som konsult i system (OK, mycket större) där "källkoden är dokumentationen" och också "lättförstådd". När vi sedan frågat dem om någon programdel och varför den gör som den gör så brukar de inte ha en aning...
Men jag tänkte mer på "Vilken GEDCOM 5.5-standard", speciellt angående avvikelser/tillägg, som följs.

Det finns såvitt jag vet bara en enda officiell 5.5-standard, men vad gäller avvikelser, ofullständigheter och tillägg i Disgen får man läsa källkoden. Mängden implementerade privata taggar är i alla fall liten (8 tror jag) och används inte; de är avstängda i de versioner av Disgen som gått ut till allmänheten. Annars finns det t ex en tagg för faddrar. Det är nog ganska otestad mark. Sedan finns det åtskilliga taggar i gedcom som inte stöds i Disgen (tänk på allt det här 'temple ready'-stoffet).

En konfigurationsfil låter bra men jag tror det är tekniskt svårt att "beskriva" avvikelser från gedcomstandarden i en konfigfil. Jag har aldrig kommit till skott, men hade jag gjort den här hanteringen i Disgen hade jag försökt definiera enskilda avvikelser eller tillägg först, på papper, och sedan gjort en lista över alla som ska stödjas. Sedan hade jag skrivit importkod i Disgen och låtit varje "väldefinierad avvikelse" eller tillägg ha sin kodsekvens. Själva användargränssnittet skulle sedan ha varit listor med kryssrutor där användaren väljer vilket program man vill importera från, vilket Disgen skulle mappa på en eller flera "väldefinierade avvikelser", eller så skulle man (avacerat) kunna välja ut enskilda avvikelser direkt.

Vi skulle ju kunna försöka använda wikin för att lista avvikelser eller tillägg och definiera hur de ska hanteras i Disgen och se hur långt vi kommer?

[tommypeters]

Det finns såvitt jag vet bara en enda officiell 5.5-standard, men vad gäller avvikelser, ofullständigheter och tillägg i Disgen får man läsa källkoden. Mängden implementerade privata taggar är i alla fall liten (8 tror jag) och används inte; de är avstängda i de versioner av Disgen som gått ut till allmänheten. Annars finns det t ex en tagg för faddrar. Det är nog ganska otestad mark. Sedan finns det åtskilliga taggar i gedcom som inte stöds i Disgen (tänk på allt det här 'temple ready'-stoffet).

En konfigurationsfil låter bra men jag tror det är tekniskt svårt att "beskriva" avvikelser från gedcomstandarden i en konfigfil. Jag har aldrig kommit till skott, men hade jag gjort den här hanteringen i Disgen hade jag försökt definiera enskilda avvikelser eller tillägg först, på papper, och sedan gjort en lista över alla som ska stödjas. Sedan hade jag skrivit importkod i Disgen och låtit varje "väldefinierad avvikelse" eller tillägg ha sin kodsekvens. Själva användargränssnittet skulle sedan ha varit listor med kryssrutor där användaren väljer vilket program man vill importera från, vilket Disgen skulle mappa på en eller flera "väldefinierade avvikelser", eller så skulle man (avacerat) kunna välja ut enskilda avvikelser direkt.

Vi skulle ju kunna försöka använda wikin för att lista avvikelser eller tillägg och definiera hur de ska hanteras i Disgen och se hur långt vi kommer?

Jovistt finns det bara en oficiell GEDCOM-standard, därför skrev jag det inom citationstecken. En del program kan exportera till ett par-tre 5.5-varianter, i huvudsak tillägg för att få med media som foton och stories - alltså länkar till externt material. I mitt träd har jag t.ex 6855 foton (porträtt, AD-källor, vapensköldar, platsbilder från internet) och 1319 stories, det är inget jag vare sig vill vara utan eller länka till manuellt.

Jag tänkte mig att körningen av "masseraren" skulle vara extremt enkel - rentavt simpel - för användaren. Kanske inte ens ett GUI, på sin höjd in- och utfilsnamn anges.

Tanken är helt enkelt såhär:
Man går igenom filen som ska masseras och när man hittar något som inte DiSGEN kommer att känna igen kollar man om man kan identifiera vad taggen + datat är för något. Antingen hårdkodat i programmet eller via en mönsterbeskrivning i en konfigurationsfil (jag har inte tänkt att användaren själv ska behöva ändra i konfigurationsfilen, det skulle föreningen göra och skicka uppdateringar som ett alternativ till programuppdateringar). Känner man igen taggen (t.ex _PHOTO) så översätter man den till "DiSGEN utökat format" och fortsätter sedan i filen tills nästa mysko tag hittas. Man tar varje okänd tag för sig, bryr sig inte om från vilket program det kommer, man vill inte komma in i någon modal körning i programmet.

[Christer]

Hittade idag ett verktyg för validering av GEDCOM-filer om någon är tänd på att testa. Se http://chronoplexsoftware.com/gedcomvalidator/index.htm

[DanielBerglund]

Man tar varje okänd tag för sig, bryr sig inte om från vilket program det kommer, man vill inte komma in i någon modal körning i programmet.

Jag tror man måste ta hänsyn till vilket program det är i en hel del fall, t ex om ett visst program genererar i och för sig väldefinierad gedcom men på ett sådant sätt att den inte följer standard. Bara för att hitta på ett exempel: anta att programmet X har växlat betydelsen av IMMI och EMIG men gör i övrigt helt rätt. I ett sådant fall kan inte en masserare veta att IMMI och EMIG ska växlas tillbaka om den inte också vet att filen kommer från just programmet X.

Ett annat fall där jag kan tänka mig att det behövs ett enkelt GUI är där användaren måste ges möjlighet att välja hur konverteringen ska ske. T ex har MinSläkt s.k. konfidentiella noteringar som kan exporteras med den privata taggen _CONF_NOTE. Disgen, däremot, har inte något officiellt begrepp som innebär att en notis är konfidentiell. Tydligen var notistypen "extra text" tänkt så från början men det har inte upprätthållits i praktiken. Här bör man alltså låta användaren av masseraren välja vad som ska ske, dvs välja på några rimliga lösningar som masseraren implementerar.

En sak till som vore bra är om man kan ändra egendefinierade notistyper under konverteringen. Man kanske inte vill använda de som finns i den inkommande gedcomfilen utan vill byta ut dem mot andra.

Nåja, sådana här saker måste inte vara med från början. Det är nog bättre att börja så enkelt som möjligt och se hur långt det räcker i praktiken. Med lite tur räcker det långt nog..

[tommypeters]

OK, jag tänkte inte på att programmen skulle vara så klantiga som ditt exempel med IMMI/EMIG. Precis när vi fixat det i programmet så rättar de det...
Jag tänkte mer på att ta hand om tillägg som var icke-standard, då hade väl mitt tänk fungerat.

Som jag skrev är ju tid en bristvara, så jag tänkte göra det så enkelt som möjligt så att en första version skulle bli färdig någon gång. Samt om man inte skulle hinna slutföra det så skulle det vara enklare för någon annan att fortsätta eller vi skulle fortsätta parallellt med varsin del.

[DanielBerglund]

Håller med om att det är bättre att börja enkelt och bygga om och till med tiden, än att vara överambitiös från början och inte komma i något mål alls.