Hej Bo Rosén
Problemet med GEDCOM är vad jag kan förstå det att programmakarna inte kan eller vill följa den standarden strikt. Detta kan dels bero på att GEDCOM inte är väl definierad men även att den kan vara svår att förstå.
Vid ett snabbt blick på standarden så tycker jag att den borde gå att använda (jag ska försöka förklara varför jag tycker så).
Du talar om DTD (Document Type Definiton) och det kanske finns ett struktur problem i GEDCOM, jag har som hastigast tittat igenom GEDCOM5.5 och tycker mig se en struktur. Struktur frågan lämnar jag dock över till Kaj Janzon som uppenbarligen har mer kunskap i dessa frågor.
Om vi talar om DTD i form av Data Type Definiton så verkar GEDCOM erbjuda iaf relations defintioner (typ, en till många, många till många, etc.). Dessutom verkar den ha storleksdefintion på fälten. Som exempel tar jag ADDRESS_COUNTRY.
ADDRESS_COUNTRY:= {Size=1:60}
The name of the country that pertains to the associated address. Isolated by some systems for sorting or indexing. Used in most cases to facilitate automatic sorting of mail.
Den har en beskrivning om innehåll och en storleks def. Det andra exemplet är struktur. Vi tar Individual_Event_Structure som exempel.
INDIVIDUAL_EVENT_STRUCTURE:=
n EVEN {1:1}
+1 > {0:1}
Här kan vi se att GEDCOM visar hur en händelse skall beskrivas. n beskriver vilken nivå händelsen befinner sig på. EVEN är taggen för händelsen. {1:1} antar jag är en relations hänvisning (jmf databas modellering). Sedan kommer det intressanta. Detaljerna, detaljerna kan variera från plats, person, datum, etc.
1 EVEN
2 TYPE Surfade på internet
2 DATE idag/denna måndad/detta år
2 PLAC Hemma
Sedan kan jag bygga på denna händelse med i princip vad jag vill. Nu kommer poängen med hela grejjen.
Trots att det verkar finnas struktur och data definiton i GEDCOM så kvarstår ändå problemet med transformation eller mappning. Varför? Jag misstänker som jag tigigare sagt att det beror på att programvaruhusen inte tar problemet på allvar. Men det kan också bero på semantisk missmatch. Denna term används inom datorspråket när man överför information från ett språk till ett annat, dvs betydelsen finns inte riktigt i det ena språket. Om felet beror på detta så hjälper inte byte från GEDCOM till SGML eller XML.
Varför det kan man då fråga sig. Jo om det ligger till så att Program A och Program B inte har exakt samma funktioner eller definerar samma sak som olika saker (tex, nyåret för kinerser och västerlänningar) då uppstår problem när man skall mappa den ena informationen till det andra programmet. Låt oss säga att Program A stödjer homosexuella giftermål, låt oss också säga att GEDCOMn.n stödjer sk. både giftermål och partnerskap och slutligen Program B som inte stödjer homoskexuella giftermål men dock partnerskap. Vad kommer då att hända när man mappar relationen? Program A --> GEDCOM == Giftermål mellan A(pojke) och B(pojke) i kyrka A. GEDCOM --> Program B == Giftermål A(pojke) och B(flicka) i kyrka A eller Partnerskap A(pojke) och B(pojke) men ingen kyrka. Hursomhelst så blir det fel och kan sabba vilken relation som helst (vitsig), men semantisk missmatch verkar dock inte vara det vanligaste transformationsfelet inom släktforskning.
Det transformationsfel som verkar vara oftast förekommande är teckentabells fel. Dvs ö blir | eller något. Denna typ av fel är ganska enkelt att komma till rätta med se mitt inlägg under GEDCOM. På tal om detta så kan ni se att { inte skall vara { utan ett vänstermåsvingeklammer, inte bara släktforskningsprogrammen lider av transformationsproblem mellan olika teckentabeller
Jag vet inte om varken du eller jag har blivit klokare men skrivet är det dock!
Visa inlägg
Cookie policy