Whole mouse brain ontology added as component

[hkir-dev]

• Added a subset of the Whole Mouse Brain Ontology, consisting of 147 cell types, as a component to the CL.
• Since WMBO relies on the Mouse Brain Atlas for anatomical locations, that ontology has also been imported.
• Allocated the ID range 4300001–4800000 for BICAN-generated terms.

A preview of the Cell Ontology including this new component is available at: https://cellular-semantics.sanger.ac.uk/ols4/ontologies/cl
Whole Mouse Brain Ontology is available at https://cellular-semantics.sanger.ac.uk/ols4/ontologies/wmbo

[gouttegd]

Technically speaking, regarding the “compliance with ODK ways of doing things” (what I was specifically asked to review), this is OK, modulo the fact that both the MBAO import and the WMBL-CL component are downloaded using their “raw” GitHub URLs instead of the BICAN PURLs.

[gouttegd]

Beyond the issue of “compliance with the ODK ways of doing things”:

(1) I have various concerns about the contents of the WMBO-CL component:

(1a) Use of http://identifiers.org/ncbigene/XXXXXX IDs for the genes. The CLM-CL component is using http://identifiers.org/ensembl/XXXXX identifiers. Couldn’t we decide on one source of gene identifiers (either ENSEMBL or NCBI Gene) and consistently use it?

(1b) All gene entities in the WMBO-CL component are dangling classes. This creates a mess when the component is merged into CL, since all those genes are thrown directly under owl:Nothing. In the CLM-CL component, gene entities are all subclasses of SO:0000704, so that they don’t pollute the root tree. Couldn’t WMBO-CL do the same?

(1c) Cells are linked to their marker sets using the has marker set (CLM:0010003) annotation property. In the CLM-CL component, the has characterising marker set (RO:0015004) object property is used instead. I think it is already bad enough to use different properties for the same thing in different components, but using an annotation in one component and a relationship in another seems very bad.

(1d) Some cell types are linked to an anatomical location by a some soma located in annotation property. Why is that not a relationship instead?

(2) CL should probably import the STATO ontology so that some of the annotations in the marker sets make sense (e.g. STATO_0000416, STATO_0000663).

[gouttegd]

Approving since my comments regarding the (non-)use of PURLs have been answered.

[dosumis]

All reasonable critiques. replies in-line

(1) I have various concerns about the contents of the WMBO-CL component:

(1a) Use of http://identifiers.org/ncbigene/XXXXXX IDs for the genes. The CLM-CL component is using http://identifiers.org/ensembl/XXXXX identifiers. Couldn’t we decide on one source of gene identifiers (either ENSEMBL or NCBI Gene) and consistently use it?

We should standardise on http://identifiers.org/ncbigene/ wherever possible. Without this we will have duplicate nodes with different identifiers. We are moving towards using the translator endpoint to do this mapping in multiple projects.

The fix should be to CLM-CL - prioritised for next release.

(1b) All gene entities in the WMBO-CL component are dangling classes. This creates a mess when the component is merged into CL, since all those genes are thrown directly under owl:Nothing. In the CLM-CL component, gene entities are all subclasses of SO:0000704, so that they don’t pollute the root tree. Couldn’t WMBO-CL do the same?

Agree - all should be subclasses of SO:0000704. I think this was present in earlier pipeline versions but must have been lost. @hkir-dev - what's the easiest way to add?

(1c) Cells are linked to their marker sets using the has marker set (CLM:0010003) annotation property. In the CLM-CL component, the has characterising marker set (RO:0015004) object property is used instead. I think it is already bad enough to use different properties for the same thing in different components, but using an annotation in one component and a relationship in another seems very bad.

We formerly used 'has characterising marker set' OP because we previously assumed that markers should be inherited down the class hierarchy. It is now clear that this is not the case for markers coming from single cell, e.g. markers may identify a general type with 95% confidence, but a small subclass might fall into the 5% not identified by the marker. I would prefer to switch all to the AP. We should work with RO to add there but this can't be a dependency.

I think this shouldn't block the release as fix should be to CLM-CL for next release.

(1d) Some cell types are linked to an anatomical location by a some soma located in annotation property. Why is that not a relationship instead?

These relationships are some-some, so OP would lead to many false inferences. This is the only realistic way for us to add location to these terms.

(2) CL should probably import the STATO ontology so that some of the annotations in the marker sets make sense (e.g. STATO_0000416, STATO_0000663).

Makes sense. Although have an issue with punning STATO class to AP. Can't recall if we can legally add this as a pun. @hkir-dev - what do we do in PCL?

[gouttegd]

Thanks! I agree with all the replies.

[hkir-dev]

• All NCBI gene classes are now defined as subclasses of SO:0000704. Additionally, labels have been added to each gene class.
• The STATO ontology has been imported. Punning between classes and annotation properties is permitted. Provisional Cell Ontology (PCL) does not import STATO; instead, relevant labels were added directly in the edit files. As a result, the following RDF description appeared in cl.owl:

    <rdf:Description rdf:about="http://purl.obolibrary.org/obo/STATO_0000663">
        <obo:IAO_0000115 xml:lang="en">The F-beta score is a measure of a model&apos;s accuracy, specifically designed to evaluate the performance of binary classification models. It is a generalized form of the F1 score, which itself is the harmonic mean of precision and recall. The F-beta score introduces a way to weigh recall more heavily than precision (or vice versa) depending on the value of beta.</obo:IAO_0000115>
        <obo:IAO_0000116 xml:lang="en">https://github.com/ISA-tools/stato/pull/86</obo:IAO_0000116>
        <rdfs:label xml:lang="en">F-beta score</rdfs:label>
    </rdf:Description>

   <owl:Class rdf:about="http://purl.obolibrary.org/obo/STATO_0000663">
        <rdfs:subClassOf rdf:resource="http://purl.obolibrary.org/obo/STATO_0000623"/>
    </owl:Class>

    <owl:AnnotationProperty rdf:about="http://purl.obolibrary.org/obo/STATO_0000663"/>

[dosumis]

@hkir-dev - So all good to merge now? Or do we have duplicate axioms on the STATO term in CL?

[hkir-dev]

All outputs look good. We can merge once the reviews are complete.