To use this new system, we need to migrate our configuration from the current system. We should to be able to verify that migration is complete and correct (see also #3).
Given a copy of the current database table, a semi-automatic, one-time conversion should be pretty easy, and we can be pretty sure that we haven't missed anything. I don't know if this is possible.
Without a copy of the table, we can use the search interface: https://purl.org/docs/purl.html#search. The results can be scraped from the HTML, or we can fetch XML like this.
The search interface only returns 100 results at a time. This is enough for all the specific ontologies that I have checked: 44 for /obo/bfo/*, 66 for /obo/obi/*, 63 for /obo/iao/*, 1 for /obo/pro/*, 7 for /obo/go/*, 6 for /obo/chebi/*.
However, for the /obo/* path there are more than 100 results. Most of the results I see belong to PRO. And I think there might be other redirect magic going on for /obo/*. @cmungall?
Isn't there an easier more incremental approach?
Can we use the existing purl server as a fallthrough?
For example, at t0 the apache config can just be something like
/obo/ http://purl.oclc.org/obo/ PARTIAL
Then we point http://purl.obolibrary.org/obo/ at the apache server. It introduces one extra level of redirects, but everything should just work.
Then we incrementally add entries to the apache config, overriding oclc.
When we are comfortable, we can eliminate the fallthrough (after scraping with the API to make sure there are no stragglers), but this can be as incremental as we like
I hadn't thought of that. Good idea!
I have code for XML migration. My experience so far is that most projects need a little manual tweaking, but it's pretty good.
We need to make decisions about the config/obo.yml file:
Add global failovers, see #4
- related to #7
Migrate as many projects as possible, closes #4