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
This is technically not wrong and the information about the element type in the array should usually be accessible through the definition of the feature which references the array - however, we can currently not serialize this.
To Reproduce
See test tsv3-testSimpleSlotFeature.
Expected behavior
Optimally, it should be serialized in the same was as it was loaded. Java UIMA v3 reifies array types in the type system - so instead of only an FSArray, it dynamically creates types like FSArray<LinkType> and binds the FSArray to that - so we have access to the array element type without having to look at the feature it is referenced from. This is particularly useful for arrays which are shared and can be referenced from multiple features (with potentially different yet compatible element type definitions).
However, it seems this won't be trivial to fix in the Python implementation and would require also introducing dynamic array types.
Please complete the following information:
Version: 0.7.5
The text was updated successfully, but these errors were encountered:
Describe the bug
When cassis is parsing an array like this:
it is serialized again as:
This is technically not wrong and the information about the element type in the array should usually be accessible through the definition of the feature which references the array - however, we can currently not serialize this.
To Reproduce
See test
tsv3-testSimpleSlotFeature
.Expected behavior
Optimally, it should be serialized in the same was as it was loaded. Java UIMA v3 reifies array types in the type system - so instead of only an
FSArray
, it dynamically creates types likeFSArray<LinkType>
and binds the FSArray to that - so we have access to the array element type without having to look at the feature it is referenced from. This is particularly useful for arrays which are shared and can be referenced from multiple features (with potentially different yet compatible element type definitions).However, it seems this won't be trivial to fix in the Python implementation and would require also introducing dynamic array types.
Please complete the following information:
The text was updated successfully, but these errors were encountered: