TG2-AMENDMENT_SCIENTIFICNAMEID_FROM_TAXON about bdq HOT 45 OPEN

• I have corrected a stray bracket in the ER.
• Quoting @ArthurChapman "If accepted it appears that we can take dwc:genericName and dwc:infragenericEpithet out of Information Elements". True for dwc:infragenericEpithet (done) but not so for dwc:genericName as it is in the current ER.

Are we all happy with the specifications on this one now?

from bdq.

We should add taxonRank to the list of fields for this and #70 . It is especially important for the interpretation of monomials in scientific name absent other supporting data.

from bdq.

In going through the data, there is an anomaly that is fixed if we accept the last suggested Expected Response from @chicoreus. I have just moved the "if dwc:taxonID is not EMPTY" to the start of the INTERNAL_PREREQUISITES_NOT_MET list as it makes parsing simpler.

from bdq.

So the text of cultivarEpithet should also be found in scientificName?

Yes, I think it should. But for a definitive answer it is best to ask someone such as @mdoering and @ nielsklazenga.

from bdq.

Why don't we have an "EXTERNAL_PREREQUISITES_NOT_MET" if we reference bdq:sourceAuthority?!

I've added it as otherwise it will stuff up the test data work.

from bdq.

I have added to the Notes to be consistent with #71:

"When referencing a GBIF taxon by GBIF's identifier for that taxon, use the the pseudo-namespace "gbif:" and the form "gbif:{integer}" as the value for dwc:taxonID."

from bdq.

Comment by Paul Morris (@chicoreus) migrated from spreadsheet:
Moving from scientificName as a string to a link to a guid in a taxonomic or nomenclatural authority is key for moving towards linked open data and other semantic delivery of biodiversity data. There is almost never enough data in flat Darwin Core to fill in any of the other ID terms in the Taxon class, but it is often possible to link scientific name strings to nomenclatural or taxonomic records.

from bdq.

@godfoder I concur. Do we need to specify a more complex set of prerequisites?

from bdq.

A couple of issues for implementation:

Acton to take when taxonID is NOT_EMPTY: The specification is mute on what action to take when dwc:taxonID has a value. Since other tests specify CHANGED only if term that is proposed to be amended is NOT_EMPTY, the implication is that an amendment is to be proposed, for purposes such as conforming taxonID values to a national authority. This should probably be spelled out in the notes section.

Extraneous terms in the list of Information Elements: The specification states that a proposed amendment should be based on "on the basis of the value of the lowest ranking not EMPTY taxon classification terms dwc:scientificName, dwc:scientificNameAuthorship, dwc:kingdom, dwc:phylum, dwc:class, etc.", with @godfoder's comment clearly indicating that taxonRank should be included in this list. The notes imply that none of the other ID terms (dwc:scientificNameID, dwc:acceptedNameUsageID, dwc:originalNameUsageID, dwc:taxonConceptID) should be included in this analysis, so it seems that they shouldn't be included in the informationElements, unless there is a clear specification of how to include them to infer a value of taxonID. Also, neither dwc:higherClassification nor dwc:vernacularName are included in the specification, and thus don't seem to fit in the list of information elements.

from bdq.

Further to the logic of @chicoreus - I don't understand the inclusion of dwc:scientificNameAuthorship as it isn't a taxon classification term in the hierarchy, and that and that field alone could not supply a taxonID.

from bdq.

@ArthurChapman I see scientificNameAuthorship as an essential term for identifying which taxonID to use, it can often disambuguate homonyms and if the authorship string associated with the source record for taxonID isn't the same as the authorship string in a record under consideration, then something likely isn't correct and an assertion of of a taxonID match is not a good one to make.

from bdq.

@chicoreus - that is correct, but it may need us to reword the test, because as written, I don't see how that field could work as dwc:scientificNameAuthorship is not strictly a classification term. dwc:scientificName should include the authorship and thus could be used to resolve the taxonID. It probably applies to a different test to use the dwc:scientificNameAuthorship to fix dwc:scientificName but as this test is written then the dwc:scientificNameAuthorship on its own doesn't work. I don't see that term belong in this test.

from bdq.

@ArthurChapman Yes, rewording would be good. Point well taken that the information should be in scientificName and scientificNameAuthorship should be a parse of that rather than a classification term. Pragmatically, scientificNameAuthorship makes for easier removal parsing of the canonical name and authorship part of scientificName when it contains both, (and often, despite the definitions, it doesn't), and services tend to return better results when queried just on canonical name and then have the results examined for similarity of authorship strings. A huge amount of the variability in the wild is in the authorship strings, people's names abbreviated or not, punctuation variability, presence and absence of prefixes, suffixes, and honorifics, and in animal names, the presence or absence of years, etc. Implementation logic needs to deal with this in a consistent way, not farming it off to what may or may not be returned from a particular services when given a value found in dwc:scientificName.

from bdq.

I defer to those far more expert on names to reword the Expected Response and tune the Information Elements accordingly. I do however offer two comments on general issues relating to this AMENDMENT-

While the precursor VALIDATION #105 tests for dwc:taxonID EMPTY, as I remember it, the 'tests' should be 'stand alone' so we should be explicit here.

I dislike the use of "etc" in the current Expected Response as these provide explicit rules for implementation. If we need to refer to a dwc term, then we MUST specify it.

from bdq.

I still greatly dislike the "etc" in the Expected Response. Related: I also don't like Information Elements that are missing from the Expected Response. We must to provide concise unambiguous instructions on this test (and in the test data where I revisited this), and as I am unsure how for example dwc:infraspecificEpithet comes into this...I'll leave to the NAME gurus.

from bdq.

This is a very difficult one. Suggested change from (may need tweaking):

EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority was not available; INTERNAL_PREREQUISITES_NOT_MET if all of dwc:kingdom, dwc:phylum, dwc:class, dwc:order, dwc:family, dwc:genus, and dwc:scientificName are EMPTY; AMENDED if a value for dwc:taxonID is unique and resolvable on the basis of the value of the lowest ranking not EMPTY taxon classification terms dwc:scientificName, dwc:scientificNameAuthorship, dwc:kingdom, dwc:phylum, dwc:class, etc.; otherwise NOT_AMENDED

to

EXTERNAL_PREREQUISITES_NOT_MET if the bdq:sourceAuthority was not available; INTERNAL_PREREQUISITES_NOT_MET if all of dwc:kingdom, dwc:phylum, dwc:class, dwc:order, dwc:family, dwc:genus, dwc:genericName, dwc:specificEpithet and dwc:scientificName are EMPTY or if dwc:taxonId is not EMPTY; AMENDED if a value for dwc:taxonID is unique and resolvable on the basis of the value of dwc:scientificName, dwc:acceptedNameUsageID, or dwc:origionalNameUsageID, or an unambiguous combination of any of the lowest ranking not EMPTY taxon classification terms dwc:infraspecificEpithet, dwc:cultivarEpithet, dwc:specificEpithet, dwc:infragenericEpithet, dwc:genus, dwc:genericName, dwc:subfamily, dwc:family, dwc:class, dwc:order, dwc:phylum, dwc:kingdom, dwc:higherClassification, dwc:vernacularName, in conjunction with dwc:scientificNameAuthorship and dwc:taxonRank; otherwise NOT_AMENDED

Some of my thinking:
1). in the INTERNAL_PREREQUISITES_NOT_MET - dwc:subfamily dwc:subgenericEpithet, dwc:subfamily, dwc:infraspecificEpithet, etc. cannot on their own give you the TAXONID. With dwc:infraspecificEpithet, for example - you'd need to have at least the dwc:species.
2. I have added dwc:genericName and dwc:specificEpithet the former is new - the latter was missing in previous version.
3. I have added dwc:taxonId is not EMPTY (it was missing in the previous version - but you aren't going to change it if it already has a TAXONID.
4). The taxonID could be obtained from dwc:scientificName, dwc:acceptedNameUsageID, or dwc:origionalNameUsageID without any other information (they all include the authorship information, etc.). All the others require a combination of two or more terms and in conjunction with dwc:scientificNameAuthorship if there are homonyms to separate them.
5). I am not sure where dwc:taxonRank should fit within that formula. I don't think it is correct where it is, and it is not a "classification term" so doesn't belong with the others.

Good luck with getting your heads around this one.

@Tasilee - if accepted it will need some work for the examples.

from bdq.

@chicoreus @tucotuco - does dwc:taxonConceptId come into this anywhere - i.e. to help distinguish the Taxon ID - it would possibly by beside dwc:scientificNameAuthorship and dwc:taxonRank in the "conjunction with" area. I'd prefer to leave it out.

from bdq.

Thanks @ArthurChapman. My eyes glaze over when it comes to names. I have enough understanding to be dangerous. I therefore defer to @ArthurChapman, @chicoreus, @tucotuco and hopefully a few more watching on for advice, or thumbs up etc.

As it stands, your Expected Response is at least explicit. My only quibble may be the use of "in conjunction with ...". How?

from bdq.

@Tasilee. We suggested "in conjunction with" in the ZOOM call. It means that if there is a homonym (possibly in different Kingdoms, or even within a genus) - then you would need "the lowest ranking taxon term" in conjunction with "dwc:scientificNameAuthorship" to separate the homonyms to get a TAXONID. This is not the case with dwc:scientificName for example, as this contains the Authorship by definition.

from bdq.

This would at least need to be in the Notes then?

from bdq.

@Tasilee - sounds reasonable - I suggest we will do Notes after we agree on the wording of the Expected Response.

from bdq.

@Tasilee I can't see the suggested Expected Response from @chicoreus to which you refer. You seem to have added my suggestion - but I am still not sure about the placement of dwc.taxonRank in the Reponse,

dwc:subfamily, dwc:genericName, dwc:infragenericEpithet and dwc:cultivarEpithet need to be added to the Information Elements and we should add something to the Notes as suggested by you above. Suggest instead of

[bdq:sourceAuthority default = GBIF Backbone Taxonomy]. (Currently found at: https://www.gbif.org/en/developer/species). This is the taxonID inferred from the Darwin Core Taxon class, not from any other sense of Taxon. Return a result with no value and a result state of ambiguous if the information provided does not resolve to a unique result (e.g. if homonyms exist and there is insufficient information in the provided data to resolve them)

we use

[bdq:sourceAuthority default = GBIF Backbone Taxonomy]. (Currently found at: https://www.gbif.org/en/developer/species). This is the taxonID inferred from the Darwin Core Taxon class, not from any other sense of Taxon. Return a result with no value and a result state of ambiguous if the information provided does not resolve to a unique result (e.g. if homonyms exist and there is insufficient information in the provided data, for example using the lowest ranking taxa in conjunction with dwc:dwc:scientificNameAuthorship, to resolve them).

from bdq.

@ArthurChapman for "Return a result with no value and a result state of ambiguous", we've moved away from using ambiguous as a Response.status, so this would be Response.status of NOT_AMENDED and ambiguous in the Response.comment or the proposed Response.qualifier extension (this makes a good example of a Response.qualifier=AMBIGUOUS being a good structured qualifier for the Response, with more details in the Response.comment). (Also noting, we seem to be settling on Response.result instead of Response.value or result value)

@ArthurChapman I'm not seeing it either (checked recent email threads), @Tasilee was the latest expected response from me something you wrote down in the last call?

from bdq.

OK - I will make a change in the Notes to:

[bdq:sourceAuthority default = GBIF Backbone Taxonomy]. (Currently found at: https://www.gbif.org/en/developer/species). This is the taxonID inferred from the Darwin Core Taxon class, not from any other sense of Taxon. Return a result with no value and a Result.status of NOT_AMENDED with a Response.comment of ambiguous if the information provided does not resolve to a unique result (e.g. if homonyms exist and there is insufficient information in the provided data, for example using the lowest ranking taxa in conjunction with dwc:dwc:scientificNameAuthorship, to resolve them).

@chicoreus - the Expected Response to which @Tasilee was referring was apparently mine - not yours (I just spoke to him by phone).

from bdq.

Aligining with #70, specification could read:

INTERNAL_PREREQUISITES_NOT_MET dwc:taxonID is not EMPTY or if all of, dwc:scientificName, dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet, dwc:taxonRank, dwc:scientificNameAuthorship, dwc:cultivarEpithet are EMPTY, AMENDED to a the value taxonID for an unambiguously resolved single taxon record in the specified source authority service through (1) if the value of dwc:scientificName and dwc:cultivarEpithet, or (2) or if dwc:scientificName is EMPTY through values of the terms dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet, dwc:taxonRank, dwc:scientificNameAuthorship (and if not EMPTY, dwc:cultivarEpithet), or (2) if ambiguity produced by multiple matches in (1) or (2) can be disabmiguated to a single Taxon using the values of dwc:subgenus, dwc:genus, dwc:family, dwc:order, dwc:class, dwc:phylum, dwc:kingdom, dwc:higherClassification, dwc:scientificNameID, dwc:acceptedNameUsageID, dwc:originalNameUsageID, dwc:taxonConceptID, and dwc:vernacularName); otherwise NOT_AMENDED

from bdq.

Key piece (from #70) to add to the notes: The terms dwc:subgenus, dwc:genus, dwc:family, dwc:order, dwc:class, dwc:phylum, dwc:kingdom, dwc:higherClassification, dwc:scientificNameID,, dwc:acceptedNameUsageID, dwc:originalNameUsageID, dwc:taxonConceptID should not be used to make a match if dwc:taxonId and dwc;scientificName or dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet, dwc:taxonRank, dwc:scientificNameAuthorship are empty.

This expresses the assertion that if only dwc:genus is populated, the taxonID for that genus should not be filled in as the amendment, as the dwc:genus (and dwc:family and up) is a classification term for the Taxon, not necessarily a constituent part of the name of the Taxon.

from bdq.

I don't think this is correct and I find this wording totally confusing

1. "or if all of, dwc:scientificName, dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet, dwc:taxonRank, dwc:scientificNameAuthorship, dwc:cultivarEpithet are EMPTY" - if you only have dwc:infraspecificEpithet, dwc:taxonRank, dwc:scientificNameAuthorship or dwc:cultivarEpithet with nothing else, there is no way you can get a TAXONID - thus I don't think these should be in this part.

I am not familiar enough with TAXONIDs but if you only have a Family - doesn't that have a TAXONID? When I previously worded #57, I assumed that all names in the hierarchy would have a TAXONID - Am I wrong?

2. dwc:cultivarEpithet shouldn't be treated any differently to dwc:infraspecificEPithet so why would it be in 1)?

3. I can't get my head around the rest - sorry. Needs another attempt

See the thinking behind my current version under my comment of 5 days ago.

from bdq.

from bdq.

Interesting -
In the Botanical Code a taxon is described as "Taxonomic groups at any rank will, in this Code, be referred to as taxa (singular: taxon)."

Darwin Core Definition is "A group of organisms (sensu http://purl.obolibrary.org/obo/OBI_0100026) considered by taxonomists to form a homogeneous unit."

As a taxonomist - I have always regarded a Family name as a taxonomic name at the rank of Family. If we are using the term taxon in a different way - then we need to be clear and define it differently

from bdq.

That's exactly it, in Darwin core, dwc:family is already defined differently. In that context it means the family into which the dwc:Taxon record is currently classified. As I read that definition, a dwc;Taxon record where only the dwc:family is populated is one for which you do not know what the Taxon is. Again, the case where both dwc:scientificName or dwc:taxonID contain values and dwc:family contains a value is totally different, even if the value in dwc:scientificName is identical to that in the dwc;family, in that case the dwc:Taxon record is for the family, and that botanical code definition applies. When only dwc:family is populated, it is a reference to a Taxon, but as dwc:family, it is only a reference to that Taxon, not an unambiguous indicator of what taxon the current dwc:Taxon instance is referring to. The issue isn't in the definition of Taxon, that is clear. The issue is that dwc:family is an explicit reference to another Taxon into which the current dwc:Taxon record is classified. Consider:

9fd1e0b1-5e62-49eb-8bdd-4aee2c58e568 is a dwc:Taxon
9fd1e0b1-5e62-49eb-8bdd-4aee2c58e568 has dwc:Family Muricidae Rafinesque, 1815

ea6ff6cf-c21e-476f-854c-1c8cf4a3cd74 is a dwc:Taxon
ea6ff6cf-c21e-476f-854c-1c8cf4a3cd74 has dwc:Family Muricidae Rafinesque, 1815
ea6ff6cf-c21e-476f-854c-1c8cf4a3cd74 has dwc:scientificName Muricidae Rafinesque, 1815
ea6ff6cf-c21e-476f-854c-1c8cf4a3cd74 has dwc:taxonID urn:lsid:marinespecies.org:taxname:148

4ecedbbd-6524-4b6f-a2f7-d3b61eda252a is a dwc:Taxon
4ecedbbd-6524-4b6f-a2f7-d3b61eda252a has dwc:Family Muricidae Rafinesque, 1815
4ecedbbd-6524-4b6f-a2f7-d3b61eda252a has dwc:scientificName Chicoreus brevifrons (Lamarck, 1822)
4ecedbbd-6524-4b6f-a2f7-d3b61eda252a has dwc:taxonID urn:lsid:marinespecies.org:taxname:558803

Can you tell from the information given what either the dwc:scientificName or dwc:taxonID of 9fd1e0b1-5e62-49eb-8bdd-4aee2c58e568 is from the information given? I can't. There is a dwc:Taxon in this data set for Muricidae, but it is 4ecedbbd-6524-4b6f-a2f7-d3b61eda252a, and from the information given, it isn't possible to tell if 9fd1e0b1-5e62-49eb-8bdd-4aee2c58e568 is the same taxon as 4ecedbbd-6524-4b6f-a2f7-d3b61eda252a.

from bdq.

OK - but still, if you only have a record with a Family i.e. Muricidae Rafinesque, 1815 and no information below - i.e. I have only been able to identify this taxon to Family - shouldn't we then add the Taxon ID if the sourceAuthority provides a TAXONID for a family name [I am not familiar enough to know if they do - if they don't then OK - I defer to what you propose]

9fd1e0b1-5e62-49eb-8bdd-4aee2c58e568 is a dwc:Taxon
9fd1e0b1-5e62-49eb-8bdd-4aee2c58e568 has dwc:Family Muricidae Rafinesque, 1815
xxxxxx-xxxx-xxxx-xxx-xxxxxxx has dwc:taxonID urn:lsid:marinespecies.org:taxname: xxx

from bdq.

Is there consensus on the Expected Response?

from bdq.

Not yet! There are some questions still to be answered (the email I sent around on #57 and #70) - for example

1. on treatment of dwc:cultivarEpithet different to dwc:infraspecificEpithet (I believe they shouldn't be differently treated - @tucotuco to clarify use of dwc:cultivarEpithet) - see my comment of two days ago

2. and whether or not the higher categories have TAXONIDs. From my email
   "I am still not fully convinced re TAXONID and higher level taxa. Does the sourceAuthority (GBIF?) give a TAXONID for a family name?I am not familiar enough with TAXON ID to know. If they don't then I accept @chicoreus arguments. But if they do, and a record has only a name at the Family level with no information at a lower level (i.e. I have only been able to identify this record to Family). If the sourceAuthority gives a Taxon ID for the Family - then why would be not use that TAXONID for the record.

   This is particularly relevant as the Botanical Code defines a taxa as
   "Taxonomic groups at any rank will, in this Code, be referred to as taxa (singular: taxon)."
   In the Zoological Code:
   "A taxonomic unit, whether named or not: i.e. a population, or group of populations of organisms which are usually inferred to be phylogenetically related and which have characters in common which differentiate (q.v.) the unit (e.g. a geographic population, a genus, a family, an order) from other such units. A taxon encompasses all included taxa of lower rank (q.v.) and individual organisms. The Code fully regulates the names of taxa only between and including the ranks of superfamily and subspecies"
   The Zoological Code treats a family name as a taxon

   "family name or name of a family
   A scientific name of a taxon at the rank of family."

   Darwin Core definition
   "A group of organisms (sensu http://purl.obolibrary.org/obo/OBI_0100026) considered by taxonomists to form a homogeneous unit." It gives the example of "The genus Truncorotaloides as published by Brönnimann et al. in 1953 in the Journal of Paleontology Vol. 27(6) p. 817-820."

from bdq.

Not yet! There are some questions still to be answered (the email I sent around on #57 and #70) - for example

1. on treatment of dwc:cultivarEpithet different to dwc:infraspecificEpithet (I believe they shouldn't be differently treated - @tucotuco to clarify use of dwc:cultivarEpithet) - see my comment of two days ago

My understanding is that a cultivarEpithet should be as determinant of a Taxon as an infraspecificEpithet is and treated in the same way.

2. and whether or not the higher categories have TAXONIDs. From my email
   "I am still not fully convinced re TAXONID and higher level taxa. Does the sourceAuthority (GBIF?) give a TAXONID for a family name?I am not familiar enough with TAXON ID to know. If they don't then I accept @chicoreus arguments. But if they do, and a record has only a name at the Family level with no information at a lower level (i.e. I have only been able to identify this record to Family). If the sourceAuthority gives a Taxon ID for the Family - then why would be not use that TAXONID for the record.
   This is particularly relevant as the Botanical Code defines a taxa as
   "Taxonomic groups at any rank will, in this Code, be referred to as taxa (singular: taxon)."
   In the Zoological Code:
   "A taxonomic unit, whether named or not: i.e. a population, or group of populations of organisms which are usually inferred to be phylogenetically related and which have characters in common which differentiate (q.v.) the unit (e.g. a geographic population, a genus, a family, an order) from other such units. A taxon encompasses all included taxa of lower rank (q.v.) and individual organisms. The Code fully regulates the names of taxa only between and including the ranks of superfamily and subspecies"
   The Zoological Code treats a family name as a taxon
   "family name or name of a family
   A scientific name of a taxon at the rank of family."
   Darwin Core definition
   "A group of organisms (sensu http://purl.obolibrary.org/obo/OBI_0100026) considered by taxonomists to form a homogeneous unit." It gives the example of "The genus Truncorotaloides as published by Brönnimann et al. in 1953 in the Journal of Paleontology Vol. 27(6) p. 817-820."

I agree with @chicoreus about the case where dwc:family (and no lower rank) is populated and dwc:scientificName is not, for the simple fact that the Taxon is ambiguous. Specifically, it MIGHT be the family, but it might be something in the family. Probably way too subtle for most people to worry about, but I think it's correct.

from bdq.

OK - if we accept the rasoning of @chicoreus and @tucotuco

INTERNAL_PREREQUISITES_NOT_MET if dwc:taxonID is not EMPTY or if all of, dwc:scientificName, dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet, dwc:scientificNameAuthorship, and dwc:cultivarEpithet are EMPTY, AMENDED the value of taxonID for an unambiguously resolved single taxon record in the specified source authority service through (1) the value of dwc:scientificName or (2) if dwc:scientificName is EMPTY through values of the terms dwc:genericName, dwc:specificEpithet, dwc:infraspecificEpithet, dwc:scientificNameAuthorship and dwc:cultivarEpithet), or (3) if ambiguity produced by multiple matches in (1) or (2) can be disambiguated to a single Taxon using the values of dwc:subgenus, dwc:genus, dwc:subfamily, dwc:family, dwc:order, dwc:class, dwc:phylum, dwc:kingdom, dwc:higherClassification, dwc:scientificNameID, dwc:acceptedNameUsageID, dwc:originalNameUsageID, dwc:taxonConceptID, dwc:taxonomicRank, and dwc:vernacularName); otherwise NOT_AMENDED

If accepted it appears that we can take dwc:genericName and dwc:infragenericEpithet out of Information Elements

Note:

1. I have taken dwc:cultivatedEpithet and dwc:taxonRank out of the INTERNAL_PREREQUISTES_NOT_MET
2. I have changed the wording of (1) and (2) around dwc:cultivatedEpithet in the AMENDED area to treat it the same as dwc:infraspecificEpithet
3. I have taken dwc:taxonRank out of (2)
4. I have added dwc:subfamily to (3)
5. Some other minor wording and spelling corrections

from bdq.

I have to defer to @chicoreus, @ArthurChapman and @tucotuco on this. I will apply @ArthurChapman's latest Expected Response, with a few more tweaks.

from bdq.

Changed "AMENDED" to "FILLED_IN" in accordance with discussions April 16.

from bdq.

Amended Example to align with @chicoreus comments in email 17th June 2022.

from bdq.

from bdq.

@nielsklazenga - any comments? [space inadvertently included in last post by @tucotuco

from bdq.

Regarding cultivarEpithet, yes, that is part of the scientificName string.

from bdq.

Changed Parameter(s) to "bdq:sourceAuthority" as per discussions 12th June 2023

from bdq.

Will need to include the new terms dwc:superfamily, dwc:tribe, dwc:subtribe tdwg/dwc#65 tdwg/dwc#45 tdwg/dwc#46

from bdq.

Added the terms dwc:superfamily, dwc:tribe, dwc:subtribe to the Information elements and Expected response, and updated Specification Last Updated.

On this one, please check my Expected response.

from bdq.

Amended Source Authority values to align with @chicoreus syntax

From

bdq:sourceAuthority default = "GBIF Backbone Taxonomy" [https://doi.org/10.15468/39omei] |
| | API endpoint [https://api.gbif.org/v1/species?datasetKey=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c&name=]

to

bdq:sourceAuthority default = "GBIF Backbone Taxonomy" {[https://doi.org/10.15468/39omei]} {API endpoint [https://api.gbif.org/v1/species?datasetKey=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c&name=]}

from bdq.