Gendatam - Model Description Model Revision Date: 1st March 2005 Model First Publication Date: 25th September 2002 This Document published: 1st March 2005 Revised 31st December 2007 Copyright (c)2002-2007 Graywork Products Ltd All Rights Reserved Author: Peter J. Seymour, Graywork Products Ltd Email: gdm@gendatam.com (plain-text is preferred) -------------------------------------------------------------------------- PENDING CHANGES - GROUP has so far only be implemented for PERSON and COUPLE. -------------------------------------------------------------------------- CHANGES Revision 15 2008-02-08 IDNUMBER record type introduced Revision 14 2008-01-16 NOTES merged into EVIDENCE GLOBAL records renames as plain (eg. EVENT) PRIVATE records renamed as ..... ASSERTION Revision 13 2007-12-31 MEDICAL now integrated with PERSON Revision 12 2007-07-19 ARCHIVE no longer refers to GLOBAL ADDRESS. This removes the possibility of recursive linkage. Revision 11 NOTES and MEDICAL NOTES objects added. Revision 10 Computer File Object added. Work Log Object renamed to Task. -------------------------------------------------------------------------- TABLE OF CONTENTS 1. Purpose 2. Intention 3. Overview 4. The Objects 5. A Diagram of the Model 6. Permitted Linkages between Objects 7. Permitted Independent Objects 8. Limitations 1. PURPOSE The purpose of this document is to describe the structure of the Gendatam model in terms of the contained objects. It supersedes descriptions previously published elsewhere under the title 'A Data Model for Genealogical Programs'. 2. INTENTION It is intended that the model will be usable on any computing platform (operating system or hardware). In case of need, it should also be maintainable in paper form. 3. OVERVIEW 3.1 GENERAL SCHEME The Data Model envisages discrete collections of data fields which collections it regards as 'objects'. A number of different types of object are defined, each identified by a specific 'type' value. Each object has a 'key' field which contains a unique value. This provides a means of reference. To provide a usable database, objects may be linked via their key fields. The resultant database consists of a network of objects that can be traversed in a variety of ways. The database is not just 'lineage-linked' or 'event-linked', but includes these modes and many more. A collection of objects is stored on an external medium as a 'file' and accessed internally to the implementing product as a 'database'. The difference is one of usage - a file simply provides a permanent data store, a database provides a means amongst other things of directly accessing particular fields. In the simple case where the external file is used just to provide a permanant store, the file may consist of many 'lines' or 'records' containing plain text delimited by one of the standard line terminator schemes. Whether the whole file is held in main memory for processing is an implementation issue. In more sophisticated arrangements, this external file may be part of the database mechanism and its contents then depend on the format of the database. In this latter case, the plain text file should still be available as an option. An 'instance' is a particular occurrence of an object. An 'entity' is some sort of real-life basis for an object. The word 'data' is considered to be indeterminate and is treated as singular. The word could refer to zero, one, many, or an unknown number of items. A 'link' is established when each of two objects stores the key value of the other object in an appropriate field within itself. This storing of a field value means that the link representation is the same on an external file as used internally by the database during execution of the program. The context determines now many links a particular object may establish. 'Multi-way' nodes consisting of many links will be commonplace. An 'implementation' is a family history or other computer program that uses the data model. An 'implementation data model' is the data model as used by an implementation. The implementation data model cannot add any features to the data model. It may omit any not required. An 'attribute' describes some aspect of an object and is broadly equivalent to a data field. In some cases it might correspond to a collection of fields, depending on complexity. 3.2 ENTITIES 3.2.1 There are four real-life types of entity forming the basis of the data model. 3.2.1.1 An individual person, who must in principle exist or have existed, even if little is known about the person. 3.2.1.2 An historical event, in principle occurring on a particular date although there may be an underlying event that occurs over a period of time. For example, consider a presentation (the event) given at some conference (the underlying event). 3.2.1.3 A physical item considered to be relevant in that it may help define or identify a person, event or other item. In the data model this entity is used in a way that corresponds with 'address'. 3.2.1.4 An item providing evidence concerning an instance of one of the other entity types. The item must in principle be an actual physical item, but may in practice only be known via mention elsewhere (such as in an index). 4. OBJECTS 4.1 PRINCIPAL OBJECTS These are the two principal objects - Person and Couple. An outline family tree could be constructed from just these two types of object as they represent sufficient direct linkage for that purpose. The only relationships recorded are Partner, Parent and Offspring (and also twins etc). Other relationships must be deduced when needed. 4.1.1 PERSON Data relating to an individual person. Much of the data consists of links to other objects. 4.1.2 COUPLE Data relating to a nuclear family group logically headed by two PERSONS acting as partners in the COUPLE. The emphasis is on 'couple' rather than 'family' as some people have multiple partners during their life. This complicates the definition of family, whereas a 'couple' is always simply defined. Much of the data consists of links to other objects. 4.2 PERSON PRIVATE OBJECTS 'Person Private' means that these are only accessible from PERSON Objects. To minimise ambiguity or confusion, each instance relates solely to a particular PERSON instance. These objects record attributes for the owning Person object. It is incorrect to regard them as 'event' objects. 4.2.1 PARENTAGE Data relating to the type of parentage separately provided by the partners in the referenced parent Couple. 4.2.2 NAMING Data relating to a person's name. In practice there is no actual NAMING object type. It is sub-classed for implementation as: TITLE FORENAME SURNAME 4.2.3 CULTURE Data relating to a person's historical social/cultural setting. In practice there is no actual CULTURE object type. It is sub-classed for implementation as: NATIONALITY RELIGION 4.2.4 OCCUPATION Data relating to how a person's time was spent, not just regarding paid employment, but in any respect. At least implicit in this, there may be an indication of the person's abilities and interests. In practice there is no actual OCCUPATION object type. It is sub-classed for implementation as: EDUCATION EMPLOYMENT Employment may refer to paid or unpaid time spent. 4.2.5 IDNUMBER Data relating to identity numbers (officially) issued to a person. 4.3 GLOBAL OBJECTS So called because they are accessible by any otherwise un-related object via the link mechanism. 4.3.1 EVENT Data relating to an historical event. In general, an event will have a timespan of less than one day (but does not have to). It is important to note that 'attributes' as contained in Person Private objects are not considered to be 'events'. 4.3.2 ADDRESS Data relating to either a) a physical location (such as a house) or b) a means of contact (such as a telephone number). 'Address' may be thought of as a simple attribute of something other than a person, but linked to that person in some way. For instance, a telephone number is not an attribute of a person, but an attribute of a telephone that that person has (possibly exclusive) access to. 4.3.3 EVIDENCE Data providing a source of and justification for other objects defined in the file. 4.3.4 GROUP This object provides a means of forming arbitrary groups of objects. The usage is very flexible and is largely defined by the user. Note that it is not used for defining families as a specific mechanism is provided for this (via the PERSON, COUPLE and PARENTAGE objects). 4.4 PRIVATE DATA OBJECTS So called because they contain 'private' data, data that belongs specifically with the owning object (i.e. the linked object next highest in the diagram below) rather than the linked-to global object. They are used as an intermediate or bridging object when linking a global object to another object. They contain data which, in the context of the owning object, assert the relationship between the linked objects. This data could be, for instance, a role in an EVENT or a date range for an ADDRESS. Private objects also provide a means of asserting the relevance of the global object to the parent object it is linked to via the private object. Each of the four Global objects has an equivalent Private Data object. - EVENT - ADDRESS - EVIDENCE - GROUP 4.5 SPECIAL EVENTS These do not exist as separate object types, jut as plain EVENT objects. Person and Couple objects may have 'special' event links defined which each point to a member of the object's Private Event list. For Person, these special links are for Birth, Death and Burial. For Couple, only Marriage is defined (Birth is considered an attribute of the person, not the couple). Note that the Couple object holds various attributes including end date and end reason, and this enables the type of relationship (married etc) and conditions such as divorce to be recorded. The point of 'special' event links is that it may be useful to display these events in a different manner or context to other events. 4.6 EVIDENCE PRIVATE OBJECTS 4.6.1 ARCHIVE Data relating to a location of items forming the basis of global evidence objects. Often, many evidence items will reside in the same location or archive. Note therefore that ARCHIVE objects are accessible to any number of EVIDENCE objects. 4.6.2 COMPUTER FILE Holds data relating to a computer file referenced by an EVIDENCE object (but does not embed the file itself). 4.7 MISCELLANEOUS OBJECTS These are supplementary objects, providing an implementation convenience. 4.7.1 FILE HOUSEKEEPING May contain items such as file specification version, date file last updated etc. File Housekeeping is strictly for file attributes. 'User' attributes, such as certain currently selected IDs should be held in a separate user properties file. 4.7.2 TASK Provides a record of work tasks relating to the file. This object is provided as a convenience to the user. TASK records may be linked to by any record (with some exceptions - clarify). 5. A DIAGRAM OF THE MODEL 5.1 A hierarchical structure of the model is shown below. The diagram presents the structure as centred on PERSON and COUPLE and relying ultimately on EVIDENCE. The hierarchy is not a strictly correct view of the data model as the structure is really a network, not a hierarchy. However, this hierarchical view serves to show the main relationships between objects. The logical flow of the diagram is from the top downwards. FILE | +----------+--------------------+ | | | FILE HDR TASK | | +---------+----------------------+ | | | | /|\ /|\ PERSON->-----------------------<-COUPLE | | | | | | | +----+ +-------------------+ | | | | | | | | /|\ /|\ | | | PARENTAGE | | | | | +--------+--------+--------+ +-----|-----+--------------+-----+---+ | | | | | | | | /|\ /|\ /|\ /|\ | /|\ /|\ | NAMING IDNUMBER CULTURE OCCUPATION | PRIVATE PRIVATE | | | | | | ADDRESS EVENT | | | | | | \|/ | \|/ | | | | | | | | | | | | | | | | | | +----------|--+-------+ | | | | | | | | | | | | | | | | | | | | | | EVENT | | | | | | | | | | | | | +--------|----+------------+ | | | | | | | | | | | | | | | | | | | | ADDRESS | | | | | | | | | +--------+--------+-------+---------+----+---------------+---------+ | /|\ PRIVATE EVIDENCE ...+... \|/ | | | | PRIVATE EVIDENCE GROUP \|/ \|/ | | +----------+---------+ | | /|\ GROUP ARCHIVE COMPUTER : FILE : 5.2 Notes 5.2.1 In the diagram, the combination '/|\' (signifying diverging) means that the upper object may reference many instances of the lower object. 5.2.2 The combination '\|/' (signifying converging) means that the lower object may be referenced by many instances of the upper object. 5.2.3 The use of '->-' and '-<-' means that the object pointed to may be referenced by the pointing object. 5.2.4 Also, '+' ('plus' sign) means that the associated lines connect, while '-|-' ('minus', 'vertical bar', 'minus') means the lines crossover without a connection. 5.2.5 PERSON and COUPLE are considered to be on the same hierarchical level. They can directly link to each other via a couple or partner link. 5.2.6 Note that parent/child links are via PARENTAGE. 5.2.7 For simplicity, Special Events are not shown. 5.2.8 (deleted). 5.2.9 OCCUPATION and EVENT link directly to ADDRESS without an intervening PRIVATE ADDRESS object. This is because they are considered to contain data that is equivalent to that held in a PRIVATE ADDRESS object and so the requirement is treated implicitly. 5.2.10 An OCCUPATION or EVENT is allowed at most a single ADDRESS. That address, as a global address, can of course be linked to by other objects. 5.2.11 While for simplicity PRIVATE EVIDENCE is shown in a consolidated branch, remember that an instance of a private object is linked to by just one object. 5.2.12 An EVIDENCE object can link to only one ARCHIVE object. This is because a physical object can only be in one place. Where different copies of evidence material are held in multiple archives, each copy must be recorded as a separate evidence object. 5.2.13 Conversely, an ARCHIVE object may be linked to by any number of EVIDENCE objects, because it may contain many such objects. 5.2.14 For simplicity, the metadata objects PRIVATE GROUP and GROUP are shown disembodied as they can link in at various points on the diagram. Note that they may each refer on to EVIDENCE/ARCHIVE sequences in the same way as other objects. 5.2.15 For simplicity, the possible linkages to TASK objects are not shown. 5.2.16 Although shown in the diagram at the same level, linked PERSON and COUPLE objects are permitted to refer to each others object trees. 6. PERMITTED LINKAGES BETWEEN OBJECTS Linkages are always bi-directional. This section refers mainly to what might be termed 'forward' links. The wording 'may link' indicates that this is optional. 6.1 Miscellaneous 6.1.1 FILE HOUSEKEEPING: This object type does not link to any other. 6.1.2 TASK: This object type does not link to any other. 6.2 Main Objects In addition to what is stated below, all objects may link to PRIVATE GROUP. 6.2.1 PERSON: may link to any of: PARENTAGE (as child) NAMING CULTURE OCCUPATION IDNMBER COUPLE (as partner) PRIVATE ADDRESS PRIVATE EVENT PRIVATE EVIDENCE PRIVATE GROUP 6.2.2 COUPLE: may link to any of: PERSON (as partner) PARENTAGE (as parent COUPLE) PRIVATE ADDRESS PRIVATE EVENT PRIVATE EVIDENCE PRIVATE GROUP 6.3 Person Private Objects 6.3.1 PARENTAGE may link to: COUPLE (PERSON as CHILD) PRIVATE EVIDENCE 6.3.2 NAMING/IDNUMBER/CULTURE may link to: PRIVATE EVIDENCE 6.3.3 OCCUPATION may link to one or both of: ADDRESS PRIVATE EVIDENCE 6.4 Global Objects - ADDRESS: may link to PRIVATE EVIDENCE and PRIVATE GROUP - EVENT: may link to PRIVATE EVIDENCE, PRIVATE GROUP and ADDRESS - GROUP: may link to PRIVATE EVIDENCE - EVIDENCE: may link to ARCHIVE and PRIVATE GROUP 6.5 Private Data Objects While Private Data objects cannot exist independently, they may exist just linked to the owner object and not have an on-going link to a global object. Private Data Objects may link to: - PRIVATE EVIDENCE (unless they themselves are Private Evidence) - GLOBAL Objects of the same type (eg Private Address may link to Address) 6.6 EVIDENCE Private Objects 6.6.1 ARCHIVE: No forward links (other than private GROUP). 6.6.2 COMPUTER FILE: No forward links (other than private GROUP). 7. PERMITTED INDEPENDENT OBJECTS 'Independent' means capable of existing without any link to another object. 7.1 FILE HOUSEKEEPING and TASK are of their nature standalone and so are always independent. 7.2 PERSON may exist as an independent object. 7.3 COUPLE may exist as an independent object, but there is little point because an independent COUPLE object would contain no useful data. An implementation is be allowed to automatically delete any COUPLE object becoming independent. 7.4 The global objects may exist independently: EVENT, ADDRESS, EVIDENCE, GROUP 7.5 ARCHIVE may exist as an independent object. 7.6 COMPUTER FILE may exist as an independent object. 7.7 Private objects may not exist independently and require at least an owner (i.e. a next highest object as show in the above diagram). 8. LIMITATIONS This model was developed from a UK/English perspective. It may not cater for all cultural situations.