[
https://issues.apache.org/jira/browse/UIMA-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682788#comment-13682788
]
Richard Eckart de Castilho commented on UIMA-2942:
--------------------------------------------------
Originally, I stumbled over this not driven by a use-case, but rather by
providing an alternative API to setting up aggregates programmatically in
uimaFIT.
Recently, I stumbled again of this issue when I was trying to pre-consolidate
an aggregate description. I'm not sure if this could be called a use-case, but
here is what I was going to do any why:
Programmatically generated descriptors via uimaFIT can become quite large. E.g.
when the type system discovery feature is used, then every descriptor generated
by uimaFIT contains a *full* type system of *all* the types on the classpath.
The same for index definitions and type priorities, if these are automatically
detected. It's pretty annoying to read these descriptors. They contain a *lot*
of redundancy.
I implemented a function "consolidate" which basically does what UIMA does when
running an aggregate: it collects type system information, type priorities, and
index definitions from all delegates recursively. Then it detaches this
information from the delegates, merges it and attaches it to the aggregate. The
final descriptor is much shorter, easier to read and contains much less
redundancy. And it works, except that UIMA complains again about not being able
to configure a type system on the aggregate.
What bugs me most about this issue isn't so much that its not possible to set
types on an aggregate. If there is a good reason to do so, ok. It would be a
different issue to figure out if the reason is really good. What bugs me here
is that it appears utterly inconsistent and arbitrary that just type systems
cannot be configured on aggregates while indexes and priorities can. So far, I
haven't seen any good reason why configuring types on an aggregate would
actually break anything. If the latter two can, there should be a really good
reason to prohibit it for types. If there is none, other than "nobody asked for
it yet", then I think it shouldn't be prohibited and actually ask that it work.
> Allow configuring a type system on the level of an aggregate
> ------------------------------------------------------------
>
> Key: UIMA-2942
> URL: https://issues.apache.org/jira/browse/UIMA-2942
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Richard Eckart de Castilho
> Priority: Minor
>
> Allow configuring a type system on the level of an aggregate. Priorities and
> indexes are allowed, but setting a type system is forbidden. Seems to be
> inconsequent.
> Consider I get an aggregate from some person. It contains a Ruta script (or
> something else that is type agnostic/type configurable). I reconfigure the
> aggregate with my own script which creates different annotations (e.g. using
> parameter overrides on the aggregate). Now, I would have to reconfigure the
> aggregate with new types as well. I wouldn't want to dive down into the
> individual components of the aggregate to do that - after all, the aggregate
> is meant to be a component in its own right.
--
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
