No equivalent class axioms are allowed? Really?

[marijane]

the CRO has a PR: https://github.com/data2health/contributor-role-ontology/pull/18

The travis build is failing: https://travis-ci.org/data2health/contributor-role-ontology/builds/535529728

it passed before: https://travis-ci.org/data2health/contributor-role-ontology/builds/518881250

why is it failing now? the passing build had the equivalent class axiom too.

[cmungall]

The error should say "no equivalence axioms between named classes"

but you would likely find this too restricted also (assumption is working in OBO mutually orthogonal space, inference of equivalence usually unintentional)

This is controlled by --exclude-duplicate-axioms / -e

Change -e none to -e asserted-only

 -e,--equivalent-classes-allowed <arg>             if 'none', any
                                                   equivalent class will
                                                   cause an error, if
                                                   'all', all equivalent
                                                   classes are allowed,
                                                   and if 'asserted-only',
                                                   inferred equivalent
                                                   classes will cause an
                                                   error.

We need to update this http://robot.obolibrary.org/reason

And we should have a top level config for this in ODK

[mellybelly]

I think that these terms should probably not be asserted to be equivalent in this way - they are not exactly equivalent really; perhaps we should use an Xref strategy and oboInOwl:treat-xrefs-as-equivalent assertions in the file header? @cmungall would this be preferable? Really we just want to be able to tell people that they can swap the CREDIT terms 1:1 for these CRO terms - the CREDIT terms never had any semantics or identifiers, we just want to make it easy for people to make the switch.

[cmungall]

There are pros and cons, if you think they are truly equivalent then it can be advantageous to state it, you will get power in consistency checking. I would add a unit test that runs robot reason over the combination of the two with the equivalence axioms (getting new inferred equivalencies will be a sign of something unintentional here). But even if you do this you can use skos, xref, seeAlso etc in the release version.

[matentzn]

This is now configurable in ODK using the odk yaml option allow_equivalents: assert-only or allow_equivalents: none or allow_equivalents: all (default)