issues with ro_import.owl / ro_extra.owl contained in hp.owl and mp.owl

[RLWOHIO]

Since October 11, I have been unable to merge and reason Zfin gene phenotypes in owl format with vertebrate.owl. Nearly all zebrafish classes became unsatisfiable. I finally isolated the issue by yesterday (Oct 24) and it points to the ro_import.owl and ro_extra.owl. There is likely something wrong with these two imports contained in mp and hp respectively. Sorry I could't be more specific at this moment. Prior to Oct. 11, everything apparently worked fine.

Thanks for your attention.

[drseb]

@cmungall @balhoff the problems with ro_import continue. Does either of you have an idea why we see a lot of anatomical entities being classified as both material and immaterial entity? (see screenshot )

[balhoff]

I think this comes down to incompatibilities between ZFA and Uberon and the ZFA-Uberon bridge. These weren't apparent before because ro_import.owl was lacking this disjointness axiom. The best approach would probably be to update ZFA to follow Uberon, but I'm not sure how easy that is.

ZFA doesn't have 'immaterial anatomical entity', but references the distinction in the definition for 'anatomical space'.

[drseb]

@cmungall any ideas or suggestions ? is there a simple solution? I am sorry that the re-generation of RO-import causes thousands of problems

[cerivs]

@cmungall & @balhoff In anatomy, anatomical spaces are part_of continuants. The first editor’s note for BFO:0000050 states “Everything is part of itself. any part of any part of a thing is itself part of that thing.” The usage note states “my stomach cavity is part of my stomach (continuant parthood, immaterial entity is part of material entity)” Anatomical spaces are inherently part of the structure they are formed within; you cannot have a vascular lumen without some vasculature. The lumen is formed by the process of vasculature development.

There are two ways to deal with this issue

1.) Remove the disjointedness in uberon between material and immaterial anatomical entity based on the usage note for BFO:0000050. 2.) Reclassify anatomical spaces as something other than an immaterial entity. -Ceri & Yvonne (@cerivs & @ybradford)

[balhoff]

Thanks for commenting @cerivs! I think the issue is whether material entities should be 'part of' anatomical spaces, or instead only 'located in'. I believe RO is fine with anatomical spaces being 'part of' structures. RO (not Uberon) has this axiom: 'material entity' DisjointWith 'part of' some 'immaterial entity'.

I don't know the origins of this constraint. Does it make sense to you?

[cmungall]

Correct it is only the one direction that is problem

[ybradford]

@balhoff @cmungall are you suggesting that all anatomical entities that are located in an immaterial space be changed from part_of to located_in? This constraint does not make sense to us. This seems to suggest that a material entity is located in an immaterial entity, which in turn is located in or part_of a material entity.

We are following anatomical conventions as other anatomical ontologies are, where anatomical spaces are part_of - see hemolymph FBBT:00005061 is_a portion of organism substance, part_of some hemocoel.

This seems to be a newly created issue. Why was this disjoint relationship added to RO? How does the disjoint relationship help reasoning?

-Yvonne & Ceri

[balhoff]

This seems to suggest that a material entity is located in an immaterial entity, which in turn is located in or part_of a material entity.

This makes sense to me. :-)

I took a look at BFO, and it seems RO is following BFO here:

every entity of which a material entity is continuant part is also a material entity. (axiom label in BFO2 Reference: [021-002])

[balhoff]

@RLWOHIO please try again now. I think the situation should be much better. I replaced the import of ZFA with a zfa_import file built for Upheno. This provides subClass relationships for ZFA terms which are not mapped to Uberon, but otherwise relies on Uberon for classification. This should prevent problems from incompatibilities between Uberon and ZFA.

There are still some unsatisfiable classes due to some problems that have already been fixed in Uberon and HPO, but have not yet been published in new releases.

[RLWOHIO]

Hi, So I did some testing with the new vertebrate.owl, but also included the local import of OWL classes generated from Zfin_phenoGeneCleanData_fish.txt (linked to individual genes). Most of the 50K+ Zfin classes are still not satisfiable, along with some ZP, MP, and HP terms. This was not the case prior to October 11 when I last successfully ran my analysis. Back then, there were only about 100 of these Zfin classes not satisfiable.

I noticed that, except for zfa_import.owl and mp.owl, everything else in the import chain remains the same as they were before when I first reported the issue. I still believe the issue lies in the ro_import.owl (or ro.owl itself?), but not sure why.

Thanks much!

On Wed, Nov 8, 2017 at 12:14 PM, Jim Balhoff notifications@github.com wrote:

@RLWOHIO https://github.com/rlwohio please try again now. I think the situation should be much better. I replaced the import of ZFA with a zfa_import file built for Upheno. This provides subClass relationships for ZFA terms which are not mapped to Uberon, but otherwise relies on Uberon for classification. This should prevent problems from incompatibilities between Uberon and ZFA.

There are still some unsatisfiable classes due to some problems that have already been fixed in Uberon and HPO, but have not yet been published in new releases.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-342887897, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxTiNkshotlUlVdXBMDAi5Abc8pixks5s0eF4gaJpZM4QF4_m .

-- Rong-Lin Wang

[balhoff]

Hi @RLWOHIO can you post a screenshot of an explanation for equivalence to owl:Nothing for one of those ZFIN phenotype classes? Let me know if you don't know how to get that from Protégé.

[RLWOHIO]

Hi Jim,

I struggled a bit to find what you asked. Attached are a few screen shots for each ontology. They all seem to have something to do with the term RO_0002573.

I will be at a conference next week so there might be a delay in my response to my emails. Thanks much!

Ronglin

On Fri, Nov 10, 2017 at 10:51 AM, Jim Balhoff notifications@github.com wrote:

Hi @RLWOHIO https://github.com/rlwohio can you post a screenshot of an explanation for equivalence to owl:Nothing for one of those ZFIN phenotype classes? Let me know if you don't know how to get that from Protégé.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-343509482, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxbX0Oc3s321rhy6BFSR6IQ2i_xvKks5s1HDzgaJpZM4QF4_m .

-- Rong-Lin Wang

[balhoff]

Hi @RLWOHIO I don't think the attachments came through. Basically you would need to click on the question mark icon next to a line showing a given class as equivalent to owl:Nothing. It will work for a little while and then pop up a panel. Feel free to email the images directly to me if it's not working here.

[RLWOHIO]

Hi Jim,

A PowerPoint attachment of screen shots sent to your email account. They include those from Zfin, ZP, HP, and MP, all pointing to the same issue. Thanks again -- Ronglin

On Fri, Nov 10, 2017 at 3:26 PM, Jim Balhoff notifications@github.com wrote:

Hi @RLWOHIO https://github.com/rlwohio I don't think the attachments came through. Basically you would need to click on the question mark icon next to a line showing a given class as equivalent to owl:Nothing. It will work for a little while and then pop up a panel. Feel free to email the images directly to me if it's not working here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-343577057, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxbxl89AJzIxbaSx2iiJvix1pG2fpks5s1LFfgaJpZM4QF4_m .

-- Rong-Lin Wang

[balhoff]

@RLWOHIO the solution to the two examples you sent is pretty straightforward I think. Here is one of the expressions:

('presynaptic active zone organization' and ('occurs in' some 'hair cell')) 
and 
('has quality' some 'decreased process quality') 
and 
('has modifier' some 'abnormal')

The domain of 'has modifier' should be a quality. The update to ro_import added several domain and range constraints that had been missing, but had been in RO for a while. Here the subject of the relation is a GO process. Can you rework your OWL generator to always apply modifiers to the quality term? Like this:

('presynaptic active zone organization' and ('occurs in' some 'hair cell')) 
and 
('has quality' some ('decreased process quality' and ('has modifier' some 'abnormal'))) 

[drseb]

Wait. Isn't he using the zp.owl that we are generating?

[RLWOHIO]

This is great! I will try it out and see how it goes. Thanks much. Note that there are also a number of similarly unsatisfiable classes in the HP, MP, and ZP as well, which also need to be modified accordingly.

On Wed, Nov 15, 2017 at 4:43 PM, Jim Balhoff notifications@github.com wrote:

@RLWOHIO https://github.com/rlwohio the solution to the two examples you sent is pretty straightforward I think. Here is one of the expressions:

('presynaptic active zone organization' and ('occurs in' some 'hair cell')) and ('has quality' some 'decreased process quality') and ('has modifier' some 'abnormal')

The domain of 'has modifier' should be a quality. The update to ro_import added several domain and range constraints that had been missing, but had been in RO for a while. Here the subject of the relation is a GO process. Can you rework your OWL generator to always apply modifiers to the quality term? Like this:

('presynaptic active zone organization' and ('occurs in' some 'hair cell')) and ('has quality' some ('decreased process quality' and ('has modifier' some 'abnormal')))

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-344738191, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxdZtYxYrLEwktjChsxDZ9pKHyWPCks5s21rwgaJpZM4QF4_m .

-- Rong-Lin Wang

[RLWOHIO]

Yes, I use the zp.owl. However, I also like to have zebrafish phenotypes tied to individual zebrafish genes, just like HP terms linked to human genes and MP terms linked to mouse genes. It is kind of difficult for me to figure out directly from zp.owl which ZP terms are associated with which zebrafish genes.

On Thu, Nov 16, 2017 at 12:44 AM, Sebastian Köhler <notifications@github.com

wrote:

Wait. Isn't he using the zp.owl that we are generating?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-344822217, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxWOCZYX8UWjpo1YTJGYRXcbZ0Hlaks5s28u_gaJpZM4QF4_m .

-- Rong-Lin Wang

[drseb]

@balhoff if @RLWOHIO is using zp.owl, we should fix the zp.owl generation. Shall we have a look at https://github.com/Phenomics/zebrafish-phenotype-ontology-build ?

@RLWOHIO for association between zp genes and zp-terms, I think our jenkins job generates these for you: http://compbio.charite.de/jenkins/job/zp-owl/

[RLWOHIO]

Somehow I missed the jenkins location for zp. Yes, that is exactly what I need. That means I dont have to do it myself at all. Thanks!

On Thu, Nov 16, 2017 at 2:51 PM, Sebastian Köhler notifications@github.com wrote:

@balhoff https://github.com/balhoff if @RLWOHIO https://github.com/rlwohio is using zp.owl, we should fix the zp.owl generation. Shall we have a look at https://github.com/Phenomics/ zebrafish-phenotype-ontology-build ?

@RLWOHIO https://github.com/rlwohio for association between zp genes and zp-terms, I think our jenkins job generates these for you: http://compbio.charite.de/jenkins/job/zp-owl/

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-345042660, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxSanpYHeVTT1eARFbqtiH5OysKlhks5s3JJCgaJpZM4QF4_m .

-- Rong-Lin Wang

[RLWOHIO]

Hi Jim,

While I no longer need to build OWL classes for zebrafish genes linked to Zfin phenotypes, I did modify my other self-constructed OWL classes (from annotations of chemical-induced phenotypes) according to your suggestion with regard to "has modifier". I still get a bunch of unsatisfiable classes (see attached slides to your work email account). The slide 1&2 show the modified syntax of "has modifier".

What basically comes down to is this: a GO term SubClassOf BFO_0000003, a Uberon term SubClassOf BFO_0000002; the two BFO terms Disjointed with each other. There must be additional issues introduced after changes were made to ro_import.

Thanks, Ronglin

On Wed, Nov 15, 2017 at 4:43 PM, Jim Balhoff notifications@github.com wrote:

@RLWOHIO https://github.com/rlwohio the solution to the two examples you sent is pretty straightforward I think. Here is one of the expressions:

('presynaptic active zone organization' and ('occurs in' some 'hair cell')) and ('has quality' some 'decreased process quality') and ('has modifier' some 'abnormal')

The domain of 'has modifier' should be a quality. The update to ro_import added several domain and range constraints that had been missing, but had been in RO for a while. Here the subject of the relation is a GO process. Can you rework your OWL generator to always apply modifiers to the quality term? Like this:

('presynaptic active zone organization' and ('occurs in' some 'hair cell')) and ('has quality' some ('decreased process quality' and ('has modifier' some 'abnormal')))

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-344738191, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxdZtYxYrLEwktjChsxDZ9pKHyWPCks5s21rwgaJpZM4QF4_m .

-- Rong-Lin Wang

[RLWOHIO]

Any news on fixing ro_import.owl? What is the status?

Tried vertebrate.owl again in Protege today, and there are still 347 unsatisfiable classes (260 HPs and 87 MPs). The story is the same: each of these classes has terms eventually be SubClassOf both BFO_0000003 and BFO_0000002, which are disjoint. If someone can recommend a quick fix for now before finding a permanent solution down the road, that would be very helpful. Thanks much in advance! --Ronglin

[balhoff]

@drseb I finally started looking at ZP. Here's a pull request to fix a bunch of unsatisfiabilities: https://github.com/Phenomics/zebrafish-phenotype-ontology-build/pull/1

The ZP PURL does not point to your more recent build in that repo. Should I update it to do so?

There are at least 2 other sources of unsatisfiable classes:

• Some classes that have unsatisfiable definitions and aren't in the data anymore (but are retained so as not to lose IDs) - this was the case when I looked at an older version of the ZP builder, need to check with this one
• Property usages in ZFIN annotation data (e.g. using 'part of' to relate a structure to a space violates BFO). This will be harder to fix. We could either add checks for specific property and superclass combinations like 'part of' to 'immaterial entity' (brittle) or ask them to change their data (not sure how possible).

cc @cmungall

[RLWOHIO]

The latest (Feb 5, 2018) version of ro_import.owl still generates a large number of unsatisfiable ZP classes.

On Mon, Jan 22, 2018 at 10:21 PM, Jim Balhoff notifications@github.com wrote:

@drseb https://github.com/drseb I finally started looking at ZP. Here's a pull request to fix a bunch of unsatisfiabilities: Phenomics/zebrafish-phenotype-ontology-build#1 https://github.com/Phenomics/zebrafish-phenotype-ontology-build/pull/1

The ZP PURL does not point to your more recent build in that repo. Should I update it to do so?

There are at least 2 other sources of unsatisfiable classes:

• Some classes that have unsatisfiable definitions and aren't in the data anymore (but are retained so as not to lose IDs) - this was the case when I looked at an older version of the ZP builder, need to check with this one
• Property usages in ZFIN annotation data (e.g. using 'part of' to relate a structure to a space violates BFO). This will be harder to fix. We could either add checks for specific property and superclass combinations like 'part of' to 'immaterial entity' (brittle) or ask them to change their data (not sure how possible).

cc @cmungall https://github.com/cmungall

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obophenotype/upheno/issues/245#issuecomment-359663605, or mute the thread https://github.com/notifications/unsubscribe-auth/AOJjxeSEoS8lFmX9SufRRErH1g6-iVbdks5tNVA8gaJpZM4QF4_m .

-- Rong-Lin Wang

[RLWOHIO]

Tested the latest version of ro_import.owl along with vertebrate.owl today (4/17/2018). There were still 1810 ZP terms NOT satisfiable (zp.owl version 2017-07-05). All these ZP terms have data. When the old ro_import.owl (sourced from ro.owl release of 2015-04-12) was used instead, ALL zp terms were satisfiable.

[cerivs]

Did you use the preversion or the production version of ZFA to build ZP?

[RLWOHIO]

I didn't build zp.owl. It was downloaded from https://github.com/Phenomics/zebrafish-phenotype-ontology-build, which contains a more recent version. The version at http://purl.obolibrary.org/obo/upheno/zp.owl is older.

[RLWOHIO]

I just like to add that, besides those unsatisfiable ZP terms, there were also a bunch of other unsatisfiable custom terms I post-composed myself. None of them happened with the older ro_import.owl, so the issue is most likely attributable to the changes introduced into ro.owl since its release of 2015-04-12. Earlier postings in this chain seem to implicate some sort of disjoint relationships present in the later versions of ro.owl, which may be incompatible with several ontologies.