Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalise QC check that ensures that all terms fall under preferred root #358

Open
matentzn opened this issue Sep 30, 2020 · 4 comments
Open
Assignees

Comments

@matentzn
Copy link
Contributor

If there is a preferred root declaration, then all terms in the base-namespace must fall under at least one class with a preferred root tag. See obophenotype/cell-ontology#725 (comment)

@matentzn matentzn self-assigned this Sep 30, 2020
@gouttegd
Copy link
Contributor

gouttegd commented Feb 16, 2025

@matentzn Do you want to add that to the odk:validate command already used for #1175?

@matentzn
Copy link
Contributor Author

Yes. i think as for the general pattern - we can try the feature in the ODK robot plugin, and if we think its useful, migrate it to ROBOT core?

@gouttegd
Copy link
Contributor

we can try the feature in the ODK robot plugin, and if we think its useful, migrate it to ROBOT core?

Sounds good.

I think this should be the general pattern for ROBOT plugins:

(1) Is the command highly specific to one project?

Then make your own plugin. It’s easy, and we don’t want ROBOT to end up with a command for every single task imaginable (that was the mistake of OWLTools).

Typical examples would be Uberon’s uberon:merge-species and uberon:create-species-subset commands.

(2) Can the command be useful for a handful of projects?

Then maybe consider making a distinct plugin, that is not tied to any single project.

(3) Can the command be useful for many projects?

Then consider adding it to the ODK plugin – especially if you think that command should be used as part of any standard ODK workflow.

Once the command had been in the ODK plugin for a while (let’s say at least a full ODK major release cycle), consider submitting it to upstream ROBOT.

(4) Is the command intended to work around a bug in upstream ROBOT?

Then submit a proper fix to ROBOT first! And then only add the command to the ODK plugin (or any other plugin) as a temporary workaround that should be removed as soon as a version of ROBOT is available in which the bug is fixed.

Typical example would the current’s odk:normalize --merge-axioms true, which I hope to remove if/when ontodev/robot#1240 is merged (or ontodev/robot#1239 is fixed by any other means).

Likewise if the command implements a new feature that would fit nicely into one of the existing ROBOT commands (like odk:normalize --add-source, which I hope is a temporary workaround until ontodev/robot#1242 is merged).

@matentzn
Copy link
Contributor Author

I agree, this is a great way to put it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants