Zooma gives an error when the annotation that is searched for contains brackets.

[henrietteharmse]

As an example

https://www.ebi.ac.uk/spot/zooma/v2/api/services/annotate?propertyValue=fatty+acids+%28200+micromolar%29&propertyType=treatment&filter=required:[atlas,gwas],preferred:[atlas,gwas],ontologies:[efo]

results in the following error:
ZOOMA encountered a problem that it could not recover from (Failed to complete a search for 'fatty acids (200 micromolar)' (java.util.regex.PatternSyntaxException: Unmatched closing ')' near index 9 micromolar) ^))

[warrenread]

https://www.ebi.ac.uk/spot/zooma/v2/api/services/annotate?propertyValue=fatty+acids+%92%28200+micromolar%92%29&propertyType=treatment&filter=required:[atlas,gwas],preferred:[atlas,gwas],ontologies:[efo]

Backslash (here urlencoded as %92) seems to fix the problem, which is to do with passing a regex where the brackets are meant to be interpreted literally as opposed to being directives to the regex. Backslash also seems to work when hard-encoded, but only if the whole URL is enlosed in quotes when invoking URL with curl on the command line. So probably safer to urlencode?

[henrietteharmse]

The problem is that it forces Zooma users who often get the data from various upstream providers to parse the annotations and insert the backslash. Therefore, it might be something we want to do on our side.

[warrenread]

Might they want to pass an actual regex though? I'm guessing that's unlikely, and that a back-end fix (i.e. on our side) that brute-forces all opening and closing parentheses to backslash-escaped literals is indeed, probably, the right approach.