On 9/26/2013 5:00 PM, Richard Eckart de Castilho wrote: > Not the controller, but its configuration. The skipping is clearly affecting > the flow. So why not add something to the flowConstraints, e.g.: > > <flowConstraints> > <fixedFlow> > <node>[String]</node> > <node>[String]</node> > ... > </fixedFlow> > <skip> > <node>[String]</node> > <node>[String]</node> > ... > </skip> > </flowConstraints> > > or > > <flowConstraints> > <fixedFlow> > <node skip="true">[String]</node> > <node>[String]</node> > ... > </fixedFlow> > </flowConstraints> > > Personally, I'd not make any modifications to the descriptor at all, but > rather would just skip the delegate when programmatically creating the > descriptor. We do that all the time in our experiments. But if that is for > some reason not an option and the extension is a strong requirement, the > change should at least be made at the location that conceptually makes most > sense (imho). > > @Marshall: do you want to provide some more background why you do not simply > create the descriptors programmatically and externalize this skipping, > including, etc. into your experimental setup? > I'm probably not the right person to respond here; maybe other users want to weigh in. Just to clarify, I'm not the person having the experimental setup :-) .
Here's my 2 cents: To promote interoperability and wide-spread adoption of annotator technology, the thought was there could easily be multiple kinds of "roles" of people, having different skills, involved in setting up and running applications. One role would be annotator writers, writing in C++ or Java or .... Another role would be an "assembler" / configurer of pipelines from parts. UIMA was intended to support the notion that some people would be comfortable with programming; but others would not. Those others could be comfortable with configuring pipelines using XML or using a more friendly tool like a GUI editor (such as the Component Descriptor Editor, CDE) to do this. I think that's a main source of this desire to have certain aspects of pipeline assembly "externalized" outside of programming. -Marshall > -- Richard > > On 26.09.2013, at 22:53, Peter Klügl <[email protected]> wrote: > >> Am 26.09.2013 22:51, schrieb Richard Eckart de Castilho: >>> I believe this is a concern of the flow controller and should not be >>> configured on the delegates, but rather within the flow controller >>> configuration. >> That was also my first guess, but do you really wanna touch or change the >> flow controller for just skipping a component? >> >> Peter >> >>> -- Richard >>> >>> On 26.09.2013, at 17:23, Marshall Schor <[email protected]> wrote: >>> >>>> To handle the use cases briefly described on the user list for selectively >>>> skipping some annotators in an aggregate, based on some externally supplied >>>> configuration data, I'd like to propose something along these lines: >>>> >>>> * Add to the existing element <delegateAnalysisEngine key="[String]"> one >>>> or two >>>> additional attributes. One would be "skip=${xxx}" and the other would be >>>> its >>>> inverse (for improved readability, only, not logically needed): >>>> "run=${xxx}", >>>> where the value of the parameter would need to be "true" or "false" (or >>>> "yes" or >>>> "no"). >>>> >>>> The parameter could be written literally as "true", etc., but also could be >>>> written using the standard variable naming syntax used elsewhere in the >>>> descriptors, and would be resolved by settings in the now-standard >>>> "external >>>> overrides" files used by UIMA. This means that the external overrides >>>> would >>>> continue to be a place where all of the specific configuration info for a >>>> particular "run" could be placed, together. >>>> >>>> The implementation would do nothing new if the parameters were indicating >>>> to run >>>> the delegate, but if they were indicating it should be skipped or not run, >>>> then >>>> the effect would be as if the delegate had been edited out of the xml >>>> descriptor. >>>> >>>> This would satisfy some pleas from some user groups for help in managing >>>> their >>>> descriptors across various related experiments. >>>> >>>> An example: a user might have a delegate which came in two forms: one to >>>> run >>>> "locally", and the other to run "remote". >>>> >>>> They could then include both descriptors in the aggregate, and have only >>>> one of >>>> them "active", by coding: >>>> >>>> <delegateAnalysisEngine key="NE-detector" run="NE-Detector-local"> ... >>>> </delegateAnalysisEngine> >>>> <delegateAnalysisEngine key="NE-detector" skip="NE-Detector-local"> ... >>>> </delegateAnalysisEngine> >>>> >>>> WDYT? >>>> >>>> -Marshall >
