dwc
dwc copied to clipboard
tdwg
New Term - objectType
New term
- Submitter: Ben Norton
- Efficacy Justification (why is this term necessary?):
- Eliminate the ambiguity in the preparations property by atomizing the information into a more logical set of properties which enriches datasets and reduces the number of compound mappings for data publishers (where multiple fields in a database are concatenated into a single field solely for publication purposes).
- Enables better mapping to Latimer Core (objectType is a property in LtC and an exact Match to the term proposed here).
- Supports MIDS by improving the Darwin Core mappings to the level 0 required information elements.
-
Demand Justification (name at least two organizations that independently need this term): Field Museum Royal Botanic Garden Edinburgh Natural History Museum (UK) Plantentuin Meise
-
Stability Justification (what concerns are there that this might affect existing implementations?): There are no concerns about any maleffects from implementation. It will enable publishers to better atomize their datasets by splitting preparations into a more logical pair of fields.
-
Implications for dwciri: namespace (does this change affect a dwciri term version)?: It does not.
Term as documented below is 'borrowed' from Latimer Core. Term Name: ltc:objectType https://ltc.tdwg.org/terms/index.html#ObjectGroup_objectType
Proposed attributes of the new term:
-
Term name (in lowerCamelCase for properties, UpperCamelCase for classes): objectType
-
Term label (English, not normative): Object Type
-
Organized in Class (e.g., Occurrence, Event, Location, Taxon): MaterialEntity
-
Definition of the term (normative): High-level terms for the classification of curated objects.
-
Usage comments (recommendations regarding content, etc., not normative): A more generic classification of items in the collection than described in preparationType.
-
Examples (not normative): Macro-object Micro-object Oversized object Cut/polished gemstone Core Fluid Hazardous material/object Mixed Audio Visual Specimen Tissue Culture HTS Library Lysate Environmental sample Extracted/Preserved DNA/RNA Microscope slide Spore print Macrofossil Mesofossil Microfossil Oversized fossil
-
Refines (identifier of the broader term this term refines; normative): Not applicable
-
Replaces (identifier of the existing term that would be deprecated and replaced by this term; normative): Not applicable
-
ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG; not normative): http://rs.tdwg.org/abcd/terms/kindOfUnit closeMatch Concepts closely aligned, but ABCD structural considerations prevents exactMatch.
** 20240710 Refinement 2 Key Points regarding objectType
-
Tighten the meaning and scope of preparation, which reduces ambiguity and misunderstandings while providing a more accurate representation of the physical entities the data represents.
-
Improving Interoperability among TDWG standards.
-
Object Type and Preparation are 'semantically sovereign' terms. There is no hierarchical relation (e.g., subtype). The scope of Preparation is narrowed both temporally and physically. A preparation occurs after a specimen has been collected for a specific purpose. The specimen's identity is unchanged. The physical nature of the specimen has deviated from its 'natural state' at the time of acquisition.
-
The scope of Object Type is limited to physical objects, which are a subset of Material Entities. As currently written, MaterialEntity is a broad match to similar terms in LtC, MIDS, and ABCD. Given the increasing interest, importance, and adoption of SKOS mappings, an exact match is critical for the interoperability of all three with DWC. The adoption of an exact match term must avoid altering any of the existing terms especially the more contentious ones such as Material Entity. objectType accomplishes the goal of interoperability without complicating the existing terms. In summary, the logic is fairly simple and avoids complications with Material Entity.
-
Material Entity is a broad match to ltc:objectType, MIDS objectType, and ABCD kindOfObject.
-
ObjectGroup is one of two required classes in ltc. For interoperability purposes, an exact match for objectType is crucial.
-
Object type (currently mapped to preparation) is a level 0 parameter in MIDS. To produce the most meaningful MIDS results, exact matches to level 0 terms are essential.
-
Kind Of Object is at the core of ABCD and lacks an exact match. The overarching intent of the new term is to improve interoperability between major standards under the TDWG umbrella. So it's best to view the term from that perspective. The Material Entity debate seems outside of this scope and therefore not directly applicable.
In biology, the distinctions outlined above are not as prevalent. To preserve something that was living requires some form of preparation. Here, preparation and objectType can be reduced to a single term. In earth sciences, this is not the case. I have a limestone on my desk that's 400 Mya. I don't need to do anything to the specimen for preservation purposes. It has that covered. The natural state of most geologic specimens is retained after acquisition, which limits the scope of preparation to specimens 'prepared' for purposes of analytical analysis. Most specimens aren't prepared for analysis and therefore will not have a preparation value. The loss of information as a consequence is substantial and needs to be avoided. This is accomplished with the objectType term.
Material Sample Task Group investigated, but abandoned as out of scope, the consideration of a MaterialEntity type term (see https://github.com/tdwg/material-sample/issues/33 and https://github.com/tdwg/material-sample/issues/14) and a controlled vocabulary for it (https://github.com/tdwg/material-sample/issues/24). The term as discussed would have ended up being materialEntityType following the pattern of type properties for classes in Darwin Core. This term was purposefully avoided by the Task Group because of myriad implications with respect to basisOfRecord, object type hierarchies, etc., but the discussion was extremely valuable and should be considered by anyone with a vested interest in this term proposal.
Is there an alternate path forward for the term? Currently, most values are being cobbled together in preparations, which can be confusing and misunderstood. I'm somewhat familiar with the Material Entity discussions. My hope was to keep objectType simple so that we could solve the problem without getting bogged down by that debate. I may have been overly optimistic about the prospect of doing so. I added it to MaterialEntity mainly because that's where preparations resides. The idea is to narrow that term to a more appropriate level of granularity and avoid the complex material entity discussion.
The issues that came up when trying to establish a dwc:MaterialEntityType property are due to dependencies that arise from the practical usage of other DwC terms rather than the generality of dwc:MaterialEntity. As such, implementing dwc:ObjectType, if it is understood to indicate the type of a particular object and as such indicates a_subclass_ of dwc:materialEntity, would be subject to exactly the same concerns (spelled out in the links above). What the earlier discussion indicates, I think, is that there are limitations of DwC expressivity when it comes to describing object histories and curatorial activities within that object history.
Setting this aside for a moment (i.e. adopting a bag of terms perspective, nothing else), I agree that data providers and data consumers must have a way to indicate the type of an object - using categories that matter to either party based on the use cases for the data.
If this is handled in an completely open fashion, i.e. allow any value that matters to a stakeholder, this is easy.
If the vocabulary is to be structured and controlled in some way it gets complicated quickly because objects can be categorized alongside many different facets and more often than not categories in one facet are (expected to be) ordered hierarchically or related in other ways.
atomizing the information into a more logical set of properties
I understand that the proposal is to use a dwc:objectType property alongside dwc:preparations (possibly updating its definition) and possibly further properties as a "more logical set of properties" that describe different facets of the object.
If this is correct then what are these facets and which logic is applied? The example list of terms in the OP seems to combine vastly different facets. Also, some of the examples do not in fact generalize values of dwc:preparations (e.g. macrofossil vs. fossil) as the proposed usage comments suggest.
For the record: I do think that the definition of dwc:preparations carries ambiguities that should be resolved (Preparations and preservation methods, which are both mentioned in the definition are different categories). Based on the examples for dwc:preparations I would say it is intended to capture the type of an object along the lines proposed in this NTR.
Here's the logic.A fossil is not a preparation. A fossil is a type of object. From my purview, it's not logical to call it a preparation. If you were to wrap it in a jacket, then that would be a preparation. I've "prepared" the specimen. Latimer Core kept this simple to avoid the problems of material entity subtype.
Preservation and Preservation Mode are in ABCD.
@ben-norton In the current situation, whether a Darwin Core record is a fossil can be deduced from basisOfRecord. What would be any further objectType kind of data that would not fit well in dwc:preparations?
(Regardless of the current example values in the DwC term list, that is a separate discussion.)
From the MIDS perspective, we currently have a MIDS element called ObjectType that maps to dwc:preparations (see this issue and this line in the mapping). This mapping was mainly made with preserved specimens in mind, not fossils. It could be omitted from mapping sets for paleontology, or moved to another MIDS level, if it is not a key piece of information to digitise and publish in that discipline.
@matdillen the current SSSOM mapping for mids:ObjectType is skos:exactMatch to dwc:preparations. But MIDS was created with all specimen types in mind, including fossils, geological objects, preserved DNA and living specimens. So if you say the mapping was created with preserved specimens in mind, that should maybe changed? Should it not be broad match?
as Ben already wrote, in LtC there is also an objectType defined as "A more generic classification of items in the collection than described in preparationType" and the intention of mids:ObjectType was to be compatible with that. Since this term is about items in a collection, would it not be nice if there is an equivalent for a single collection item in DwC as Ben suggests?
The definition as Stephen Richard once proposed seems to make sense: ObjectType is a description of countable things. I think that is much clearer than preparation type which is about how something is made ready for a particular purpose and would include things like dried, preserved in alcohol but these could still be captured in ObjectType as dried material or jar with alcohol. So changing dwc:preparationType to dwc:objectType would also be an option.
The mappings are going to be discipline-specific, so we have at least distinct mapping sets for (preserved) biology, geology and paleontology. DNA samples and living organisms have not been discussed (yet).
So the mapping in the SSSOM tsv file I linked means that "the MIDS element ObjectType, in the scope of this mapping set, exactly matches dwc:preparations". This may be different in other mapping sets, and may also (need to) change if Darwin Core changes.
I'm not against adding a property like objectType, building on the definitions in Latimer Core. But for now, I'll already be very happy if people use dwc:preparations [for preserved specimens], as it can already go a long way in making specimen data more interoperable. Hence I'd love to hear from Ben what additional needs he sees in paleontology that could be addressed by ObjectType.
Since this term is about items in a collection, would it not be nice if there is an equivalent for a single collection item in DwC as Ben suggests?
I'm still not very familiar with Latimer Core, but this question did prompt me to wonder whether data at the individual specimen level could be fully modeled using the Latimer Core terms and structure.
@matdillen 95% of specimens in earth sciences (geology, mineralogy) collections would fall into this category. All specimens have an object type, but not all specimens have a preparation. For biological collections, most specimens are prepared in some manner for preservation purposes. So little is lost in this regard. In geology, this is not the case. I have a 400 million-year-old limestone on my bookshelf. I don't need to prepare it any further for preservation purposes. Preparation is done for specific purposes such as powdering for a variety of analyses or taking a slice for a thin section. However, most specimens aren't and, therefore, wouldn't use the preparation field. I refer back to what @wouteraddink and Stephen Richard say. For paleontology, the landscape is more complicated. Preparation has a specific meaning, although usage is very broad. This seems contradictory, but it's not and indicative of the underlying issue. In general, preparation can be synonymous with preservation. Here, there are two types: natural and anthropogenic. Think of a bug in amber as natural and a specimen in a jacket as anthro. Then there's the object type, which gets awkwardly lumped in, but should not, which includes things like cast and trace fossil. Object type term would make this distinction clearer and help resolve the ambiguous term use.
from what I see in the examples form the LtC workshop given in the latest TDWG conference I see that objectType would be just "Specimen", so not below specimen level what Ben was looking for. It then has "MaterialEntity" as base type of the object group and "Preserved" as Type of object group (one of: Preserved, Living, Fossilized, Non-biological, Human-made).
In openDS we do the latter slightly different where we have LivingOrPreserved with values Living, Preserved and in addition topicOrigin with values "Natural", "Human-made", "Mixed origin". We do not have something for Fossilized but can have a combination of e.g. Preserved and Human-made. Most fossilized specimen can be found by topicDiscipline=Palaeontology and these are still preserved specimen. But there may be cases where a Palaeontology specimen is not fossilized which we cannot express currently in openDS. Nothing is perfect..
@wouteraddink What about rocks and minerals that are neither anthropogenic nor preserved? You are correct. The objectType for the examples provided during the workshop would be specimen. However, that's anecdotal. ObjectType could be many things—a video clip, image, physical object, piece of equipment, or powder in a small vial. I'm curious where the idea for a Living or Preserved originated. Rocks and minerals are neither. You might argue that a mineral is preserved, but then the question is 'what specifically is being preserved?' Nothing. Otherwise, everything is a preservation of something. As you said, nothing is perfect and earth sciences needs a larger presence. Regardless, these are good conservation. Challenging, but good nevertheless.
I'm curious where the idea for a Living or Preserved originated.
Since this didn't sound like a rhetorical question, I'll provide the background. The dwc:basisOfRecord term was an early addition (pre-standard) to Darwin Core to address the need to be able to filter Observations (HumanObservation and MachineObservation) from Physical Specimens (PreservedSpecimen), and while at it to also be able to filter Botanical Garden or Zoo Organisms (LivingSpecimen) and Fossil Specimens (FossilSpecimen) from the rest. In the pre-standard version it also allowed StillImage, MovingImage, and Sound from the Dublin Core type vocabulary that later were relegated to dc:type.
The earliest surviving term version can be used as a source to follow the evolution of the dwc:basisOfRecord term: http://rs.tdwg.org/dwc/dwcore/version/BasisOfRecord-2007-04-17.htm
I would add to John's explanation that the original context for the Darwin Core (and TDWG) was biodiversity; i.e., all the object types listed in John's note were examples of living or once-living things.
A short characterization of the things Ben described might be "untreated geo(logical) samples". 🤷♂️
On Wed, Oct 9, 2024 at 3:55 PM John Wieczorek @.***> wrote:
I'm curious where the idea for a Living or Preserved originated.
Since this didn't sound like a rhetorical question, I'll provide the background. The dwc:basisOfRecord term was an early addition (pre-standard) to Darwin Core to address the need to be able to filter Observations (HumanObservation and MachineObservation) from Physical Specimens (PreservedSpecimen), and while at it to also be able to filter Botanical Garden or Zoo Organisms (LivingSpecimen) and Fossil Specimens (FossilSpecimen) from the rest. In the pre-standard version it also allowed StillImage, MovingImage, and Sound from the Dublin Core type vocabulary that later were relegated to dc:type.
The earliest surviving term version can be used as a source to follow the evolution of the dwc:basisOfRecord term: http://rs.tdwg.org/dwc/dwcore/version/BasisOfRecord-2007-04-17.htm
— Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc/issues/517#issuecomment-2403561693, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACKZUDN767EKV7KPOSKWUQLZ2WX5HAVCNFSM6AAAAABKASFQOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTGU3DCNRZGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I would like to attempt a summary of the discussion in this issue so far in an effort to make it easier to assess and find a satisfactory solution.
A term is sought to categorize a dwc:MaterialEntity for what kind of physical object it is rather than a history of what it has been through. The term dwc:preparations allows both a type (as specific as you like) and something of its preparation and/or preservation history, but does not require both, nor either one individually. Because dwc:preparation CAN have the history part, it complicates the use of the term searches on a physical object category. A term to categorize based only on the physical object type is seen as a solution to ameliorate the search challenge somewhat.
On the other side of the categorization scale is the very restricted recommended controlled vocabulary for dwc:basisOfRecord, which, based on the community needs when created, has just five values that help to distinguish physical objects, MaterialEntity, MaterialSample, PreservedSpecimen, LivingSpecimen, and FossilSpecimen. The consensus is that more differentiation is needed than dwc:basisOfRecord can provide as currently recommended.
There is a lot of discussion about controlled vocabulary, but since none is actually being proposed, it might simplify assessment to not take that into consideration.
There are precedents for the needed term from related terms in Latimer Core, MIDS, and ABCD. The names for these are ltc:objectType, mids:ObjectType and abcd:KindOfUnit. Darwin Core lacks the needed term. The Latimer Core term ltc:objectType can not be borrowed for the needed Darwin Core term because ltc:objectType is a property of the ltc:ObjectGroup class, and a dwc:MaterialEntity is not an ltc:ObjectGroup.
I think the proposed name for the term, 'objectType' would be an unfortunate choice, because 'object' is an unfortunately ambiguous word in English. This, combined with the fact that we have a very well defined term in Darwin Core (dwc:MaterialEntity) for the class the proposed term is supposed to be organized in, suggests to me that the term should be called 'dwc:materialEntityType'.
I would go further and make the definition succinct and simple, such as 'The category that best matches the nature of a dwc:MaterialEntity', realizing that the 'best match' is going to be a community challenge based on how data providers want to express their holdings and what data users want to find. If we try to solve that challenge by trying to determine vocabulary in the minting of this term, it will almost assuredly mean that the term will not achieve a consensus and will not be included in the standard.
A good model for proceeding in the way I have just described is dwc:eventType. Its current definition is, 'The nature of the dwc:Event.' Its usage comments recommend a controlled vocabulary, but do not say what that should be. Its examples are few and carefully chosen. I would do the same for this new proposed term if you want to get it into circulation and thereby have a way in practice to let the community figure out how best to make it as useful as possible.
Sounds like a good solution to me and could also (in the long term) be beneficial for MIDS.
I agree with @tucotuco's suggestion. "object" has too many meanings and therefore could cause confusion about how to use the term. It would also allow for progress on a "next step" that was considered when the MaterialEntity class was created: having a term to describe more specifically what kind of MaterialEntity is intended. The controlled vocabulary could be developed later by careful examination of the types of material entities that the community needs to describe.
I'm also in favour of a field that helps us explicitly describe the nature of the specimen as it is now - using dwc:preparations for its history and a dwc:materialEntityType or similar would definitely support things like access requests. As it is people don't know that all we have is a skull when they're hoping for a wet specimen.
the term could also be used to make e.g. a distinction between specimen, specimen part and sample but that is a different interpretation from earlier given examples.
From the Latimer Core group we are in agreement with @ben-norton so from the LtC standpoint we are ok with this solution.
It makes sense to add a new term to DwC that allows dwc:preparations and the new term to capture more specific meaning. I support the proposal for dwc:objectType and alternatively can live with dwc:materialEntityType.
Definition of the term (normative): High-level terms for the classification of curated objects. Usage comments (recommendations regarding content, etc., not normative): A more generic classification of items in the collection than described in preparationType.
Definition I can live with the current definition and those proposed within this thread.
That said, please consider if some aspects of the following definition can provide more clarity to users on how to use the term. To not open a discussion that will be out of scope of this public review, the description could be used as/added to the usage comments:
"The type of stored object defined by its storage container and/or general state that you expect to find at a storage location."
The idea is to answer the question 'What kind of object will be found "on the self" if one walks into the collection space?' User of the term can provide hands-on, practical attributes classifying the stored curated objects. You will expect to find these kinds and types of objects when you go to and access their storage location.
Usage comments
A more generic classification ...
Keeping with the current approach of DwC as a bag of terms, I would remove any hinting at relationships between terms. Thus, I would remove this part from the usage comments. In addition, I don't see both terms as hierarchical, but rather describing different dimensions of meaning.
Term name
- The scope of Object Type is limited to physical objects, which are a subset of Material Entities. ...
That's not the case in my mind, though I am not sure how to approach this. I see ltc/ods:objectType as aligning with and expanding the essence of DCMI Type Vocabulary to our material entity types. Deciding about what might be a good approach to bridging between DwC and DC would require more thought and thus is out of scope here. Therefore, I can live with both, a dwc:objectType and a dwc:materialEntityType
Examples
Examples (not normative)
Given the above proposed list, these are the terms that I see suitable for guiding users:
Macro-object
Micro-object
Oversized object
Cut/polished gemstone
Mixed
Microscope slide
Macrofossil
Mesofossil
Microfossil
Oversized fossil
Proposal to add all or some of the below terms that are more applicable to biodiversity entities:
Core tube
Slide box
Pinned object/specimen
Unmounted body (not assembled)
Assembled body
Taxidermy mount
Paper package
Unpackaged object
Herbarium sheet
Blood sampling cards
Box
Vial rack
Eppendorf tube
SEM stub
Spore print carrier (eg. a piece of paper)
Storage container -- for ltc:materials of eg. water ice, liquid water, non-aqueous liquid material, liquid or gaseous matter sample, etc.
[Human-made] Artefact
Remove since more aligned with ltc:material and further semantic dimensions:
Core -- see Core tube
Specimen
Tissue
Culture
HTS Library
Lysate
Fluid
Environmental sample
Extracted/Preserved DNA/RNA
Spore print -- see Spore print carrier
Remove since not material, but belonging to DCMI:
Audio
Visual
Unrelated to the description of a material/digital type:
Hazardous material/object
I am in favor of renaming this term dwc:materialEntityType and the definition proposed above by @tucotuco. It might be helpful to update the issue description if the community consensus is trending this direction, which the above comments make it seem like it is.
I think there's been general agreement to @tucotuco's suggestion to rename the term to dwc:materialEntityType.
There hasn't been any reaction to @jbstatgen's suggested changes to the examples list. Any comments on this?
The examples have been revised in compliance with the feedback provided. @jbstatgen I integrated nearly everything you recommended. Please comment on whether you are satisfied with the compromise when you have an opportunity.
@ben-norton , thanks for updating the example terms. In the spirit of compromise, go ahead with the updates to the examples and the proposed changes to the term name and definition by @tucotuco . The new term will be a substantial improvement to the current state, which is much needed.
Though, we also need to be realistic that the term and the data that it will produce won't be sufficiently fit to provide the well-structured, information-rich data needed for globally monitoring progress towards the Kunming-Montreal Global Biodiversity Framework of the CBD.
As community, we (still) have the experts who are able to tackle such a complex, multidimensional and hierarchical/networked ontology to describe the material/digital entities that provide evidence about reality. However, we don't have the resources. The fate of the Material Sample task group seems to provide proof for the need for paid full-time engagement within the scope of TDWG's work area. We were a highly proficient, engaged and productive group with solid contributions, though we couldn't arrive at a shared synthesis, since everyone had to do this on the side. Furthermore, a significant number of members were on non-permanent employment, working independently or had reached retirement. With some of these experienced members having already dropped away from the TDWG community, the community is loosing expertise and its chances for (intergenerational) knowledge transfer. It's high time to do something about this ongoing loss of capacity.
Update Proposed attributes of the new term after consensus:
- Term name (in lowerCamelCase for properties, UpperCamelCase for classes): materialEntityType
- Term label (English, not normative): Material Entity Type
- Organized in Class (e.g., Occurrence, Event, Location, Taxon): MaterialEntity
- Definition of the term (normative): A category that best matches the nature of a dwc:MaterialEntity.
- Usage comments (recommendations regarding content, etc., not normative): A more generic classification of a dwc:MaterialEntity than dwc:preparations. Recommended best practice is to use a controlled vocabulary. This term has an equivalent in the dwciri: namespace that allows only an IRI as a value, whereas this term allows for any string literal value.
- Examples (not normative):
Macro-object;Micro-object;Oversized object;Cut/polished gemstone;Compound Specimen;Core;Mixed Materials;Environmental sample;Microscope slide;Spore print;Macrofossil;Mesofossil;Microfossil;Pinned object/specimen;Taxidermy mount;Blood sampling cards;Oversized fossil;Anthropogenic Artifact - Refines (identifier of the broader term this term refines; normative): Not applicable
- Replaces (identifier of the existing term that would be deprecated and replaced by this term; normative): Not applicable
- ABCD 2.06 (XPATH of the equivalent term in ABCD or EFG; not normative): skos:closeMatch to /DataSets/DataSet/Units/Unit/KindOfUnit. ABCD structural considerations prevent an exactMatch.
I am not sure what the eventual plan would be for creating a controlled vocabulary for this, but again we are suggesting values that are difficult to control (containing upper and lower case, spaces, dashes, etc.). If there would be a plan to eventually create a controlled vocabulary, I would hope that we would follow the lowerCamelCase convention that we've used in other controlled vocabularies that we've created. What is listed here looks more like free text to me.
I am with @baskaufs , but, given that these are types, I'd suggest Pascal case (or UpperCamelCase) will be more appropriate.
@baskaufs @nielsklazenga I agree, but we need a new process or a simplified route using the current processes to ratify controlled value lists, especially given the new Assertions class in DwC DP. I agree with @nielsklazenga but thats a minor issue compared to the metadata, structure, and distribution. The current standards ratification process is far too cumbersome for a controlled value list. Its excellent for standards, but it needs to be adjusted for value lists. Also, there are value lists suitable for this term in existence. Its just a matter of community synergy. I'm working on it, but it's a process. Anyway, this is a much larger discussion for the months ahead.
some additional example controlled vocabs for this term: biologicalMaterialSample, fluidInContainer, non-biologicSolidObject, researchProduct (this vocab is currently used in DiSSCo specimen FDO profile) and, how I would like it to be if we had the metadata or an AI that could classify the material entity this way: anthropogenicArtifact, environmentalSample, fossil, gasPreservationSample, inanimateSolidMaterial, liquidPreservationSample, organismPart, organismProduct, preparationArtifact, recordingBearingObject, wholeOrganismSpecimen