uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Baessler <...@michael-baessler.de>
Subject Re: Default Result Specifications too complicated?
Date Wed, 18 Apr 2007 18:10:10 GMT
Adam Lally wrote:
> This changed in 2.0 with the introduction of the flow controller.  The
> ResultSpec no longer has any dependence on the flow.  The framework
> assumes the most general case of the custom flow controller.
>
> The effect is that an annotator's ResultSpec will include all of the
> input types of *any* component in the same aggregate, even if that
> component happens to run before the annotator, not after it.  We
> decide that this is such a strange case that it wasn't worth worrying
> about.
OK, but can the FlowController manipulate the ResultSpec for an 
annotator before it is
called? Or can the FlowController just decide the flow of the engines 
(if they are called, which order ...)
If the FlowController does not manipulate the ResultSpec where else can 
it be done, only in the application
that calls the main engine?
> The default result spec is not "all they can".  A type is only
> included in an annotator's default result spec if one of the following
> is true:
> (a) The type is listed in the outputs of all containing aggregates (so
> it's concluded that the type is a final output of the whole aggregate
> which the application may inspect)
> (b) The type is listed in the inputs of some other component of the
> aggregate (so it's concluded that the type may be a necessary
> intermediate type that some other annotator may inspect in order to
> produce output that's of interest to the application)
>
> As I recall, you (Michael) and/or Thilo felt that a default result
> spec of "all they can" was not appropriate, and that it was a
> necessary feature to restrict the outputs of an annotator based on the
> declared outputs of an enclosing aggregate.  In any case this was
> always done in the capability language flow in previous versions of
> UIMA, but in 2.0 was generalized to be independent of flow.
I still think that it is necessary to have a way to specify what output 
types an annotator
should produce. And it is not efficient that an annotator always produce 
anything that's possible.

I will look into the code to get a better understanding how this stuff 
works in UIMA 2.1.

-- Michael


Mime
View raw message