Customise OBO products #2860
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -175,10 +175,10 @@ test: $(REPORTDIR)/taxon-constraint-check.txt | |
| # ---------------------------------------- | ||
|
|
||
| .PHONY: obocheck | ||
| obocheck: $(SRC) | all_robot_plugins | ||
| $(ROBOT) merge -i $(SRC) \ | ||
| remove --base-iri $(URIBASE)/CL_ --axioms external --trim false \ | ||
| uberon:obo-export --merge-comments --obo-output $(TMPDIR)/cl-check.obo | ||
| fastobo-validator $(TMPDIR)/cl-check.obo | ||
|
|
||
| test_obsolete: $(ONT).obo | ||
|
|
@@ -258,6 +258,36 @@ pattern_docs: $(ALL_PATTERN_FILES) | |
| -o ../../docs/patterns/ | ||
|
|
||
|
|
||
| # ---------------------------------------- | ||
| # CUSTOM OBO OUTPUT | ||
| # ---------------------------------------- | ||
| OBO_EXPORT_OPTIONS = --merge-comments --strip-gci-axioms --strip-owl-axioms | ||
|
|
||
| $(SUBSETDIR)/%.obo: $(SUBSETDIR)/%.owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
|
||
| $(ONT).obo: $(ONT).owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
There was a problem hiding this comment. My only concerns with this approach is that we artificially break isomorphicity between owl and obo products (on content supported by OBO format). I am ok with this suggestion, but I would ask @cmungall for a review, and consider the alternative, which is that There was a problem hiding this comment. Makes me a bit queasy too, but round-tripping is already broken for OBO products as untranslatable OWL axioms are stripped from header. I'm not aware of any products that use the OBO GCI axioms @cmungall - please yell if I'm wrong. They are mainly an irritation as we get frequent tickets from people confused by them. I have a slight preference that comments get merged in all products but went with this as @gouttegd indicated it was much more straightforward for the pipelines. There was a problem hiding this comment.
As I said elsewhere: that horse has already left the barn. It left the barn at the latest when the ODK started stripping untranslatable axioms in all OBO products – a behaviour that is not configurable. I personally couldn’t care less about that. From my point of view, the OBO format, for all its benefits, is a legacy format and people who choose to use an OBO artefact over any other format should already be aware that they may not get the full picture of what the ontology contains.
You may notice that this is exactly what I did. :)
Disagree. For two reasons. First, merging the comments make them slightly less practical, because the annotations on those comments (cross-references) are merged as well, and there is no longer any way to know which cross-reference applies to which part of the comment. Okay, it may not be a big deal, but why should we make comments less useful in all artefacts in all formats just to accommodate the idiosyncrasies of one particular format? Second, merging the comments early in the pipeline would not in fact be as easy as it sounds, because in this instance the comments are spread over two different files (comments from the editors in And no, using I did in fact consider the alternative and try merging the comments early in the pipeline, and soon concluded that it was way too much of a hassle. Feel free to have a go at it if you want, but my position is that late merging specifically for the OBO products is the option that is the least disruptive to the existing pipelines. There was a problem hiding this comment.
Note my emphasis on "isomorphic (on content supported by OBO format)". Deleting axioms that cant be rendered in the format is a bit different than merging. I am thoroughly convinced by your argumentation, and I want to add that "rdfs:comment" is really not a thing we need to concern ourselves with too much - merge-comments is probably better than "drop random one", which is the alternative if the goal is "legal OBO". Just for future: I would argue strongly against merging key properties like label and definition. Hopefully this is never going to be necessary! Thanks for the explanations! There was a problem hiding this comment.
For completeness, I have implemented the "drop random one" behaviour as an option to Basically with the next version of the Uberon plugin it will be possible to choose what happens when a class has more than one comment:
There was a problem hiding this comment.
I personally wouldn’t care (as I don’t care much about the OBO format generally), but that’s noted. But if we ever get to the point that there is a need to merge labels and/or definitions, then something must have gone horribly wrong long before the conversion to OBO, and it’d be much better to fix the root cause than trying to hide the dust under the rug during the OBO conversion. There was a problem hiding this comment.
Soooo coool! Great. Eventually you will need to start thinking of the scope of your robot plugin, I think it goes way beyond Uberon already! But no worries, I can rename it to "gouttegd-tools" locally if I so wish it :D
Exactly! There was a problem hiding this comment.
That is of course completely possible given the way the ROBOT plugins work, but that’s something that would be best avoided IMHO. If everybody starts renaming plugins locally according to their own wishes, it’s going to be a mess. I’d recommend that whenever a plugin is used, it is used under its original name, to minimise confusion. The fact that a given plugin was initially named after a particular project because it was originally specifically intended for that project should not be a problem, and is not reason enough IMO to rename the plugin. The FlyBase plugin was initially intended solely for FlyBase’s ontologies (hence its name), and now CL is also using it. Is that reason enough to rename it? I don’t think so. |
||
|
|
||
| $(ONT)-base.obo: $(ONT)-base.owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
|
||
| $(ONT)-full.obo: $(ONT)-full.owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
|
||
| $(ONT)-simple.obo: $(ONT)-simple.owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
|
||
| $(ONT)-basic.obo: $(ONT)-basic.owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
|
||
| $(ONT)-non-classified.obo: $(ONT)-non-classified.owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
|
||
| cl-plus.obo: cl-plus.owl | all_robot_plugins | ||
| $(ROBOT) uberon:obo-export --input $< $(OBO_EXPORT_OPTIONS) --obo-output $@ | ||
|
|
||
|
|
||
| # ---------------------------------------- | ||
| # DIFFS/REPORTS | ||
| # ---------------------------------------- | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh my woooooooord - I would love a generic OBO "fixer" tool that does things like merging comments and dropping duplicate labels! This should really be in ROBOT but hey! Plugin is just as well!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will certainly consider upstreaming that to ROBOT at some point. At the very least for the
--strip-owl-axiomsoption (removing the untranslatable axioms), since (1) the ODK already does that systematically, so presumably everybody is already fine with that behaviour, and (2) the OWLAPI already provides the required option to enable that behaviour, it’s just that ROBOT is not using it.