Imported classes and annotation properties

[mark-jensen]

A general issue to raise concerns with the current imports. A secondary goal for this issue is to establish a protocol for future imports into SDGIO.

@pbuttigieg @cmungall I would like to aid in resolving these and am happy to make any needed modifications.

1. None of the imported classes have annotations other than 'label', except for some classes from BFO.
2. Several BFO classes have duplicate labels and definitions. Eg- 'realizable entity' has four duplicate labels (declared separately in iao_import, ro_import, envo_import and bfo_import).
3. Not all classes from BFO are imported. Why not a direct import of BFO?
4. PATO 'morphology', 'shape' and 'linear' appear as subclasses under both BFOs and PATOs 'quality', which are siblings. I realize this is a PATO problem, inherited via RO, but shouldn't we have a way of addressing it for users/viewers of the ontology? At least via comment?
5. Similar to above, CHEBI 'role' exists independently of BFO 'role'. CHEBI 'role', like PATO 'quality', doesn't map directly to its BFO namesake. It's a sibling realizable entity though.
6. Perhaps a problem for PCO, but why isn't 'collection of organisms' asserted as an BFO 'object aggregate'?

[cmungall]

Most of these are known issues with either ontologies using root classes in the non BFO sense or issues to do with the fact we do not have a perfect modularization tool

None of the imported classes have annotations other than 'label', except for some classes from BFO.

We can customize this

Several BFO classes have duplicate labels and definitions. Eg- 'realizable entity' has four duplicate labels (declared separately in iao_import, ro_import, envo_import and bfo_import).

Indeed. See https://github.com/ontodev/robot/issues/38 for more background. Any fixes in robot much appreciated

Not all classes from BFO are imported. Why not a direct import of BFO?

We will only take BFO classes

PATO 'morphology', 'shape' and 'linear' appear as subclasses under both BFOs and PATOs 'quality', which are siblings. I realize this is a PATO problem, inherited via RO, but shouldn't we have a way of addressing it for users/viewers of the ontology? At least via comment?

File this on the PATO tracker, it won't be resolved here I'm afraid

Similar to above, CHEBI 'role' exists independently of BFO 'role'. CHEBI 'role', like PATO 'quality', doesn't map directly to its BFO namesake. It's a sibling realizable entity though.

File on CHEBI tracker

1. Perhaps a problem for PCO, but why isn't 'collection of organisms' asserted as an BFO 'object aggregate'?

[mark-jensen]

Not all classes from BFO are imported. Why not a direct import of BFO?

We will only take BFO classes

The current release of BFO is classes only See here

[mark-jensen]

None of the imported classes have annotations other than 'label', except for some classes from BFO.

We can customize this

I'd be happy to do that, but may need some feedback on the import process.

[cmungall]

Maybe we can start with some requirements - who will be viewing the classes, what tool will they view them from, what information do they need to get out?

Many of the BFO annotations are potentially confusing to a broad range of users. For example, I believe I am one of the few people who can read the CLIF axioms, and even then these are useless to me (if I want to see the CLIF, I'll look at the CLIF file). If these are to be included in the import modules, we need to coordinate with the portal developers to ensure that these are tucked away so that they aren't the first thing UNEP people see.

On 29 Oct 2015, at 8:19, Mark Jensen wrote:

None of the imported classes have annotations other than 'label', except for some classes from BFO.

We can customize this

I'd be happy to do that, but may need some feedback the import process.

---

Reply to this email directly or view it on GitHub: https://github.com/SDG-InterfaceOntology/sdgio/issues/32#issuecomment-152211956

[mark-jensen]

@cmungall This is a good point. Many of the BFO annotations can be distracting.

My first thought is that they should be included in the development version of the ontology, but then potentially removed from what is used for the portal. Depending, I guess, on how the files are used.

[mark-jensen]

I believe the reason for PCO 'collection of organisms' being outside the 'entity' hierarchy is because in PCO it is defined via an equivalency, but not directly asserted as subclass of 'object aggregate'. That may be intentional though. @rlwalls2008

[mark-jensen]

@cmungall @pbuttigieg I would find it helpful to have at least definitions for imported classes included the editors version.

Importantly though, moving forward, I believe that the inclusion of annotation and object properties is now a requirement since we intend to provide a master JSON-format summary file for use in the portal (#100). UNEP will need our release version to include all annotations (definitions, synonyms, comments) for imported as well as SDGIo natives for use in the search dialogue and class information pages, as well as object properties for the visualization tool Kevin has built.

But I think we can skip this for the BFO import since we will eventually be ignoring those classes for the portal anyways (#102).

[cmungall]

I believe the Makefile is setup to preserve these now:

# clone remote ontology locally, perfoming some excision of relations 
and annotations
mirror/%.owl: $(SRC)
    owltools $(OBO)/$*.owl --remove-annotation-assertions -l -s -d 
--remove-dangling-annotations --make-subset-by-properties -f $(KEEPRELS) 
  -o $@
.PRECIOUS: mirror/%.owl

the lsd options are for preserving labels, synonyms and definitions

It could just be that we need to regenerate the imports

On 29 May 2016, at 9:26, Mark Jensen wrote:

@cmungall @pbuttigieg I would find it helpful to have at least definitions for imported classes included the editors version.

Importantly though, moving forward, I believe that the inclusion of annotation and object properties is now a requirement since we intend to provide a master JSON-format summary file for use in the portal (#100). UNEP will need our release version to include all annotations (definitions, synonyms, comments) for imported as well as SDGIo natives for use in the search dialogue and class information pages, as well as object properties for the visualization tool Kevin has built.

But I think we can skip this for the BFO import since we will eventually be ignoring those classes for the portal anyways (#102).

---

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/SDG-InterfaceOntology/sdgio/issues/32#issuecomment-222369326