Since we are now discussing https://github.com/clamsproject/mmif/issues/228 that can permanently break the MMIF, I'd also like to bring another question of mine related to the id field of annotation objects.
We need id field to properly place and locate the annotation objects in the context of the MMIF format, but id values provide nothing intrinsic about the annotations themselves. I can imagine a id value is actually represent some intrinsic property of the type (e.g., a social/governmental identification number for a Person type), but that's not the way we use the field in the current MMIF format.
That said, I think the id field should be moved up to the top of annotation object, at the same level as @type field.
Plus, view objects have their id field at their top level, so annotations having id in a nested dict seems syntactically inconsistent.
Since we are now discussing https://github.com/clamsproject/mmif/issues/228 that can permanently break the MMIF, I'd also like to bring another question of mine related to the
idfield of annotation objects.We need
idfield to properly place and locate the annotation objects in the context of the MMIF format, butidvalues provide nothing intrinsic about the annotations themselves. I can imagine aidvalue is actually represent some intrinsic property of the type (e.g., a social/governmental identification number for aPersontype), but that's not the way we use the field in the current MMIF format.That said, I think the
idfield should be moved up to the top of annotation object, at the same level as@typefield.Plus, view objects have their
idfield at their top level, so annotations havingidin a nested dict seems syntactically inconsistent.(this could also be remotely related to this discussion https://github.com/clamsproject/mmif/issues/230#issuecomment-2205900344 to try to better define the distinction between "metadata" and "property" of annotation types )