Should we remove "unknown" as option in FoodAcquisitionLocationType?
- Dominant language
- Jinja
- Stars
- 3
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
As suggested by Amos Anim student at the Kumasi Food Science and Technology university as well as PTFI fellow, he believes MIFC should eliminate the "unknown" citing that
> Compilers can fish out all these data should the need be. The "Unknown" option puts no constraints on them.
My response is that perhaps it's reasonable to do the spec currently has "other" and "unknown" (see https://kaiiam.github.io/mifc/FoodAcquisitionLocationType/). Note that these options were taken from a previous version of the PTFI metadata sheet. Its up for debate here and in similar situations that if you give vague options you tend to get lower quality annotations on the flip side if people don't know that level of granularity and not giving them an option prevents their data from being formatted in the standard.
In this case perhaps keeping one of other or unknown but not both is a better solution. Thoughts?
Contributor guide
Research direction
Start by reviewing the FoodAcquisitionLocationType specification at https://kaiiam.github.io/mifc/FoodAcquisitionLocationType/ and the issue's rationale for retaining both "other" and "unknown." Resolve whether one option should be removed based on annotation quality and data constraints; done means the project has a decided, documented specification change.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100