uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: UIMA shared external resources with config parameters
Date Wed, 19 Oct 2016 18:10:50 GMT
1) Specifying "object A" to a component.  My thinking did not go beyond what is
done today for external shared resources.  UIMA provides an
ExternalResourceDescription as part of a component; this is eventually fed to
UIMA's "produceResource" methods to produce an instance of the resource.

So, I was thinking that you would specify "object A to a component" by just
including the external resource description as part of the component's metadata.

2) How to specify an "object B" as a parameter to "object A":
2a) Object A gets to define a key (or keys) for its parameters.  Let's say uses
"myObjB" as the key.
Object A gets to decide how to interpret the value for this key coming from the
external settings file.  (Not architected by UIMA).
2b) At a time chosen by Object A, when object A is "running", it reads the value
of the key "myObjB" from the external settings file, and then interprets this in
any way it chooses, and then uses that to define Object B (again, this would be
arbitrary, not architected by UIMA)

3) how to set non-String parameters?  Both the external settings and the normal
UIMA configuration parameter settings (I'm thinking of the XML descriptor)
represent these as strings.  So the number 1.0 is represented as the string
"1.0", and the code that gets configuration parameter settings is responsible
for type conversions, for instance, converting the string to the declared
configuration parameter type.

For accessing directly external settings, there is no architected place for
specifying the "type" of the parameter, other than the configuration
declarations (which could be used for simple UIMA types only);  the external
settings API returns just the string (or an array of strings, which is
supported) to the caller, and it's up to the caller to then do whatever
interpretation of this string value is desired (not architected by UIMA).

4) re: disambiguating parameters for multiple instances of a shared resource. 
UIMA today has the ability to have multiple instances of a shared resource, e.g.
a "dictionary" that is parameterized by "language";
multiple instances of these can be loaded.  The "get resource" api for this
includes specifying the parameter(s) to select the proper one, and each instance
that is created gets a initial "load" call whose argument can identify the instance.

So, (not architected by UIMA) the implementation could, for example, define a
set of "keys": e.g.
my_thesaurus_en, my_thesaurus_de, ...  for some parameters that are dependent on
a language code. 

Beyond this, External Resources doesn't support multiple instances, and I had
not considered extending this (as part of this discussion, which was about how
to read configuration parameters).

If you're thinking this is pretty minimal, I agree...  If something more
substantial is desired, this would take some more thinking, and, as you've
suggested, might even be to incorporate other mini-framework approaches (e.g.
from Spring).


On 10/19/2016 1:26 PM, Richard Eckart de Castilho wrote:
> 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 resource?
> Cheers,
> -- 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
>> 2) Key assumption:  These objects are to be UIMA Shared External Resources.  This
means that
>> 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,
>>>> 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
>>>> 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
>>> 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