2 Database Fields
This section seeks to document the status of the various fields in the University Museum’s PastPerfect collections database.To help understand how information was entered into the various fields, Craig leveraged PastPerfect export files and R’s (2022) ability to summarize categorical data. For each of the fields listed in the Inventory Fields section, Craig used dplyr’s group_by and summarize functions to count entries by value (Wickham et al. 2022); this information is then presented as a reactive JavaScript table accessed by the DT wrapper (Xie, Cheng, and Tan 2022). Craig as well as Johnson and Harper used reports of these kinds as tools to guide the updating of data in PastPerfect.
Database field names are listed below based on their PastPerfect export name that appears as column headings in export files and their internal interface “Name” that appears in the PastPerfect UI. In addition to this document, Otto provided her list of field definitions, how she used them, and how she intended students to contribute to the inventory. In the Museum SharePoint, see the files:
\Collections\Inventory\Inventory How To.docx\Database\Object Field Descriptions.PDF\Database\PastPerfect Training Manual.pdf
Those working on the Museum’s database must understand that it was customized by Otto so information was structured in non-standard ways (Figure 2.1). Otto set up the PastPerfect database such that University Museum tab is the intended primary screen for entering information (Figure 2.2).
With an eye towards maintaining data consistency, when either creating new data or wrangling existing data, Craig aimed to follow these protocols outlined by Otto.
2.1 List Fields
The University Museum data base contains a number of “list fields”. Craig defines “list fields” as fields that potentially encode a list of values rather than a single value.
Generally it is not a good idea to put multiple values into a single table cell. This structure is not tidy (Figure 2.3) and is cumbersome to deal with (Wickham 2014; Wickham and Grolemund 2017). However, given the constraints of PastPerfect, one may need to encode “untidy” compound values to describe an object. For example, PastPerfect offers a single material field that is present in various screen views. Many, if not most, objects are composed of multiple materials. Therefore, it can be necessary to enter multiple values into a single field (Figure 2.4). When confronted with such situations, people often enter some kind of delimited value like wood/stone/sinew where / is the separator for three values.
In theory, list fields are not ideal. However, “in the wild” the legitimate need to enter multiple values into a single field can arise. In the case of PastPerfect this need arises in a number of situations. If list fields are to be used, it is crucial that consistent delimiters are applied and ideally, for the sake of consistency, unless there is some overwhelming reason not to, the same list delimiter should be used in all list fields that are present within a database.
Craig encountered a number of different delimiters used in the University Museum’s PastPerfect database (Figure 2.4). Where Craig encountered list fields he attempted to standardize delimiters always applying the / character as the list delimiter. Known list fields are flagged below with a callout note.
2.2 Object Descriptions
Object descriptions are listed first because understanding how description information was logged over time helps shed light on some of the University Museum’s collection’s database idiosyncrasies more generally.
2.2.1 udf21: “Description (UM)”
An object’s description is a key narrative variable. The field is useful for staff who need to relocate an object or to external researchers or community members who are interested in the Museum’s holdings. Given these uses, properly structuring the description field is among the more important variables to track for an object.
Otto’s customized interface (Figure 2.2) uses PastPerfect’s udf21 field as the primary description field. However, Strankman and others previously entered data into the standard description field. Moreover, prior users of the standard description field often placed mixed information into this field: donor, recipient, materials, condition, and other information.
As a result of the database’s history of users and customizations, description information was spread across two fields and one of these often contained complex variables that were inconsistently formatted. This artifact of the data’s history renders the database cumbersome when searching or exporting to external interface tools like JavaScript, R, or Python. In developing a web interface for the Museum, Craig sought to ameliorate some of these matters. Resolving the description field was among the largest wrangling tasks.
When the description field contained information and udf21 did not, Craig propagated information from the stock description field to other fields in the database. As PastPerfect does not seem to have an accessible application programming interface (API) this work had to be done manually via the graphical user interface. Partial copy editing was performed during the propagation process, but more careful review and correction is very much needed. When present, dimension and condition information were propagated to their respective fields. Data were not confirmed or validated, information was simply moved into appropriate fields.
There may be circumstances where standard description and udf21 both contain information and were not retrieved by Craig’s searches. Some of these may represent cases where multivariate data were housed in the description field. This is likely a productive area for future data cleaning.
2.2.2 udf22: “Additional Object/Collection”
This is a custom field created by Otto. Craig understood this field to contain descriptive or ancillary information about an object that that may not be suitable for public dissemination. As Craig propagated information from standard description field to the custom udf21 description field he attempted to ensure that any sensitive information in the standard description field was moved to udf22 the private field rather than udf21 the public field.
The udf22 field is not revealed in this public document.
2.3 Object Names
2.3.1 objname: “Object Name”
Object Names are presented up front because this field contains information that is meant to standardize object designations for consistency and interoperability. Object Name is the primary field into which Nomenclature terms are entered. Craig initially encountered many records for which this field was improperly assigned. See Section 4.2 for further discussion of improper assignment issues at the Univesrity Museum. Craig made an effort to assign a proper Nomenclature term to each object. PastPerfect v5 only supports Nomenclature up to v3, but the current edition of Nomenclature is v4. In some cases, Nomenclature v3 lacked the term while it is present in v4. In several cases, Craig added v4 terms and when doing so followed the v4 hierarchy. Craig was not able to assign all objects to a proper Nomenclature term, more attention is needed on this aspect of the database.1
See also the file in the Museum’s SharePoint:
\Collections\Inventory\PastPerfect\Nomenclature+PastPerfect+Help+Guide.pdf
PastPerfect does not include the entire term hierarchy on export. This information would need to be reconstructed. The entire Nomenclature lexicon, with complete in-tact object hierarchies, can be downloaded from the Nomenclature website in a number of formats. If objname is properly filled out, it should be possible to join the full Nomenclature hierarchy for that term. Craig sees this as an area for improving the post-processing of PastPerfect export files.
2.3.2 objname2: “Object Name 2”
The objname2 field contains few values and is thus largely under exploited. Craig entered some information into this field and noted that Johnson did as well. Craig and Johnson used this field to indicate secondary names.
2.3.3 othername: “Other Names”
The othername field contains a seeming mix of different categories. Documentation suggests that this field can be used for emic terms for objects. This is how Craig approached the othername field. However, Craig did not edit existing records that contain non-emic terms. Most of the data in this field seems to be non-emic terms. In Craig’s opinion, this field represents an area where the Museum could better represent Native terms and emic-views.
2.4 Material, Construction Method, Decoration
2.4.1 udf4: “Material (UM)”
PastPerfect’s default material field is called material. The field udf4 “Material (UM)” is a custom material field created by Otto. Craig followed Otto’s protocol. Craig also attempted to move information from the default material field to udf4 “Material (UM)” field created by Otto. There may still be some records for which udf4 is empty while material is not.
When an object is made of more than one material, this field can contain a value list. Craig applied the / delimiter to any list field in the database.
2.4.2 udf6: “Construction”
This is a custom field was created by Otto for logging an object’s construction methods. Craig made limited attempts to migrate or propagate existing data into this field.
When an object is made with more than one method of construction, this field can contain a value list. Craig applied the / delimiter to any list field in the database.
2.4.3 udf7 “Decoration”
This is a custom field was created by Otto for logging an object’s decorations.Craig made limited attempts to migrate or propagate existing data into this field.
When an object is made with more than one method of decoration, this field can contain a value list. Craig applied the / delimiter to any list field in the database.
2.5 Function
2.5.1 udf5: “Use”
This is a custom field was created by Otto for logging an object’s function. Craig attempted to propagate use information into this field, but more work is needed.
When an object has more than one identifiable function, this field can contain a value list. Craig applied the / delimiter to any list field in the database.
2.6 Status
2.6.1 status
This is PastPerfect’s default status field.
2.7 Cultural Affiliation
2.7.1 udf1: “Culture (UM)”
This is a custom field created by Otto. Craig continued with this protocol, but did little to clean or modify variables entered into this field. Most of the cultural affiliations are groups native to North America and primarily the Southwest. Craig believes that department faculty with an emphasis on the Southwest should be asked to review these cultural designations. Craig sees this as a priority area.
When an object has more than one identifiable cultural affiliation, this field can contain a value list. Craig applied the / delimiter to any list field in the database.
2.7.2 udf8: “Country”
2.7.3 udf9 “State”
2.7.4 udf10: “Locale”
2.8 Recieved
2.8.1 udf3: “Source”
This is a custom field created by Otto. Craig continued with Otto’s protocol. However, Craig noticed that many values in this field are not source related but appear date related. This field needs some additional attention, and Craig was not able to address it during his appointment.
2.8.2 recas: “Received as”
2.8.3 recfrom: “Source”
2.9 Collection
2.9.1 collection: “Collection”
This is a standard PastPerfect field. Entry of data into this field has been incomplete and idiosyncratic. Where collection names were applied in obviously inconsistent ways, Craig made an effort to standardize collection names. However, some may still need revision. Craig also believes that many object that should belong to a given collection have not been properly assigned in PastPerfect. The Amador Collection is one such example as several objects that were recovered from the Amador house are not included in the Amador Collection. Craig and Johnson began using a PastPerfect list to track Amador Collection candidates. A similar approach could be taken with other collections. Additionally, several collections only contain a single object. Craig recommends adopting a formal definition of collections that includes a minimum number of objects to be considered a collection.
Craig notes that there are a number of object in the museum that would make good candidates for new Nomenclature terms. Craig and Johnson worked together to assemble some of these potential terms.↩︎