You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The two required keys are `@type` and `properties`. As mentioned before, the `@type` key in JSON-LD is used to define the type of data structure. The `properties` dictionary typically contains the features defined for the annotation category as defined in the vocabularies at [CLAMS vocabulary ](vocabulary) or [LAPPS vocabulary](http://vocab.lappsgrid.org/). For example, for the *TimeFrame* annotation type the vocabulary includes the feature `frameType` as well as the inherited features `id`, `start` and `end`. Values should be as specified in the vocabulary, values typically are strings, identifiers and integers, or lists of strings, identifiers and integers.
Values should be as specified in the vocabulary, values typically are strings, identifiers and integers, or lists of strings, identifiers and integers.
However this only causes problems like clamsproject/mmif-python#252, and I'm becoming quite skeptical on maintaining the code in the python SDK that is not specified in the specification.
Because
While the MMIF spec is utterly delegating any responsibility to define data types for vocabulary at_types' property values to the vocabulary writer
mmif/specifications/index.md
Line 242 in fa34a55
,
mmif-python
is trying to define some (reasonable) upper bound in the complexity of the possible values.However this only causes problems like clamsproject/mmif-python#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
clamsproject/mmif-python#144
The text was updated successfully, but these errors were encountered: