Domain for Common Core IRIs

[alanruttenberg]

I'd like to raise the issue of what domain will be used in the IRIs for the CCO MLO standard. I'll be raising this issue for DoD/IC foundry ontologies in general. A design goal is to have the domain, and the server behind it, guaranteed to survive in perpetuity. I'm not sure who owns and manages the ontologyrepository.com domain that is currently used as the whois information, as is typical these days, does not reveal the actual managing entity and contact information. The OBO Foundry has one method of accomplishing this, but our foundry will need a different solution that addresses access and security issues.

For reference:

• OBO Foundry Identifier Policy
• OBO Foundry Permanent URLs
• Ontobee: A linked ontology data server to support ontology term dereferencing, linkage, query and integration
• Ontobee

[jimschoening]

Here are things to factor into a solution:

1. CCO is currently being standardized by INCITS, but they have approved in writing that we can share CCO (the ontologies, not the INCITS 573-2 document) for free on the Internet.
2. We plan to try to move ISO/IEC 21838-2 BFO from ISO/IEC SC32 to SC42 AI, and if a good community forms around it, we might consider moving CCO there, either before or after approval by INCITS.
3. Q: Could a foundation, with volunteers, support this service? We should avoid a hosting situation where controlling parties could charge what they pleased. We should estimate what the costs would be and if volunteers could do this work. I don't think the cloud server fees would be very high, unless this went viral, and then perhaps a donation model like Wikipedia might support the server costs.
4. The CCO service should include commercial, so should probably not be DoD. If DoD wants a classified solution, they should set it up.

[alanruttenberg]

@jimschoening Nicely laid out. I've asked @jamesaoverton, who built the current OBO PURL system for some information about how the domain is managed and the cost of running the server.

Re (3), For OBO, which is run mostly run by volunteers the bigger issue is making sure that there are several people who have permission to modify the domain, e.g. by changing what IP address it lives at, otherwise if a single maintainer is hit by a bus...

I like the idea of a foundation.

I'd like to hear more about the DoD/Commercial issues, perhaps at the next MLO meeting. I was thinking that I'd recommend that foundry have a similar setup in which case it would be desirable, to the extent that CCO is the designated mid-level for the foundry, for CCO to use the same domain they do.

DoD could manage security and presence on appropriate networks by having the DNS on those networks resolve the domain to a server that lives on the network in question. The public facing version would just 404 for any non-public term.

[alanruttenberg]

@jamesoverton says:

The PURL server has been running happily on an AWS EC2 t2.micro instance. AWS gives you monthly free credits amounting to about one micro instance, so if that's all you're running under your AWS account then I think it would be free. Since I run a bunch of EC2 instances I'm not sure exactly how much this one costs by itself, but it's less than $20 per month. This is an on-demand instance, and reserved instances are cheaper, and there are cheaper alternatives to AWS out there. The upshot is that the compute time is not expensive.

We haven't had major maintenance problems in six years. It takes time to review PRs and hold hands. The worst part is that there needs to be someone on call 24/7 in case there are problems with the server. [last sentence a paraphrase]

---

The PRs referred to are for changes to the ontology-specific PURL configuration. The config files are also on Github but changes need to be reviewed in case there's a mistake that might affect others or otherwise be unhealthy for the server.

[jamesaoverton]

Thanks @alanruttenberg. Regarding the last point about reviews, I'll just add two things about the OBO PURL system:

1. By construction, project namespaces (e.g. OBI) are configured separately, so most changes cannot cause problems for other namespaces (e.g. GO).
2. There's an automated test suite that is run on every commit and before changes are deployed. It can catch a lot of problems, but manual review is still required. Most manual reviews take just a minute, but if the submitter misunderstands something about how PURLs should work then there's an education component that can take a lot of time.

[jimschoening]

Perhaps the site should be controlled by the same standards organization that standardizes CCO, if they will accept this control. Once CCO becomes a standard, some committee will be responsible for maintaining it, including responding to issues, and starting to draft the next version. This would be stable and have well-defined rules.

[neilotte]

@jimschoening @alanruttenberg Moving to discussion.