Version 2.0 IRIs do not resolve as URLs

[mark-jensen]

The new IRIs in v2.0 do not resolve as URLs to an ontology file via the web. We are woking on a solution that will improve on the previous implementation. Stay tuned. And thanks for your patience.

In the meantime, we encourage you to work with a local copy of CCO by either downloading the merged version of CCO or the full release, or forking or cloning the repository directly to your computer. For most users, we encourage use of the merged version.

v/r
CCO Governance and Development

[swartik]

@mark-jensen Your sentence:

The new IRIs in v2.0 do not resolve as URLs to an ontology file via the web.

explicitly states something everyone needs to know: how to use CCO. The README file should state, in no uncertain terms, that CCO v2.0 currently has to be used by downloading its modules, not by trying to reference it via URLs.

I'm assuming, from the way you wrote, that a solution isn't imminent. Even if it's as little as a month away, users should be aware of how to use CCO now. And when the solution is implemented, the README file should explain it.

If you are too busy, I'll submit something. Just let me know.

[mark-jensen]

@swartik I updated the main readme and linked to this issue. Thanks. I plan to start a discussion about the use cases for having resolvable IRIs. I'll tag you when ready and look forward to hear about how and why you use CCO via web vs downloading.

[aamedina]

I look forward to having the IRIs be dereferencable again.

[jravenel]

Are we talking about this page when you click on IRI?
This hurts when people I talk to are trying to discover CCO and learn why we us it.

Can I help?

[DanBerrios]

@jravenel I think they are talking about having all the individual entity IRIs resolve to pages that describe the entity, the way that the OBO Foundry ontologies have set up a framework for doing that for the OBO ontologies. I am also interested in how this may progress, as we would like to use the CCO as well.

[jravenel]

thanks @DanBerrios, so not related to the fact that when you click on IRI you have this page I shared "we are in construction" right?. This has been like this for months so I'm wondering if it's something on the todo. I would like to contribute in doing it if it helps.

[DanBerrios]

@jravenel Well, kind of related.... it depends on what CCO has planned for scope of IRI resolution... Typically for OBO ontologies, the "whole" ontology IRI resolves to a location to see a serialized version of the whole ontology, and concept IRIs resolve to an Ontobee or other ontology viewing web app showing just that concept with appropriate context. Neither of those work currently for CCO, which they are aware of (per the usage guidance in the README.md). The IRI for the whole ontology doesn't have to point to the project's web site, but looks like currently for CCO it does, and their web site is the placeholder you shared.

[jravenel]

If I can help solving this, I would. When people are discovering CCO they don't understand what's happening.

[jravenel]

is there a way we can plan work on this?

[johnbeve]

@mark-jensen and @neilotte have actually been working behind the scenes on this; perhaps they can fill you in?

[jravenel]

That's great, thanks @johnbeve for the feedback. I'm happy to help.
I can suggest using docusaurus, very practical to build javascript website, markdown based, easy to host via github pages

[swartik]

@mark-jensen I never responded to your question about why I prefer resolvable IRIs to downloading files.

1. Protege isn't the only tool we use to access ontologies. We've also written some Python applications that use Owlready2. Owlready2 doesn't use catalog*.xml files.
2. Protege's use of full path names in catalog*.xml files creates headaches when we transfer ontologies between ourselves and when we access them on shared drives. Some of our users are not savvy enough to edit XML files.
3. We send products to our sponsors, and we have no control over (or visibility into) their network configurations. We have to document proper ways to use ontologies, or adapt to their needs – creating merges, say.

These issues inevitably add time and effort. How much easier it would be if an OWL import directive worked without intermediate instructions!

We will never fully achieve that goal because we deliver ontologies to classified environments. If a DNS on one of those environments resolves http://www.ontologyrepository.com, a serious security breach has taken place. However, we do most of our work on unclassified systems, so every step to reduce our workload helps.