Add support for 'Multiple Object Types'

[grantfitzsimmons]

Is your feature request related to a problem? Please describe.
It is not currently possible to manage several different types of collection objects in a single collection that use different names and attribute fields. Managing a single collection with multiple materials using this definition has never before been possible in Specify. Each discipline can currently only have one taxon tree and no types are given to an object.

This prevents users from querying specimen records managed by the same people in the same space in addition to preventing them from using the same incrementing/standardized catalog numbering scheme. The workflow for cataloging specimens that are similar/housed together but named differently becomes difficult when cataloging across multiple collections.

Components

• Add business logic for MOTs #4982
• Complete schema changes to add new tables and fields for MOTs #4981
• Add support for creating new trees #4833
• Add support for multiple trees of the same type within a single discipline #4829

Desired Solution

This would involve creating a new table and relationship field on Collection Object.

• A new field would be added to Collection Object in the data model named objectType
• A new table would be added named collectionobjecttype
• This table would contain a number of fields used for application business logic
  • CollectionObjectTypeID (int) - Database ID
  • Name (text) - Name of the type (i.e. Fossil, Rock, Meteorite, etc.)
  • IsLoanable (boolean) - Indicates whether this type of material can have its preparations be transacted in interactions (to be reconsidered)
  • Version (int) - Version to identify which revision it is
  • TimestampCreated (datetime)
  • TimestampModified (datetime)
  • CreatedByAgentID (FK to Agent) - Created by agent
  • ModifiedByAgentID (FK to Agent) - Modified by agent
  • CollectionID (FK to Collection) - Used to scope the table to the collection it was created in
  • TaxonTreeDefID (FK to TaxonTreeDef) - Indicates which taxon tree definition contains the names associated with this object

Business Logic & Requirements

• Each collectionobjecttype would be scoped to a particular collection

• An objectType would be chosen from a pick list on the Collection Object form

• When creating a new Determination record, the system should check the objectType.taxonTreeDef field to find the tree to search for the user's entered name when searching in the taxon or preferredTaxon query combo boxes

• objectType should not be a required field but can be made to be using the form editor.

• Conditional forms must be able to use the value from the objectType field to determine the layout in an intuitive way for users

  • If the user can define a form definition as follows:

    <cell type="panel" coldef="100px,2px,76px" colspan="6">
      <rows>
        <!-- This view definition will be displayed in Specify 6, or if all other conditions don't match -->
        <row>
          <cell type="label" label="Without any object type, this will display." />
        </row>
      </rows>
      <rows condition="objectType=Rock">
        <row>
          <cell type="label" label="This is a rock!" />
        </row>
      </rows>
      <rows condition="objectType=Mineral">
        <row>
          <cell type="label" label="This is a mineral!" />
        </row>
      </rows>
    </cell>

  That would be satisfactory. This would enable users to create forms or display subviews based on the value, which would also enable users to create specific determination forms or collection object attribute forms based on the value of objectType.

To be reconsidered:

• If the IsLoanable field is TRUE, preparations associated with the object can be used in interactions
• If the IsLoanable field is FALSE, preparations associated with the object cannot be used in interactions.

Interface

• The user should be able to create a new collectionobjecttype record easily in the interface.

  • The user should be able easily name the object type
  • On this form, the user should be able to search for a taxon tree from any discipline and choose it from the list

• The query builder should display all tree ranks across all trees that have objects in the current collection at once

• The user should be able to switch between all taxon trees used in a single discipline from the tree viewer

• If a query is built in a collection with Collection Objects with various different objectType values and different taxon trees associated with the collectionobjecttype records linked by objectType, the query builder must be able to search across all trees at once.

• If the object type is changed, the determination should be cleared and the user must select a new name

• When the user creates a new determination, the taxon tree searched when entering a taxon or preferredTaxon value must be based on the object type's tree (if objectType is present), otherwise it should use the discipline default

• When creating a new Collection Object record, if there is no objectType value, it will use the default taxon tree for the current discipline.

  • If there is an objectType value, the taxon tree linked to that object type will be used when creating the determination.

Data Unique to a Type (Attribute)

After discussing internally approaches to handling attribute data, it seems the frictionless and most effective solution (at least until the discontinuation of Specify 6) is to continue managing attribute data in a single table between all object types.

To be able to successfully display certain fields when a specific object type is selected, we need to leverage the conditional form rendering system that will be added in the 7.9.4 update.

This means that all attribute fields will be "unhidden" in the schema and visible all at once when building queries. It would be up to the user to define conditional forms that display only the fields they desire to show for that particular object type.

This allows users to store "Weight" or any attribute in a single field across different object types, simplifying searches across various objectTypes.

In summary, no changes would be necessary in this area and it is up to the user to define conditional forms based on type to hide or show certain attribute data based on the object type. The object type only influences what names are returned when creating a determination.

Trees

• Add support for multiple trees of the same type within a single discipline #4829

Because the TaxonTreeDefID (FK to TaxonTreeDef) indicates which taxon tree definition contains the names associated with an object, adding support for MOTs requires a fundamental change in the scoping hierarchy in Specify.

We would need to add the ability to view and switch between several taxon trees in a single discipline.

Because the trees would need to share a common schema configuration, the model I propose is to have it so that every tree is specific to that discipline, so even if there are 3, 4, or more trees in a discipline, they cannot be accessed outside that discipline.

Screen.Recording.2024-03-12.at.12.20.11.PM.mov

It could be as simple as a picklist that switches between the tree definitions so that the user can edit and view all of the trees linked to the various objects in that collection.

Specify could return all object types in the current collection and show only the trees that are connected to types in that list.

Special Considerations

Schema and Scoping

At present, the interface schema is scoped to the discipline. This means that all object types must share the same field captions and descriptions for all data model fields in the application. That means text1 cannot be "Size" for rocks and "Gleam" for minerals, it must be the same between both object types.

Ultimately this means that collection objects within the same collection (despite having multiple object types) must conform to the same format for all resources scoped to collection, discipline, division, and institution.

The following will be shared between all collection objects in a single collection regardless of object type:

---

Institution,

Accession*, Journal, Permit, Reference Work, Storage

Division

Accession*, Agent, Collector, Exchange In, Exchange Out, Funding Agent, Group Person, Repository Agreement

Discipline

Attribute Def, Collecting Event, Collecting Event Attribute, Collecting Trip, Collecting Trip Attribute, Exchange In Prep, Exchange Out Prep, Field Notebook Page, Field Notebook Page Set, Gift, Gift Agent, Gift Preparation, Loan, Loan Agent, Loan Preparation, Loan Return Preparation, Locality, LocalityCitation, LocalityNameAlias, PaleoContext, Shipment, Sp Export Schema, Sp Locale Container, Geography, Geologic Time Period, Lithostratigraphy

Collection

Field Notebook, Pick List, Prep Type, Sp App Resource Dir

---

The exception to this now is that multiple object types requires that Specify is capable of modifying, displaying, and searching across several trees from within a single discipline. This changes the scoping hierarchy to some extent as it is now "flexible" in a way it was not previously.

Queries

Queries in Specify currently resolve the tree rank based on a constructed string ID. This string ID unfortunately does not resolve the rank by a unique identifier but rather by the user inputted name field in the taxontreedefitem record.

For example, here is a query in Specify 7 that shows "Phylum", "Class", "Family" and "(any rank)".

When you look at the string IDs associated with this query, you see the following:

<?xml version="1.0" ?>
<query name="Tree Query" contextTableId="1">
	<field stringId="1,93.collectionobjectattribute.text11" oper="1" value="10m" isNot="false" isRelFld="false"/>
	<field stringId="1,9-determinations,4-preferredTaxon.taxon.Phylum" oper="8" value="" isNot="false" isRelFld="false"/>
	<field stringId="1,9-determinations,4-preferredTaxon.taxon.Class" oper="8" value="" isNot="false" isRelFld="false"/>
	<field stringId="1,9-determinations,4-preferredTaxon.taxon.Family" oper="8" value="" isNot="false" isRelFld="false"/>
</query>

That means if there are two trees with a rank named "Family", the query would only know to search that rank by the relationship and rank name (1,9-determinations,4-preferredTaxon.taxon.Family). This decision has manifested in other issues in the past (see #3351, #3424, and #3340)

The other consideration with trees is that you may be unable to build a single export for all materials since each column can only be mapped to a DWC term once. If you divide the tree ranks into separate trees and select a rank, then choose a tree and create multiple string IDs and query items, you can only map one full name column to the scientificName field.

If we change the construction of the string IDs, we would likely break queries in Specify 6 and require a migration to handle this issue.

For these reasons, I imagine it would be easier and preferred to show all ranks for all trees associated with objects in that discipline in a single list rather than segmenting them.

My main concern is the user experience and interface when seeing all tree ranks at once in a single list. If possible, it would be better to address these concerns without compromising compatibility with Specify 6, ensuring accurate exports, and enabling simultaneous cross-collection queries. At this time I do not feel it is essential to segment the trees into several lists but my opinion/group opinion may evolve as we develop.

Strawman Diagram

Diagram