Review MaterialSampleState and consider disposition about collection-specs HOT 13 OPEN

• Agree that we should not use BasisOfRecord based on state change
• Agree that the use of the term disposition makes sense in the way suggested
• Agree with suggested restricted use of materialSampleState but I have not kept up with the discussion about materialSamples in the community and how they see "State" being used/modelled... [if a controlled vocab then we could potentially share the state in BasisOfRecord where it made sense?]

from collection-specs.

Categories like alive or preserved to me are more like characterizing general kinds of dina:MaterialSample, rather than states of the same instance of dina:MaterialSample. I would argue that the live snake in the zoo and its preserved carcass in alcohol after it died are not the same dina:MaterialSample. They are different instances of dina:MaterialSample but obviously related: the latter is derived from the former and I would find it attractive to see that relation reflected in the data model. Of course, it's a modeling choice but I find a notion of dina:MaterialSample that lumps them together as states of the same instance uninformative.

If terminological proximity to DwC is desired, then disposition is probably the best option to represent (mutually exclusive?) states for a given instance of dina:MaterialSample.

I would avoid dwc:BasisOfRecord which I view as an idiosyncratic way to refer to the type of origin of a record in a Darwin Core Archive data file in that same record.

from collection-specs.

For the snake in the zoo, yes it would work like that since there is a process involved (preparation) an provenance would be preserved.

It is less obvious to me when it's something grown in a lab.

from collection-specs.

So lets say we use disposition for: destroyed, damaged, lost, decommissioned .

Where should we indicate a material sample is living ? I'm assuming this is different than the disposition since you could loose a living specimen for example.

from collection-specs.

It is less obvious to me when it's something grown in a lab.

What is the use case here, i.e. which state of affairs does the system need to represent?

from collection-specs.

We can start with the virus case. For the virus collection we need to capture if a material sample is alive (target organism living in a tree) or Freeze Dry (captured in Preservation Type). This will drive the next steps in sequencing. #135 (comment)

from collection-specs.

Couple thoughts here. There's some discussion about this tdwg/dwc#363 and tdwg/dwc#228. Seems much thought here is that organismStatus or vitality is about the Organism, not necessarily about the material, so somewhat aligned with what @cboelling has written above.

from collection-specs.

It is indeed about the organism, not sure about the impact of that but it makes sense.

from collection-specs.

If the driver here is to indicate "alive" vs. "dead" as a flag or controlled vocabulary, it might be a good idea to adopt vitality as a new term with four vocabulary items & definitions indicated here https://docs.google.com/document/d/1FUzJlwo2penHjvNgLmy8z2VJ-ja0HA2vyXpZTFxrPwU: alive, dead, unable to determine and not recorded even though these are not ratified as far as I know. The first three are evidently most important for material samples whereas the last one is perhaps more relevant to observations. materialSampleState leans heavily to curatorial/preservation status & disposition for its availability.

from collection-specs.

We can start with the virus case. For the virus collection we need to capture if a material sample is alive (target organism living in a tree) or Freeze Dry (captured in Preservation Type). This will drive the next steps in sequencing.

Can you elaborate? What is the relation of items in the virus collection to the material samples you mentioned as examples? How do the sequencing processes depend on the characterization of a material sample as alive or preserved (or, as a sub-category of the latter, freeze dried?

from collection-specs.

At the risk of throwing a spanner into the wheels, I see two main sources of ambiguity here:

(1) Mixed material samples where the organisms at the time of collection have a mixed bag of vitalities and,
(2) Ongoing conservation checks, especially relevant for living collections whereby vitality is periodically verified/assessed

Singular (or homogeneous) organisms in a material sample are not as ambiguous & so where you put vitality is not so important.

The first above would be well accommodated if vitality were nested under organism, notwithstanding the implicit relationship with the collecting event. So, if a material sample starts its "life" in the system as a living host and a dead(?) virus, you have two organisms with two vitalities. However, there's also the question of what happens later. There is no present conservation component to accommodate the second scenario, which would be the more logical place for such a data item.

The question is, does it make logical sense to create a new material sample in a living collection when an organism transitions from living to dead? What is the intended use of a now dead organism that was once alive & in the living collection? Is this really about provenance? If a once living organism in a material sample within a living collection is tossed because it's no longer useful, does the entirety of the material sample (of which there might have been more than one organism) acquire a materialSampleState / disposition = decommissioned (in the legal sense) as a whole? If on the other hand that now dead organism in a mixed material sample once in the living collection is then donated to a collection that specializes in dead organisms, I'd see that as a new material sample because it would quite likely adopt a new catalogNumber, but what then happens/ened to the functional relationships of the originating parent/children material samples, one of which would have had the original collecting event?

from collection-specs.

Perusing tdwg/dwc#363 and tdwg/dwc#228 I find that a simple categorization like dead or alive can't possible deliver the information desired for the different use cases sketched there; a lot of contextual information will be needed to satisfy those. See also the comment by @stanblum

I propose to stick to the use cases at hand in DINA and find a solution that is adequate and at the same time honours the derived from relationship as the prime relation between instances of dina:MaterialSample.

Nonetheless, this is what I would chip in in a wider context:

If a once living organism in a material sample within a living collection is tossed because it's no longer useful, does the entirety of the material sample (of which there might have been more than one organism) acquire a materialSampleState / disposition = decommissioned (in the legal sense) as a whole?

This is a question best answered by users - I guess in many cases the particular dina:MaterialSample continues on to exist but there might also be examples where this is seen differently, depending on what are useful distinctions in the case at hand.

If on the other hand that now dead organism material sample once in the living collection is then donated to a collection that specializes in dead organisms, I'd see that as a new material sample because it would quite likely adopt a new catalogNumber, but what then happens/ened to the functional relationships of the parent/child of material samples, one of which would have had the original collecting event?

If parent/child refers to the derived from relation then all is well. This relation must be thought of as incredibly generic (and where we are free in defining any number of more specialized sub-properties or defined classes which reflect certain kinds of derived from processes).

The collecting of the live snake from the desert (not that I encourage this for any frivolous reason) is an event in which the live snake (instance A of dina_MaterialSample) participates. When it dies years later and its carcass is preserved these are different events (a dying process, a preservation process) entered by the live snake, and out comes its preserved carcass, another instance (B) of dina:MaterialSample. Ignoring all details (which could sure enough be represented using appropriate constructs though), B is related to A by the derived from relation. You could still retrieve the information that the snake whose carcass constitutes a preserved dina:MaterialSample was collected from the wild, there and then.

The same case could be made, with entirely different processes at hand, if the snake that was cought has offspring in captivity: each of its offspring (and also the offspring in its entirety) can be seen as an instance of dina:MaterialSample, that is in the alive category.

I keep using dina:MaterialSample to remind us that we are dealing with a highly technical construct here and to avoid being trapped by case-specific connotations of the English language word "sample".

from collection-specs.

I suppose this discussion all boils down to why a dina:MaterialSample (or a dina:Organism) needs to be categorized as living or dead. Are there any expected downstream implications for a user's available options in DINA given they might indicate something is (now or later) alive or dead? I was assuming that there's no particular interest in a natural or curatorial process that triggers or results in a need to change the value of vitality (or other home for this flag) unless of course users need to deduce why they unintentionally killed a living organism. That strikes me as outside the scope of a collections management system and is best served by a log book of protocols. If the intent at this stage is merely to store an optional piece of metadata that is not applicable to all collections, do we need to modify materialSampleState to accommodate it?

from collection-specs.