One of the features of the mapr applications is the fact it rewrites the right-hand panel to improve the UI representation of terms associated to hyperlinks. For instance, in current production IDR:
is the UI representation of a MapAnnotation with namespace openmicroscopy.org/mapr/compound composed of two keys/values
Compound Name: Trametinib
Compound Name URL: https://www.ncbi.nlm.nih.gov/pccompound?term=Trametinib
Compound Name URL is detected as an URL, associated with Compound Name by key name and turned into an inline icon in the following section of the code
In the example above, the usage of https://www.ncbi.nlm.nih.gov/pccompound?term=Trametinib is problematic as this is effectively a search. In the compound space, given the lack of term unification, there is no guarantee this will either return a result or return an unique result.
As part of the curation work of idr0094, work has been done to associate most compounds to their PubChem identifiers and we investigated using PubChem URLs like https://pubchem.ncbi.nlm.nih.gov/compound/11707110 in the annotation i.e.
Compound Name: Trametinib
Compound Name URL: https://pubchem.ncbi.nlm.nih.gov/compound/11707110
With the current omero-mapr 0.4.0, this map annotation renders as follows in the right-hand panel:
In addition to matching the keys, the current version of the code also checks whether the URL contain the term defined in Compound Name in order to display icon next to the term and hide the Compound Name URL row.
Workaround
With the current implementation, it is possible to workaround the code assumption by adding a no-op anchor to the URL e.g.
Compound Name: Trametinib
Compound Name URL: https://pubchem.ncbi.nlm.nih.gov/compound/11707110#Trametinib
This will produce the expected rendering:
Proposal
There is certainly some rationale beyond the check between the values of the <name> and <name> URL pairs. However, the current solution generically prevents linking a term to an associated reference URL (ontology, database) unless the latter URL contains the term.
This is fairly restrictive and taking only the example of IDR, there are a number of keys that could benefit from having this limitation lifted in order to display arbitrary URLs as inline icons:
Status
One of the features of the mapr applications is the fact it rewrites the right-hand panel to improve the UI representation of terms associated to hyperlinks. For instance, in current production IDR:
is the UI representation of a
MapAnnotation
with namespaceopenmicroscopy.org/mapr/compound
composed of two keys/valuesCompound Name URL
is detected as an URL, associated withCompound Name
by key name and turned into an inline icon in the following section of the codehttps://github.com/ome/omero-mapr/blob/89f9c87fba77be8f0e9b7a532400a0c6d57902a7/omero_mapr/templates/webclient/data/includes/right_plugin.general.js.html#L118-L133
Issue
In the example above, the usage of https://www.ncbi.nlm.nih.gov/pccompound?term=Trametinib is problematic as this is effectively a search. In the compound space, given the lack of term unification, there is no guarantee this will either return a result or return an unique result.
As part of the curation work of
idr0094
, work has been done to associate most compounds to their PubChem identifiers and we investigated using PubChem URLs like https://pubchem.ncbi.nlm.nih.gov/compound/11707110 in the annotation i.e.With the current
omero-mapr 0.4.0
, this map annotation renders as follows in the right-hand panel:In addition to matching the keys, the current version of the code also checks whether the URL contain the term defined in
Compound Name
in order to display icon next to the term and hide theCompound Name URL
row.Workaround
With the current implementation, it is possible to workaround the code assumption by adding a no-op anchor to the URL e.g.
This will produce the expected rendering:
Proposal
There is certainly some rationale beyond the check between the values of the
<name>
and<name> URL
pairs. However, the current solution generically prevents linking a term to an associated reference URL (ontology, database) unless the latter URL contains the term.This is fairly restrictive and taking only the example of IDR, there are a number of keys that could benefit from having this limitation lifted in order to display arbitrary URLs as inline icons: