Allow adding new terms (for import) by declaration in -edit.owl

[dosumis]

It used to be standard to add new terms from external ontologies by adding a new root term to Protege, pasting in the IRI of the new term. This => declaration in X-edit.owl - meaning the term can be used in axioms straight away (referred to by short_form) and will automatically be used in the update import seed.

This no longer seems to a viable option, because a bare declaration in the -edit file is sufficient to => a fatal build error due to lack of a label. This is even true when imports have been updated, with the only clear remedy being to delete the declaration by hand:

https://github.com/obophenotype/cell-ontology/pull/735#issuecomment-695208059

It would be good if we could get this option back. At a minimum, the check should pass once imports have been updated.

[matentzn]

This problem has been bugging me for years.. unfortunately its not that simple. There are three basic paths we can take:

1. We never run tests on the edit file, only ever on the full release (lots of noise (errors) from external ontologies)
2. We restrict these tests to terms in the namespace (obo:CL_) of the ontology. Advantage: we can run on edit (less noise). Disadvantage: this won't extend to robot report, which has its own routine (so robot report no matter what has to be run on the release file, which has a lot of noise)
3. We have travis actually removing declarations from cl-edit before running. Thats easy to implement.
4. we create a special QC ontology we derive from the edit file that contains only those things we actually run QC over. My preferred option (we can strip out declarations etc from that).

Otherwise I cant see how we can solve this; unless you have any other idea?

[dosumis]

We restrict these tests to terms in the namespace (obo:CL_) of the ontology

I think this sounds best. Could just add a FILTER clause the queries.

so robot report no matter what has to be run on the release file, which has a lot of noise)

Why?

[matentzn]

I think this sounds best. Could just add a FILTER clause the query.

Yep, we do that for quite a few queries already.

so robot report no matter what has to be run on the release file, which has a lot of noise); Why?

ROBOT report will never understand namespace restrictions; so you need to decide betwee these:

1. You run ROBOT report on edit file. This causes a lot of errors like the one you want to avoid as part of this ticket (GO class with no label).
2. You run ROBOT report on release file. This causes a lot of warnings (noise) because of violations in the imports which are now merged in.

[dosumis]

Robot report looks way too inflexible. I should have been paying more attention. It feels like a step back. Don't we have pretty much all the reports/checks in SPARQL for ODK anyway?

Note: the label report fails even when imports have been updated, suggesting it is not using imports. I think it would be OK to have build fail when the term is first added, as long as it can be fixed by a pull request reviewer updating imports. With that workflow, all tests that are required for imports to run must be turned on, so they a caught upstream of work on a completely separate pull request.

[matentzn]

You can configure the severity levels in ROBOT, but yes, getting a NO error situation with ROBOT report is difficult when importing ontologies. Many of the SPARQL checks are in ODK as well; not all. There are some clear advantages to ROBOT report though, most importantly that it allows us to easily deploy an OBO profile of checks for released ontologies that no one can mess with. I guess the right way is to work with both!