How we reviewed the origianlly proposed HC Vocabulary terms

This page describes how we proceeded within the Task Group for the review of the HC terms. We worked using the latest HC_terms vocabulary file, which can be found in the vocabulary folder.

Table of Contents

1. Understanding the csv vocabulary file
2. What should I do with the vocabulary file

🍄 Understanding the csv vocabulary file

This file was provisional. It included both the elements that would be required to formalize HC as an extension and other elements to aid in discussions. The final version of the file only keeps entries for the terms included in the Humboldt extension (i.e., no DwC terms that are in the Event Core, no EML terms, no deprecated terms), and only the columns under the two last categories (see below).

The csv has a series of columns, each described as follows:

Background columns: intended to provide context for discussions.

category: general categorization of the terms, meant only for working purposes. Categories may later be defined as 'classes' or be used loosely in the vocabulary quick reference guide to group terms.

original_HC_label: term labels as originally given in Humboldt Core paper.

original_HC_definition: term definitions as originally given in Humboldt Core paper.

current_termName: term names currently in use to test the extension in IPT.

Review columns:

review_decision: decisions taken during the review. Intended to track destination of original HC terms. The values in this column can be one of the following:

• deprecate: get rid of this term altogether.
• deprecate/indirect mapping: get rid of this term as a separate term as it would be indirectly mapped to a DwC term.
• EML: term maps to EML
• direct mapping to DwC: term maps to existing DwC term in the Event Core.
• HC term: term to include in the HC extension.
• HC term *borrowed: term that maps to an existing DwC term NOT included in the Event Core, so would be included in the HC extension as dwc:blaBla.
• Needs group review – self-explanatory, I hope :)

notes: comments about the decision taken for the terms, including term name changes. Includes links to relevant GitHub issues in the HC repo and DwC repo as appropriate.

Columns for latest proposed term names, definitions, comments and examples:

term_localName and label: latest proposed names and labels for the terms. In some cases, they will match the current names (the ones we are using right now in the extension to test in IPT). In some other cases we have proposed new names, and we have noted that in the “notes” column.

rdfs_comment [DEFINITION]: latest proposed definitions for the terms.

dcterms_description [COMMENTS]: latest proposed comments to accompany the terms, e.g., about their usage.

examples: latest proposed examples to accompany the terms.

Other columns

rdf_type: indicates if the term is a property or a class.

tdwgutility_abcdEquivalence: indicates equivalences with the ABCD standard – dismiss this column for now.

tdwgutility_organizedInClass: class in which terms are organized. We have not defined new classes (yet, but see this ISSUE), so for the moment these are loose matches to existing DwC classes.

tdwgutility_decision: indicates decision taken by the TDWG Executive – dismiss this column for now.

tdwgutility_usageScope: indicates if the terms are to be part of a core (“simple”) or an extension (“extension”). For our purposes “simple” means the term is in the Event Core, and “extension” means it would be part of the Humboldt extension.

🍄 What should I do with the vocabulary file?

📢 NOTHING RIGHT NOW! We are at the testing phase

1. Look at it (crying allowed...)

2. Review each term, paying attention to the notes. Don’t take anything for good, check all columns and shoot to kill.

3. If you have concerns, comments, suggestions about a term, or set of terms:

   a. Check if there are issues about them already in the repo and add to those issues. Issues may be linked in the notes column, but new issues may have also been added by others after this file was uploaded, so please check for those as well.

   b. If there are no issues related to the term(s) in question, please build a new issue in the repo.

4. You DO NOT need to modify the Vocabulary file, the update will be done periodically to gather everyone’s perspectives.

General notes:

• For the terms that are mapped directly to Darwin Core, the definitions, comments and examples are taken directly from Darwin Core. If you think any modifications should be made, there are two possible routes:

1. Suggest changes to Darwin Core

   Standards have normative and non-normative parts.

   • To change normative parts a formal process must be followed, which involves not just proposing the changes, but that those changes are requested from 2 or more independent parties, and that the changes go through a series of reviews including a 30 days community review period.

   • Non-normative parts can be changed more easily, as they only go through the review of the standard Maintenance Interest Group.

   In Darwin Core, definitions of the terms are normative, while comments and examples are non-normative.

2. Propose a new term within Humboldt Core (consider avoiding overlap with DwC specially where differences are small / trivial).

• Please consider that the terms that we define may need to accommodate different hierarchy levels in a sampling event (from summary inventories to transects within plots within zones within sites).