Define Connections
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.
However Heurist also provides two powerful 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. 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). Typical uses might include specifying the excavator(s) of a context−necessarily Persons−or sample bag belonging to a context−necessarily a Context.
Note. You can create pointers that are not connected to a particular record type ('untyped pointers'); 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.
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.
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.).
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 acts as a special place-holder marker or prompt that allows a relationship to be embedded as a field directly in the data entry form −it does not actually contain any data, it simply says 'show this type of relationship at this point in the form'. It inserts a relationship in context when the user is populating a record via the Shared Information data entry page.
A Relationship Marker ('Relmarker') 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. Relationship markers may be constrained to specific record types and a limited set of relationship types appropriate to that point in the form.
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.
Heurist relationship records have some very powerful features:
The following relationship record defines a two-way link between two Person records that you wish to connect:
Jack (Person record record) isBrotherOf (Relationship Type) Jill (Person record type).
This relationship is stored in the relationship record like this:
Relmarkers show inverse relationships of any defined relationships. For example, if Relmarker says isParentOf > Person, it should show:
if Relmarker in a Painting says isPaintedAt > Location, it should show:
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)
Relationship type (enumerated value, detail code 200, defaulting to vocabulary 200)
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.
The Relationship field contains no data. Instead, it prompts the user to select a relationship type and search for another record (target) to which to link the current record (source).
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).
You can create a relationship record via either:
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 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 advantages of using a Record Pointer or a Relationship Marker field are outlined in more detail below:
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. 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 artefact. |
Relationship Records 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:
|
Created with the Personal Edition of HelpNDoc: What is a Help Authoring tool?