DLN:CC Beta - observations on auxiliary fields

[Dave Martin]

Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31

 

In addition to the technique-specific fields on image sets, currently:

• there is an unformatted free-form ‘Notes’ or ‘Description’ field/area on many of the register screens;

• the Equipment Overview has a number of hard-coded auxiliary fields, which are enabled in specific cases if the equipment is a lens / lens filter, or illumination source / illumination filter; and

• the Subject Overview screen has an option to populate four free format label:value pairs, one of which whose label indicates it is intended to be ‘is part of’.

 

The auxiliary fields on the Equipment records have fixed purpose and are stored in hard-coded columns.

 

However, the auxiliary fields on the Subject are to all effects uncontrolled. As it stands, the user, on a per-subject basis, decides on the purpose they wish to use the field for that single subject and  types in what they want the field name / item label to be and then types in the value to be stored – both of these are totally free format.

 

What this means is that these auxiliary fields are, I would argue, of possibly even less value than the free-format Notes field – whereas the auxiliary fields could actually be so much more useful….

 

With the current system, there are two issues:

1. There is no control over the labels, so on one record the user could type in “Gift of” as the title or label for the first field (as in the sample data), and on another subject, they could type in the first field’s label as “Donated by” or “Donor”.
   If the user then sought to search for all records where label1 = “Donor” … then they would miss ones where the label had been typed as “Gift of” or “Donated by”.
   (as it happens, I suspect “Gift of” as cited in the example database might actually be better as a stakeholder role, but the “Gift of” serves well to illustrate the point.)

2. Also, as there is no control over which of the fields is used, even if there was standardisation to call an entry, say, “Catalogue number”, as that could be stored in subject auxiliary field 1, 2 or 3, then any query would have to be some form of (… WHERE subject_id1_lbl = ‘Catalogue number’) UNION  (… WHERE subject_id2_lbl = ‘Catalogue number’) UNION ( … WHERE subject_id3_lbl = ‘Catalogue number’)

As it stands, having the free-format labels and data fields allow highlighting (a bit like having the ability to underline or embolden text in the Notes field) but doesn’t contribute as much as it could in terms of structured data.

 

I think that a simple change could resolve these, and add to the power of DLN. Instead of having multiple auxiliary fields embedded in the Subject rows, store the auxiliary data in a linked table, and control the list of possible labels via a ‘label type’ register?