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). -Marshall 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 <[email protected]> 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 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 <[email protected]> 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 2.4.3.5 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 >>> >>> >
