Until now, child records such as life events of a person or components of a structure, context, artefact, transaction or work, required the use of a pointer back to the parent in order to include data from the parent in the title of the record (eg. the person’s name in their life event records). We have used that method successfully in several published databases, both archaeological and historical. However, there was no mechanism to ensure that a child record could not be accidentally attached to or switched to the wrong parent.<\/p>\n

The latest update of Heurist allows a record pointer field to be designated as a child record pointer simply by checking a box when creating (or modifying) the field. Any record pointer field so-marked will create a new record which is inherently identified as a child of the current record. The parent is shown when editing the record (as shown above) and fields from the parent are automatically available for use in the constructed record title. Once a child record has been created, it cannot be accidentally changed to a new parent.<\/p>\n

Child record pointers allow one to define records which are inherently part of, or owned by another record. This is useful for recording components, such as scenes and motifs in art panels, events in a person’s life, or variant subsets of attributes describing an artefact. It provides a cleaner generic method for modeling these structures compared to existing methods used in some archaeological and prosopographic databases.<\/p>\n

When to use<\/strong><\/p>\n

The main question to ask before defining a child record is the following:\u00a0 Can this related record exist on its own, without the parent record? If the answer is yes, then the related record is Not a child record. The child record has to be dependent on the parent record, recording further information about\/relating specifically to the parent record. An example of this would be a life event, such as the coronation of a king. In the example below, the coronation of King Richard III (an historic event linked to the Shakespearean play, Richard III and a life event of Richard of Gloucester) is shown. Any king or queen can have a coronation, and many in England were crowned at Westminster Abbey, however, only Richard of Gloucester was crowned on 6 July, 1483, at Westminster Abbey in London. That combination of who, where and when is unique and relates purely to King Richard III. Thus the coronation as a life event is a child record of Richard of Gloucester. Many other people can, of course, be linked to this event as participants (or have life events which specify participation in this event).<\/p>\n

<\/a><\/p>\n

You can see from the image above that the record of Richard III’s coronation not only lists the parent record in the title: “Gloucester, Richard of : Coronation 6 July 1483 @ London” along with the date and place of the event, but also has a link to the Parent record: “Gloucester, Richard of” in the first line of the record display. This field is generated automatically when the child record is created. The parent record also appears in the Linked From area for linked records at the bottom of the display.<\/p>\n

<\/a>
\nSetting child record pointers<\/strong><\/p>\n

To create child records, choose “Record Pointer” as the field type and then check the box next to the text “Create new records as children” in the edit screen of the pointer field (see above). This will add “(child)” underneath the words “Record pointer” in the Data type listing for the field. When entering data, the edit screen will show\u00a0<\/a>\u00a0instead of the usual\u00a0<\/a>\u00a0to add a Pointer record. You have a choice of adding a new record, which becomes the child record, or selecting an existing record, which will make the existing record a child record (this might be needed if child records have been imported in bulk). It is most likely, and highly recommended, that you create new records to be the child records, and we make sure you can’t allocate existing records by accident. You will then be given the usual add data screen, with an additional required (but already populated, and non-editable) field at the top of the screen showing the parent record (see first image).<\/p>\n<\/span>","protected":false},"excerpt":{"rendered":"

Until now, child records such as life events of a person or components of a structure, context, artefact, transaction or work, required the use of a pointer back to the […]<\/p>\n","protected":false},"author":6,"featured_media":5969,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[23],"tags":[32,36,48,35,33,49,34,47],"yoast_head":"\n