Open keighrim opened 9 months ago
While the MMIF spec is utterly delegating any responsibility to define data types for vocabulary at_types' property values to the vocabulary writer
https://github.com/clamsproject/mmif/blob/fa34a5528049791b36665212929dcb58c93df15f/specifications/index.md?plain=1#L242
Values should be as specified in the vocabulary, values typically are strings, identifiers and integers, or lists of strings, identifiers and integers.
, mmif-python is trying to define some (reasonable) upper bound in the complexity of the possible values.
mmif-python
However this only causes problems like https://github.com/clamsproject/mmif-python/issues/252, and I'm becoming quite skeptical on maintaining the code in the python SDK that is not specified in the specification.
We decide to do either
and execute the decision.
https://github.com/clamsproject/mmif-python/issues/144
Because
While the MMIF spec is utterly delegating any responsibility to define data types for vocabulary at_types' property values to the vocabulary writer
https://github.com/clamsproject/mmif/blob/fa34a5528049791b36665212929dcb58c93df15f/specifications/index.md?plain=1#L242
,
mmif-python
is trying to define some (reasonable) upper bound in the complexity of the possible values.However this only causes problems like https://github.com/clamsproject/mmif-python/issues/252, and I'm becoming quite skeptical on maintaining the code in the python SDK that is not specified in the specification.
Done when
We decide to do either
and execute the decision.
Additional context
https://github.com/clamsproject/mmif-python/issues/144