INCATools / INCATools/ontology-development-kit

Consistently use URIBASE / ONTBASE

Open
#1,367 1 comment 1 reaction 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.