New Term - objectType

[ben-norton]

New term

• Submitter: Ben Norton
• Efficacy Justification (why is this term necessary?):

1. 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).
2. Enables better mapping to Latimer Core (objectType is a property in LtC and an exact Match to the term proposed here).
3. 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

1. 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.

2. Improving Interoperability among TDWG standards.

3. 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.

4. 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.

5. Material Entity is a broad match to ltc:objectType, MIDS objectType, and ABCD kindOfObject.

6. ObjectGroup is one of two required classes in ltc. For interoperability purposes, an exact match for objectType is crucial.

7. 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.

8. 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.

[tucotuco]

Material Sample Task Group investigated, but abandoned as out of scope, the consideration of a MaterialEntity type term (see tdwg/material-sample#33 and tdwg/material-sample#14) and a controlled vocabulary for it (tdwg/material-sample#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.

[ben-norton]

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.

[cboelling]

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.

[ben-norton]

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.

[matdillen]

@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.

[wouteraddink]

@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.

[matdillen]

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.

[ben-norton]

@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.

[wouteraddink]

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..

[ben-norton]

@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.

[tucotuco]

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

[stanblum]

I would add to John's explanation that the original context for the Darwin Core (and TDWG) was *bio*diversity; 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 <#517 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKZUDN767EKV7KPOSKWUQLZ2WX5HAVCNFSM6AAAAABKASFQOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTGU3DCNRZGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>