Why Not to Use a Prefix in Your Catalog Number

Documentation Configuration & Installation
1

Choosing your catalog number formatting is an important decision. There are several advantages to using a numeric catalog number in contrast to a catalog number including a collection-identifying or institution-identifying prefix.

Some of the major benefits of using a numeric catalog number are:

  • Easier searches. You will be able to search much easier. Instead of typing “ABC000001, ABC000002, ABC000003” you could search “1,2,3” and return the same results.
  • Auto-incrementing. When creating a new record in the database, you can automatically create a record with the next number necessary. This prevents you from needing to find the previous record and add “1” to the end of it.
  • Darwin Core Exporting. The Darwin Core specifies that catalog numbers should be exported without a collection-identifying prefix.
    On reports and labels, you can add the prefix easily. When exporting to Darwin Core archive, the collection and institution codes can be shared in the export.
  • Validation. Specify will not allow any non-standard values to be placed in the catalogNumber field.
2

Extremely good point. I wish many decission makers on Catalog Number format adoption had read this loooong ago.
Besides, formats that contain, for example, a numerical prefix (which may stand there for whatever function), make impossible any attempt to sort by “true” catalog number.

However, aren’t the “components” of the format in some way “modular”, which Specify then splices together? I mean, aren’t the components stored separately (e.g., institutional code + prefix integer + suffix integer + true catalog number, ect.), so there’s always some kind of independence for the true catalog nr.?
If that’s the case (which I may have just dreamed) I wish I knew how to segregate them.
Íñigo

3

If you configure the formatter in Specify 6 using the Field Formatting Editor, you can create the formatter used to create new catalog numbers. This unfortunately does not separate those values and the result is saved to the catalogNumber field.

The collection and institution codes should be stored in their respective tables in the schema under the code field. This information can be preserved when configuring an export to data aggregators so that nothing is lost and catalog numbers can have all of the advantages described above.