You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One would expect to see the content of the over-the-wire data: Automated change 2022-04-14: <http://purl.obolibrary.org/obo/GO_0015696> replaced_by <http://purl.obolibrary.org/obo/GO_0072488>. However, notice that the PURLs are bracketed by chevrons, which the HTML renderers in browsers seem to be taking as failed HTML tags and not displaying as they are malformed and unrenderable.
Pondering this, I think there are three ways forward:
It's a data problem: the PURLs in the comments should actually be CURIEs, like everything else that goes on between client and server; we should change the spec and update minerva and the data accordingly.
It's a minerva/data problem: the PURLs in the comments should actually be CURIEs, like everything else that goes on between client and server; minerva should fix this on the fly before sending to the client.
It's a client problem: as these are not technically PURLs, but rather PURL-like things embedded in user-consumable strings, the fault is in the client and the client should special case these to look as intended.
I think "2" is a little weird and "1" is maybe a bit too much work for what is essentially a "visual" bug. I think that "3" is likely the best choice for the moment, but have a little reserve concern there that we're communicating similar things in different ways in different places. I don't remember the rationale for using PURLs instead of CURIEs in this one location and think it might be good to (re?)discuss that so that we have consistent rules moving forward (or at least rules that I remember).
). It would be something that converts the "tag" >s and <s into renderables for annotation string, a la str.replace(/</g, "<").replace(/>/g, ">").
The reason for the PURLs is that the strings are constructed inside a SPARQL Update, where I don't have access to prefix declarations. I could put in a special case for GO, which will be the most common type of PURL encountered (but in general it's open-ended).
In some cases, PURLs may not appear in display in graph editor. For example, looking at http://noctua.geneontology.org/editor/graph/gomodel:ZFIN_ZDB-GENE-060209-2 :
One would expect to see the content of the over-the-wire data:
Automated change 2022-04-14: <http://purl.obolibrary.org/obo/GO_0015696> replaced_by <http://purl.obolibrary.org/obo/GO_0072488>
. However, notice that the PURLs are bracketed by chevrons, which the HTML renderers in browsers seem to be taking as failed HTML tags and not displaying as they are malformed and unrenderable.Pondering this, I think there are three ways forward:
I think "2" is a little weird and "1" is maybe a bit too much work for what is essentially a "visual" bug. I think that "3" is likely the best choice for the moment, but have a little reserve concern there that we're communicating similar things in different ways in different places. I don't remember the rationale for using PURLs instead of CURIEs in this one location and think it might be good to (re?)discuss that so that we have consistent rules moving forward (or at least rules that I remember).
Tagging @vanaukenk @balhoff
The text was updated successfully, but these errors were encountered: