Suggest new term - materialSampleType

[Jegelewicz]

From TDWG Issue: New Term - materialSampleType

Originally posted by @Jegelewicz in #2 (comment)

[jbstatgen]

Andy Bentley shared this recently, it might provide information for this topic here, too. Looking through the slides in the pdf, especially slide 11 of the first talk seems of interest.

Not sure if anyone else caught the iSamples webinar yesterday concerning
“Supporting Interdisciplinary Sample Data Discovery, Integration, and Reuse”

The recording is worth a watch as it has close ties to what we are
proposing with Digital Extended Specimens

https://www.rd-alliance.org/ps-interdisciplinarysampledata-October-webinar

[jbstatgen]

... another resource: http://www.cidoc-crm.org/Version/version-7.0.1
This is the Conceptual Reference Model (http://www.cidoc-crm.org/) by the International Council of Museums and the International Committee for Documentation developed over many years for information integration in the field of cultural heritage.

For pointers to connections with our "Material Sample" topic, see Alex Hardisty's text on the relationship of the openDS to the standard: https://github.com/DiSSCo/openDS/blob/master/positioning-opends.md#integration-with-information-representations-in-the-wider-cultural-heritage-sector , especially the classes mentioned in paragraphs 4 and 5:

As an identifiable immaterial item with an objectively recognizable (defined) structure, documented as a single identifiable unit, a Digital Specimen object structured in accordance with the openDS specification corresponds to an instance of the E73 Information Object class in the CIDOC CRM. In contrast, a physical specimen is an instance of the class E19 Physical Object (or one of its subclasses, such as E20 Biological Object). As instances of Persistent Items (class E77) both a digital specimen (of class E73) and a physical specimen (of class E19) are eventual subclasses of E72 Legal Object, meaning that both can have Rights (class E30) attached to them.

Interestingly, a digital specimen can also be considered (by being an instance of class E73) as being an instance of a Human-Made Thing (class E71); whereas a physical specimen is a Human-Made Thing only in specific cases: for example, when a photograph, microscope slide or audio-/video-recording is treated by an institution as a specimen for curation purposes.

[Jegelewicz]

From #2 (comment)

the way I see it is that things like LivingSpecimen, PreservedSpecimen, FossilSpecimen, "EnvironmentalSample", "TissueSample", etc. are better framed as entries in a controlled vocabulary, as values for something like a materialSampleType property, rather than subclasses with their own specific/unique properties and relationships.

This is how I see it as well

[dr-shorthair]

A controlled-vocab of types might be easier to maintain alongside the main DWC vocabulary.

But consider
(a) if you are happy for this classification to only be used as an annotation, and in particular
(b) if you can already define different sets of properties for the different types

[deepreef]

@dr-shorthair : I think this comes back to the question of "how big of a leap do we want to make at this stage"? Eventually this will probably all end up in a triple-store (or maybe on a blockchain?), but I'm not sure the community is quite ready for that yet. Representing the different "types" of MS instances as classes is certainly more powerful/flexible; but my gut says that the gain/pain ratio might be better for a simple controlled vocabulary annotation approach -- at least for most biodiversity data producers/consumers at this time in history.

More to your point (b): Off the top of my head, I would guess that 90%+ of MaterialSample properties and relationships would be (at least potentially) shared among most or all of the different types (i.e., very few properties would be specific to one or a few types/subclasses), and even among the ones that are particular, they would probably be applicable to >1 subclass. So you'd probably end up with something of a mosaic of mappings of properties to subclasses. That seems like a lot of complexity to accommodate a small number of exceptional cases where properties or relationships are not (potentially) relevant to all subclasses.

There are a number of other DwC classes where not all properties are relevant to all instances within the class (e.g., waterbody, island within Location).

[Jegelewicz]

Closing this as out of scope for the task group.