[
https://issues.apache.org/jira/browse/UIMA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708539#comment-13708539
]
Richard Eckart de Castilho commented on UIMA-2903:
--------------------------------------------------
Reducing the definition of an external resource to the minimal, it remains
"External Resources are Java objects that have a life cycle." What is more
interesting is, that these objects are also parametrizable.
On the abstract level, we use external resources to model the strategy pattern.
Strategies can be of various kinds: feature extraction strategies in a machine
learning context, ranking strategies in a IR context, data access, etc.
The problem in using the strategy pattern is the scoping of parameters. As long
as these strategies are not parametrizable, it would be easy just to pass a
class name as a parameter to an UIMA component, instantiate the class
internally and use it. If a strategy has configuration parameters, how do they
get into the strategy instance? In particular, if multiple strategies using the
same implementation but different parameters, how can this be handled? ClearTK
uses the classname-based approach. Parameters destined for the strategy use the
full classname of the strategy implementation as prefix, are set on the AE, and
then are internally forwarded to the strategy.
Using external resources is much more convenient though. They allow parameters
to be neatly scoped to a single resource instance. Consider the following
illustrative uimaFIT code snippet:
{code}
createPrimitiveDescription(
Learner.class,
Learner.PARAM_FEATURE_EXTRACTOR,
createResourceDescription(
NGramFeatureExtractor.class,
NGramFeatureExtractor.PARAM_NGRAM_SIZE, 3));
{code}
This is a minimal example. However, it can be seen here, that the parameter
PARAM_NGRAM_SIZE is set directly on the NGramFeatureExtractor strategy, not on
the AE. It is properly scoped.
Recent versions of uimaFIT elaborate on this idea, e.g. by providing the
ability to pass multiple strategies, like:
{code}
createPrimitiveDescription(
Learner.class,
Learner.PARAM_FEATURE_EXTRACTOR, asList(
createResourceDescription(
NGramFeatureExtractor.class,
NGramFeatureExtractor.PARAM_NGRAM_SIZE, 3),
createResourceDescription(
RightContextExtractor.class,
RightContextExtractor.PARAM_CONTEXT_SIZE, 5),
createResourceDescription(
RightContextExtractor.class,
RightContextExtractor.PARAM_CONTEXT_SIZE, 5)));
{code}
Also, resources can be used by other resources, e.g.:
{code}
createPrimitiveDescription(
Learner.class,
Learner.PARAM_FEATURE_EXTRACTOR, asList(
createResourceDescription(
DictionaryLookupExtractor.class,
DictionaryLookupExtractor.PARAM_DICTIONARY,
createResourceDescription(
DatabaseDictionary.class,
DatabaseDictionary.PARAM_URL, "jdbc:..."
...))));
{code}
In the latter example, the DictionaryLookupExtractor "fetches" the
DatabaseDictionary with which it was configured.
To realize all of this, uimaFIT uses UIMA's external resources declarations and
bindings mechanism. However, the examples given here are pushing the current
implementation of UIMA quite a bit. A few but strategic points, uimaFIT needs
to go beyond what plain UIMA provides. The most critical of these points is the
initialization of external resources, which currently require uimaFIT to access
a private field of the ResourceManagerImpl in order to query all known resource
bindings.
> List resources in a ResourceManager / remove hack in uimaFIT
> ------------------------------------------------------------
>
> Key: UIMA-2903
> URL: https://issues.apache.org/jira/browse/UIMA-2903
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework, uimaFIT
> Reporter: Richard Eckart de Castilho
>
> uimaFIT currently gets a list of resources that are registered with a
> ResourceManager. This is handled via accessing the "mResourceMap" field of
> the ResourceManager_impl class via reflection. Obviously, this is not a good
> solution.
> uimaFIT iterates over the resources in the context while initializing
> resources that are referenced form other external resources.
> There may be two options:
> # add a listResources() method to the ResourceManager interface
> # get the resources that need to be initialized in some other way. I don't
> know if there is one, because if there was, I'd probably have used it.
> Looking at the @ExternalResource annotations doesn't help, because they do
> not give informations about the resource bindings. The bindings are only
> available in the ResourceManager, which takes us back to 1).
> Would it be possible to add a method allowing to list the resource bindings
> registered in a ResourceManager to the ResourceManager interface?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
