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

[alanruttenberg]

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

[alanruttenberg]

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

[alanruttenberg]

No, it should be obvious.

[alanruttenberg]

The merged version does have BFO in it.

[alanruttenberg]

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

[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]

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

[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