Define if and when it is OK to inject axioms into an external ontology

[cmungall]

Previously we have had issues when one ontology injected axioms into another

For example, previously OBI injected an axiom GO:molecular_function subClassOf BFO:function

This did not contravene any stated OBO rule or principle, so there was formally nothing wrong with it. But intuitively this kind of thing is undesirable, as it should be up to the external ontology to state their axioms. If other ontologies state axioms on another ontology's behalf we will have issues of conflicts (as what happened here).

Of course, OBI later lifted this axiom, but this serves as a good example.

We may choose to formulate a rule: an ontology O MUST not create any axioms about a class C in any non-O ontology.

Note that here, there is a precise definition of about in the OWLAPI. Intuitively and roughly it is where C is on the LHS of the axiom.

Here by create we mean to make an axiom de-novo. Of course, O may include axioms from an external ontology derived via robot extract, and merge these in to O (we have strategies for avoiding injection of stale axioms with base modules).

This is a good start, but is not sufficient.

First, it would forbid any disjointness axioms crossing ontologies, as these are by definition about classes in two ontologies. I think we want to have a way of allowing this, but to encourage both ontologies to 'sign off' on this.

Similarly, it would forbid equivalence axioms between two named classes in two ontologies. We generally wouldn't expect this in OBO as we strive for orthogonality, but there may be temporary situations (e.g. GO:cell = CL:cell, now resolved by GO obsoleting their cell)

There is also a more nuanced situation, where we have injected entailed axioms

E.g. if I say MyOnt:drug synthesis = MyOnt:synthesis and RO:has-output some CHEBI:drug, and RO:has-output has a range restriction of material entity, I am injecting via entailment an axioms CHEBI:drug subClassOf mat-entity, which clearly conflicts with CHEBI's role hierarchy

similarly, when PRO (cc @nataled) has axioms that reference the identifiers.org URI for an HGNC gene (e.g. has-gene-template), then we are entailing:

• that URI has an interpretation that is an OWL class
• the superclass of that class conforms to the range restriction (in this case PRO doesn't have a range constraint- yet)

obviously this could be problematic later, a different ontology may make different ontological commitments of HGNC that conflict

This problem is compounded by the fact HGNC is not providing any ontological commitments, we are translating a database to OWL. I touch on this in my slides:

https://docs.google.com/presentation/d/1zKKCfFdbWA5JiNDdRQuvmvDpcjvwvMXEGgmzgnSYL2w/edit#slide=id.p

As a start, I propose a principle for an ontology O and any class C for a non-O ontology:

• O MUST NOT make any direct axioms about C
• O MAY create axioms that reference C, provided:
  • any entailed axioms about C are in accord with both axioms entailed within C's containing ontology AND with the stated intentions of that ontology
• maintainers of O MAY make separate bridge ontologies that contravene these (e.g. NC-NC-equivalence axioms) provided the bridge axioms are not merged or imported in O, and metadata clearly indicates that the bridge ontology may inject asserted or entailed axioms that do not necessarily correspond to the intentions of the external ontology

The "stated intentions" part could be documented according to some standard template. Where this involves an ontology converted from a database to OWL, we will need guidelines on how the OWL-naive upstream will understand and state conformance with ontological commitments

[matentzn]

I think this is really great. I wholeheartedly endorse this! You mainly talk about logical axioms here, which is the important bit; if we can get the OBO committee to agree on this, then we can open a new issue, one step further, that actually encourages annotations to go where they belong as well. For example, we now have quite a few ontologies defining synonyms, definitions etc for term from non-O - it would be very good if these could end up in non-O as well. But yes, separate issue, this here is much more important.

I guess what the big question is how this relates to our base program.

maintainers of O MAY make separate bridge ontologies that contravene these (e.g. NC-NC-equivalence axioms) provided the bridge axioms are not merged or imported in O

One could argue that these "glue" axioms are there because the ontology developer wants their class graph to look a certain way for their users - which is undesirable, but I would say, minus logic, minus bfo, fair enough. So I can see how my.owl (the main release artefact) could be considered a sort of massaged version of the ontology made for "the user".

What is however truly important, and I think there can't be any reasonable way to contradict this, is that the base ontologies adhere to this proposal absolutely stringently. It is kind of messy on how to deal with this technically. Maybe an axiom annotation excludeFromBase.

[dosumis]

Strongly agree with the aims here.

+100 to annotation at the axiom level for axioms that contravene principle 1 (O MUST NOT make any direct axioms about C). It is inevitable that we have some of these (I've been guilt of adding a few; shared agreement is hard & sometimes we need to build before we've achieved it). As well as allowing these axioms to be weeded out from base so they don't pollute import chains. they could be used to generate reports that can be the basis for discussion with developers of the ontologies being imported with the aim of having these axioms live in source ontologies.

I also agree that tagging of local axioms for at least some types of APs is important.

Still a bit confused about how this applies to non-ontology sources. e.g. gene identifiers. Where we have to use them, is it not useful to have some reasonable level of classification in SO?

[matentzn]

Should be discusssed at the call today

[jamesaoverton]

This is the OBI issue that @cmungall refers to at the top: https://github.com/obi-ontology/obi/issues/963

[cmungall]

Brief notes from call today:

• we should include something to the effect that O can inject axioms about C so long as they are consistent with cob-to-external. We want to avoid O unilaterally making decisions about where C belongs. COB provides the central forum/decision recording place

[cmungall]

I propose we add a dashboard check

For any given ontology O, if O references or reuses any part of O2 (i.e there is any logical axiom whose signature contains a class from O2), then we do a test:

1. robot merge O and O2 into O3, along with cob and cob-to-external
2. run robot reason over O3 to determine if new incoherencies are introduced (omit this step if O2 is not coherent, though this should be flagged some other way)
3. run robot report over O3 to determine if other non-logical problems are introduced

Step 2 will detect if O injects logical axioms inconsistent with O2's intent

Step 3 will detect cases such as O over-riding labels or text definitions or any maxCardinality=1 annotation properties

Note that steps 2 or 3 will flag cases where O's imports are out of date w.r.t O2 (we deliberately use whole ontologies not basefiles). I think it's useful to know when one's imports are out of sync, but I think we need a way of separating this scenario from "intentional injection".

So I would propose that O can optionally include as metadata versionIRIs of all referenced ontologies, and these are used in step 1. If this is not indicated, then the latest version is always used (and if O get's lots of red marks from using stale ontologies and not providing indication, it is on their head)

[matentzn]

I think this is a great idea in general, but it will seriously increase the overall runtime of the dashboard.. especially since the some if the most frequently reused ontologies are also the largest (pro, go, ncbitaxon, obi etc). Also it is something really hard to distinguish if a reuse was actually intentional (think of a range constraint one an RO relation pulled in). Is there any smart way we could do this in a cheaper way?

[mellybelly]

Perhaps slightly orthogonal, but can we explore examples related to NCIt - we have the obo version and the NCIt-plus version where we are trying to create interoperability (e.g. obo-compliant axioms) with a well renowned resource rather than reinventing. This happens regularly enough that we should have a strategy for handling cases like these. Or rather, it should happen more than it does at present so that OBO doesn't reinvent authoritative sources.

[alanruttenberg]

My sense is that this isn't going to be a good idea as there will enough exceptions to render the discrimination between the ok cases and the not ok cases impractical. I'll think about this some more and try to write back with more examples, but I can't do so for at least a few days.

I think the determination of whether an axiom is ok or not should be based on the correctness of the axiom, not the syntax.

One case: You create an ontology which has a class (A) that is truly, by examination of the definitions, a superclass of a class from another ontology (B), so you properly assert A subclassof B. A subset of these cases are one in which a defined class is a union of some other classes. In that case you can explicitly assert the disjuncts subclass of the union, and in any case those axioms will be inferred.

Another case: You are working with an under-axiomatized ontology (O) with developers not receptive to adding axioms. So you add, for instance, domain and range of some properties that are correct given the definitions of the properties. If that happens to cause some trouble with O then it is O that has a problem.

@Chris Mungall @.***> What's the OWLAPI definition of "about"?

On Sun, Jun 13, 2021 at 9:08 AM Melissa Haendel @.***> wrote:

Perhaps slightly orthogonal, but can we explore examples related to NCIt - we have the obo version and the NCIt-plus version where we are trying to create interoperability (e.g. obo-compliant axioms) with a well renowned resource rather than reinventing. This happens regularly enough that we should have a strategy for handling cases like these. Or rather, it should happen more than it does at present so that OBO doesn't reinvent authoritative sources.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443#issuecomment-860226023, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDTJJLKX726SAVLPM7DTSTCVZANCNFSM4X3AECRA .

[dosumis]

How about:

When importing a class C from an external ontology O, it can be tempting to inject direct logical or annotation axioms about C that restrict or otherwise change the logical definition of C. Before attempting this, you are heavily encouraged to contact the editors of O to request the desired change in the source ontology. Where shared agreement can not be reached in a timely manner and the desired axioms are required for some urgent use-case, you may only inject such axioms if they are annotated using the following standard:

<AP for injected axiom tagging>: True

Annotation will allow these axioms to be removed from the ‘base’ product used to generate imports to other ontologies, so preventing axioms not approved by the editors of C from polluting import chains.

A related issue: You may inject entailed axioms into an ontology (although doing may not be wise in anything other than derived release products). Such axioms should be annotated as follows:

[cmungall]

I think @alanruttenberg's concerns are valid, especially about under-axiomatized ontologies. In fact I have developed an entire ontology (CHIRO) that does nothing except inject axioms into CHEBI. But I am hopefully clear that this is a bandaid and that CHIRO should not exist.

I like @dosumis proposal, I think it addresses Alan's concerns, and furthermore it provides an easy way for us in OBO to survey the landscape and ask: what axioms are being intentionally injected, and where? what ontologies frequently get injected into? what are the reasons? is the target ontology unwilling to accept axiom suggestions? or are they under-resourced? how can we help?

[alanruttenberg]

Dave's wording is an improvement, but I'm not convinced. If we think a language tag is going to confuse users, how is "injected axioms" or "entailed axiom" going to play?

I think the wording is still too strong or not specific enough. The "tempted" language(and "pollute") imposes a value judgement above and beyond the goal of not changing the meaning of the term. I'm not sure mentioning restrictions is useful as it is implied when we say "don't change the meaning". We want to convey that any axioms should be correct. We don't want to suggest that correct axioms will ever be removed. The language about annotations is confusing as annotations aren't logical assertions and so can't change anything, at least formally. Not all uses are appropriate to be put in the source ontology, in particular the defined classes or in cases in which the source ontology would need to import something from the derivative.

I'd like to see the language be more narrowly scoped, to not make unqualified statements, for instance that such axioms should always be added to the source ontology, or that all such axioms are candidates for removal. It would be better to present this in a neutral tone. More emphasis on correctness - perhaps lead with what the goal is, which is to ensure that the intended meaning of the imported term is stable. Include a suggestion that they can also ask the developers if the suggested axioms are correct. It's less intrusive than asking them to modify their ontology and possibly more likely to be responded to.

A case that might be distinguished is where an axiom only uses terms that are already accessible to the source ontology via imports, or which are in a commonly imported ontology. In that case it is clearer that the appropriate place for the axiom is the source ontology.

On Tue, Jun 15, 2021 at 10:58 AM Chris Mungall @.***> wrote:

I think @alanruttenberg https://github.com/alanruttenberg's concerns are valid, especially about under-axiomatized ontologies. In fact I have developed an entire ontology (CHIRO) that does nothing except inject axioms into CHEBI. But I am hopefully clear that this is a bandaid and that CHIRO should not exist.

I like @dosumis https://github.com/dosumis proposal, I think it addresses Alan's concerns, and furthermore it provides an easy way for us in OBO to survey the landscape and ask: what axioms are being intentionally injected, and where? what ontologies frequently get injected into? what are the reasons? is the target ontology unwilling to accept axiom suggestions? or are they under-resourced? how can we help?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443#issuecomment-861668906, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDX4R34BDVIZP22ZTBTTS6BCLANCNFSM4X3AECRA .

[alanruttenberg]

Also, why do the axioms need to be annotated manually. Can't we tell syntactically which axioms have the potential to change the meaning by looking at which terms are used and the kind of the axiom?

On Tue, Jun 15, 2021 at 11:19 AM Alan Ruttenberg @.***> wrote:

Dave's wording is an improvement, but I'm not convinced. If we think a language tag is going to confuse users, how is "injected axioms" or "entailed axiom" going to play?

I think the wording is still too strong or not specific enough. The "tempted" language(and "pollute") imposes a value judgement above and beyond the goal of not changing the meaning of the term. I'm not sure mentioning restrictions is useful as it is implied when we say "don't change the meaning". We want to convey that any axioms should be correct. We don't want to suggest that correct axioms will ever be removed. The language about annotations is confusing as annotations aren't logical assertions and so can't change anything, at least formally. Not all uses are appropriate to be put in the source ontology, in particular the defined classes or in cases in which the source ontology would need to import something from the derivative.

I'd like to see the language be more narrowly scoped, to not make unqualified statements, for instance that such axioms should always be added to the source ontology, or that all such axioms are candidates for removal. It would be better to present this in a neutral tone. More emphasis on correctness - perhaps lead with what the goal is, which is to ensure that the intended meaning of the imported term is stable. Include a suggestion that they can also ask the developers if the suggested axioms are correct. It's less intrusive than asking them to modify their ontology and possibly more likely to be responded to.

A case that might be distinguished is where an axiom only uses terms that are already accessible to the source ontology via imports, or which are in a commonly imported ontology. In that case it is clearer that the appropriate place for the axiom is the source ontology.

On Tue, Jun 15, 2021 at 10:58 AM Chris Mungall @.***> wrote:

I think @alanruttenberg https://github.com/alanruttenberg's concerns are valid, especially about under-axiomatized ontologies. In fact I have developed an entire ontology (CHIRO) that does nothing except inject axioms into CHEBI. But I am hopefully clear that this is a bandaid and that CHIRO should not exist.

I like @dosumis https://github.com/dosumis proposal, I think it addresses Alan's concerns, and furthermore it provides an easy way for us in OBO to survey the landscape and ask: what axioms are being intentionally injected, and where? what ontologies frequently get injected into? what are the reasons? is the target ontology unwilling to accept axiom suggestions? or are they under-resourced? how can we help?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443#issuecomment-861668906, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDX4R34BDVIZP22ZTBTTS6BCLANCNFSM4X3AECRA .

[matentzn]

I don't understand the problem with @cmungall suggestions 1,2,3 - If I understand it correctly I support it 100%, as well as what David suggests. The essence is that we need some way to prevent downstream ontologies to change the meaning of a term in any way - @alanruttenberg your notion of "correctness" would be of course a desirable guiding principle but is a lot harder to test and maintain than simply flagging up axioms with a tag. Also, you put IMO too much trust in the abilities of people to "correctly" infer the intended semantics from the textual definitions. Right now all our pipelines rely on stripping out all disjointness axioms so we can reason with even 2 ontologies together - this needs to stop. So we need an easy way to remove such axioms if they are needed for classification or something. Or do you have a concrete idea on how else to solve this? I just don't see another, but happy to change my mind!

I do however agree that none of this needs to happen manually - its easy to build the annotation process into robot (I would do it).

[cmungall]

Just an addendum to point out another hidden problem others may not be aware of

injected axioms are currently stripped in base modules. This is good if I want to avoid injected axioms and the attendant incoherencies. However, it is bad in that it masks the problem, and it makes it harder to automatically detect if multi-ontology incoherencies are arising from version superpositions or are issues with asserted axioms.

An example is here, combining foodon and obi, both of which inject. This is masked by using the obi base but this just masks the problem:

https://github.com/obi-ontology/obi/issues/1375

[cmungall]

Note that I am myself guilty of horrendous injections which virally propagate. This was a really hard one to debug:

https://github.com/EnvironmentOntology/envo/issues/1187

it is quite hilariously recursive and ironic, an (unintentional) injection on the editor preferred label of editor preferred label, rendering something that is the opposite of an editor preferred label.

[matentzn]

Action items:

• [ ] Break this ticket down into small decisions and call a vote

[wdduncan]

Not sure I follow all the proposals and counter-proposals here. So, let's consider two concrete cases:

1. UBERON contains both processual entity and process. As far I can tell, the extension of these class is the same. So, if an application imports UBERON and another ontology that only has process, the developer should create a "bridging" class named something like process or processual entity?

2. A chebi:role seems like a kind of bfo:function to me. But, rather than asserting that in an application ontology, the developer should make a class like function or chebi role?

[cmungall]

@wdduncan:

If you create a grouping class using UnionOf then you are still injecting an axiom that is about the uberon/chebi class. See the section "There is also a more nuanced situation, where we have injected entailed axioms" in my original comment.

The spirit and implementation of my proposal is intended to be very simple. Don't inject axioms about external classes. Instead work with the external ontology and have them incorporate the axiom you need. If this is not achievable, then inject axioms in a single consensus place, i.e. COB.

In the uberon case, someone should just make an uberon issue asking for UBERON:0000000 processual entity to be obsoleted, and for Uberon to provide the subClassOf axiom from life stages to COB/BFO. There is no need for injection or awkward grouping classes unless the Uberon developers reject this proposal.

The chebi case is more complicated because of both the chebi development paradigm (the OWL is made from the CHEBI relational database using a process the CHEBI developers control, and they have lacked funding to fix this) and because of the confusing nature of the CHEBI roles (despite their name, they are not clearly roles). See my comments here: https://github.com/OBOFoundry/COB/pull/173#issuecomment-917789017. In this particular case, because CHEBI could not themselves provide the bridging axioms, we do this in the consensus place, COB. See:

• https://github.com/OBOFoundry/COB/issues/169

[wdduncan]

@cmungall Yes. You are right. If I define the class:

myont:foo equivalent-to bfo:material-entity or bfo:role

A reasoner will infer that bfo:material-entity and bfo:role are subclasses of myont:foo. I agree that this is not desirable if my ontology is going to be part OBO Library. I was thinking about the case in which an ontology developer is working on a so-called "application ontology" that is not necessarily intended to be included in the Foundry.

The UBERON and ChEBI classes I mentioned were for demonstration purposes. You understand better than me as to why these ontologies are constructed in these ways.

Instead work with the external ontology and have them incorporate the axiom you need.

This is desirable if the external ontology is active and open to taking such requests. However, time constraints may make this impractical in cases in which the ontology is not being actively maintained.

If this is not achievable, then inject axioms in a single consensus place, i.e. COB.

What if COB is not open to such a proposal or the developer prefers to work using BFO as the upper-level and not use COB?

[cmungall]

There are a lot of theoretic what-ifs here. My assumption here is that aligning to COB is desirable for OBO. If you don't want to do that, no one is forcing you to do that, and if you want to do unusual things in an application ontology, that is fine too. But if you want your ontology to be interoperable and reused/imported by others in an interoperable framework we need some level of consensus on what can and can't be done. The current status quo of free for all unilateral injections is causing massive issues, expensive blockages of ontology releases, etc. These issues aren't being caused by some random application ontology, they are caused by injection in some important OBO ontology that others are importing.

Thankfully it seems we are in agreement that this current is not desirable, and I think the guidelines I propose in my comment above provide a practical alternative to unilateral injection.

On Fri, Jan 7, 2022 at 9:54 AM Bill Duncan @.***> wrote:

@cmungall https://github.com/cmungall Yes. You are right. If I define the class:

myont:foo equivalent-to bfo:material-entity or bfo:role

A reasoner will infer that bfo:material-entity and bfo:role are subclasses of myont:foo. I agree that this is not desirable if my ontology is going to be part OBO Library. I was thinking about the case in which an ontology developer is working on a so-called "application ontology" that is not necessarily intended to be included in the Foundry.

The UBERON and ChEBI classes I mentioned were for demonstration purposes. You understand better than me as to why these ontologies are constructed in these ways.

Instead work with the external ontology and have them incorporate the axiom you need.

This is desirable if the external ontology is active and open to taking such requests. However, time constraints may make this impractical in cases in which the ontology is not being actively maintained.

If this is not achievable, then inject axioms in a single consensus place, i.e. COB.

What if COB is not open to such a proposal or the developer prefers to work using BFO as the upper-level and not use COB?

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443#issuecomment-1007609647, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOL3WJR6SDXUPUUG5FTUU4SFTANCNFSM4X3AECRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[wdduncan]

@cmungall Sorry. Not trying to "what-if" you to death. Just trying to consider the various ways a developer may want to use OBO ontologies, and how this change may impact such ways.

Will this change become one of the principles? I think it should.

[alanruttenberg]

I'll again raise objection to this formulation. A more permissive approach would be to request, that if an Ontology does add axioms that it also provide an artifact which does not have them. The dashboard and information pages can then advertise the presence of the axioms and the URLs of the variant. It would be up to the Ontology developers to decide which Ontology lives at the primary URL. As more infrastructure is built, at some point a listing of incompatibilities can be automatically generated.

It is a fact that many ontologies are underaxiomatized and there can be a variety of reasons. As Bill points out, not all developers will be responsive to requests to add axioms, for reasons that are sometimes legitimate design choices. However, those design choices may not work for other efforts. In fact, I can easily imagine an Ontology which advertised it as a feature that they have axiomatized terms from other ontologies, as the additional axioms may provide wider value.

A policy which outlaws this seems inconsistent with prior attitudes towards inclusiveness and also second guesses what developers are doing in a way I think inappropriate, particularly as we are still a young discipline. In other cases we typically offer sufficient information for developers to make informed choices. That, I believe, should be the goal of this effort.

[alanruttenberg]

As a thought experiment consider the other directions. Would we want to insist that developers mireoting terms not drop axioms within a module? This also can have negative consequences such as having an ontology that should be inconsistent according to the original ontology be consistent in the ontology that uses it.

[cmungall]

I think we are on the same page. That's the idea with cob-to-external. We attempt make these decisions consensus rather than unilateral injection

On Sat, Jan 8, 2022 at 10:18 AM Alan Ruttenberg @.***> wrote:

I'll again raise objection to this formulation. A more permissive approach would be to request, that if an Ontology does add axioms that it also provide an artifact which does not have them. The dashboard and information pages can then advertise the presence of the axioms and the URLs of the variant. It would be up to the Ontology developers to decide which Ontology lives at the primary URL. As more infrastructure is built, at some point a listing of incompatibilities can be automatically generated.

It is a fact that many ontologies are underaxiomatized and there can be a variety of reasons. As Bill points out, not all developers will be responsive to requests to add axioms, for reasons that are sometimes legitimate design choices. However, those design choices may not work for other efforts. In fact, I can easily imagine an Ontology which advertised it as a feature that they have axiomatized terms from other ontologies, as the additional axioms may provide wider value.

A policy which outlaws this seems inconsistent with prior attitudes towards inclusiveness and also second guesses what developers are doing in a way I think inappropriate, particularly as we are still a young discipline. In other cases we typically offer sufficient information for developers to make informed choices. That, I believe, should be the goal of this effort.

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443#issuecomment-1008089858, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOKR6WD2CMCGOZT3GVTUVB5YJANCNFSM4X3AECRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[alanruttenberg]

Not sure how we're on the same page. I am advocating for being able to unilaterally add axioms at the discretion of the ontology developers, with appropriate information provided on, e.g. dashboard or project page. Of course there should be an attempt at consensus, but not a requirement, and a request that the ontology offers a version without the added axioms, but also not a requirement. Legislating this crosses a line I don't think should be crossed.

There isn't a requirement for a global consensus on every term an ontology adds and I don't think there should be a requirement for global consensus for axioms. The fact is we already have logic modifying choices such as the choice of omitting axioms. As far as the model theoretic semantics, omitting an axiom (thus allowing models that wouldn't be allowed if the axiom was present) can be just as bad as adding one (disallowing models that would be allowed otherwise).

Alan

[cmungall]

Thanks for confirming - yes we are in disagreement.

All I can say is that unilateral injection from ontologies that are used in imports has been incredibly costly so far

On Wed, Jan 12, 2022 at 9:29 PM Alan Ruttenberg @.***> wrote:

Not sure how we're on the same page. I am advocating for being able to unilaterally add axioms at the discretion of the ontology developers, with appropriate information provided on, e.g. dashboard or project page. Of course there should be an attempt at consensus, but not a requirement, and a request that the ontology offers a version without the added axioms, but also not a requirement. Legislating this crosses a line I don't think should be crossed.

There isn't a requirement for a global consensus on every term an ontology adds and I don't think there should be a requirement for global consensus for axioms. The fact is we already have logic modifying choices such as the choice of omitting axioms. As far as the model theoretic semantics, omitting an axiom (thus allowing models that wouldn't be allowed if the axiom was present) can be just as bad as adding one (disallowing models that would be allowed otherwise).

Alan

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443#issuecomment-1011809492, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOI45OF6T7DEQTWPOWLUVZPLJANCNFSM4X3AECRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[dosumis]

A practical suggestion: We have a standard annotation property axiom for tagging unilaterally injected axioms. This can be used for filtering out these axioms. Ideally this filtering will take place as part of an ontology release but it could also become a standard part of our import pipelines.

We should strongly encourage use of this tagging system on the simple principle that it lowers the cost of re-use. This cost is significant right now - and can be a terrible drain on the time of developers. (This is a significant issue in my group right now).

Where we come across examples that are untagged that cause problems, this can be solved by tagging if there is no agreement on a consensus solution.

Note - this issue is much broader than the issue of consensus upper ontology commitments. In the Foundry we have a growing set of interdependent ontologies, each importing subsets of each other's axioms. It is not unusual for ontology A to import from ontologies X and Y and for ontology X to also import from Y. In choosing to import from X and Y, developers of A have made a decision to trust X and Y wrt their own content. They have not made a decision to trust X's unilateral additions to Y.

Action items:

1. Add a standard AP to RO for use in tagging. Annotation on this AP should include guidance around usage. I don't think adding this needs consensus here - see https://github.com/oborel/obo-relations/issues/550
2. Can we agree on OBO Foundry guidance that says tagging and providing release artefacts that lack unilateral injection is strongly encouraged?

[cmungall]

very practical way forward, I agree with all

Minor: you suggest RO for the AP, I think OMO is a better choice long term, but unfortunately OMO is a bit blocked up just now

On Fri, Jan 14, 2022 at 1:17 AM David Osumi-Sutherland < @.***> wrote:

A practical suggestion: We have a standard annotation property axiom for tagging unilaterally injected axioms. This can be used for filtering out these axioms. Ideally this filtering will take place as part of an ontology release but it could also become a standard part of our import pipelines.

We should strongly encourage use of this tagging system on the simple principle that it lowers the cost of re-use. This cost is significant right now - and can be a terrible drain on the time of developers. (This is a significant issue in my group right now).

Where we come across examples that are untagged that cause problems, this can be solved by tagging if there is no agreement on a consensus solution.

Note - this issue is much broader than the issue of consensus upper ontology commitments. In the Foundry we have a growing set of interdependent ontologies, each importing subsets of each other's axioms. It is not unusual for ontology A to import from ontologies X and Y and for ontology X to also import from Y. In choosing to import from X and Y, developers of A have made a decision to trust X and Y wrt their own content. They have not made a decision to trust X's unilateral additions to Y.

Action items:

1. Add a standard AP to RO for use in tagging. Annotation on this AP should include guidance around usage. I don't think adding this needs consensus here.
2. Can we agree on OBO Foundry guidance that says tagging and providing release artefacts that lack unilateral injection is strongly encouraged?

— Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443#issuecomment-1012942543, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOOZRKMMMBGZQOVHR4TUV7SZHANCNFSM4X3AECRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[alanruttenberg]

I'd be interested in hearing the details of how they have caused trouble.

I'm all for tagging. I just think the restriction is too strong an action. I think some thought should be given to tool aid for it, as I'm not sure it will be done consistently otherwise.

Regarding the trust issue, there can be a variety of choices. Both X and Y together might be trusted, for instance. But offering choices and information will allow there to be more experimentation, which I would like to see, particularly because my impression is that under-axiomatization is a problem.

As far as pipeline goes, I'd rather see input filters than output files, since if the latter was default it would make it much less likely constructive efforts to axiomatize would surface, whereas having an import pipeline is something that some of the larger ontology efforts might need, but lesser efforts wouldn't necessarily do my default.

I also think that it is far from clear how one distinguishes "unilateral injection" from constructive re-use. I think @cmungall mentioned he thought "subject" was well defined, but I don't see that. Perhaps exactly what is meant might be more carefully expressed.