Primary JSON and TTL release artefacts get wrong ontology IRI (ONTBASE instead of URIBASE)
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 78/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Ambito
- build-system
Direzione di ricerca
Inizia da src/incatools/odk/templates/src/ontology/Makefile.jinja2, in particolare dalle regole principali per $(ONT).ttl e $(ONT).json intorno alle righe 1805–1815, e confronta i relativi argomenti --ontology-iri con la regola per $(ONT).owl intorno alla riga 1555. Controlla il Makefile generato con l’esempio fornito make -n -B omo.json. Il lavoro è completato quando le esportazioni JSON e TTL principali usano in modo coerente la base IRI canonica di OWL, mentre le regole delle varianti mantengono le IRIs esistenti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- Jinja
- Stelle
- 3
- Fork
- 4
- Merge medio
- 1g 3h
- PR unite (30g)
- 12
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di INCATools/odkcore
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
INCATools/odkcore#57 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Fix `ODK_RESOURCES_DIR` default and plugin download dir in `Makefile.jinja2`Forse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di INCATools/odkcore
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
react/react-native#59693 ·
I maintainer di solito rispondono entro 2 giorni
-
python3Packages.certifi: contents() fails decoding NSS bundle when NIX_SSL_CERT_FILE is unsetAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
C-untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
swoole/swoole-cli#1092 ·