[
https://issues.apache.org/jira/browse/UIMA-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13682759#comment-13682759
]
Marshall Schor commented on UIMA-2942:
--------------------------------------
Type specifications are typically driven by code that will be making use of the
types. Code lives in Primitive Annotators, and outside the UIMA pipeline (in
applications which use UIMA APIs to setup pipelines, run them, get results,
etc.).
The current design provides methods for specifying the types in these two
cases. Here are some use-cases.
* If, we are imagining use-cases where the UIMA programming API is being
driven with custom code, then that code can construct (via API calls) merged
type systems from all the delegates *plus* any other type system(s) that might
be of interest.
* On the other hand, if we're imagining use-cases where the UIMA programming
API is *not* being driven with custom code, but we're thinking that the
Aggregate XML specification is being tweaked, it can be tweaked by adding an
additional delegate which has the particular types you need, and that would be
working with those types.
* On the other hand, if we're thinking of use-cases where there's no need for
another delegate with a declared type system, the one I can imagine is one
where we have a pipeline that's type-agnostic, using some "script" which will
at run time via some configuration or perhaps some even more dynamic method
(e.g., reading some external source) decide what types and features it wants to
generate and process.
This last case is one where there's no pre-defined type system. For this last
case, it seems to me that this (in a way) goes against the main design
tradeoffs in UIMA - which are focused on exploiting a
"fixed"-at-initialization-time specification of type systems.
It seems to me that the actual use case here would be one where you end up with
some specification that includes a type system, but where no annotator makes
use of that type system, and no custom external API setup of the UIMA pipeline
is being done.
Is this an actual use case? If it is, I'd like to learn more about it so we
can understand what the tradeoffs would be for a good solution.
> 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
