Component Extension to Collection Objects

Overview

The Component extension enhances the existing Collection Object (CO) data structure by introducing a flexible and structured way to manage sub-elements of a CO—such as rocks, fossils, and minerals—within a one-to-many relationship. This feature directly addresses the slow and cumbersome data entry process associated with the current Collection Object Group system, simplifies the entry of sub-objects, reduces time spent on repetitive tasks, and responds to feedback received from domain experts and partner institutions.

Background and Motivation

Following concerns raised in correspondence and during meetings about inefficiencies in the current data entry process, we developed the Component extension to streamline workflows and reduce redundancy. The existing Collection Object Group (COG) model remains available and continues to be the appropriate tool for representing more complex specimen relationships where full object-level modeling is required. Users reported difficulties such as:

• Repetitive entry of the same data across COs within a COG

• Limited ability to clone or inherit shared information

• Risk of catalog number duplication and inconsistency

• Inefficient representation of trace minerals or fossil sub-parts

Component Extension Goals

The Component extension is designed to:

• Provide a way to represent identifiable parts of a CO without elevating each to a member of a COG.

• Reduce data redundancy by allowing Components to inherit information from their parent CO.

• Simplify data entry, especially for specimens with multiple sub-elements.

• Improve catalog number management through an optional inheritance system and cross-table uniqueness validation.

Key Functional Benefits

1. Simplified Data Entry

• Users can now add Components (e.g., minerals, fossils, tissues) directly within a CO form.

• Avoids the need for cloning or separate creation of COs and later linking them via COGs.

• All contextual information (e.g., locality, collection event) is entered once in the parent CO.

2. Flexible Catalog Numbering

• Components may inherit the CO’s catalog number or be assigned their own.

• New business rule ensures catalog number uniqueness across both CO and Component tables within the same collection based on the collection preference.

3. Improved Query Support

• Components can be included, excluded, or targeted directly in queries.

• Aggregated display of components within COs supports better visualization and reporting.

4. Configurable Interface

• Institutions can configure which Component fields are visible or required.

• Components are supported in WorkBench for import and batch editing, ensuring workflow compatibility.

Technical Scope and Implementation Summary

• New Component Table : One-to-many relationship from Collection Object.

• Key Fields:

  • Catalog Number (optional/inheritable)

  • Component Type (determines applicable taxon tree)

  • Name (from taxon tree based on type)

  • Identifier (agent)

  • Proportion, Role, Verbatim Name, GUID

  • Additional configurable text, checkbox, number, and integer fields

• Business Rules:

  • Cross-table catalog number uniqueness scoped per collection.

• Tree Integration:

  • Dynamic filtering of taxon names by selected Component type.

  • Full name display to ensure accurate and standard naming.

• Workbench Support:

  • Components can be imported alongside COs using child component column.

Conclusion

The Component extension represents a direct response to user feedback and solves real problems encountered in managing complex specimens. It simplifies workflows, improves data consistency, and enhances querying capabilities.

Why Components Were Not Implemented as Child Collection Objects

We chose not to implement Components as child Collection Objects within the existing CO table using a parent-child relationship. While this approach was initially considered, we determined it introduced too many usability, structural, and performance drawbacks that outweighed its potential benefits. Key reasons for this decision include:

• Determination View Limitation: The determination relationship could not support a Query Combo Box (QCBX) in this setup and would have required a subview, reducing usability and flexibility.

• Shared Schema Issues: Components and full Collection Objects would share the same schema, making it difficult to enforce distinct behavior.

• No UI Enforcement: The application would not prevent Components from being accessed or used as standalone Collection Objects, creating confusion and potential data misuse.

• Query Ambiguity: Users would need to search for Determination Full Name in two separate contexts, complicating the querying process.

• Filtering Required in Query Builder: Differentiating between a true CO and a Component in queries would require users to add filters based on the presence of a parent, adding complexity to everyday operations.

• WorkBench Complexity: Data entry in WorkBench would have been significantly more difficult, requiring multiple columns to represent nested parent-child relationships.

• Limited Benefit: The only clear advantage of this model was the potential for hierarchical nesting of children, which did not justify the additional complexity introduced.