Merge PURL configuration into ontology detail files

[alanruttenberg]

One place to go to edit metadata versus two...

[jamesaoverton]

Chris (@cmungall), Seth (@kltm), and I discussed this at some length. I argued for a strict separation of concerns, but now I'm not as sure as I was. Given that the PURL YAML config is now non-trivial, I no longer have a strong argument for keeping it separate from the OBO registry YAML config.

My position has been to keep the PURL system separate and very simple. The original idea was raw Apache configuration files per-project -- technically as simple as it gets. But I was swayed by the argument that Apache config is hard for our ontology developers to read and write, so I developed the YAML format and scripts. I wanted to have just an entries list, corresponding to the PURL.org entries. Then there were good reasons to add term_browser, products, and base_redirect to allow for constrained top-level config in the project configuration files. Then there were more edge cases than I expected. The upshot is that we ended up with much more code than I wanted, requiring much more documentation than I wanted.

The new system works. My t2.micro server on AWS isn't even breaking a sweat. I'm pleased with the GitHub and Travis CI integration. The tests and logs have helped us find a bunch of problems that we couldn't see before.

But I wanted the YAML configuration format to make sense without having to read the fine manual, and it doesn't. And I wanted any OBO admin to be able to modify the code, but now that's getting doubtful. I'll be on the hook for any changes.

[alanruttenberg]

If you want we can do a code review. Idea would be both of us (maybe chris too) reading and editing comments at the same time as we talk.

There's room for simplification - I suggested an alias directive. In addition we can offer a template with all the typical situations and embedded comments. People could start with that and then not have to go look for documentation.

[jamesaoverton]

A code review would be good. I'm not sure when. I've completely blown by budget of hours for this project and I have two big end-of-year deadlines.

The README has examples of all the features that users should touch, with explanations and links. People don't read the docs (myself included). If you have a better template, I'm happy to add it.

The alias idea deserves a tracker issue. It would make things easier, but not simpler.

[cmungall]

We have a robust base system that works, people should be able to configure this themselves, or with the help of other OBO people. However, I want to do make sure that you don't end up shouldering either future development burdens or sys admin duties.

Not sure how best to do that. For new features, let's at least make use of milestones or labels in github to separate out enhancements from urgent changes.

I can provide server in January but it sounds like the amazon VM is working OK so far

[kltm]

Sorry, I've been out of the loop on this for a bit (end of the year goodness).
I agree with @cmungall that there is nothing but great improvement here. I would also (and I think everybody agrees here) ideally want separation of concerns and a simple editable interface for users. Maybe the solution is just a slightly different approach or a little tweak? Time is short, but if there is a review to this end, I'd love to be around for it.

[cmungall]

I'm going to close this for now as there hasn't been any action, we seem ok with how things work, we plan more tools to make this easier, we have a separate ticket for the code review, and we have a lot currently in place that uses the system as it is now