Primary JSON and TTL release artefacts get wrong ontology IRI (ONTBASE instead of URIBASE)
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 78/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Área
- build-system
Línea de trabajo
Empieza con src/incatools/odk/templates/src/ontology/Makefile.jinja2, especialmente con las reglas principales de $(ONT).ttl y $(ONT).json en torno a las líneas 1805–1815, y compara sus argumentos --ontology-iri con la regla de $(ONT).owl en torno a la línea 1555. Comprueba el Makefile generado con el ejemplo proporcionado make -n -B omo.json. El trabajo estará terminado cuando las exportaciones principales JSON y TTL usen de forma coherente la base de IRI canónica de OWL y las reglas de variantes conserven sus IRIs actuales.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Since the release artefacts section was reformatted, the rules for the primary $(ONT).json and $(ONT).ttl annotate the ontology IRI with $(ONTBASE)/$@ instead of $(URIBASE)/$@. For OBO ontologies that puts the primary JSON/TTL under obo/<id>/<id>.json rather than the canonical obo/<id>.json.
I hit this updating OMO (information-artifact-ontology/ontology-metadata) from v1.6.1 to v1.7. The released omo.json has "id" : "http://purl.obolibrary.org/obo/omo.json"; after the update the next release would ship with http://purl.obolibrary.org/obo/omo/omo.json, which is not the canonical PURL. The $(ONT).owl rule still uses $(URIBASE)/$@, so the primary .owl and .json/.ttl now carry different ontology IRIs. This hits every ODK repo that has json or ttl in export_formats.
The variant rules ($(ONT)-full.json, $(ONT)-base.ttl etc.) were already using $(ONTBASE)/$@ in v1.6.1 and are unchanged. The primary rules used $(URIBASE) and were folded into the variant pattern during the reformat; the commit message says nothing about changing IRIs, so I take this to be a side effect, not a decision. Whether exports should get a format-specific IRI at all is the separate question in INCATools/ontology-development-kit#1366. I compared every --ontology-iri in the 1.6.1 template against the current one: these two rules are the only accidental change.
Examples
v1.6.1:
$(ONT).json: $(ONT).owl
$(ROBOT) annotate --input $< --ontology-iri $(URIBASE)/$@ $(ANNOTATE_ONTOLOGY_VERSION) \
convert --check false -f json -o [email protected] &&\
mv [email protected] $@
v1.7:
$(ONT).json: $(ONT).owl
$(ROBOT) annotate --input $< --ontology-iri $(ONTBASE)/$@ \
$(ANNOTATE_ONTOLOGY_VERSION) \
convert --check false --format json --output $@
$(ONT).ttl changed the same way ($(URIBASE)/$@ → $(ONTBASE)/$@); OMO doesn't export TTL so I only saw the JSON one in practice.
With URIBASE=http://purl.obolibrary.org/obo and ONTBASE=http://purl.obolibrary.org/obo/omo, make -n -B omo.json in OMO gives:
robot --catalog catalog-v001.xml annotate --input omo.owl --ontology-iri http://purl.obolibrary.org/obo/omo/omo.json \
annotate --version-iri http://purl.obolibrary.org/obo/omo/releases/2026-10-27/omo.json ...
| Artefact | v1.6.1 ontology IRI | v1.7 ontology IRI |
|---|---|---|
omo.owl |
http://purl.obolibrary.org/obo/omo.owl |
http://purl.obolibrary.org/obo/omo.owl |
omo.json |
http://purl.obolibrary.org/obo/omo.json |
http://purl.obolibrary.org/obo/omo/omo.json |
omo-full.json |
http://purl.obolibrary.org/obo/omo/omo-full.json |
http://purl.obolibrary.org/obo/omo/omo-full.json |
Related
- Template:
src/incatools/odk/templates/src/ontology/Makefile.jinja2, L1805-1808 ($(ONT).ttl) and L1812-1815 ($(ONT).json); the$(ONT).owlrule at L1555 still uses$(URIBASE) - Introduced in ac746b7 ("Move and re-format the release artefacts section.")
- INCATools/ontology-development-kit#1366
- Lenguaje dominante
- Jinja
- Estrellas
- 3
- Forks
- 4
- Merge medio
- 1 d 3 h
- PR fusionados (30 d)
- 12
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de INCATools/odkcore
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
INCATools/odkcore#57 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Fix `ODK_RESOURCES_DIR` default and plugin download dir in `Makefile.jinja2`Quizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Replace `dataclasses-jsonschema`Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Todos los issues de INCATools/odkcore
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
react/react-native#59693 ·
Los mantenedores suelen responder en 2 días
-
python3Packages.certifi: contents() fails decoding NSS bundle when NIX_SSL_CERT_FILE is unsetAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
C-untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
swoole/swoole-cli#1092 ·