Fix the "metadata" templates. - #22
Conversation
We update the dynamic templates that produce the files in `src/metadata` (the description of the ontology for the OBO Foundry and the PURL configuration file). Mostly, we try to use the ODK configuration to fill those files as much as possible, especially regarding the available release artefacts and export formats. When we do _not_ have the information we need from the ODK configuration, we let some explicit placeholder for the ontology owner to replace. We also avoid generating GitHub-specific URLs if the ontology does not appear to be intended to be hosted on GitHub (no `github_org`). For the PURL config file, we redirect to attached release artefacts rather than to files from the repository itself, _except_ for imports, components, and pattern files -- those files are expected to be imported from the -edit file, so most users would expect that their PURLs should point to the tip of the main branch rather than to the last release. In most cases this should not matter because the XML Catalog is there to redirect IRIs of import modules and components to local files so that we won't even hit the network, but this may be useful if one needs to process the -edit file with a tool written in a niche language that does not have support for XML Catalogs (e.g., Python; see obophenotype/cell-ontology#3119). closes INCATools/ontology-development-kit#1236
52046f9 to
a27e981
Compare
matentzn
left a comment
matentzn
left a comment
There was a problem hiding this comment.
Looks great, some cosmetic stuff to consider
| {% endif -%} | ||
| {% if project.use_dosdps -%} | ||
| - prefix: /patterns/ | ||
| replacement: https://github.com/{{ project.github_org }}/{{ project.repo }}/raw/refs/heads/{{ project.git_main_branch }}/src/ontology/patterns/ |
There was a problem hiding this comment.
| replacement: https://github.com/{{ project.github_org }}/{{ project.repo }}/raw/refs/heads/{{ project.git_main_branch }}/src/ontology/patterns/ | |
| replacement: https://github.com/{{ project.github_org }}/{{ project.repo }}/raw/refs/heads/{{ project.git_main_branch }}/src/patterns/ |
There was a problem hiding this comment.
Or even
| replacement: https://github.com/{{ project.github_org }}/{{ project.repo }}/raw/refs/heads/{{ project.git_main_branch }}/src/ontology/patterns/ | |
| replacement: https://github.com/{{ project.github_org }}/{{ project.repo }}/raw/refs/heads/{{ project.git_main_branch }}/src/patterns/dosdp-patterns/ |
Depending on what the intention is of this process prefix.
There was a problem hiding this comment.
The point is to make sure that an import declaration like http://purl.obolibrary.org/obo/MYONT/patterns/definitions.owl can find the current version of the definitions.owl file even without a catalog.
Files under dosdp-patterns are used by the DOSDP pipelines but none of them should ever be imported directly (they are not even OWL files), so there shouldn’t be any reason to have a redirection to that directory.
| {%- endif %} | ||
| {%- endfor %} | ||
| {%- for artefact in project.release_artefacts %} | ||
| {%- if artefact != project.primary_release %} |
There was a problem hiding this comment.
drops <id>/<id>-base.owl from products when someone sets primary_release: base, so PURL resolves only through fall thru?
There was a problem hiding this comment.
so PURL resolves only through fall thru?
Err, what are you talking about? Those lines are not in the PURL config template, they are in the OBO Foundry metadata template. This is the list of available products, as in:
products:
- id: myont.owl
name: "My Ontology main release in OWL format"
- id: myont-base.owl
name "My Ontology BASE release in OWL format"
So yes, we drop myont/myont-X.owl when X is the ”primary release” product, to avoid needlessly listing what is in effect the same product twice (once under the name of the primary release, and once under the qualified name).
This seems to be the norm on the OBO FOundry website: For most ontologies, the “primary release” is -full, and the -full product is not listed among the available products (see for example Uberon, CL, …).
Both the project.title and project.description are free text, and could contain YAML-breaking stuff.
When not using GitHub, we cannot predict what the URLs to redirect to for all the various parts of the ontology will be, so we just write out placeholders for the ontology owner to fill.
2 participants
We update the dynamic templates that produce the files in
src/metadata(the description of the ontology for the OBO Foundry and the PURL configuration file).Mostly, we try to use the ODK configuration to fill those files as much as possible, especially regarding the available release artefacts and export formats. When we do not have the information we need from the ODK configuration, we let some explicit placeholder for the ontology owner to replace.
We also avoid generating GitHub-specific URLs if the ontology does not appear to be intended to be hosted on GitHub (no
github_org).For the PURL config file, we redirect to attached release artefacts rather than to files from the repository itself, except for imports, components, and pattern files -- those files are expected to be imported from the -edit file, so most users would expect that their PURLs should point to the tip of the main branch rather than to the last release. In most cases this should not matter because the XML Catalog is there to redirect IRIs of import modules and components to local files so that we won't even hit the network, but this may be useful if one needs to process the -edit file with a tool written in a niche language that does not have support for XML Catalogs (e.g., Python; see obophenotype/cell-ontology#3119).
closes INCATools/ontology-development-kit#1236