tdwg / dwc

Darwin Core standard for sharing of information about biological diversity.
https://dwc.tdwg.org
Creative Commons Attribution 4.0 International
204 stars 70 forks source link

New term - tribe #45

Closed tucotuco closed 1 year ago

tucotuco commented 9 years ago

Was https://code.google.com/p/darwincore/issues/detail?id=147

==New Term Recommendation== Submitter: David Remsen

Justification: Many taxa belong to large taxonomic families, particularly among the insects but also among other animal and plant groups. Often the 'interesting' components of the classification are operating at the sub-familial-and-below level. In order to effectively capture this more refined classification information, I recommend the addition of tribe (and sub-tribe).

Definition: The full scientific name of the tribe in which the taxon is classified.

Comment: Examples "Ortaliini", "Arethuseae"

Refines:dwc:Family

Has Domain: http://rs.tdwg.org/dwc/terms/Taxon

Has Range:

Replaces:

ABCD 2.06:

Oct 3, 2013 comment #5 gtuco.btuco I would like to promote the adoption of the concept mentioned in this issue. To do so, I will need a stronger proposal demonstrating the need to share this information - that is, that independent groups, organizations, projects have the same need and can reach a consensus proposal about how the term should be used. It might be a good idea to circulate the proposal on tdwg-content and see if a community can be built around and support the addition.

ammatsun commented 9 years ago

+1 with evidence for the need of this term from iDigBio data

peterdesmet commented 4 years ago

This proposal needs more evidence for demand (see the Vocabulary Maintenance Specification - Section 3.1). Anybody who is interested in the adoption/change of this term, should comment with their use case below. If demand is not demonstrated by the next annual review of open proposals (late 2020), this proposal will be dismissed.

ianengelbrecht commented 4 years ago

Entomologists use tribes quite a lot. If the field was available to them they would potentially populate it.

WUlate commented 3 years ago

+1 From World Flora Online project to harvest DwCA files from content providers and ideally provide taxonomic data to Catalogue of Life and GBIF we've been using:

<field index="8" term="http://rs.emonocots.org/terms/subfamily"/>
<field index="9" term="http://rs.emonocots.org/terms/tribe"/>
<field index="10" term="http://rs.emonocots.org/terms/subtribe"/>

And also:

<field index="28" term="http://rs.worldfloraonline/terms/majorGroup"/>
<field index="29" term="http://rs.worldfloraonline/terms/tplID"/>

As far as I know, these IRI's are not from "real" namespaces...

chicoreus commented 3 years ago

We capture Tribe in MCZbase, and about 15& of our taxonomy records currently have a value for tribe, the majority of these are insects, and about 45% of our insect taxonomy records currently have a value for tribe.

tucotuco commented 3 years ago

Closing for lack of demand.

dhobern commented 3 years ago

I certainly include superfamily and tribe in the columns for the datasets I share for insect families - these are enormously informative taxonomic ranks in the hyperspeciose insect orders. Not having these ranks would be like losing genus and order from classification in Mammalia. I would note that large numbers of iNaturalist observations are identified only to superfamily or tribe.

Niels is correct that we can (and perhaps should) normalise into a hierarchical model rather than relying on convenience terms, but these are two ranks that are very heavily used in entomology.

mdoering commented 3 years ago

I would hope we can reopen the ticket and include this term together with superfamily in the April Fools Rush

tucotuco commented 3 years ago

As with the call for superfamily, if we can get support from iNaturalist or any other group needing to share these data, we will have shown sufficient evidence for demand.

On Tue, Apr 20, 2021 at 11:56 AM Markus Döring @.***> wrote:

I would hope we can reopen the ticket and include this term together with superfamily in the April Fools Rush https://github.com/tdwg/dwc/milestone/14

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc/issues/45#issuecomment-823342566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQ724UITCYQAJ4YPYPQDLTJWI2ZANCNFSM4AXK6XGQ .

deepreef commented 3 years ago

Keep in mind this is a slippery slope. In fishes, the main higher ranks not included in DwC are subfamily and suborder. If we want to go down this path, then there are probably at least a half-dozen (or more) new ranks we're going to want to add. I already wrote about this on a discussion about infraspecificEpithet (which I can't seem to find now). I think the better way to handle all these intermediate ranks is through parentNameUsage/parentNameUsageID. However, if we really want to accommodate more ranks in a flat form, then I would recommend creating a single new term higherClassification that would function in a way that is analogous to the existing term higherGeography. Something like:

If we wanted to include ranks, we could alter the Comments and examples to yield something like: Kingdom:Animalia|Superphylum:Deuterostomia|Phylum:Chordata|Subphylum:Craniata|Superclass:Gnathostomata|Class:Actinopterygii|Order:Perciformes|Suborder:Labroidei|Family:Pomacentridae|Subfamily:Chrominae

mdoering commented 3 years ago

https://dwc.tdwg.org/terms/#dwc:higherClassification which misses the rank and thus makes it very hard to use in reality.

tucotuco commented 3 years ago

@deepreef You mean... https://dwc.tdwg.org/terms/#dwc:higherClassification?

On Tue, Apr 20, 2021 at 2:01 PM Richard L. Pyle @.***> wrote:

Keep in mind this is a slippery slope. In fishes, the main higher ranks not included in DwC are subfamily and suborder. If we want to go down this path, then there are probably at least a half-dozen (or more) new ranks we're going to want to add. I already wrote about this on a discussion about infraspecificEpithet (which I can't seem to find now). I think the better way to handle all these intermediate ranks is through parentNameUsage/parentNameUsageID. However, if we really want to accommodate more ranks in a flat form, then I would recommend creating a single new term higherClassification that would function in a way that is analogous to the existing term higherGeography. Something like:

-

Definition: A list (concatenated and separated) of taxonomic names at higher rank than the information captured in the scientificName term.

Comments: Recommended best practice is to separate the values in a list with space vertical bar space ( | ), with terms in order from highest rank to lowest rank.

Examples: Animalia | Deuterostomia | Chordata | Craniata | Gnathostomata | Actinopterygii | Perciformes | Labroidei | Pomacentridae | Chrominae (with accompanying values Animalia in kingdom, Chordata in phylum, Actinopterygii in class, Perciformes in order, and Pomacentridae in family.

If we wanted to include ranks, we could alter the Comments and examples to yield something like:

Kingdom:Animalia|Superphylum:Deuterostomia|Phylum:Chordata|Subphylum:Craniata|Superclass:Gnathostomata|Class:Actinopterygii|Order:Perciformes|Suborder:Labroidei|Family:Pomacentridae|Subfamily:Chrominae

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc/issues/45#issuecomment-823447387, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQ72Z7LUGZW6YK36S7NJ3TJWXNZANCNFSM4AXK6XGQ .

mdoering commented 3 years ago

For sharing taxonomic data the ID based terms are clearly superior and should be strongly recommended. The need for the terms are more in spreadsheet, human faced applications and in GBIF with its large, flat view on occurrences.

deepreef commented 3 years ago

Ha! I thought it was already there! I looked for it, but couldn't find it (I must be going blind -- actually, I am sorta going blind, but that's another story). Anyway, OK, let me rephrase my comment:

However, if we really want to accommodate more ranks in a flat form with values linked to specific ranks, then I would recommend modifying the definition and examples for higherClassification to something like:

Definition: A list (concatenated and separated) of taxa names and their corresponding ranks terminating at the rank immediately superior to the taxon referenced in the taxon record.

Comments: Recommended best practice is to represent each value as a key:value pair in the form of rank:name, with each pair separated in a list with space vertical bar space ( | ), with terms in order from highest rank to lowest rank.

Examples: Kingdom:Animalia | Superphylum:Deuterostomia | Phylum:Chordata | Subphylum:Craniata | Superclass:Gnathostomata | Class:Actinopterygii | Order:Perciformes | Suborder:Labroidei | Family:Pomacentridae | Subfamily:Chrominae (with accompanying values Animalia in kingdom, Chordata in phylum, Actinopterygii in class, Perciformes in order, and Pomacentridae in family.

deepreef commented 3 years ago

I know we don't normally do two-level structure for content presented as DwC terms; but I really think that adding more rank-specific terms could get out of hand. For example, some groups use subclass frequently. If we leveled this out for all taxa, we'd probably end up with (at least) all the "subs" and "supers" as new terms, and maybe a few others as well. I guess the question is, would it be too cumbersome for most data consumers to parse out a key-value pair structure like the one proposed above? If it's not too cumbersome, then maybe we can think about (eventually) deprecating the existing higher-rank terms (although it's probably worth keeping at least kingdom and family, as those are used often enough that it would be nice to be able to filter them without having to parse them.

On the one hand, DwC is a data exchange system, not a normalized data model, so it should be optimized for sharing information in a standard package. In that context, the additional step of concatenating on the provider side and parsing on the consumer side seem minimal.

On the other hand, DwC content providers aren't known for consistently following "Recommended best practice" when formatting DwC content, so the utility of such a structured way of presenting information like this could be diminished if there are a large number of providers who don't structure the content correctly.

tucotuco commented 3 years ago

Not that I am promoting this as a solution, but if one were to go so far as to create key:value pairs for higher taxa, the dynamicProperties term already recommends that type of encoding and we could get rid of higherClassification altogether.

On Tue, Apr 20, 2021 at 2:21 PM Richard L. Pyle @.***> wrote:

I know we don't normally do two-level structure for content presented as DwC terms; but I really think that adding more rank-specific terms could get out of hand. For example, some groups use subclass frequently. If we leveled this out for all taxa, we'd probably end up with (at least) all the "subs" and "supers" as new terms, and maybe a few others as well. I guess the question is, would it be too cumbersome for most data consumers to parse out a key-value pair structure like the one proposed above? If it's not too cumbersome, then maybe we can think about (eventually) deprecating the existing higher-rank terms (although it's probably worth keeping at least kingdom and family, as those are used often enough that it would be nice to be able to filter them without having to parse them.

On the one hand, DwC is a data exchange system, not a normalized data model, so it should be optimized for sharing information in a standard package. In that context, the additional step of concatenating on the provider side and parsing on the consumer side seem minimal.

On the other hand, DwC content providers aren't known for consistently following "Recommended best practice" when formatting DwC content, so the utility of such a structured way of presenting information like this could be diminished if there are a large number of providers who don't structure the content correctly.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc/issues/45#issuecomment-823462093, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQ722FH4QETWWSCCL2NA3TJWZZNANCNFSM4AXK6XGQ .

deepreef commented 3 years ago

Not that I am promoting this as a solution, but if one were to go so far as to create key:value pairs for higher taxa, the dynamicProperties term already recommends that type of encoding and we could get rid of higherClassification altogether.

Huh... excellent point! I wasn't familiar with that term (if I was, I would have proposed the same structure). So... might this also apply to higherGeography? Or is that term more intended to capture an unstructured text blob (as opposed to greater granularity than the individual Location terms?

tucotuco commented 3 years ago

I don't want to open up much of a discussion here about higherGeography, but it is to accommodate geographic concepts that include all of the existing atomic terms and those not covered by the atomic geography terms. Examples would be protected areas, map quads, administrative areas that are no longer used (USSR, Yugoslavia, etc.) and are the most specific avalable, even more specific administrative geography that level 3 (covered by the municipality term), etc.

On Tue, Apr 20, 2021 at 3:33 PM Richard L. Pyle @.***> wrote:

Not that I am promoting this as a solution, but if one were to go so far as to create key:value pairs for higher taxa, the dynamicProperties term already recommends that type of encoding and we could get rid of higherClassification altogether.

Huh... excellent point! I wasn't familiar with that term (if I was, I would have proposed the same structure). So... might this also apply to higherGeography? Or is that term more intended to capture an unstructured text blob (as opposed to greater granularity than the individual Location terms?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc/issues/45#issuecomment-823509177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADQ7254C4NGADWVJSOFJTDTJXCHTANCNFSM4AXK6XGQ .

deepreef commented 3 years ago

Yeah -- I just wasn't sure how consistently people tracked the "key" part of the key:value pair for the higher geography. The taxon ranks are pretty standard, but perhaps higherGeography is a place where users put something more akin to "verbatim" locality data, less easily converted into a key:value structure.

mdoering commented 1 year ago

I would like to reopen this issue as tribe is an important rank and there is an open issue subtribe which makes no sense without a tribe term.

mdoering commented 1 year ago

Another party using tribe already in a different namespace is WFO. See latest dwca download for their meta.xml from which I quote an excerpt here:

    <field index="7" term="http://rs.tdwg.org/dwc/terms/family"/>
    <field index="8" term="http://rs.emonocots.org/terms/subfamily"/>
    <field index="9" term="http://rs.emonocots.org/terms/tribe"/>
    <field index="10" term="http://rs.emonocots.org/terms/subtribe"/>
    <field index="11" term="http://rs.tdwg.org/dwc/terms/genus"/>
    <field index="12" term="http://rs.tdwg.org/dwc/terms/subgenus"/>
DaveNicolson commented 1 year ago

Sorry for cross-posting this... I was alerted to the discussions about proposed new ranks (superfamily, subfamily, tribe and subtribe), and thought it might be good to note that there is a fair amount of use of these ranks in ITIS, especially in Animalia. In that kingdom, here are the counts of the valid/accepted names at those ranks, as a quick data point:

rank_name Animalia Superfamily 577 Subfamily 2534 Tribe 1634 Subtribe 176

Clearly, some are in use more than others. I would argue that the superfamily level and subfamily level are not at all uncommon, particularly in some groups.

ianengelbrecht commented 1 year ago

GlobalNames has a nice way of doing this. The taxon names are in one field, and essentially match the current definition of dwc:higherClassification, e.g.:

Animalia|Deuterostomia |Chordata|Craniata|Gnathostomata|Actinopterygii |Perciformes|Labroidei|Pomacentridae|Chrominae

Then there’s another field that indicates the corresponding ranks. Perhaps we could add a term like this to Darwin Core, something like dwc:higherClassificationRanks, with:

Kingdom|Superphylum|Phylum|Subphylum| Superclass|Class|Order|Suborder| Family| Subfamily

On Wed, 09 Nov 2022 at 20:45, DaveNicolson @.***> wrote:

Sorry for cross-posting this... I was alerted to the discussions about proposed new ranks (superfamily, subfamily, tribe and subtribe), and thought it might be good to note that there is a fair amount of use of these ranks in ITIS, especially in Animalia. In that kingdom, here are the counts of the valid/accepted names at those ranks, as a quick data point:

rank_name Animalia Superfamily 577 Subfamily 2534 Tribe 1634 Subtribe 176

Clearly, some are in use more than others. I would argue that the superfamily level and subfamily level are not at all uncommon, particularly in some groups.

— Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc/issues/45#issuecomment-1309208813, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACH3QI2XYHLBUWTOCA7ZIX3WHPWODANCNFSM4AXK6XGQ . You are receiving this because you commented.Message ID: @.***>

-- Ian Engelbrecht Digitization Coordinator Natural Science Collections Facility South Africa https://nscf.org.za/ https://nscf.org.za/ +27 82 763 4596 i @.**@. / @.***

JCGiron commented 1 year ago

I support adding the tribal rank to DwC. In some Neotropical beetle groups it is difficult to identify genera (lack of keys and identification resources), but in collections there are specimens identified to subfamilies and tribes. Being able to document the tribe in a dataset, or harvest data only associated with a particular tribe would be useful, since it would provide/recover more specific datasets than those recorded only to family or subfamily levels.