Refactor of terminology retrieval of sections
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by locating get_terminology_equivalent() and reading its callers and the Section model. Reproduce the reported case with multiple Sections sharing a type, then clarify how additional attributes should select terminology and what result callers expect before defining completion criteria.
Written by the indexing model from the issue text.
Description
Currently the terminology equivalent of a Section is found in the given repository by matching the Section type.
This is problematic for the following reason: A Section type, as I understood it so far, is meant to group related Sections to an superior class. For example, two different Electrodes from different vendors with different Properties can be grouped via their type which could be 'electrode', even if the Section names are vendor-specific. In such a case, the function get_terminology_equivalent() will currently unfortunately only return the first Section with the type 'electrode' and ignore the second Section in the repository.
Of course one could provide always a unique Section type to avoid this, but I think then one could directly use the Section Name instead and the possibility an overall classification method for Sections is lost.
Instead one could return a list of all sections with the stated type and also use in addition other attributes to retrieve terminologies.
- Dominant language
- Python
- Stars
- 25
- Forks
- 30
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from G-Node/python-odml
-
RDF
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
G-Node/python-odml#172 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
G-Node/python-odml#420 ·
-
Sparse file output Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
G-Node/python-odml#418 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
G-Node/python-odml#417 · 8 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
G-Node/python-odml#406 ·
All issues in G-Node/python-odml
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·