New term - organismPart

[mdoering]

Looking into the GBIF data it appears that dwc:preparations is used to capture 2 distinct pieces of information, the preservation method and the part of the organism being stored.

ABCD has a related concept KindOfUnit defined as:

Part(s), physical state, or class of materials represented by this specimen.

organismPart definition

Part(s) or class of materials represented by an organism.
Recommended best practice is to use a controlled vocabulary.

Examples:

whole organisms, antlers, bark, blood samples, bones, eggs, feathers, fruits, galls, heads, leaves

[mdoering]

Top 50 values found in preparations in GBIF as of last week. Colored orange is the organismPart, in green the preservation method:

[tucotuco]

See also #1.

[tucotuco]

It isn't clear to me how this differs from what preparations would be after preservationMethods were separated.

There is also a problem of how this would be implemented in SimpleDarwin Core. If the part and the preservation method are in separate terms, and there are multiple parts, how would you assure that the right parts were associated with the right preservation methods. To me this proposal seems like it would relegate preparations to an extension where a one-to-many relationship could be maintained.

[mdoering]

If we have preparations and preservationMethods the issue would be mostly about a redefinition of the term preparations so it excludes how it was preserved and focuses more on what part of the organism has been collected. Understanding that a record is about a bone, skull, feather, owl pellets or the entire organism should make a big difference to users. Currently this information is very inaccessible. In that light deprecating preparations in favour of organismPart and preservationMethod makes more sense to me as the terminology is cleaner.

[mdoering]

If you look at the GBIF values at the top I cannot see the need for a one-many extension. It is all about one thing. If there are multiple parts of the same individual that have been preserved differently these should normally also result in several DwC specimen records. Alcohol and bones for example are usually different collections.

[tucotuco]

It is by far more common in vertebrate collections to have multiple parts than it is to have only one, and it is far less common to catalog these separately then it is to ist all the parts of an organism under one record. The partial exception to this is for tissues from which DNA was or can be extracted. See https://raw.githubusercontent.com/VertNet/DwCVocabs/master/vocabs/preparations.csv for distinct preparations found going through VertNet migrators.

…

On Thu, Sep 10, 2020 at 4:32 AM Markus Döring ***@***.***> wrote: If you look at the GBIF values at the top I cannot see the need for a one-many extension. It is all about one thing. If there are multiple parts of the same individual that have been preserved differently these should normally also result in several DwC specimen records. Alcohol and bones for example are usually different collections. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADQ72ZAXPMAOEBTF3YXP7DSFB6IHANCNFSM4AWPFUDA> .

[tucotuco]

There have been discussions about having part/preservation method histories as an extension, but that activity seems to have stalled. This seems like a good candidate for a Task Group.

[deepreef]

I think this issue is related to the MaterialSample (not Organism class), and would probably better managed with a hierarchical structure for instances of MaterialSample. To make this work, I think it would be better to move preparations into the MaterialSample class (where it really belongs), and add a parentMaterialSampleID term to that class as well. Bottom line: I agree with @tucotuco that this would best be handled through a Task Group -- perhaps focused on how to frame the MaterialSample class in the context of other DwC Classes (especially Organsim).

[tucotuco]

Related issues are Issue #1, Issue #24 (reopened because of renewed interest), Issue #314, Issue #332, Issue #344, Issue #345, Issue #346, and Issue #347.