How strictly does FH follow the gedcom 5.5
Posted: 16 Nov 2002 20:50
Date: Mon, 19 Aug 2002 10:31:10 +0100
Jim Winfrey ask how strictly FH follows the gedcom 5.5 definition.
Family Historian supports all GEDCOM 5.5 'tags' in all occurrences of use (this is what we mean when we talk about F.H. being '100% GEDCOM complete'). A 'tag', in GEDCOM terms, represents an item of data - what, in a database context, would be called a field. SEX, for example, would be a GEDCOM tag, used to store a person's sex.
GEDCOM tags form a hierarchy. A tag can have qualifying tags. These in turn can have qualifying tags too. Sometimes these form a recursive 'loop'. Every SOUR (source) tag, for example, can be qualified by a NOTE (note) tag, and every NOTE tag can be qualified by a SOUR tag, and so on forever. Family Historian can even fully support recursive tags like these.
GEDCOM also allows other applications to provide their own extensions to GEDCOM and make up their own tags, and many applications (including Family Historian) do this. Application-extension tags always begin with an underscore. Family Historian will load all application-extension tags (its own and others), but it will treat any application-extension tags that it doesn't recognise (ie. all of them except its own) as text fields. This may mean that you can't do anything very useful with them if they weren't designed to be used as text fields.
Family Historian will also load any tags with invalid tag names - that is, tags which do not exist in GEDCOM 5.5 (e.g. EMAIL), or tags which do exist but are not allowed to occur in the context in which they are being used (e.g. SEX is a valid tag, but not as a qualifier for the NOTE field). Again, in these cases, F.H. will load the tags but it will treat them as text fields. Tags that Family Historian doesn't recognise have a little 'sunburst' icon next to them - like an ordinary (circle) field icon, but with things that look like sun rays emanating from the circle.
Family Historian sometimes will refuse to load a tag that it *does* recognise but which has been used in an invalid way. One example that has cropped up is where another application invalidly puts text after a tag where the GEDCOM definition does not allow that. By loading invalid tag names, Family Historian is already pretty tolerant of invalid GEDCOM. In the future, though, we will be looking at ways of making Family Historian even more tolerant, to make it as easy as possible to transfer data into Family Historian, even from applications that make mistakes when they generate their GEDCOM (which unfortunately is not uncommon).
Jim Winfrey asks:
>> some genealogy programs allow the user to set up non-gedcom event names. Will FH read these special events and, if so, how will it handle them? If not, will it simply ignore this information or does it put it in Notes or some other place in the database?
GEDCOM actually includes support for custom events. Applications can allow their users to specify their own custom event names, without having to create any new GEDCOM tags at all. So, in this sense, custom event names are not necessarily 'non-gedcom'. Where another application uses the GEDCOM mechanism for defining custom event names (without errors!), you should see these custom events transferred into Family Historian with no problems, and be treated like any other custom event that you might have created in Family Historian (i.e. basically like any standard event). The events should appear as events, dates should be dates, places should be places, etc. If the other application uses some other mechanism for defining custom events (unlikely - why should it when GEDCOM lets you specify custom events?) such as adding its own application extensions, Family Historian will still load these, but it won't know what they are.
Simon Orde List Administrator and Family Historian designer
Jim Winfrey ask how strictly FH follows the gedcom 5.5 definition.
Family Historian supports all GEDCOM 5.5 'tags' in all occurrences of use (this is what we mean when we talk about F.H. being '100% GEDCOM complete'). A 'tag', in GEDCOM terms, represents an item of data - what, in a database context, would be called a field. SEX, for example, would be a GEDCOM tag, used to store a person's sex.
GEDCOM tags form a hierarchy. A tag can have qualifying tags. These in turn can have qualifying tags too. Sometimes these form a recursive 'loop'. Every SOUR (source) tag, for example, can be qualified by a NOTE (note) tag, and every NOTE tag can be qualified by a SOUR tag, and so on forever. Family Historian can even fully support recursive tags like these.
GEDCOM also allows other applications to provide their own extensions to GEDCOM and make up their own tags, and many applications (including Family Historian) do this. Application-extension tags always begin with an underscore. Family Historian will load all application-extension tags (its own and others), but it will treat any application-extension tags that it doesn't recognise (ie. all of them except its own) as text fields. This may mean that you can't do anything very useful with them if they weren't designed to be used as text fields.
Family Historian will also load any tags with invalid tag names - that is, tags which do not exist in GEDCOM 5.5 (e.g. EMAIL), or tags which do exist but are not allowed to occur in the context in which they are being used (e.g. SEX is a valid tag, but not as a qualifier for the NOTE field). Again, in these cases, F.H. will load the tags but it will treat them as text fields. Tags that Family Historian doesn't recognise have a little 'sunburst' icon next to them - like an ordinary (circle) field icon, but with things that look like sun rays emanating from the circle.
Family Historian sometimes will refuse to load a tag that it *does* recognise but which has been used in an invalid way. One example that has cropped up is where another application invalidly puts text after a tag where the GEDCOM definition does not allow that. By loading invalid tag names, Family Historian is already pretty tolerant of invalid GEDCOM. In the future, though, we will be looking at ways of making Family Historian even more tolerant, to make it as easy as possible to transfer data into Family Historian, even from applications that make mistakes when they generate their GEDCOM (which unfortunately is not uncommon).
Jim Winfrey asks:
>> some genealogy programs allow the user to set up non-gedcom event names. Will FH read these special events and, if so, how will it handle them? If not, will it simply ignore this information or does it put it in Notes or some other place in the database?
GEDCOM actually includes support for custom events. Applications can allow their users to specify their own custom event names, without having to create any new GEDCOM tags at all. So, in this sense, custom event names are not necessarily 'non-gedcom'. Where another application uses the GEDCOM mechanism for defining custom event names (without errors!), you should see these custom events transferred into Family Historian with no problems, and be treated like any other custom event that you might have created in Family Historian (i.e. basically like any standard event). The events should appear as events, dates should be dates, places should be places, etc. If the other application uses some other mechanism for defining custom events (unlikely - why should it when GEDCOM lets you specify custom events?) such as adding its own application extensions, Family Historian will still load these, but it won't know what they are.
Simon Orde List Administrator and Family Historian designer