Main element types in GenXML
- file - The file structure is the very first structure of the GenXML-file. This tells the parser which version of the GenXML format the file uses and at what level it is.
- header - The header structure includes information about the system that created the GenXML file, and about the owner of the database.
- repository - The repository structure represents a repository of sources, like a library or a public record office.
- source - The source structure represents a book, a collection of documents, or similar. It may be printed, hand-written, in electronic form, or on microfilm/-fiche.
- excerpt - The excerpt structure represents a single excerpt (like “John was the third son of Robert” or “John was 64 years old in 1759”) extracted from a source.
- eventtype - The eventtype represents a certain event type (such as marriage, birth, retirement), user defined or application defined.
The description field makes event types language dependant. It may seem a drawback that the event types can't easily be translated from a language to another. But event types may be quite different in different cultures, and an automatic translation may not retain the correct meaning. It is therefore important to understand that the event types is a part of the database as well as other genealogical data, and the database can only be translated by a qualified person. - person - The person structure represents a single individual. If, however, there are two persons, each with their own data, that may be the same individual, there may be created a third person that, through the subpersons substructure, combines the two persons into one. If it is certain that the two person records really represents the same individual, they should be merged into one instead of using the subpersons structure. Note that no data except a name may be connected to a person record using the subpersons structure.
- place - The place structure represents a place where some event happened. It is not intended for postal addresses.
- assertion - The assertion represents a piece of conclusional data for a person, such as the birth date, hair color or relationships.
- objective - The objective structure represents a research objective. A research objective consists of one or more research tasks. The research objective is split into one task for each affected person.
- task - The task structure represents a research task. A research task may be related to a specific person, and to a specific source. It may (and should) also be part of a research objective.
- total - The TOTAL structure is always the last one in the file and must always be included. The purpose is to tell the importing program how many structures that should have been imported.
Definitions of elements
<repository>
attributes: (id, lang?)
content: (name, address?, email?, uri?, note?, change?, ext*)
</repository>
<source>
attributes: (id, class?, kind?, media?, lang?)
content: (author, title, shorttitle, published?, (isbn | issn)?, (repositoryref* | sourceref)?, template?, sourname*, place*, object*, note?, change?, ext*)
</source>
<excerpt>
attributes: (id, lang?)
content: (text?, quality?, page?, sourceref, level?, note?, change?, ext*)
</excerpt>
<eventtype>
attributes: (id, class, active?, lang?)
content : (description, gedcomtag ?, roles ?, principalfmt ?, withnessfmt ?, print ?, note ?, ext*)
</eventtype>
<person>
attributes: (id, sex, lang?)
content: (personalname, (subpersons | (excerptref*, object*) ), note?, change?, ext*)
</person>
<place id?>
attribute: (id?, tp?, lang?)
content: ( prefix?, name, place*, alias?, date?, cords?, ext* )
</place>
<assertion>
attributes: ( id, datatype?, lang? )
content: ( (alias | relationship | attribute | event | info),
(excerptref* | (assertionref, assertionref) ), object*, note?, change?, ext*)
</assertion>
General Substructures
- Stringlang - General string with language attribute.
- Normstringlang - General normalized string with language attribute.
- Object - Objects represents a file. An object may be included as a reference to an external file or completely included in the GenXML file.
- Address - The address structure represents an postal address of something, someone or where something happened. It is formatted as it would be for example on a mailing label.
- Personalname - The personalname structure records the name of a person. The structure is used for two purposes:
1. In the person structure for storing the name used to identify the person in the database.
2. In the alias structure for storing the name found in a source. In many cultures in may be useful to normalize the name, while storing the name exactly as found in the source in the referred excerpt structure.
The name is split into name parts. - Coords - This structure holds the geographical coordinates of a place name.
- Date - The date structure represents a specific date (known or unknown) when something happened, or it may represent a period of time.
Note that the original date phrase belongs in the excerpt structure. The date structure holds the dates that are to be presented in reports. - Simpledate - Simpledate represents a single date. The format of the date itself is based on the XML Schema Specification‟s dateTime datatype. Please note that the time zone part of dateTime is not a part of simpledate. The reason for this is that in an GenXML event, the time zone is defined by the recorded place. If the place is unknown, so is the time zone.
Substructures of the Person Structure
- Subpersons - The subpersons structure is used for combining two (and only two) persons that probably (but not necessarily) were the same individual. For more information, see the person structure.
Substructures of the Assertion Structure
- Alias - The alias structure stores a name of a person as found in a source. The user may want to normalize it, though, and refer to an excerpt (from the encapsulating assertion structure) with the exact spelling.
- Relationship - The relationship structure represents a parent-child relationship. The father-child and mother-child relationships may (and should if both relationships come from the same source) be combined into a single relationship structure.
Note that GenXML does not guarantee the match between selected father/mother tag and their recorded sex, as this depends on the user who entered the data and the application which accepted the data. - Attribute - The attribute structure represents an attribute or characteristic of a person. As opposed to events, attributes typically take place over a period of time. However, the most important difference between events and attributes is that attributes have a text of some sort. For example the attribute “hair colour” will need to store the actual hair colour, and the attribute “education” will need to store the kind of education and school.
- Event - The event structure represents an event in the life of one or more persons. An event is something that happened at a certain moment – a certain day. There are however a few exceptions, like residence.
The event may include many participants that have different roles in the event, principal or subordinate. In some events, for example the invasion of Normandy 5. June 1944, there are a very large number of principal participants. (In such “group”-events, talking of subordinate participants has little meaning.)
All events have at least one principal participant. However in some cases the principal participant may be unknown. Therefore the principal field is not mandatory.
Note that although the parents of a child do have a subordinate role in the birth event of the child, the parent-child relationship should not be recorded using this mechanism. Instead use the relationship structure. - Info - The info structure represents general information that does not fit well into other assertion structures.
- Personref - The personref structure represents a link between an assertion and a person. A sequential number may be supplied. This states the sequence of assertions for a person. The number should be unique for each person, but it is not required. The sequence of assertions with equal sequential numbers for the same person, must be regarded as not specified.
- PersonrefRole - The personrefrole structure is a pointer to a person that has a subordinate role in the event of which personrefrole is a subject.
person - The person structure represents a single individual. If, however, there are two persons, each with their own data, that may be the same individual, there may be created a third person that, through the subpersons substructure, combines the two persons into one. If it is certain that the two person records really represents the same individual, they should be merged into one instead of using the subpersons structure. Note that no data except a name may be connected to a person record using the subpersons structure.
Why is this so complicated?
person - The person structure represents a single individual
That person would have attributes and relationships. The sending and receiving application should be able to do the rest.
What am I missing?
Thank you,
Russ
If this is a better way than what Tom proposes (i.e. constructing a tree of <person> elements), I have no clue.
When Christoffer drops by, I hope we'll know more.
I have however not implemented this so far. Possibly there are better ways of handling such situations, but a simple merge may actually add information without evidence.
Regards,
Christoffer
a. are all person in the outline navi area the same as all these shadow persons which are almost duplicates.
b. or the persons in the outline navi area same the same, while there is another area where these shadows of people dont interfear? then when you make your final choice you turn the evidence records to point at the real person.
c. either a or b, you will never really delete any shadow people of real people to hold your research path as a documented reminder how you did it letting all the extra shadow people records stay there as a place marker?
I have seen a few message where a person coined is at times used in two seprated area functions with records, or it just sounded like that. I know you can do it both ways but maybe that would clear it up if one would answer it. People think the shadow person merged into a real person place marker can cuase record damage. when you have three types of birth evidence and each date may be off by a day or week.
I am use to old school merge where they force you to choose a record and write over an evidence record, then you only have 1 out of two records left.
What is unclear to me is exactly what a subperson is, as you have not yet defined on your model page. Is it a substructure that fits inside the person structure, or is it a another whole person structure that the first person structure points to? I believe you mean the former just by the words, but it would be good to know for sure.
I also wonder why you only want there to be two subpersons? What's wrong with many? For example, I have found my great-great grandfather in a series of city directories over a span of about 20 years. I want to keep all of those 20 evidence persons and I'd like to put them all together at once as part of a conclusion person.
I find it interesting that you support both a destructive merge and a non-destructive one. In a destructive merge, how do you keep the sources for the various sub-parts of the merged person straight. For example, if the birth event came from one source, occupation from another, residence from another. I assume you can put a source pointer into your records at any point to handle this? That is also the GEDCOM way which does work when supported.
Tom Wetmore