You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2006/11/22 03:20:11 UTC
Are configuration parameter groups depreciated in version 2?
This is a fairly complex feature that is not much used I think. Should
we deprecate this in version 2?
-Marshall
Re: Are configuration parameter groups depreciated in version 2?
Posted by Michael Baessler <mb...@michael-baessler.de>.
Eddie Epstein wrote:
>> eddie_epstein@aewatercolors.com wrote:
>>
>>> The current parameter group design requires replicating all
>>> configuration
>>> parameters for each language. This is neither elegant nor easy to
>>> maintain. A better design would use common configuration paramters with
>>> the provision to override specific parameters for a given configuration.
>>> All parameters could be in a flat space, but a parameter could be
>>> addressed using a variable suffix. For example:
>>>
>>> windowSize = (Integer)getConfigParameterValue("WindowSize", suffix);
>>>
>>> where suffix could be a string variable extraced from the CAS. If
>>> "WindowSize" + suffix did not exist as a parameter, the framework would
>>> attempt to use just "WindowSize" as a parameter key
>>>
>> But how do I know in my annotator code what groups/suffixes are
>> available? Currently I can ask for the groups and
>> get back an array of available groups.
>>
> The list of suffixes would be dynamically created based on scanning all
> configuration parameters and returning a list of unique suffixes found.
>
> Eddie
>
>
>
So if there is an API to return all suffixes, fine with me.
-- Michael
Re: Are configuration parameter groups depreciated in version 2?
Posted by Eddie Epstein <ed...@aewatercolors.com>.
> eddie_epstein@aewatercolors.com wrote:
>> The current parameter group design requires replicating all
>> configuration
>> parameters for each language. This is neither elegant nor easy to
>> maintain. A better design would use common configuration paramters with
>> the provision to override specific parameters for a given configuration.
>> All parameters could be in a flat space, but a parameter could be
>> addressed using a variable suffix. For example:
>>
>> windowSize = (Integer)getConfigParameterValue("WindowSize", suffix);
>>
>> where suffix could be a string variable extraced from the CAS. If
>> "WindowSize" + suffix did not exist as a parameter, the framework would
>> attempt to use just "WindowSize" as a parameter key
> But how do I know in my annotator code what groups/suffixes are
> available? Currently I can ask for the groups and
> get back an array of available groups.
The list of suffixes would be dynamically created based on scanning all
configuration parameters and returning a list of unique suffixes found.
Eddie
Re: Are configuration parameter groups depreciated in version 2?
Posted by Michael Baessler <mb...@michael-baessler.de>.
eddie_epstein@aewatercolors.com wrote:
> The current parameter group design requires replicating all configuration
> parameters for each language. This is neither elegant nor easy to
> maintain. A better design would use common configuration paramters with
> the provision to override specific parameters for a given configuration.
> All parameters could be in a flat space, but a parameter could be
> addressed using a variable suffix. For example:
>
> windowSize = (Integer)getConfigParameterValue("WindowSize", suffix);
>
> where suffix could be a string variable extraced from the CAS. If
> "WindowSize" + suffix did not exist as a parameter, the framework would
> attempt to use just "WindowSize" as a parameter key
But how do I know in my annotator code what groups/suffixes are
available? Currently I can ask for the groups and
get back an array of available groups.
-- Michael
Re: Are configuration parameter groups depreciated in version 2?
Posted by ed...@aewatercolors.com.
> Marshall Schor wrote:
>> This is a fairly complex feature that is not much used I think.
>> Should we deprecate this in version 2? -Marshall
>
> I disagree with that. I know two annotators using configuration
> parameter groups for language specific configuration parameters settings.
> If we drop the configuration parameter groups, these the annotators
> cannot run with version 2.
>
> I think it's a good feature which makes configuration parameter settings
> easier when having for example language specific settings.
> For example, when we have a simple ngram tokenizer that creates ngram
> tokens for a given text. By default the ngram window size is two but for
> some language it is 3. This ngram window size setting is language
> specific and it is easy to configure when having configuration parameter
> groups.
>
> -- Michael
>
The current parameter group design requires replicating all configuration
parameters for each language. This is neither elegant nor easy to
maintain. A better design would use common configuration paramters with
the provision to override specific parameters for a given configuration.
All parameters could be in a flat space, but a parameter could be
addressed using a variable suffix. For example:
windowSize = (Integer)getConfigParameterValue("WindowSize", suffix);
where suffix could be a string variable extraced from the CAS. If
"WindowSize" + suffix did not exist as a parameter, the framework would
attempt to use just "WindowSize" as a parameter key.
Eddie
Re: Are configuration parameter groups depreciated in version 2?
Posted by Michael Baessler <mb...@michael-baessler.de>.
Marshall Schor wrote:
> This is a fairly complex feature that is not much used I think.
> Should we deprecate this in version 2? -Marshall
I disagree with that. I know two annotators using configuration
parameter groups for language specific configuration parameters settings.
If we drop the configuration parameter groups, these the annotators
cannot run with version 2.
I think it's a good feature which makes configuration parameter settings
easier when having for example language specific settings.
For example, when we have a simple ngram tokenizer that creates ngram
tokens for a given text. By default the ngram window size is two but for
some language it is 3. This ngram window size setting is language
specific and it is easy to configure when having configuration parameter
groups.
-- Michael