[jira] [Updated] (UIMA-2812) Support ResultSpecification

["Richard Eckart de Castilho (JIRA)" <de...@uima.apache.org>]

     [ https://issues.apache.org/jira/browse/UIMA-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Eckart de Castilho updated UIMA-2812:
---------------------------------------------
    Fix Version/s: 2.3.0uimaFIT

> Support ResultSpecification
> ---------------------------
>
>                 Key: UIMA-2812
>                 URL: https://issues.apache.org/jira/browse/UIMA-2812
>             Project: UIMA
>          Issue Type: New Feature
>          Components: uimaFIT
>            Reporter: Richard Eckart de Castilho
>             Fix For: 2.3.0uimaFIT
>
>
> Provide support for controlling the output of a component using a ResultSpecification. Consider the e.g. use-case that a component can produce a "PartOfSpeech" annotation, but it should not, because another component in the same pipeline has already produced that or will later produce it. Here some pseudocode:
> {noformat}
> AnalysisEngineDescription aed = createPrimitiveDescription(Parser.class);
> // Tell Parser not to produce PartOfSpeech annotations
> ResultUtil.removeType(aed, PartOfSpeech.class);
> {noformat}
> *How to "remove" a type?* UIMA requires that a ResultSpecification contains _all_ the types that the component produces, which would normally requiring to add all types except the ones that should not be produced. uimaFIT has access to _capability_ annotations, which it could use to pre-fill a result specification with all the types that a component could produce, allowing the user to conveniently remove the ones not required.
> *How to transport the information?* Unfortunately, there appears to be no way to store the ResultSpecification as part of an _AnalysisEngineDescription_. As far as I can see, UIMA has two ways to control the ResultSpecification for a component:
> * via the components _capabilities_
> * via a parameter passed to the _AnalysisEngine.process_ method (or via _setResultSpecification_) 
> There are two scenarios I can imagine: 
> * _at description time_: changes to the result specification are added to the descriptor.
> ** Add the ResultSpecification to the component descriptor -- unfortunately is not supported by UIMA.
> ** Change the _capabilities_. E.g. uimaFIT creates an AE descriptor with the capabilities filled in, then one could add or remove types/features there.
> * _at runtime_: uimaFIT could be used to acquire an initial ResultSpecification from the annotation on the AE class, which can then be modified to add/remove types/features. The final specification needs to be passed in some way into the pipeline execution code
> ** _along with the component descriptor_: pairs of {descriptor, resultspec} needed to be passed to the pipeline execution code (e.g. SimplePipeline), making the API more complex.
> ** _as part of already instantiated components_: in case of SimplePipeline, there are also non-descriptor-based methods that could be used, in which case the result specifications could be set on each component individually before passing them into the pipeline code.
> *Does it fit into the uimaFIT concept?* So far, it was possible to implement uimaFIT in such a way that all information pertaining to the component configuration could be reflected, configured, and stored in a descriptor, so that any UIMA execution engine could then pick up the descriptor and execute the component as it was configured. UIMA appears to be lacking the concept of a ResultSpecification as part of the descriptors. In particular, that seems to affect ability to configure results within aggregate analysis engines.
> *Conclusion* Since a ResultSpecification cannot be stored in a descriptor, the next best thing appears to be adding some convenience methods to change the reflected capabilities in the descriptor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)