uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Lally" <ala...@alum.rpi.edu>
Subject Re: Default Result Specifications too complicated?
Date Thu, 07 Jun 2007 20:05:52 GMT
On 6/6/07, Michael Baessler <mba@michael-baessler.de> wrote:
> Here is a short example.
> Annotator 1 can do Tokens and Lemmas
> Annotator 2 can do Tokens and Sentences
> Application is interested in Tokens, Lemmas and Sentences.
>
> I guess the default result spec for Annotator 1 is Tokens and Lemmas.
> The default result spec for Annotator 2 is Tokens and Sentences, right?
>
> So if the flow can't manipulate the ResultSpec both annotator will
> produce Tokens. But this is not the
> case for the capabilityLanguage flow. Within the capabilityLanguage flow
> the ResultSpec for the annotators
> is overridden with a computed ResultSpec from the I guess default
> ResultSpec.
>

Yes, you are right.  That aspect of the capability language flow is no
longer supported.  I guess we must not have had a unit test for that,
since I tried to get all the unit tests to pass when I implemented the
custom flow controller.

If this functionality is necessary then we'll need to think about how
to extend the Flow Controller interface to allow it.  Maybe a new Step
type that can specify the ResultSpec along with the destination AE?

I think it was nice, though, to simply the Result Specs and make them
more of a "static" concept rather than something that changes per-CAS.
 And it's unfortunate if Result Specs cause additional complexity in
other parts of UIMA, given that most annotators don't even pay
attention to them.

> > OK.  I think what we're leaning towards doing here is just providing
> > some better checking/tracing for result specs so that it is easier to
> > debug problems with them.
> So maybe we have to improve the documentation to explain more detailed
> how the result spec is working
> and how it can be manipulated, if I'm right with my assumption above.
>

The documentation is there, somewhere... but it is very difficult for
people to even know that they have a Result Spec problem.  Most users
don't even know what result specs are.  So I think documentation alone
can't address this issue.  Better checking in the framework I think is
necessary for this - perhaps some debug mode that people can run in
that would tell them when certain types had been excluded from an
annotator's result spec, and ideally why they were excluded.

-Adam

Mime
View raw message