Issue importing bfo-core.ttl about commoncoreontologies

[neilotte]

@swartik I'm using Protege 5.6.1 to open the files from same branch and commit and I'm not encountering a problem importing bfo. Perhaps @johnbeve or @alanruttenberg can speak to your ontology IRI question.

[alanruttenberg]

The ontology IRI is always http://purl.obolibrary.org/obo/bfo.owl
The version IRI is http://purl.obolibrary.org/obo/bfo/2020/bfo-core.ttl - that's the one to import. or http://purl.obolibrary.org/obo/bfo/2020/bfo-core.owl -both have the same content but are different formats.
The ontology is accessible from either the ontology IRI or the version IRI, but you import the version IRI if you want the specific version.
The extended relations ontology is importing the wrong IRI: owl:imports obo:bfo ; which translates to http://purl.obolibrary.org/obo/bfo

It needs to import one of the above version IRIs.
The entry in catalog-v001.xml is also wrong. Currently

    <uri id="User Entered Import Resolution" name="http://purl.obolibrary.org/obo/bfo" uri="imports/bfo-core.ttl"/>

Should be

    <uri id="User Entered Import Resolution" name="http://purl.obolibrary.org/obo/bfo/2020/bfo-core.ttl" uri="imports/bfo-core.ttl"/>

Once the catalog is fixed and the correct IRI is imported all will be good.

The reason that changing the IRI to http://purl.obolibrary.org/obo/bfo works is due to a cascade of errors. Extended relations imports http://purl.obolibrary.org/obo/bfo. That's looked up in the catalog. The catalog has that IRI, so it thinks it's going to find the ontology with the IRI (version or main) that is http://purl.obolibrary.org/obo/bfo. When it doesn't apparently it's deciding something is wrong and not loading, because, well, something is wrong.
The ontology it looks up must have the same value of ontology or version IRI that was imported. It doesn't.

[alanruttenberg]

Technically, any file that uses a BFO term should be importing BFO. Which I'm guessing is all of them. But all have to import the same IRI.

[swartik]

The IRI http://purl.obolibrary.org/obo/bfo resolves to the GitHub web page for the BFO project, not a file containing an ontology, so @alanruttenberg's statement that the imports directive in ExtendedRelationOntology.ttl is wrong makes sense to me.

I'm less certain about the claim that the catalog entry is wrong. At least, I don't think there's a single entry that's right. I tried various combinations of owl:imports directives and catalog entries. (Keep in mind I'm using Protege 5.5, and @neilotte's experience suggests 5.6 behaves differently.) There's no single catalog entry that works for any of the three IRIs. The 's name attribute has to match the object of an imports directive, so http://purl.obolibrary.org/obo/bfo/2020/bfo-core.ttl in the catalog only works if the imports directive is:

owl:imports <http://purl.obolibrary.org/obo/bfo/2020/bfo-core.ttl>

Someone needs to decide which IRI to use in the imports directive, and the catalog should be changed in response to that decision.

[mark-jensen]

@swartik Thanks for the catch. I can confirm this behavior does not occur in 5.6, but does in 5.5.
@alanruttenberg Your suggested changes to import stmt. in ERO and the catalog.xml fixed the problem. Thanks!

How is BFO being versioned? I expect a v-IRI to have a date or some numeric to distinguish unique versions.
http://purl.obolibrary.org/obo/bfo/2020/bfo-core.ttl seems static to me. What will change about that IRI when the next version is released?

[mark-jensen]

@swartik Check out this branch and let me know if it works for you.

https://github.com/CommonCoreOntology/CommonCoreOntologies/tree/ero-import-fix

@neilotte @johnbeve Any reasons not to merge these changes into master?

[swartik]

@mark-jensen It's working now. Thanks for the quick response.

[alanruttenberg]

When a new release happens we'll change the version IRI of this one to have a date and have the new version have this IRI. best we can do because the ontology IRI is fixed

[oliviahobai]

The BFO's version IRI has changed accordingly as of February 21