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.
Relationships are immediately available between ANY record types, without any further work, but these can also be constrained through a constraints menu so that only particular relationship types are allowed between particular pairs of record types, and this also allows constraint of the number of relationships allowed (e.g. one can only have two parents or a specimen bag can only belong to one context).
However we also have two powerful methods for embedding connections directly in the records so that they appear contextualised in the data entry form: Record Pointers & Relationship Markers.
A record pointer is a field within a record that defines or references a one-way link to one or more specific record types. You define pointers between data when you create the database structure. The type of a pointer can be constrained so you can only select a record of a particular type (or types).
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.
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 field definition 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.
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.).
A relationship marker is a record that defines a two-way link between two records that you wish to connect.
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 field allows a relationship to be embedded as a field directly in the data entry form – it does not actually contain any data, instead it acts as a marker (or prompt) to the user to create a new relationship record (‘show this type of relationship at this point in the form’). Relationship markers may be further constrained to specific record types and a limited set of relationship types appropriate to that point in the form; the constraints restrict the term list (of relationships available) and the target record types.
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.
Jack (Person record record) isBrotherOf
(Relationship Type) Jill (Person record type).
This relationship is stored in the relationship record like this:
You can also create a (unconstrained) relationship record via the Relationship Tab.
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:
Heurist relationship records have three very powerful features:
- They are implemented as a standard Heurist record type, so they inherit all the characteristics of a Heurist record; they can be edited like any other record, they have a title, data fields, annotation, discussion, tags, ownership, even a geographic location.
- 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.
- They include, by default, fields for relationship type (required) and time period (optional) over which the relationship applies (many real-world relationships have a limited duration).
The primary difference (as shown in the diagram below) 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.).
When to use a pointer and when a relationship?
The simple rule is, if you simply need to identify a fixed type of relationship, such as an incontrovertible whole-part or a specific function such as Excavator, use a 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.
The differences between a Record Pointer and a Relationship Marker field are outlined in more detail below:
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.
For resource pointer fields 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.
This is 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 (e.g. author) 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 artifact.
One advantage in using relationship markers (and relationship records) is that you can store additional information about the relationship, including the type of relationship (from a list of allowable types), the date range of the relationship and notes about the relationship.
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.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.
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);
- 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.
- By using relationships you can record additional information about the relationship, including the type of relationship (from a list of allowable types), the date range of the relationship and notes about the relationship. Relationships provide a richer method for linking different types of record, and should be used in preference to pointer fields.