Trait governance and curation

Traits form a public, installation-wide library. Dataset permissions control the Measurements that use a Trait; they do not turn the Trait definition into a private Dataset resource. Trait governance therefore protects both scientific meaning and every Dataset that reuses the definition.

Installation and upgrade

For a new installation, choose interface and user-content locales during setup; assisted translation remains disabled unless the administrator explicitly configures a provider. After an upgrade, run database migrations, php artisan locales:audit, clear configuration caches and restart queue workers. The migration initializes existing Traits as valid, records the first super administrator as creator when available, and creates the governance and duplicate-review tables; no separate Trait backfill is required.

After installation, a super administrator may assign Trait curator on a full user’s profile. Curators can then review the shared library. Configure optional translation, Tropicos and e-mail services as described in Administrator configuration.

Trait lifecycle

Every Trait has a creator and a status:

• valid: an active definition that may be selected for new Measurements;
• duplicate: an alias consolidated into another Trait, identified by canonical_trait_id;
• deprecated: retained for provenance but not recommended for new use.

Deleting an unused Trait owned by the current user permanently removes it when it has no protected usage or dependencies. This also applies to normal batch deletion. Other eligible deletions archive the Trait with a soft delete, keeping its relations and history available for restoration.

When duplicate Traits are consolidated, Measurements, forms, references, tags, object types, and compatible categories are reconciled with the retained Trait. The old Trait remains as a duplicate alias. A Measurement import that refers to that alias is redirected to the canonical Trait.

Who can do what

In the Trait model-index, normal deletion automatically purges an isolated Trait owned by the acting user. For records owned by someone else, curators and administrators must explicitly select Permanently delete eligible Traits; without that option the deletion remains recoverable. Every selected record is checked independently, and protected Traits are rejected.

The Trait model-index separates Active Traits, Merged duplicate Traits, Deprecated Traits, and soft-deleted Archived Traits. Merged aliases are visibly marked and link to the canonical Trait. Measurement totals shown in the Trait list count all linked Measurements because the Trait library is public; opening that total still applies Dataset access rules, so a user may see fewer Measurement records than the public aggregate.

Full users may select Archived Traits in the Trait model-index and open an archived definition. This read-only access explains an import collision with a reserved export_name; the import result also reports the archived Trait id. It does not grant restoration or curation rights. In the archived view, curators and administrators may restore selected records or permanently delete eligible ones. A creator may permanently delete their own isolated legacy archived Trait from its detail page. Registered users continue to see active Traits only.

A Project or Dataset administrator does not automatically become a Trait curator. Dataset administration is nevertheless relevant to the creator rule: the creator may correct a used Trait directly only when they administer every Dataset containing its Measurements. Once other Datasets depend on the definition, the correction must be handled by a Trait curator.

Changing or adding a category can change the meaning of existing categorical Measurements. Categories already used by Measurements may only be redefined or reordered by a Trait curator.

Review possible duplicate Traits

Full users can open Measurements → Review possible duplicate traits, search for one Trait by export name, name, or description, and compare it with the suggested records. The comparison uses multilingual names and descriptions and requires the same Trait type. Numeric Traits may still be reported when their units differ: units can be converted, and therefore should not suppress a scientific duplicate warning.

A full user cannot consolidate records. They submit a suggestion and can later see whether it is pending, confirmed, or rejected. Curators review those suggestions in the same tool.

Trait curators may also select Scan the complete trait database. The scan runs as a background UserJob and groups connected similarity matches instead of showing only isolated pairs. Load the result after the job finishes, then review the name, description, type, unit, and Measurement count shown for every member. Large result sets are paginated, and their full state is kept in a short-lived server cache so the browser does not resend every group on each decision.

For each member of a group, the curator chooses:

• No decision: leave it for later;
• Record to retain: the canonical definition;
• Merge: consolidate this Trait into the retained record;
• Delete permanently: remove an isolated Trait without merging it, when the current user is authorized and the Trait has no protected usage or dependency;
• Not a duplicate: record that this pair represents different concepts.

Save decisions persists non-duplicate judgments while leaving merge and delete choices available for execution. Mark all as not duplicates changes every member to that judgment, saves all pairwise decisions, and disables execution because no operational action remains. Execute decisions first inspects structural compatibility and authorization, then submits selected merges and permanent deletions as a UserJob. Detection is intentionally broader than execution: for example, Traits with different units can be detected as possible duplicates, while an unsafe merge may be rejected until the unit/value implications are resolved.

A non-duplicate decision is pair-specific, not a judgment about the whole group. Future scans ignore that pair. If a relevant name, description, type, unit, category, range, parent, or other conceptual field changes, related decisions are invalidated so the pair can be evaluated again.

Missing content translations

Traits, Trait categories, Trait units, Tags, Projects, and Media contain user-authored translatable content. When a translation provider is configured, the navigation displays Missing translations.

Google-assisted translation saves repetitive multilingual work but is never a scientific authority: previews and bulk results must be reviewed. It is optional and unavailable while USER_TRANSLATION_PROVIDER is empty.

The validation action starts a UserJob that checks every enabled content locale and reports missing fields that the current user is authorized to update. A missing field without source text is reported but cannot be generated. The correction action rechecks the record, authorization, source, target, character limit, and whether another user has already supplied the text before calling the provider and saving a result. Always inspect the UserJob results and review the generated scientific terminology.

Forms can also generate missing fields while a record is being edited. The translation API provides a preview endpoint and a separate save endpoint, so a client can review generated content before persistence.

Trait POST and PUT do not machine-translate missing locales. They store only translations explicitly submitted by the client; a partial PUT preserves translations in omitted locales. This separation prevents an import from silently publishing unreviewed terminology.

The same similarity check used by the form also protects API POST and PUT. A row with possible duplicates is rejected with candidate identifiers. After review, a genuinely distinct concept may be resubmitted with confirm_similar_trait=true; this explicit acknowledgement is per row and must not be applied blindly to an entire import.

See also Traits and Measurements and Import Traits with R.