Terms Lists

A 'term list' is a set of predefined 'enumerated' values in a dropdown menu. Term lists may be used for any form of classification or categorisation of preconfigured data, such as raw material, condition, period, religious affiliation, language, country etc. For example, a Language dropdown might include English (term), French (term), Italian (term) etc. Use term lists where the list is relatively static and the categories do not exist as separate records in the database (in which case use record pointers).

Terms for a term list are stored in a set of vocabularies, which you can manage via Manage / Structure / Manage Terms. A 'vocabulary is the underlying complete set of common terms. Heurist provides a default set of vocabularies. For example: Language, Organisation Type, Discipline etc. Vocabularies can have nested ('tree') sub-vocabularies. The lowest level values are the terms. You can edit the existing vocabularies and add your own (see Terms).

When creating a term list, you can choose the underlying vocabulary, as well as adding a new vocabulary or adding individual terms (your definition of a term can include a label, a code (for standard codes such as three letter country indicators) and a URL (e.g. pointing to a semantic definition).

Record Pointers and Relationship Markers

A powerful feature of Heurist is the ability to relate or link records together to connect your data in a meaningful way without the complexity one might be familiar with in relational systems.

Note. The convention in Heurist is to use  > & < to indicate pointers and >> & << to indicate relationships.

While relationships are immediately available between ANY record types, Heurist also provides two methods for embedding connections directly in the records so that they appear contextualised in the data entry form:

Record Pointer fields

Record pointers are a way of embedding a 'concrete' link within a record type to another record type. These are used to include or link to data about objects which have their own set of complex attributes such as a person, a site or a book.

Relationship Marker fields

A relationship marker is a separate record that links two records together, regardless of type. All relationship details are stored in the relationship record itself, which has two fields that point to the source record of the relationship and the target record.

Both pointer and relationship marker fields can constrain the types of relationship which can be created (e.g. one might constrain a relationship from a person to another person and only allow genealogical relationships; this stops a person being the father of a building or the author of another person). These are very powerful tools for setting up a well-structured database which can be sliced and diced in flexible ways.

(See below for details of the differences between record pointers and relationship markers and When to use a pointer and when a relationship.)

Record Pointer Fields 

A record pointer is a field within a record that defines or references a one-way link to one or more specific record types.

For example, a Journal Article record type might have a pointer to the Journal Volume record type. This enables the article data (article title, author, etc.) to be linked to the journal data (journal title, volume, number, etc.) at the time of the Journal Article record creation. 

Pointers are not formally expressed relationships (as are the relationship records with a Relationship Marker type). They are a means of ensuring that meaningful links to other records (with relevant information contained in the record) are created. 

Restrained versus unconstrained. Pointer fields can be constrained so you can only select a record of a particular type (or types) to help maintain the quality of data entry. Typical uses might include specifying the excavator(s) of a context−necessarily Persons−or sample bag belonging to a context−necessarily a Context. Pointers can also be unconstrained ('untyped pointers') in cases where you don't know in advance what type of record might be referenced; these can then be connected by the user to any record type.

Similar to term lists, pointers allow a field to be populated from a controlled list, but in this case the list is all records in the database of a particular type, or types. This effectively ‘embeds’ all the information from the chosen record in your current record (but it is only stored once, however often it is ‘embedded’).

Typically, record pointers are used when there is a specific known relationship. For example, to identify people (authors, owners, actors), multimedia items (pdf, images, video), events, places, organisations etc. with specific relationships to a record. Using pointers saves typing, reduces data entry errors, and ensures a continuous connection between records that share the same source material (e.g. authors, books, publishers etc.).

Example

Record pointers can define relationships between heterogeneous records (e.g. event with person, building with date etc.). For example, imagine a record about a chapter in an edited book. It has one or more authors and it belongs to a book. But it may share the author(s) with many other books, book chapters, articles and so forth, and the book with a dozen or so other chapters, each with different authors. Rather than entering the author(s) as text fields and repeating this information for every chapter in the book, you can create records for each of these Author entities and link them into the record for the chapter. The record in Designer View would look something like this:

The record in User View would look something like this:

You can then use the Author(s) field (which in this cases is a repeatable field) to select exciting authors in the database, or if they do not already exist, create them.

In the same way you can create book records, series records, publisher records and so forth, and simply point to these records instead of re-entering the data.

Relationship Marker Fields 

Normally relationships exist at the level of connecting records as a whole. But how do you prompt users to make a connection?

The Relationship Marker ('Relmarker') field is embedded as a special placeholder field (a marker) in the data entry form. The field contains no data; instead, it prompts the user to select a relationship type (i.e. 'show this type of relationship at this point in the form') and search for another record (target) to which to link the current record (source). The relationship marker further specifies relationship constraints that restrict the term list (of relationships available) and the target record types (or unconstrained).

What the relationship marker does is build in the relationship to the databases structure and prompts the user as they build their database. It provides structure as to what relationships the user can build.

Use a relationship marker field where you wish to prompt the user to create a new relationship record and to provide additional restrictions about the relationship as well as the ability to further describe the relationship (e.g. what kind of relationship it is etc.). For example, to record people with specific roles and other important types of relationships between records which need to be seen in the context of other fields rather than simply relating to the record as whole.

About the Relationship Record

Relationships between records are implemented as a standard Heurist record of type Relationship. By default, any record type can be related with any other record type using any of the standard relationship vocabulary terms within Heurist. The most important details in the relationship record are:

  • Source Record (pointer to a record ID)
  • Target Record (pointer to a record ID)

This links the two records together, regardless of type, with two fields that point to the source record of the relationship and the target record; all relationship details are stored in the relationship record itself

When creating a relationship marker, you will be selecting the list of relationships that the user can choose (e.g. Family, Organisational), and the target record or record types they can connect the source record to.

Note. There is no reason why two records cannot have several relationships, which may reflect alternative views on the relationships between the records, or relationships which have different time periods. For instance, scholars may disagree on the start and end dates of a relationship or a person may be employed by the same institution on more than one occasion. A relationship record is simply a normal Heurist record and it can be searched for and edited like any other record. This means that it can be annotated with text or a discussion such as questions of historical interpretation, its Ownership and visibility can be set, it can be tagged and so forth, like any other record. This can be extremely useful with historical data in order to represent differing views or to tag set of relationships in order to present a cluster of events in a timeline. This is also used for aggregations (see Aggregations).

Example

The following shows the creation of a relationship marker indicating a relationship record 'Is Played In' or 'has_location' between a Play record and a Venue record.

When creating the relationship, the relationship will be listed like this:

When to use a pointer and when a relationship? 

The primary difference (as shown in the diagram above) between a record pointer and a relationship marker is that in the first instance the relationship details are stored in the record whereas in the second instance the relationship details are stored in the intermediate relationship record, which gives you more control over the relationship (e.g. specifying the type of relationship, date range, label, annotations etc.):

The simple rule is, if you just need to identify a fixed type of relationship, such as an incontrovertible whole-part or a specific function such as Excavator, use a Record Pointer field. If you want greater richness, such as specifying an open-ended list of roles (e.g. for a film Director, Producer, Gaffer, Actor, Cinematographer, etc.) and to enrich those roles with temporal limits, annotation and so forth, then use a Relationship Marker field.

Advantages of using Record Pointers

Record Pointers are particularly useful where some entity (e.g. an author), is referenced by many records. The data about that entity (name, title, date of birth, location, roles etc.) can be entered once into the record describing the entity and then referenced from as many other records as you wish.

Another advantage of pointer fields is that you can constrain the pointers to one or more specific record types. This is useful, for example, if you want a pointer to a person or organisation (e.g. as the Owner of copyright), and want to make sure that this pointer can only point to one of these entities and not to, say, a web site or an artefact.

Advantages of using Relationship Records

Heurist relationship records have some very powerful features:

  • They are implemented as a standard Heurist record type, so they inherit all the characteristics of a Heurist record: they have a title, data fields, annotation, discussion, tags, Ownership, even a geographic location. In addition, they can be searched for and edited like any other record. This means, like any other record, that they can be annotated with text or a discussion (such as questions of historical interpretation), they can be tagged, Ownership and visibility can be set and so forth. This can be extremely useful with historical data in order to represent differing views or to tag a set of relationships in order to present a cluster of events in a timeline.
  • Relationships can be constrained in a number of different ways to ensure that only valid relationships can be created (for example, a building cannot be ‘FatherOf’ a person). This provides a lot of flexibility to build controlled networks of relationships between entities.
  • They can link any two records, regardless of type; no prior knowledge or specialise programming is needed. With this simple function, Heurist provides much of the power of many-to-many relationships in a conventional database, with a fraction of the effort (with relational databases a separate linkage table, and programming, is generally required for every pair of record types to be linked). Users can create relationships on-the-fly between any two records, with no prior knowledge or specialised programming needed.
  • By using relationships you can record additional information about the relationship, including the type of relationship, from a list of allowable types(required), the date range (time period) of the relationship (optional); many real-world relationships have a limited duration, and notes about the relationship.
  • You can optionally specify inverse relationships. By default, a relationship uses the same term for its inverse. However, you can specify a different inverse term if required. For example, if Relmarker in a Painting says isPaintedAt > Location, it can show:
    • isPaintedAt relationships involving it, which point at a Location (outwards)
    • isPaintingDoneHere relationships, which point at it from a Location (inwards)

Relationships provide a richer method for linking different types of record, and should be used in preference to pointer fields in the following circumstances:

  • If the relationship is not permanent (i.e. it has a time range, such as a person as emperor of an empire).
  • Where there are several different types of relationship possible between any pair of entity types (for example, an organisation can be related to people as director(s), Owners(s), member(s), student(s) etc). Rather than creating separate pointer fields for each of these relationships, they can be created as relationship records with a range of relationship types.
  • The relationship is not unequivocal or has rich information associated with it, and therefore requires commentary, justification or bibliographic references (which can be entered as Interpretations or notes in the relationship record - there is nowhere to store additional information in a pointer field).
  • The set of relationships is open-ended or requires complex constraints, such as genealogical relationships which might be extended with new relationships, and where one might wish to specify, for example, that a person can have no more than four grandparents, only two of whom can be grandfathers.

Created with the Personal Edition of HelpNDoc: Qt Help documentation made easy