At the moment materialSampleState is a platform controlled vocabulary limited to: destroyed, damaged, lost, decommissioned.

Considering that:

• For some collections we need to also capture the information about if something is "alive" and we should probably avoid BasisOfRecord since it's actually the same material sample, only its state will change (something alive will die at some point).
• DwC and ABCD are using disposition for things like in collection, missing

Suggestion:

• Add disposition to record information about the "status" of the material sample in the collection/lab: destroyed, damaged, lost, decommissioned (assuming nothing means in collection)
• Use materialSampleState to record information about the material sample itself: "living", "preserved"

Date field format (YYYY-MM-DD) causes problems with some of our data sources with many inaccurate dates. Would it be possible for all date fields to have the timestamp format (YYYY-MM-DDTHH:MM:SS.MMM).

The above fields are free-text fields, but there ist also a pick-list avaible. Tags can be stored, but cannot selected again, so its obviously not a learning list. This affects the following fields:

• Preparations > Degree of Establishment
• Organisms > Determinations > Type Specimen > Type Status

Information sent via the backend will end up in the right place, but will not be displayed in the frontend, but can only be accessed via the API.

When I try to create a material sample association in a material sample, the Association Type field cannot be filled.
Clicking on one of the selection options has no effect at all - the field simply remains empty.
If I send the material sample association information via the backend, it works, but the information is not visible!

THis is another request from the Franck Stefani Lab's OPF.

Ability to name the specimens and their associated data according to a logical nomenclature that captures their history.

Currently SeqDB uses a mix of letters and numbers. Franck would like to use a different system.

Currently, only the Created By and Location fields can be searched to identify an existing Collecting Event. All fields from the Collecting Event section are required for the search function.

Currently there is an icon shown when a Material Sample is being "transacted". It would be more ideal to have a table of the full history of transactions on the material sample page as a summary and only show the icon if the material sample is "currently" transacted.

This ticket follows the work from #159

Currently, all units for size fields are directly linked to the field and which unit it is, is specified in the field description. This is not useful, because the unit varies strongly depending on the object. It would be useful if every field that contains a size specification is linked to another field where the matching size unit can be selected.

dwcCatalogNumber is replaced by materialSampleName since some material sample don't have a catalogNumber.

This is a request from the Franck Stefani lab's OPF.

Ability to search only for the active (in culture) specimens and to discriminate the active specimens from the stored or destroyed specimens (colour code for the specimen IDs),

Another request from the Franck Stefani Lab's OPF.

Ability to show on a map the geographic origin of the mixed specimens. This feature request might actually below in the reports module, not here in collection-specs

We complemented scheduled actions with a reminder function via e-mail. Currently we cannot refer to the concerned material sample in our e-mail: The problem at the moment is that our existing material samples do not have a mandatory Primary ID. Is there a way to share a material sample?

Ability to store and update PHAC Risk Group (RG) and Containment Level. SeqDB currently tracks these fields and I believe we have a script to update specimen records based on taxonomic matching.

The main specification file should be collection.yml and collectingEvent.yml should simply be included in it (like the other specs repo).

material-sample preparedBy is currently a to-one relationship, considering a material-sample can be prepared by more than 1 person, the relationship will be changed to a to-many.

If a specimen record has been given to another lab or collection we would like to link between permanent collections and working collections and other use cases like P to P or W to W.

Current use cases: https://github.com/DINA-Web/dina-model-concepts/issues?q=is%3Aissue+is%3Aopen+label%3A%22component%3A+collecting-event%22

Draft should cover requirements 13 to 17.

acquisitionEvent is a legacy concept that is now replaced by a transaction (incoming).

Generate the specifications in html and publish them as GitHub pages

I ask that the definitions in the Readme.md of this repo are updated with definitions for any term used for specifying model components. I find the current definitions confusing (and also somewhat cursory) as they refer to representations of the entities in question rather than their attributes.

For example, the current definition of Collecting Event is

Data associated with the collecting of the specimen(s) at a given time and place.

whereas I would (tentatively, subject to further refinement by whatever is deemed characteristic of a collecting event) define it as:

A collecting event is an event in which a material sample is collected.

deferring any ambiguity just to what an "event" or "material sample" denotes.

Otherwise I find it hard to understand if issues like #25 are just a terminological issue or something that requires structural amendments so it can be represented.

Proposed definitions could be discussed in this thread or in separate issues.

Addition of the button "Not Publicly Release" to search filter (Material Samples).

We would like to use tags for existing free-text fields and managed attributes. An admin should be able to assign the tag function to all available free-text fields and managed attributes.

• host
• hostOrganism (with name and remarks)

As far as I know only the second one is expected to be there. The first field is probably coming from a previous version and hostOrganism was supposed to replace it.

We still need managed attributes in the Preparations section, you said you could help with this:

"I would not recommend that route to add a managed attribute related to the preparation (a managed-attribute to the material-sample related to its preparation to be exact). A regular managed attribute with the component set to Preparation would do the work. We can help with that."

The existing field Other Catalogue Numbers is a free-text field. We want to split this field in three single fields for number, number-type and remarks. We would like to add any number of other numbers, if neccesary with the help of a button "add another catalog number".

Currently, selected transactions cannot be seen directly on a material sample. A list of selected material samples can only be viewed when a transaction is called up directly.