Connections (Links)
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.
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:
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.).
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.
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 terms 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.
Relationships between records are implemented as a standard Heurist record of type Relationship. 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
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.
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:
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 Create Aggregations).
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:
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.):
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.
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.
Heurist relationship records have some very powerful features:
Relationships provide a richer method for linking different types of record, and should be used in preference to pointer fields in the following circumstances:
Created with the Personal Edition of HelpNDoc: What is a Help Authoring tool?