[
https://issues.apache.org/jira/browse/UIMA-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664252#comment-13664252
]
Richard Eckart de Castilho commented on UIMA-2917:
--------------------------------------------------
It'd be interesting to support the union strategy. It would allow for a kind of
"mix-in" strategy. Consider you have one "base" type system which defines a
type "Token" with a feature "part-of-speech". Another "tagset" type system
would redefine "Token" only allowing "part-of-speech" values from a certain tag
set. That would allow to use the inheritance mechanism for something different
than specializing for a particular tag set, e.g. to have "Word", "Number" or
"Whitespace" sub-types of "Token".
So what happens now in this case? Your definition of "strict" says the values
are not merged in a union if the value sets are different. What if one type
system does not make a restriction at all and the other does? At least the
"closed world" assumption would not be violated, if the restriction was now
applied, rather the contrary.
> Type System Merging for string subtypes with allowed values
> -----------------------------------------------------------
>
> Key: UIMA-2917
> URL: https://issues.apache.org/jira/browse/UIMA-2917
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Affects Versions: 2.4.0SDK
> Reporter: Marshall Schor
> Priority: Minor
> Fix For: 2.4.1SDK
>
>
> UIMA uses type system merging to combine separately developed annotators and
> their type systems. When the same type is define in multiple type systems,
> perhaps with different features, these are "merged" where possible, and if
> not possible, exceptions are thrown. The current implementation is missing
> any support for merging subtypes of Strings - which UIMA uses for associating
> Allowed-Values for. If two type systems define the same-named subtype of
> String, no merging of allowed values is done, no exception is thrown if the
> allowed value sets are different, and the merge uses the first definition as
> the merge result, ignoring the others.
> The behavior could be changed to be "strict" - throwing an exception if the
> allowed values are not identical, or more lenient - for example, having the
> merged definition be the union of the the sets of allowed value. The
> drawback to the union approach is that any annotator which was assuming a
> "closed universe" of possible values, could now be seeing values not in the
> set it expected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
