Question: Can I configure the PURL to redirect to a curie based IRI?

[matentzn]

For example, I would like:

http://purl.obolibrary.org/obo/HP_0002088

to redirect here:

https://hpo.jax.org/app/browse/term/HP:0002088

[jamesaoverton]

Yes. The default is to redirect term IDs to Ontobee, but several projects choose a different term browser:

• documentation https://github.com/OBOFoundry/purl.obolibrary.org#custom-term-browsers
• configuration https://github.com/OBOFoundry/purl.obolibrary.org/blob/master/config/obo.yml#L37

You're free to redirect these where you like, but please be extra careful when modifying obo.yml, because changes here apply to everything under /obo/*. If you make a PR for this, please let me review it -- then it will be my fault if something breaks. :^)

[matentzn]

Awesome, thanks @jamesaoverton

Will check with HP folks to see what they think.

[cmungall]

Should we have a more general solution for this?

(I had mistakenly assumed the redirect was based on the part after the _, but it seems not)

If we tackle this now it will save us a lot of work later.

We have a large community of ontologies that have always been in OBO but have not been OWL aware, and hence not PURL aware, as everyone outside the semweb/OWL community use IDs/CURIEs. Many probably have no idea what ontobee is. But as Nico trains up multiple groups they will become PURL aware and see their official class URIs go to ontobee, and that ontobee is not biologist-friendly and (most importantly) frequently out of date.

Maybe switching to OLS (which is easy with the current system) will be a perfectly good stopgap for a while, but I suspect many will want a redirect to their own database, which will assume prefixed IDs. I think in some cases (e.g. HPO) they have the developer resources to support the OBO fragment but in other cases it will be surprisingly difficult to get this changed.

How about adding an optional field that specifies that the CURIE local part will be used in constructing the URL, e.g.:

- prefix: /about/
  use_local_id: true
  replacement: https://proconsortium.org/cgi-bin/entry_pro?id=PR:

i.e. for PR_nnnnnnnn, then nnnnnnnn would be used

This will be a one time change in the code, rather than N nerve-wracking changes and potential future PRs to the central obo redirects.

What this predicted migration away from ontobee will mean for the original semantic web vision of PURLs that are resolvable to RDF using the 2-in-1 model is another issue....

[jamesaoverton]

My suggestion is to replace this chunk of obo.yml:

# Term redirects for CHEBI
- regex: ^/obo/CHEBI_(\d+)$
  replacement: http://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:$1
  status: see other
  tests:
  - from: /CHEBI_15377
    to: http://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:15377

by modifying the term_browser key in chebi.yml like:

term_browser: http://www.ebi.ac.uk/chebi/searchId.do?chebiId=CHEBI:$1

So instead of term_browser: custom we provide a regex. term_browser: ontobee would then be a special case, still used as default. We could also add support for term_browser: ols special case.

This should cover most of the custom term browsers defined in obo.yml, if we restrict the match to digits (which I prefer). PR and NCIT would still be exceptions since they allow alphanumeric IDs.

[matentzn]

Hey all! Are there any updates on which solution I should go for in the short term? At least for HPO it would be nice if I could solve this issue soonish..

[jamesaoverton]

In the short term, I suggest using the existing solution that I described above (June 14).

[cmungall]

Also a potential solution here: #536