Dual injections from FOODON and OBI into GAZ causes incoherency #1375
Comments
|
Call discussion Monday June 21: much of this hinges on COB position with respect to geographic location, and allowing subscribing ontologies to synchronize with COB's classification. However COB development plan timeline is uncertain so wouldn't want to import COB at this point. Suggest move question of treatment of geographic location up to OBO Operations for decision. In meantime FoodON will consult with Chris about needing timing for resolution of this. Multiple groups are considering alternative sources for geographic location (e.g. geonames), however OBO still needs a term for geographic location (or its sensu variations). |
|
Also, see COB discussion about this already: OBOFoundry/COB#91 . Should this be raised to OBO operations level debate? |
|
Yes, we definitely need to talk about this and other injections at the OBO level But was my short term fix discussed on the call?
This is very straightforward, completely ontologically justifiable, and as far as I can see suffers no downside. We need to be more agile about this kind of thing and fix simple common sense things quickly |
|
Yes, that was discussed on the call. The problem is that there is
an unknown number of systems using GAZ 'geopgraphical entity' defined as
site in systems using / importing OBI. It has been present like this for a
long time. Based on the call with ~10 people present, we already found a
handful of people affected. So we are not going to change this on a whim,
but would rather find a COB wide agreement, and also find a potential
replacement for GAZ in the process.
…On Mon, Jun 21, 2021 at 6:28 PM Chris Mungall ***@***.***> wrote:
Yes, we definitely need to talk about this and other injections at the OBO
level
But was my short term fix discussed on the call?
My proposal is that OBI changes its injection to be consistent with FOODON.
This is very straightforward, completely ontologically justifiable, and as
far as I can see suffers no downside. We need to be more agile about this
kind of thing and fix simple common sense things quickly
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1375 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADJX2IWKTOQV3ELZ4AS74KLTT7RKHANCNFSM46YMPV6A>
.
--
Bjoern Peters
Professor
La Jolla Institute for Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
|
|
I don't think it's true that there is an unknown number of systems using GAZ 'geopgraphical entity' in OBI. We can see the usages clearly. In fact there is a single usage, in IAO "postal address subClassOf is-about some geographic location" http://www.ontobee.org/ontology/IAO?iri=http://purl.obolibrary.org/obo/GAZ_00000448 I think we need to be better at balancing the need for such rococo axioms against the fact that we have had a major incoherency in OBO for over a month. This is akin to a major software library release software that doesn't compile for a month. There is a very very simple solution here - simply remove the axiom from IAO and remove the GAZ import (this was the only GAZ class used) information-artifact-ontology/IAO#248 If people truly find the axiom valuable then it can be re-added using ENVO or GEO later, but I doubt anyone has ever found this axiom useful |
|
I see these Ontobee ontologies reference GAZ geographic location directly: AERO, APOLLO_SV, CHEMINF, DIDEO, DUO, EUPATH, FLU, FOODON, GENEPIO, GSSO, HSO, HTN, IAO, ICO, KTAO, OBI, OBI-NIAID-GSC-BRC-view, OBIB, OLAM, OMRSE, ONE, ONS, OOSTT, OPMI, PNO, PSDO, VICO, d-acts, and all place it under "site" except for FoodOn and GenEpiO. I'm updating FoodOn and GenEpiO to switch to GEO Geographical Location today to avoid conflict. |
|
FoodOn switching to "GEO geographical location" which will fix unsatisfiability of GAZ geographic location itself, but FoodOn and GenEpiO include the GAZ subclasses for continents and countries, so this still poses a problem if a merged ontology includes both GAZ and GEO location branches. Addendum: FoodOn will drop GAZ subclasses for country and leave it up to consuming ontologies to choose their preferred geo ontology for the moment. |
|
I suspect this is not correct and this just reflects ontologies importing
IAO
I think we need a script to detect who truly uses an ontology term. I think
this would be trivial in spaql over ontobee.
…On Tue, Jul 13, 2021 at 11:27 AM Damion Dooley ***@***.***> wrote:
I see these Ontobee ontologies reference GAZ geographic location directly:
AERO, APOLLO_SV, CHEMINF, DIDEO, DUO, EUPATH, FLU, FOODON, GENEPIO, GSSO,
HSO, HTN, IAO, ICO, KTAO, OBI, OBI-NIAID-GSC-BRC-view, OBIB, OLAM, OMRSE,
ONE, ONS, OOSTT, OPMI, PNO, PSDO, VICO, d-acts, and all place it under
"site" except for FoodOn and GenEpiO.
I'm updating FoodOn and GenEpiO to switch to GEO Geographical Location
today to avoid conflict.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1375 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMMOPZK5YO4SGYT5OXHHLTXSASJANCNFSM46YMPV6A>
.
|
|
A few things to clarify:
- I believe the incoherency only arises from conflicting injections. So if
IAO accepts the PR I made, then the problem is resolved as soon as everyone
refreshes their IAO imports
- regardless of this specific incoherency, I do not think importing
classes from an ontology that (a) is inactive and (b) that was never
intended as a source of classes, only instances -- is a good idea. I think
you are shoring up future technical debt
Somewhere (outside of this ticket, as I suspect OBI does not care too much
about geolocations) we need to solve the geolocation instance problem in
OBO. I suspect we take this over here:
https://github.com/EnvironmentOntology/gaz/issues where various plans to
rescue GAZ are proposed. IMHO we should use Wikidata URIs or some other
system for place instances.
But just to reiterate: to solve this **immediate** incoherency problem is
very simple and doesn't require us going down the GAZ rabbit hole. Just
accept my PR on IAO
…On Tue, Jul 13, 2021 at 12:24 PM Damion Dooley ***@***.***> wrote:
FoodOn switching to "GEO geographical location" which will fix
unsatisfiability of GAZ geographic location itself, but FoodOn and GenEpiO
include the GAZ subclasses for continents and countries, so this still
poses a problem if a merged ontology includes both GAZ and GEO location
branches.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1375 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMMOK6OJUB4IRFE6JWBHDTXSHGJANCNFSM46YMPV6A>
.
|
|
Regarding usage of GAZ 'geopgraphical entity' in OBI, I was not referring
to other ontologies, but applications that utilize OBI. From the call we
know that they include the IEDB as well as independent systems run by James
and Chris S.
…On Tue, Jul 13, 2021 at 10:10 AM Chris Mungall ***@***.***> wrote:
I don't think it's true that there is an unknown number of systems using
GAZ 'geopgraphical entity' in OBI. We can see the usages clearly. In fact
there is a single usage, in IAO
"postal address subClassOf is-about some geographic location"
http://www.ontobee.org/ontology/IAO?iri=http://purl.obolibrary.org/obo/GAZ_00000448
I think we need to be better at balancing the need for such rococo axioms
against the fact that we have had a major incoherency in OBO for over a
month. This is akin to a major software library release software that
doesn't compile for a month.
There is a very very simple solution here - simply remove the axiom from
IAO and remove the GAZ import (this was the only GAZ class used)
information-artifact-ontology/IAO#248
<information-artifact-ontology/IAO#248>
If people truly find the axiom valuable then it can be re-added using ENVO
or GEO later, but I doubt anyone has ever found this axiom useful
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1375 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADJX2IVBIMRC6CCAWEDXYMTTXRXQ7ANCNFSM46YMPV6A>
.
--
Bjoern Peters
Professor
La Jolla Institute for Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
|
|
To be clear:
- I agree with the desire to have a better assessment of actual usage of
terms across ontologies by excluding the effect of imports
- It would be better still to assess use of terms 'in the wild', like that
in the IEDB. We had talked about that before, and it is obviously
technically hard (we would need graph exports or the like of those projects)
- I agree with Chris that this needs urgent resolution. But I don't like
the default of dropping site and switching to material entity, which is the
opposite of what I would argue for. I don't want my opinion to block this,
but I also don't want us to change it one way now, and then have the
OBO/COB discussion and change it back. So my preference was to do the
OBO/COB discussion now. If that is inconclusive, I am in favor of carrying
out Chris M. pull request.
…On Thu, Jul 15, 2021 at 7:48 AM Bjoern Peters ***@***.***> wrote:
Regarding usage of GAZ 'geopgraphical entity' in OBI, I was not
referring to other ontologies, but applications that utilize OBI. From the
call we know that they include the IEDB as well as independent systems run
by James and Chris S.
On Tue, Jul 13, 2021 at 10:10 AM Chris Mungall ***@***.***>
wrote:
> I don't think it's true that there is an unknown number of systems using
> GAZ 'geopgraphical entity' in OBI. We can see the usages clearly. In fact
> there is a single usage, in IAO
>
> "postal address subClassOf is-about some geographic location"
>
>
> http://www.ontobee.org/ontology/IAO?iri=http://purl.obolibrary.org/obo/GAZ_00000448
>
> I think we need to be better at balancing the need for such rococo axioms
> against the fact that we have had a major incoherency in OBO for over a
> month. This is akin to a major software library release software that
> doesn't compile for a month.
>
> There is a very very simple solution here - simply remove the axiom from
> IAO and remove the GAZ import (this was the only GAZ class used)
>
> information-artifact-ontology/IAO#248
> <information-artifact-ontology/IAO#248>
>
> If people truly find the axiom valuable then it can be re-added using
> ENVO or GEO later, but I doubt anyone has ever found this axiom useful
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1375 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADJX2IVBIMRC6CCAWEDXYMTTXRXQ7ANCNFSM46YMPV6A>
> .
>
--
Bjoern Peters
Professor
La Jolla Institute for Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
--
Bjoern Peters
Professor
La Jolla Institute for Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
|
|
Would removing GAZ from the import impact these systems? I assume if IEDB
etc are using GAZ, then you are using terms beyond what is imported in
OBI/IAO, such as specific countries? So I would suspect that merging the
IAO PR would have no effect
Or perhaps it is the case that the database is relying on the injected
axiom - e.g. I can foresee a scenario where losing the injected axiom
would cause the GAZ tree to float to the root which may have consequences
for your system which relies on things being placed in some kind of BFO/COB
like structure? I am guessing, but I am very interested in these kinds of
database-ontology dependencies, so that we can continue to develop best
practice guidelines for OBO that lead to robust information systems.
…On Thu, Jul 15, 2021 at 7:49 AM bpeters42 ***@***.***> wrote:
Regarding usage of GAZ 'geopgraphical entity' in OBI, I was not referring
to other ontologies, but applications that utilize OBI. From the call we
know that they include the IEDB as well as independent systems run by James
and Chris S.
On Tue, Jul 13, 2021 at 10:10 AM Chris Mungall ***@***.***>
wrote:
> I don't think it's true that there is an unknown number of systems using
> GAZ 'geopgraphical entity' in OBI. We can see the usages clearly. In fact
> there is a single usage, in IAO
>
> "postal address subClassOf is-about some geographic location"
>
>
>
http://www.ontobee.org/ontology/IAO?iri=http://purl.obolibrary.org/obo/GAZ_00000448
>
> I think we need to be better at balancing the need for such rococo axioms
> against the fact that we have had a major incoherency in OBO for over a
> month. This is akin to a major software library release software that
> doesn't compile for a month.
>
> There is a very very simple solution here - simply remove the axiom from
> IAO and remove the GAZ import (this was the only GAZ class used)
>
> information-artifact-ontology/IAO#248
> <information-artifact-ontology/IAO#248>
>
> If people truly find the axiom valuable then it can be re-added using
ENVO
> or GEO later, but I doubt anyone has ever found this axiom useful
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1375 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ADJX2IVBIMRC6CCAWEDXYMTTXRXQ7ANCNFSM46YMPV6A
>
> .
>
--
Bjoern Peters
Professor
La Jolla Institute for Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1375 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAMMOOPDNCTV7G7PXOGADDTX3YOTANCNFSM46YMPV6A>
.
|
|
so it seems that in addition to IAO referencing GAZ location for 'postal address', there is also an OBI axiom that references it: country_name is-about some geographic location:
I'd recommend removing this is as well, then you remove an entire brittle dependency. You can add back a more precise axiom later using GEO or ENVO, but I suspect this axiom is also not useful |
I am merging FOODON and OBI, and I get an incoherent ontology:
OBI says GAZ:geographic_location is a site (ie immaterial):
http://www.ontobee.org/ontology/OBI?iri=http://purl.obolibrary.org/obo/GAZ_00000448
FOODON says GAZ:geographic_location is a material entity:
http://www.ontobee.org/ontology/FOODON?iri=http://purl.obolibrary.org/obo/GAZ_00000448
Clearly the source issue here is that GAZ is under-axiomatized, thus people feel the need to inject their own axioms. You can blame me for that. (We need a plan for this, but I suggest we don't discuss that here, let's use https://github.com/EnvironmentOntology/gaz/issues or the OBO tracker)
However, the current situation of anyone getting to inject whatever axioms they want is not tenable if OBO is to be coherent. A global solution is being discussed here: OBOFoundry/OBOFoundry.github.io#1443
But for now I think we have to resolve these one at a time.
My proposal is that OBI changes its injection to be consistent with FOODON. I also suggest we use this as an opportunity to adopt @dosumis' proposal here and tag this axiom.
The alternative is we ask @ddooley to change the FOODON injection to be consistent with OBI. However, I don't think that is a good suggestion, it opens us up to further cryptic incoherencies. I recommend that "site" is avoided as a class in general (OBOFoundry/OBOFoundry.github.io#1539).
The text was updated successfully, but these errors were encountered: