Issue 13557

Wildcard search of verbatim scientificName

13557
Reporter: feedback bot
Assignee: fmendez
Type: NewFeature
Summary: Wildcard search of verbatim scientificName
Priority: Major
Resolution: WontFix
Status: Closed
Created: 2013-08-06 12:19:10.691
Updated: 2017-10-06 14:48:38.906
Resolved: 2017-10-06 14:48:38.865
        
        
Description: Dear portal developers,
Below please find two problems I had with the new portal.
Kind regards,
Wolf-Henning

Use case:
Search for occurrences of „Phacus smulkowskianus“ (Algae, not in the taxonomic Backbone).
Problem 1: Wild card “*” in filtering for scientific name produces an error.
Problem 2: Occurrences not available via the scientific name even though the name is displayed in the drop down menu.

Search in new porta (documentation)l:
Step 1: Filter for Scientific name, Full name 2 times in dropdown menu
Phacus smulkowskianus (B. Zakrys) W.-H. Kusber (1. Without search results [same as in the current portal]
Phacus smulkowskianus (B. Zakrys) W.-H. Kusber (2. Without search results [same as in the current portal]
Step 2: Put the name “Phacus smulkowskianus*” into the box [this was exactly the way to get data in the current portal]:
Result: “discovered an unforseen error!” (05.-06.08.2013).

Expected results from data.gbif.org: 3 occurrences:
http://data.gbif.org/occurrences/118451933/ ACOI 1226
http://data.gbif.org/occurrences/237923829/ AlgaTerra 6518
http://data.gbif.org/occurrences/search.htm AlgaTerra 6490

Cross-Check: Occurrence ID: 237923829 (was found in the new portal filtering for Collection Code = AlgaTerra & Catalog Number = 6518)
http://uat.gbif.org/occurrence/237923829


*Reporter*: Wolf-Henning Kusber
*E-mail*: [mailto:w.h.kusber@bgbm.org]]]>
    


Author: mdoering@gbif.org
Created: 2013-08-06 14:24:58.595
Updated: 2013-08-06 14:24:58.595
        
Hello Henning,
it is expected that you can only search for names in the gbif backbone, not the names used by the source. Also the wildcard is not supported directly. The scientific name autocomplete adds it implicitly, while the regular species search does a fuzzy search on canonical name parts only.

Doing your species search I see that we have the name twice in the backbone, but under different families:
http://uat.gbif.org/species/search?q=Phacus+smulkowskianus&dataset_key=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c

Both of them have no occurrences linked to them though. Using the catalog numbers to search here are the 2 occurrences:
http://uat.gbif.org/occurrence/118451933
http://uat.gbif.org/occurrence/237923829

Apparently we have not been able to match both to our backbone, also the name given in the raw data looks pretty good:
http://uat.gbif.org/occurrence/118451933/verbatim

If I look at the matching api directly I get no result:
http://api.gbif.org/lookup/name_usage?name=Phacus%20smulkowskianus%20(Zakrys)%20Kusber

I *think* this is because we have 2 records of that name in the nub and they only differ at family level. The matching API cannot reliably match to one record in this case and safely returns no match (btw, the new matching API not yet deployed shows you the close alternative matches and the reason why it didnt match). If I also add a family name to the matching API I do get a record:

http://api.gbif.org/lookup/name_usage?name=Phacus%20smulkowskianus%20(Zakrys)%20Kusber&family=Phacaceae

Thanks for the issue, this appears to be a true backbone issue I will try to get solved now while working on a new implementation