Expanding Source Enumeration Files

[yelenacox]

No description provided.

[github-actions]

PR Preview Action v1.6.2
🚀 View preview at https://include-dcc.github.io/cam-expanded-enums/pr-preview/pr-3/
Built to branch gh-pages at 2026-07-08 18:59 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[torstees]

Let's create a new file, docs/term-expansion.md which explains what is happening:

1. Link out to Term Weaver and summarize which LinkML features it supports (source_nodes and include_self = true/false, is_direct = true/false) Probably worth pointing out it does not support 'traverse_up'
2. Explain the new just targets, _source_enums and _expand (what do they do, etc)
3. point out any new dependencies you added: (_expand is now a dependency of gen-project, etc)
4. Add this new file to the nav section in the mkdocs.yml

It is probably worth doing #1 and 4 above for the cam_source as well.

[RobertJCarroll]

With regards to the output, using this example:

edam:data_3270:
text: edam:data_3270
description: Unique identifier for a gene tree from the Ensembl database.
title: Ensembl gene tree ID

• I'm not sure I understand the text element- it doesn't seem necessary.
• I would like to see that value in a meaning element.
• I'd prefer a slightly different order to the elements for readability.
• I also noticed snomed doesn't have descriptions- can we get them?
• If there are no descriptions, I would expect leaving off the element vs having an empty string make

This is what I'd expect to see (very close!)

edam:data_3270:
title: Ensembl gene tree ID
description: Unique identifier for a gene tree from the Ensembl database.
meaning: edam:data_3270

I believe this would validate and is consistent with what was in the manually defined items. Note that github is flattening these on display, there is a nested whitespace still!

[RobertJCarroll]

I also discussed with Eric checking the linting- it'd be good to either update the code / output to come back clean or understand how we need to adjust the linter in these models.

[torstees]

I also discussed with Eric checking the linting- it'd be good to either update the code / output to come back clean or understand how we need to adjust the linter in these models.

I made a small commit containing a fix for the linter rules. This repo now returns a green arrow when running 'just lint'. @yelenacox If you could copy these changes/files over to cam-source-enums, that will ensure that we don't miss other things as they occur.

[yelenacox]

@RobertJCarroll I have updated the output to the format specified in the comment.

[RobertJCarroll]

I also discussed with Eric checking the linting- it'd be good to either update the code / output to come back clean or understand how we need to adjust the linter in these models.

I made a small commit containing a fix for the linter rules. This repo now returns a green arrow when running 'just lint'. @yelenacox If you could copy these changes/files over to cam-source-enums, that will ensure that we don't miss other things as they occur.

Thanks Eric- have you been able to find the "original" linting rules? I haven't and tried a few times in the last few weeks. I would like to understand the what's different here. The dash is the main element I'd be "concerned" about, though I don't think it'd be problematic.

[RobertJCarroll]

This looks good to me. Glad everything is validating!

[torstees]

Thanks Eric- have you been able to find the "original" linting rules? I haven't and tried a few times in the last few weeks. I would like to understand the what's different here. The dash is the main element I'd be "concerned" about, though I don't think it'd be problematic.

@RobertJCarroll There is this page. The default is uppersnake, and my change provides a lighter restriction (alphanumeric, "_", "-" and ":"). Are you concerned about allowing the dash or are you concerned that we will see them in the future? The latter should be currently permitted, but we can remove the "-" if that sounds risky to you.