With the release of 1.1.0, we introduced refinedParameters field in the view metadata. (https://github.com/clamsproject/mmif/issues/208) However, as I mentioned in the body of that issue, I was skeptical from the beginning on adding such a new field.
but I wonder if there's any value in adding one (optional) field in the MMIF to record the configuration after the "normalization" (@keighrim)
I see how we want the parameters to contain the original ones as given by the user, but am not quite sure why we also need to keep track of the refined ones for reproducability. (@marcverhagen )
, I'm proposing we "un-release 1.1.0" and go back to 1.0.x. with removal of refinedParameters field.
Done when
Since there has been no SDK released on top of MMIF spec 1.1.0, I think we can safely assume that MMIF 1.1.0 was never "used" in any significant way. That said, the un-releasing will involve
rebasing main branch
re-build web pages from rebased branch with version stamp of 1.0.x
force-push to main to overwrite the published website on mmif.clams.ai
Because
With the release of 1.1.0, we introduced
refinedParameters
field in the view metadata. (https://github.com/clamsproject/mmif/issues/208) However, as I mentioned in the body of that issue, I was skeptical from the beginning on adding such a new field.And now that I have another datapoint that shares the same skepticism(https://github.com/clamsproject/mmif/pull/214#pullrequestreview-1851273250)
, I'm proposing we "un-release 1.1.0" and go back to 1.0.x. with removal of
refinedParameters
field.Done when
Since there has been no SDK released on top of MMIF spec 1.1.0, I think we can safely assume that MMIF 1.1.0 was never "used" in any significant way. That said, the un-releasing will involve
main
branchmain
to overwrite the published website on mmif.clams.aiAdditional context
No response