On 9/26/2013 11:53 AM, Thilo Goetz wrote:
> On 09/26/2013 05:23 PM, Marshall Schor 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").
>
> To my mind, there should only be one parameter, and that should be the
> positive one, i.e., "run". Adding the the inverse as well just adds
> complexity, not readability (for example, you need to check that not
> both parameters are set, or if they're both set, that the setting
> agrees).
I agree the complexity (of the implementation) is more complex (but that's
hidden from the users, I think).
I agree there are more "error" cases: e.g., if a user specifies both of these
with true values, or both with false values, then that's a user-error to be
reported.
So that user error could be avoided if we only had one form.
If we had one form, I think I would prefer "skip", as I've seen that kind of
attribute in several other contexts with a similar meaning, whereas I've never
seen "run"...
-Marshall
>
>>
>> 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
>>
>
>
