search_names not returning exact matches

[johnbaums]

I've encountered instances where a search for a subspecies returns a hybrid instead of the ALA taxon with an exact name match. E.g.:

search_names('Asplenium obtusatum subsp. northlandicum')
                                searchTerm                                                                               name       rank                                           guid
1 Asplenium obtusatum subsp. northlandicum Asplenium bulbiferum subsp. gracillimum x Asplenium obtusatum subsp. northlandicum subspecies urn:lsid:biodiversity.org.au:apni.taxon:320470

But taxon Asplenium obtusatum subsp. northlandicum does exist in ALA. Changing the search string to "Asplenium obtusatum ssp. northlandicum" returns the expected taxon.

search_names('Asplenium obtusatum ssp. northlandicum')
                              searchTerm                                     name       commonName       rank                                           guid
1 Asplenium obtusatum ssp. northlandicum Asplenium obtusatum subsp. northlandicum Shore Spleenwort subspecies urn:lsid:biodiversity.org.au:apni.taxon:269397

I'm not sure if this is a biocache issue or an ALA4R issue... a GET request using the species search web service returns the expected taxon, as well as the hybrid (see http://bie.ala.org.au/ws/search.json?q=Asplenium%20obtusatum%20subsp.%20northlandicum).

Other similarly-affected taxa include:

• Asplenium bulbiferum subsp. gracillimum
• Daviesia mimosoides subsp. mimosoides

[Tasilee]

Hi John

Ben Raymond, Adam Collins (ALA developer) and I have been trying to identify the issues here. We know it is a bie issue with bulk lookup (not freetext search) and not an ALA4R issue as such (as we just call the ALA ws). After some discussion, Adam has seeded a new bie issue at https://github.com/AtlasOfLivingAustralia/bie-service/issues/4

We hope that the 'bie people' will be able to fix this anomaly.

[johnbaums]

Thanks Lee - appreciate it :)

[raymondben]

Closing this issue since it's really one for the underlying service (referenced in Lee's comment above). Will reopen here if the service gets fixed but somehow it doesn't fix the downstream issue in ALA4R.