Adding New Data Fields to Collections

Greetings,
Suppose the task at hand involves introducing additional data fields to collection objects, events, or preparations. I’ve followed various tutorials on this platform detailing how to modify the XML Specify form, and the insights gained have been valuable.

Nevertheless, could you provide best practice recommendations and a technical guide on creating fresh information fields within the schema? I’ve noticed several unoccupied fields in the database that appear to serve as placeholders for forthcoming data. However, the process of effectively utilizing these new data fields and establishing connections with the associated forms remains unclear. Specifically, I’m seeking guidance on which table fields I can leverage for my new data, whether I can customize their names in the schema, and how this customization aligns with the XML forms.

Your assistance in clarifying these aspects would be greatly appreciated.
Thank you.

Hi @Heryk:

Please note I am not a member of the specify team, and I am providing this guidance based on my experience with the software.

You are correct there are several fields within the schema that are user definable. These are usually labeled according to the kind of data that they store. These fields also have defined maximum allowable lengths. You may use these fields however you wish.

Text#: Will store text data
Integer#: Will store java.lang.Integer data.
Date#: Will store java.util.Calendar data.
And so on and so forth…

When you use one of these fields, you will almost certainly want to change the label from “Text2” to something understandable to the user, and also describe in your team’s documentation what the field should be used for. Changing the way this field is labeled in specify can be done in two places.

Within the database schema, you can customize the caption for the field, but not the underlying name in the database itself (nor would you want to, because then the next time a schema update was pushed out from the Specify team there would be inconsistencies to address). For all intents and purposes, changing the caption from the schema config will change the “name” of the field in most places within the specify system, including in queries and in workbench mappings etc.

Whether the name changes on a particular form is dependent on if you have manually set a label= string in a cell in the .xml view. Let’s take a look at two examples:

  1. Carrying the caption set in the schema through to be the label on the field in the form.
<cell type="label" labelfor="2"/>
<cell type="field" id="2" name="altCatalogNumber" uitype="text"/>

This would grab the caption for the field altCatalogNumber as defined in the schema config and use that as the label.

  1. Using a custom label for that particular view. The custom label supercedes the caption.
<cell type="label" labelfor="2" label="Display something different than the field caption"/>
<cell type="field" id="2" name="altCatalogNumber" uitype="text"/>

In my opinion, it is best to make changes to the caption in the schema config as opposed to applying the label within the xml. This ensures that your desired name also applies throughout the system, and not just in the form. The most common rationale that I have come across for making the change just in the form is if a particular user or collection really wants to refer to something in a specific way. For instance, they may not like the word “cataloger” and may want to call it “Person that entered the data”. If I don’t want to make that change for others, I can just apply it to a view through the label= argument and then assign the view just to them.

Let me know if anything from that was unclear!

1 Like

Hello @markp,

I appreciate the precise information you provided—it’s exactly what I needed. Your assistance is greatly appreciated. Additionally, it’s wonderful to discover other Canadian collectors utilizing Specify. Are you employing Specify to oversee the Beaty collections?

Thanks again,
Cheers

:canada:

Indeed! We are transitioning to Specify for the database management system for the collections in the museum. We are about a year into it and in the middle of moving the bigger collections right now.

I am glad that the info helped!