Make repair command more flexible #1194
Conversation
This commit makes it possible to selectively invoke repair functions rather than a all or nothing approach.
| --merge-axiom-annotations true \ | ||
| --output results/uberon_axiom_annotation_merged.owl | ||
|
|
||
| By default, annotation axioms are not migrated to replacement classes. |
There was a problem hiding this comment.
@balhoff what does this mean? I dont get this part of the repair method at all. This sentence also makes no sense to me.
There was a problem hiding this comment.
If you use that option, you can automatically move xrefs on an obsolete class to its replacement.
There was a problem hiding this comment.
I have updated the documentation to make the command a bit clearer, but this particular part I still dont get it.
Lets say we have
A sub R some B
And B is deprecated.
When I "repair" my ontology I would assume this happens:
A sub R some X
where X is a replacement of B.
How does this relate to "fixing" anything about B? This seems like a totally different command to me (robot deprecate or similar).
There was a problem hiding this comment.
I guess it's "repairing" the ontology itself.
Resolves #1099, and makes repair command more flexible.
docs/have been added/updatedmvn verifysays all tests passmvn sitesays all JavaDocs correctCHANGELOG.mdhas been updatedThis PR makes it possible to selectively invoke repair functions rather than having all or nothing approach (which still works by default).
WARNING: This PR contains a breaking change:
would have previously ran the entire repair pipeline (
RepairOperation.repair()). Now, it will only run the merge axiom annotations pipeline.