more properties in API/v2/taxonomy/taxon response

[mtholder]

The taxonomy/match_names response has info about the scoring of each match and taxon information about each taxon that is a potential match. It seems like the taxon info in the match_names should be a subset (or identical to) the taxon info that you can get back if you request info using the taxonomy/taxon service. Using the "Barnadesia" example in the docs, we can see that the taxon web service lacks:

• is_deprecated
• is_dubious
• is_synonym
• nomenclature_code

properties. This service (unlike match_names see #83 ) seems to have the rank information correct. But the unique_name field is empty in the "taxon" response, but "Barnadesia" in the "match_names" response.

[chinchliff]

Makes sense. The is_synonym property would always be false for results from
the /taxon service though, since only recognized taxa can be
retrieved using that service. Leave it off or include it and have it always
equal false?

On Monday, December 8, 2014, Mark T. Holder [email protected]
wrote:

The taxonomy/match_names response has info about the scoring of each match
and taxon information about each taxon that is a potential match. It seems
like the taxon info in the match_names should be a subset (or identical to)
the taxon info that you can get back if you request info using the
taxonomy/taxon service. Using the "Barnadesia" example in the docs, we can
see that the taxon web service lacks:

• is_deprecated
• is_dubious
• is_synonym
• nomenclature_code

properties. This service (unlike match_names see #83
#83 ) seems to have
the rank information correct. But the unique_name field is empty in the
"taxon" response, but "Barnadesia" in the "match_names" response.

—
Reply to this email directly or view it on GitHub
#85.

[mtholder]

Good point.

I'd be tempted to put it in the response just in case we support queries on synonyms later.

I don't think that we want to assign IDs for all synonyms, but it might be nice to support this call for all names that were thought to be valid names by ott. For example, if ott2.9 realizes that a name in ott2.8 is a junior synonym, we might still want to support the v2/taxonomy/taxon call with that ID - in which case we might get is_synonym = true