Publish SSSOM mappings #3249
Merged
Publish SSSOM mappings #3249
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Make sure the mapping sets we will use are known to the ODK. This is the first step towards moving the maintenance of those sets from the existing custom code to ODK-managed code.
We had started to put the mapping sets in src/ontology/mappings, but the directory recommended by the ODK is src/mappings. So we move the existing sets to that directory. We also change the naming convention to remove the `-mappings` suffix before the extension (i.e. `fbbt.sssom.tsv` instead of `fbbt-mappings.sssom.tsv`). Again, this is to align with the ODK recommendations.
We update the custom Makefile to take into account that the mapping sets are now in src/mappings instead of src/ontology/mappings. We also move the rules that generate the sets a bit, so that they are all in the same section (previously the rule that generated the set extracted from Uberon's xref was in the bridge section). We also introduce the "meta" Uberon set, which is a compilation of * uberon-local (the set derived from Uberon's xrefs); * cl (the set derived from CL's xrefs); * zfa (the set derived from ZFA's xrefs); * fbbt (the set mirrored from FBbt).
We add the "meta" mapping set to the list of files to be uploaded as release artifacts on GitHub. We cannot rely on the ODK's built-in `publish_mappings` feature, as it is currently broken.
Avoid committing the `uberon-local.sssom.tsv` mapping set to the repository. This is not needed for now as the set depends only on Uberon's -edit file, so it can always be re-generated whenever it is needed even from a freshly cloned repository. Also avoid committing the "meta" set `uberon.sssom.tsv`. It is merely a compilation of the other mapping sets (including remote sets that *are* committed to the repository) and so can also always be re-generated as needed. In addition, the set is published as a release artifact, which is how it should be accessed.
matentzn
approved these changes
Apr 9, 2024
Contributor
matentzn
left a comment
matentzn
left a comment
There was a problem hiding this comment.
Amaaaaazing! Great great!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is first and foremost intended to allow the publication of the set of mappings between Uberon/CL and other ontologies (#2833).
As an aside, it also moves the mapping files from their current location in
src/ontology/mappingstosrc/mappings, because the latter is the directory recommended by the ODK for mapping files.Ultimately the goal is to have most of the mappings entirely managed by the ODK. This is not possible currently, due to limitations of the ODK. So for now we merely declare the mapping sets in the ODK configuration, but set them all to being “manually maintained“ and generated by custom rules in
uberon.Makefile.