Closed peterdesmet closed 11 months ago
Maybe we also have to rename this term to reference
or source
to make it more broadly applicable (but still require a URL).
Discussed with @kbubnicki. We suggest to:
taxonIDReference
As it is currently only human readable. E.g. in the example dataset, the current value:
"taxonID": "5BSG3",
"taxonIDReference": "https://www.checklistbank.org/dataset/COL2023",
Is understandable to a human (COL2023 was used), but a machine cannot discern that both can be combined as {taxonIDReference}/taxon/{taxonID}
to https://www.checklistbank.org/dataset/COL2023/taxon/5BSG3. It would be better if that URL was provided by the publisher in taxonID
directly
taxonID
from observationstaxonID
must currently be provided in observations (in combination with scientificName
). The reasoning was to disambiguate homonyms in scientificName
. However:
scientificName
in observations with the package.taxonomy
using scientificName
as the foreign key.taxonID
in the observations can be a burden for data providers (and thus adoption). They might revert to providing internal integers which isn't helpfultaxonID
in observations (especially URLs, see point above) unnecessarily increases the file size for observations.scientificName
in observations should be sufficient, all other taxonomic information (taxonID, vernacular names, higher classification) can be provided (just once per taxon) in package.taxonomic
taxonID
in package.taxonomic
To still support building a package.taxonomic
(a required property) from the observations data (i.e. as in the IPT), we have to make taxonID
an optional term (since it won't be provided any longer in observations). We can update the term definition to nudge users to provide a URL from a trusted source, e.g. https://www.checklistbank.org/dataset/COL2023/taxon/5BSG3
package.taxonomic currently has 3 required fields per taxon:
For systems that want to infer the taxonomic scope for the observations (such as the IPT, see this discussion), it is possible to get the
taxonID
andscientificName
, but nottaxonIDReference
. I think it would be better to relax the requirement for ataxonIDReference
to support such systems.