uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-2942) Allow configuring a type system on the level of an aggregate
Date Thu, 13 Jun 2013 21:19:20 GMT

    [ 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

View raw message