see why NCBITAXON is not parsing

[syphax-bouazzouni]

For information it don't work also in NCBI bioportal

[syphax-bouazzouni]

related ncbo/ontologies_linked_data#124, ncbo/bioportal-project#228
The NCBO folks thinks it is a heap size memory problem.

[jonquet]

Certainly fixed in BioPortal with new heap size setting. Thus can be tested again with the new heap-size parametrized setting (ontoportal-lirmm/ontologies_linked_data#15)

[syphax-bouazzouni]

Retry after ncbo/ontologies_linked_data#124 and ncbo/goo#122

The Result is an error : "file not found in https://data.bioontology.org/ontologies/NCBITAXON/download?apikey=..."

There is a special handler for UMLS files

[syphax-bouazzouni]

Changing the format from UMLS to OWL did fix the issue

[syphax-bouazzouni]

FYI @naouelkaram

[naouelkaram]

Hi @syphax-bouazzouni, do you know why the Classes are also Individuals? you can see it in the metrics and also on the raw data of the classes.

[jonquet]

This need some investigation indeed.
Seeing the ressource as an OWL file on our side has enabled parsing, but the result in the tree hiearchy is not good. We have stuff that should not be there as top concepts.
I would suppose the OWL-API also ends up counting every classes an instances too.

[naouelkaram]

Definitely @jonquet, I did an initial investigation on the BioPortal ttl version and I suspect the issue comes from the use of umls:hasSTY which is an ObjectProperty so the OWL-API classified all classes also as individuals. Also the top concepts appearing in Agroportal are not classified, they are also in BioPortal, they just do not appear in the hierarchy until you search for them, like this one: http://purl.bioontology.org/ontology/NCBITAXON/374660.
There are SKOS Classes (Concept, etc...) because the ontology imports skos.
And finally, the URIs are different from the OBO ones: http://purl.bioontology.org/ontology/NCBITAXON/374660 instead of http://purl.obolibrary.org/obo/NCBITaxon_374660