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.


View raw message