I think there's a tradeoff when using Specifications - they're more clear when
they have the information locally, and harder to understand when they point to
an unknown arbitrary thing.
Generally, the UIMA spec design philosophy have tried to encourage community and
part-interoperability by leaning toward making things more transparent /
obvious.
-Marshall
On 9/26/2013 5:06 PM, Richard Eckart de Castilho wrote:
> Another alternative could even be to control the import to point the desired
> flow:
>
> <flowController key="[String]">
> <import location="${xxx}"/>
> </flowController>
>
> That would completely remove the need for any skipping attributes and work
> without dynamically generated descriptors.
>
> -- Richard
>
> On 26.09.2013, at 23:00, Richard Eckart de Castilho <[email protected]> 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?
>>
>> -- 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
>
