Current version of CCO accessed on web does not import BFO!

[alanruttenberg]

http://www.ontologyrepository.com/CommonCoreOntologies/Mid/AllCoreOntology
retrieves http://www.ontologyrepository.com/CommonCoreOntologies/Mid/2024-02-14/AllCoreOntology

which doesn't have a BFO imports, so only IDs are shown at the top level.

[alanruttenberg]

The merged version does have BFO in it.

[alanruttenberg]

But the merged version IRIs don't resolve.
What am I missing?

[alanruttenberg]

Maybe the readme should say what the official IRIs are...

[mark-jensen]

Is this related to #221?

All Core is just an import handler. It pulls in 5 or 6 ontologies, which themselves all eventually pull in the 11 CCO modules plus BFO via ERO.

I don't like the way we currently do this. We are now exploring alternatives to improve CCO modularization, the release, and import methodology.

[alanruttenberg]

All core does not import BFO, even indirectly. Try it: http://www.ontologyrepository.com/CommonCoreOntologies/Mid/AllCoreOntology

[alanruttenberg]

This is what I see in Protege

[ewrayjohnson]

I would appreciate a online meeting (with @alanruttenberg and @mark-jensen) to discuss this issue and #221.

[alanruttenberg]

@ewrayjohnson I am available this afternoon.

[ewrayjohnson]

@ewrayjohnson I am available this afternoon.
See my direct email

[mark-jensen]

@alanruttenberg @ewrayjohnson I believe I have discovered the problem here. If you open this link in your browser, or download the file and look at it in a text editor, you see the import statement for BFO is absent in ERO.

https://www.ontologyrepository.com/CommonCoreOntologies/Mid/ExtendedRelationOntology

The version of ERO that is part of the 1.5 release contains it however. Not sure what happened. I'll get the server updated asap.

[alanruttenberg]

Mark, please add a BFO import to each of the domain ontologies.

…

On Thu, May 30, 2024 at 3:35 PM Mark Jensen ***@***.***> wrote: @alanruttenberg <https://github.com/alanruttenberg> @ewrayjohnson <https://github.com/ewrayjohnson> I believe I have discovered the problem here. If you open this link in your browser, or download the file and look at it in a text editor, you see the import statement for BFO is absent in ERO. https://www.ontologyrepository.com/CommonCoreOntologies/Mid/ExtendedRelationOntology The version of ERO that is part of the 1.5 release contains it however. Not sure what happened. I'll get the server updated asap. — Reply to this email directly, view it on GitHub <#255 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB3CDWANCXW35LGC45C2PLZE55RXAVCNFSM6AAAAABIANEPDOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQG42DGMBWHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mark-jensen]

@ewrayjohnson @alanruttenberg This problem has been fixed. The version of ERO loaded up on the server has the correct import for BFO2020. Loading it, or All Core, or any of the other CCO ontologies, will find and load BFO as intended.

[alanruttenberg]

@mark-jensen Well, I'll say it one more time for emphasis. It is bad practice to rely on an indirect import. Ontologies that use terms in imported ontologies should directly import those ontologies.

[neilotte]

@alanruttenberg Has this ticket been resolved?

[alanruttenberg]

No. As I commented there should be an import of BFO in every ontology that uses a BFO term.

[neilotte]

@alanruttenberg Is there a reference or documentation for the rule that any ontology that uses a resource in another ontology shall directly rather than indirectly import that ontology?

FYSA: @johnbeve @mark-jensen @APCox

[alanruttenberg]

No, it should be obvious.

[mark-jensen]

This raises an unsettled question about the status of the individual ontologies as independent ontologies that get a proper release vs them serving as module parts of a whole. These options aren't exclusive, of course, but we don't currently do a good job explaining this. Users are told to start with All Core, which sets off an import chain requiring resolving dependancies, most indirect. Many users have trouble with this. The ubiquitous diagram displaying the import chain of CCO is painful to look at as it tells people almost nothing about how terms in one ontology depend on terms in other ontologies. The true dependencies of each ontology are hidden by a convoluted import strategy that implicitly adopts a view of the CCO as one ontology with interdependent modules. This is exemplified by the fact that when a release is cut, all ontologies get new version info, even if nothing has changed in some ontology other than its version IRI and annotation. I have advocated in the past for making the main release of CCO be one merged file with BFO included and placing the individual ontology files in a separate folder, with their own versioning strategy where only CCO merged would get a new number, but the individual ontologies do not get a number and only get their version IRIs updated when they are changed. Advanced users wishing to work with one ontology, or, more likely, a subset of terms from several of the ontologies, should have no difficulty navigating this approach.

I recognize this comment above does not directly address @alanruttenberg desire to have no indirect imports, but a clear decision on release strategy and the status of the 11 base ontologies will in part help answer that question.

One task, an easy one I think, is to do some sparqling and get an explicit list of dependancies for each ontology. E.g., the Facility Ontology directly imports Artifact, which results in chain of full ontology dependancies: Information Content, Geospatial, Time, Extended Relation, and BFO. Yet, the only other terms from CCO that Facility ontology depends on are 'Facility', 'Material Artifact', and 'Portion of Geosphere'. The leaf terms from BFO are: 'located in', 'fiat object part', and 'material entity'.

[mark-jensen]

An example of this confusion of how the ontologies fit together, i.e, CCO design strategy, can bee seen in #337

[swartik]

There is another approach, which is to treat the 11 ontologies as development modules. The official CCO is the one in the cco-merged directory. The obvious advantages: it eliminates:

• The entire problem of importing all the ontologies.
• Arguments over whether every one of them should import BFO.

The obvious disadvantages:

• It adds an extra step to the production of a CCO release.
• It requires every CCO user to import the elements of all 11 modules.

Has this approach been considered?

[alanruttenberg]

Concur that this depends on the status of the 11 ontologies. If they are only development artifacts then it's not so much an issue, though even in development it's easier to focus if less than the whole of CCO is loaded at once. Yes there is Protege's ability to show just the focus ontology, but that's unsatisfactory because then external terms that are referenced don't include any annotations and this is particularly problematic when opaque ids are used. I've submitted a tick to Protege asking that this be fixed, but alas no funding for Protege so very little development gets done.

Another strategy is to better manage them being used independently by creating, for each, a MIREOT of terms from the other ontologies. Those MIREOT imports would be ignored when merging.

Personally I am finding working with large ontologies (in particular my own) to be painful because of the focus issue and have been thinking of ways to automate the creation of many smaller modules, each focused in an area or on a use case.

[neilotte]

Adding reference here to a duplicate issue that I have closed: #227

[neilotte]

@mark-jensen I believe the originating issue for this ticket was addressed in the 2.0 release, but then a discussion opened. I recommend taking this to the discussion section. Let me know if you concur.

[johnbeve]

@mark-jensen @neilotte @alanruttenberg where did we land on this?

[ewrayjohnson]

It looks like the immediate issue was caused by the version of ERO on the server missing the BFO import, which has since been corrected. So from a runtime perspective, loading behavior should now be consistent again.

However, I think this thread exposed a deeper architectural concern that is still unresolved:

• The current model relies on indirect imports (e.g., via ERO) to bring in foundational ontologies like BFO.
• This creates fragility and ambiguity, especially when different distribution artifacts (merged vs modular) behave differently.
• As noted earlier, this can lead to cases where:
  • Classes appear in merged versions but not modular ones
  • IRIs don’t resolve as expected
  • Tooling (e.g., Protégé) shows incomplete hierarchies

From an ontology engineering standpoint, this suggests we should clarify and standardize one of the following:

Option A (recommended):
Each ontology directly imports any ontology whose terms it uses (e.g., explicit BFO imports where applicable).
→ Improves determinism, tooling behavior, and reuse clarity.

Option B:
Formally define and document an import contract (e.g., “AllCore guarantees BFO via ERO”), and ensure:

• All distribution artifacts honor it
• Server-hosted versions are consistent with releases

At minimum, the README / documentation should explicitly state:

• What the authoritative IRIs are
• Whether direct vs indirect imports are expected
• Which artifact (merged vs modular) is considered canonical

Otherwise, we risk recurring inconsistencies like this.

Curious where the team wants to land on this—particularly given the ongoing work on improving modularization and release methodology.

[alanruttenberg]

A: +1

[johnbeve]

A: +1

[johnbeve]

Task here will be option A:

Each ontology directly imports any ontology whose terms it uses (e.g., explicit BFO imports where applicable).

Plan to implement this in the next release.

[johnbeve]

I've added import statements for BFO to the modules. Currently moving this to discussion alongside this #899 since a strategy is needed for balancing importing entire CCO modules vs what's needed to recreate the module hierarchy.

As an example of the challenge, just adding explicit imports for classes in a given import brings along with it all of the Time Ontology, Geospatial Ontology, and Extended Relations Ontology. Often this is for a single class, which results in a lot of content to sort through.

Targeting this for release 3.0.