uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: UIMA shared external resources with config parameters
Date Wed, 19 Oct 2016 17:26:19 GMT
Ok, but I mean actually in code. How would it look like?

- how to specify one "object B" as a parameter to another "object A" and finally "object A"
to a component?
- how to set non-String parameters?
- while setting parameters, how to disambiguate between multiple instances of a such a shared


-- Richard

> On 19.10.2016, at 19:22, Marshall Schor <msa@schor.com> wrote:
> re: how to realize the scenarios illustrated in [1] could be implemented
> using the External Configuration parameters? 
> Here's the high level thoughts:
> 1) Implementor designs several "objects" that require configuration.  They decide on
the configuration parameters, giving each of them unique names (perhaps using a kind of package-naming-scheme).
> 2) Key assumption:  These objects are to be UIMA Shared External Resources.  This means
> 2a) there is one instance shared among many things
> 2b) there might be multiple instances if "parameterized" versions of the 
>     external resource are being used (e.g. dictionary, parameterized by language)
> 3) When a user puts a system together, it consists of a pipeline and a set of these external
resources, and an external configuration settings (usually a file, but could be a computed
Java Object, in general).
> 4) The framework runs; the external resources are created, some at initialization time
(for the pipeline component that is declaring it), some at getResource( parameter) time, for
parameterized resources (where, for instance you don't know the language until you get a CAS
with a document and determine it).
> 5) When the resource code starts running, it sees that it needs to read its configuration
parameters, so it gets the external settings object and reads whatever parameters it wants
to, using its unique key names.
> --------------
> Missing from this scenario is one of the things UIMA (but not uimaFIT) can offer as a
"feature" - the externalization into some metadata information about configuration parameters.
 Note that this could be added - the external resource could make use of the resourcMetaData
xml element to specify configuration parameter definitions.  The UIMA framework currently
ignores these, but other tooling could make use of this, if it seems desirable.
> Hoping that I've not overlooked some basic flaw,
> -Marshall
> On 10/19/2016 4:17 AM, Richard Eckart de Castilho wrote:
>> Hi Marshall,
>>> On 18.10.2016, at 23:28, Marshall Schor <msa@schor.com> wrote:
>>> Several Jiras talk about wanting external shared resources that can be
>>> configured using the standard UIMA configuration settings and parameters.
>>> For example: https://issues.apache.org/jira/browse/UIMA-2979.
>>> Currently, there is one UIMA external resource descriptor that supports this,
>>> which is the configurableDataResourceSpecifier.  It has a resourceMetaData
>>> sub-element, which, in turn, has the configurationParameters and
>>> configurationParameterSettings elements.
>>> There is an alternate, simpler approach to configuring external resources, now
>>> available (as of UIMA 2.9.0) - using direct access to the External Configuration
>>> parameters.  See section in the UIMA Reference book.  The idea is that
>>> each External Resource would define its own set of key-value parameter settings,
>>> and retrieve them at run time.
>> Could you comment how to realize the scenarios illustrated in [1] could be implemented
>> using the External Configuration parameters? The point in these scenarios is
>> having complex (potentially nested) objects that are composed and used to customize
>> the behavior of one or more components. The objects take parameters and contain logic.
>> Best,
>> -- Richard
>> [1] https://issues.apache.org/jira/browse/UIMA-2903?focusedCommentId=13708539&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13708539

View raw message