Ik zie de laatste tijd weer meer items van GenealogieOnline (GO) gebruikers die zich zorgen maken maken over de volgende melding op de Publicatiebeheer pagina van hun GO publicatie:

 "Controle van uw ... GEDCOM leert dat, er kans op informatieverlies is!".

Doorklikken levert op:  Waarschuwing omtrent mogelijk informatieverlies » Genealogie Online  (voor de link wel eerst inloggen als beheerder).

Dat heeft er misschien mee te maken dat steeds meer stamboomprogramma's bezig zijn om GEDCOM 7.0 te faciliteren.

Om maar met het slechte nieuws te beginnen: Het is een illusie om te denken dat u bovengenoemde melding kunt voorkomen, die melding is er altijd.

Het goede nieuws: De soep wordt nooit zo heet gegeten als ze wordt opgediend.

Na het uploaden door GO word de Gedcom eerst gecontroleerd m.b.v. GED-inline validator software. Ik heb gemerkt dat dat soms al gebeurt terwijl de job nog in de wachtrij staat om verder door GOnline verwerkt te worden.

GED-inline is een standard GEDCOM validator die niet geschreven is door GO. Daarmee bedoel ik te zeggen dat GED-inline op geen enkele manier rekening houd met de GO context. GED-inline kijkt alleen naar wat er in de betreffende GEDCOM specificatie staat. Omgekeerd heeft GO geen enkele invloed op welke tests wel en niet uitgevoerd worden.

Er zijn meer van dat soort validator programma's, zoals b.v. de Chronoplex GEDCOM Validator, die je gratis op je eigen computer kunt installeren. Die heeft voor GEDCOM 5.5.1 zelfs een keuze uit "Best practice" en "Standards Only".

De GED-inline software maakt een rapport. In de Header van dat rapport staan o.a. het aantal gevonden fouten en/of waarschuwingen. Die Header wordt door GO getoond op de Waarschuwing omtrent ...  pagina.  Onderaan die pagina een knop waarmee het volledige rapport door de GO gebruiker gedownload kan worden.

Als het aantal fouten plus het aantal waarschuwingen nul is toont GO waarschijnlijk een andere tekst dan de bovengenoemde. Welke tekst dat is weet ik niet, want ik heb nog nooit een rapport met nul fouten/waarschuwingen gezien. Zelf zou ik in dat geval ook niet durven beweren dat er geen informatie verlies is, want GEDCOM heeft zo zijn beperkingen.

Dit geeft al aan dat we waarschijnlijk e.e.a. wat moeten nuanceren.

Vooral van belang is hoe GO omgaat met eventuele tekortkomingen van de aangeleverde Gedcom. Mijn ervaring is dat Bob Coret wat dat betreft pragmatisch is en altijd probeert de bedoeling van het gebruikte stamboomprogramma te achterhalen.

Twee voorbeelden van een GED-inline waarschuwing in een 5.5.1 Gedcom:

*** Line 81:      Invalid content for FILE tag: the value is more than 30 characters, the maximum length for

*** Line 755:     Invalid content for ROLE tag: '(overleden partner)' is more than 15 characters, the maximum length for

Op regel 81 staat een pad naar een bestand met een totale lengte meer dan 30 karakters. Dat is een beperking waarvan we allemaal weten dat het echt onvoldoende is, daar dachten ze in de vorige eeuw bij het opstellen van de 5.5.1. spec. anders over. GO heeft geen enkele moeite met langere padnamen.

Dat die ROLE op regel 755 maar maximaal 15 karakters lang mag zijn is een rekenfoutje dat gemaakt is door de opstellers van de 5.5.1 spec, zie blz 61 van die spec. Er had minstens 25 moeten staan, maar ja, in de spec staat 15, dus moet GED-inline er iets van zeggen.

GO accepteert echter een ROLE die veel langer is en verwerkt die helemaal correct.

Het gaat hier om waarschuwingen, d.w.z. dat de beperkende regeltjes aanbeveling zijn. Het gaat dus niet om een echte fout.

Eén van de moderniseringen in GEDCOM 7.0 is dat veel van deze lengte beperkingen verdwenen zijn. Zelfs de CONC tag is afgeschaft omdat men er van uitgaat dat een tekst altijd op één regel past.

Nog een padnaam waarschuwing, ditmaal GEDCOM 7.0:

*** Line 200314:  Invalid content for FILE tag: 'Scholl/internet/18130208_DukenbergJ+B_Epe_ BSgebA11_FAim84.jpg' is not a valid

Er staat een spatie in deze bestandsnaam, iets dat in GEDCOM 7.0 kennelijk afgeraden wordt. In eerdere GEDCOM versies stond daarover niets en werd er dus ook niet op getest.

Vanwege dat laatste, moet GO in staat zijn om te gaan met spaties in pad en bestandsnamen ten behoeve van die eerdere GEDCOM versies.

Ik kan u verzekeren dat Bob Coret nu voor GEDCOM 7.0 een pad of bestandsnaam met een spatie er in niet gaat weigeren. Ik probeer spaties in bestandnamen altijd te vermijden, want vroeg of laat geeft dat toch vaak problemen. Dus heb ik de 2 gevallen waar ik dat over het hoofd gezien had gecorrigeerd. Als dit in uw stamboom dossier bij heel veel bestandsnamen voorkomt, is het haast niet te doen dit allemaal te corrigeren.  Maakt u zich dan geen zorgen, want GO kan er prima mee omgaan. Wel vervelend van die vele GED-inline meldingen hierdoor.

Daar is misschien ook nog iets tegen te doen.

Bij een publicatie op GO zou u zich af kunnen vragen of u alle dossier bestanden ook wilt uploaden. Persoonlijk deed ik dat nooit, maar sinds kort, alleen wat pasfoto's. In mijn stamboomprogramma GensDataPro kan ik bij het aanmaken van een Gedcom bestand kiezen uit de opties "Dossiers weglaten", "Dossiers opnemen" of "Alleen pasfoto's opnemen", waar ik dus voor het laatste kies. Als er spaties voorkomen in mijn pasfoto bestandsnamen zou ik die wel corrigeren, omdat het er niet zo veel zijn. De andere bestandsnamen uit mijn dossier komen niet in het Gedcom bestand voor en kunnen dus ook niet meer de bovengenoemde waarschuwingen veroorzaken.

 Als u in uw stamboomprogramma ook een dergelijke keuze hebt en niet van plan bent dossier bestanden te uploaden, kies dan voor "Dossiers weglaten". In dat geval verdwijnen dus alle bovengenoemde waarschuwingen in het GED-inline rapport.

Er is ook een categorie mogelijke meldingen in het GED-inline rapport waar u niets aan kunt doen als gebruiker. Die moeten opgelost worden door de makers van het door u gebruikte stamboomprogramma.

TOEVOEGING 31-12-2024:

warnings: Invalid content for FORM tag: 'jpg' is not a valid 
                Invalid content for FORM tag: 'JPG' is not a valid

Ik denk dat .jpg of .JPG niet uitmaakt, voor beiden geldt dat de FORM value in GEDCOM 7.0 niet hetzelfde is als voor 5.5.1. Dit valt overigens in de categorie die door stamboomprogramma beheerders opgelost moet worden.

Voor 7.0 is het een MediaType:  "/" , zie GEDCOM 7.0 blz 30.

Wat je ook meer ziet in de 7.0 spec is dat niet alles vastgelegd wordt in de GEDCOM spec zelf, maar dat er doorverwezen wordt naar een andere standaard, in dit geval RFC 2045,  zie Media Types.

Voor .jpg en .JPG bestanden is het Mediatype: image/jpeg, zie kolom "Template". Verder vind je daar ook "image/png",  "application/pdf", "application/msword", "text/plain", etc.

dus: x FORM image/jpeg          [die e is belangrijk]

==

Als u nog meldingen tegenkomt die het vermelden waard zijn hier, laat het dan weten. Ik zou die dan toe kunnen voegen aan dit openingsbericht voor dit item. In een vervolgbericht zal ik dan melden dat dit bericht aangepast is. Op die manier krijgen we misschien een inventarisatie van mogelijke meldingen, waar naar toe verwezen kan worden.

Bedankt Gerrit, een formele vraag: betekent dat, dat GO onze Gedcom files naar een externe partij stuurt? Ik vind het prima, maar vraag mij af of het in het kader van dataprotection mag zonder toestemming? Dit kan naar mijn weten de hele website in gevaar brengen als het bekend wordt?

Nee, GO gebruikt de software van GED-inline bij het importeren van de Gedcom. Zal dit proberen te verduidelijken in mijn openingsbericht.

Ik heb het openingsbericht aangepast om duidelijker de rol van de validator te beschrijven en om aan te geven dat het vaak om waarschuwingen gaat.

Dankjewel Gerrit voor de duidelijke toelichting op GED-inline en de hieruit volgende Warnings in GO. Zelf had ik me (nog) niet zo druk gemaakt om deze standaardmelding, zodra een GEDCOM-upload gereed was. De laatste weken ben ik daar wel mee bezig geweest (zie mijn eerdere item).

Zelf ben ik begonnen met het oplossen van de Warnings na een upload (uit Aldfaer) van GEDCOM versie 5.5.1. Bijna alle meldingen opgelost, met uitzondering van:
- Invalid content for FILE tag: the value is more than 30 characters, the maximum length for <MULTIMEDIA_FILE_REFERENCE>
- Invalid content for OCCU tag: the value is more than 90 characters, the maximum length for <OCCUPATION>
- Invalid content for FACT tag: '' missing value for <ATTRIBUTE_DESCRIPTOR>

Alle drie de meldingen komen niet voor, zodra ik een GEDCOM versie 7.0 upload. Voor de eerste 2 vind ik dat ook logisch, gezien jouw opmerking aangaande de lengte van teksten. De 3de foutmelding kan ik nog niet achterhalen. De betreffende FACT tag gebruik ik bij meerdere personen, alleen bij een 3-tal personen krijg ik de Warning.

Na het uploaden van een GEDCOM versie 7.0 krijg ik alleen Warnings op afbeeldingen, namelijk:
- 1544 warnings op spaties in een bestandsnaam, zoals Invalid content for FILE tag: '1903-07-31 Antonius Aker.jpg' is not a valid <g7:FILE>
- 5 warnings: Invalid content for FORM tag: 'jpg' is not a valid <g7:FORM>
- 5 warnings: Invalid content for FORM tag: 'JPG' is not a valid <g7:FORM>

Het verwijderen van de spaties wordt een hele klus (als ik dat zou overwegen). De 2de warning moet ik nog onderzoeken. Misschien moet ik de betreffende afbeelding eens opnieuw uploaden. Mijn conclusie bij de laatste warning is dat de extentie van een bestandsnaam blijkbaar niet met hoofdletters mag. Vreemd.

Fijne Jaarwisseling.

Bepaal jij zelf of je die FACT tag gebruikt, of ben je een stamboomprogramma ontwikkelaar ?

Wat betreft de .jpg FORM heb ik iets onderaan toegevoegd in mijn openingsbijdrage.

Als je heel veel bestandsnamen met en spatie hebt zou ik in jouw plaats mijn tijd liever aan genealogie besteden.

Ook een fijne jaarwisseling gewenst allemaal.

Ik heb gemerkt dat het controleren van de Gedcom door de GED-inline software al gebeurt terwijl de job nog in de wachtrij staat om verder door GOnline verwerkt te worden.

Heb het startbericht dienovereenkomstig aangepast.