INCATools / INCATools/ontology-development-kit
Consistently use URIBASE / ONTBASE
Nobody has claimed this yet.
- Dominant language
- Dockerfile
- Stars
- 375
- Forks
- 69
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 7
Description
The standard Makefile has three very similar variables:
* `OBOBASE` (hardcoded to `http://purl.obolibrary.org/obo/`);
* `URIBASE` (set to the project’s `uribase` setting, defaulting to `http://purl.obolibrary.org/obo/`);
* `ONTBASE` (set to `URIBASE` + either the project’s `uribase_suffix` setting or its `id` setting).
Within the Makefile, `URIBASE` is mostly used whenever we need to use ROBOT’s `--base-iri` option, while `ONTBASE` is mostly used to set the ontology IRI and the version IRI.
However we are not entirely consistent, for example:
* Most of the import pipeline actually uses either
* `{{ project.uribase }}` directly instead of the `URIBASE` variable, or
* `$(OBOBASE)/something` – that one is particularly problematic as it basically hardcodes the fact that an import is assumed to be an **OBO** import.
* The main release artefact (`$(ONT).owl`) is annotated with an ontology IRI of `$(URIBASE)/$(ONT).owl` instead of `$(ONTBASE)/$(ONT).owl` – presumably this is on purpose, to reflect the OBO convention that the main release artefact (the artefact that is not qualified with any “variant” suffix) is expected to be found at `http://purl.obolibrary.org/obo/$(ONT).owl`, while “qualified” released artefacts are expected to be found at `http://purl.obolibrary.org/obo/$(ONT)/$(ONT)-qualifier.owl`.
* When producing the main ROBOT report, we are using `$(URIBASE)/{{ project.id }}` and `$(URIBASE)/{{ project.id.upper() }}` – thereby ignoring the project’s `uribase_suffix` setting.
We need to be much more consistent here. In particular, I’d argue that we should _never_ use `$(OBOBASE)` – in fact, that variable should not even exist in the Makefile in the first place.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the standard Makefile and trace every use of OBOBASE, URIBASE, and ONTBASE, including the import pipeline, release artefact, and ROBOT report rules. Compare those uses with the project uribase, uribase_suffix, and id settings. Done means the variables are used consistently, OBOBASE is removed, and the intended ontology and version IRIs remain correct.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100