Mailing-List: contact user-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@uima.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Richard Eckart de Castilho <eckart@ukp.informatik.tu-darmstadt.de>
To: "<user@uima.apache.org>" <user@uima.apache.org>
Subject: Re: Calling an annotator from another annotator
Thread-Topic: Calling an annotator from another annotator
Thread-Index: Ac1FQ+Kd9TEGkoP8TIqqTVe0UEgbLf//63UA
Date: Fri, 8 Jun 2012 07:43:22 +0000
Message-ID: 
 <FF2A0B5A-C2EE-4288-A32C-4D8854131198@ukp.informatik.tu-darmstadt.de>
References: <A734E21E566ADB40A70F2EBC5D3C2EB09B19E0@SWMMBX12.bk.bka.bund.de>
In-Reply-To: <A734E21E566ADB40A70F2EBC5D3C2EB09B19E0@SWMMBX12.bk.bka.bund.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <A30826E36D878B439FDE3A186D61246B@ukp.informatik.tu-darmstadt.de>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Am 08.06.2012 um 08:56 schrieb <Armin.Wegner@bka.bund.de>:

> Hi,
>=20
> I like to call an annotator from another annotator as it uses annotatatio=
ns for which annotators already exist. Calling is not a problem, but settin=
g the parameter is. Can this be done at all? How? Using uimaFIT the paramet=
er values are injected using the AnalysisEngineFactory.createPrimitive(). D=
oing so the parameters are set in the UIMA context of the outer annotator. =
The inner annotator has its own UIMA context, does it? How can the outer an=
notator's context be accessed while creating the inner annotator? At first =
I thought that this could be done the same way as Philip Ogren has done wit=
h XWriterFileNamer and XWriter. You just set the parameters for your XWrite=
rFileNamer implmentation in the XWriter context. But this seems to be a lit=
tle different as I don't instantiate a CasAnnototar_ImplBase object but cre=
ate an annotator description which is than use to instantiate an AnalysisEn=
gine object by AnalysisEngineFactory in uimaFit or UIMAFramework in UIMA it=
self. Do you have any suggestions? Or is it just me, not getting to underst=
and the UIMA way again?

If I understand you correctly, you want to create an OuterAE to which you p=
ass parameters. The OuterAE should use some of these parameters itself and =
forward the rest to an InnerAE that it creates. To accomplish that, you wou=
ld like the InnerAE to access the same UIMAContext object as the OuterAE.

I think it's not possible or wise to have two AEs access the same UIMAConte=
xt object. But it is possible to forward parameters - NOT recommened for va=
rious reasons (read on). I tried to hack something together here that shoul=
d work (untested):

	public static class OuterAnnotator extends CasAnnotator_ImplBase
	{
		@Override
		public void initialize(UimaContext context) throws ResourceInitialization=
Exception {
			super.initialize(context);
		=09
			// Copy all parameters into an array which can be passed as the variadic=
 parameter list
			// to createPrimitiveDesription
			List<Object> parameters =3D new ArrayList<Object>();
			for (String name : context.getConfigParameterNames()) {
				parameters.add(name);
				parameters.add(context.getConfigParameterValue(name));
			}
		=09
			// Create a new AE which has access to all the parameters set on the out=
er AE
			AnalysisEngineDescription aed =3D createPrimitiveDescription(InnerAnnota=
tor.class,=20
					parameters.toArray(new Object[parameters.size()]));
		}
	=09
		@Override
		public void process(CAS aCAS) throws AnalysisEngineProcessException {
			//...
		}
	}

I would like to point out though, that you are going to run into problems w=
ith this approach, because in general there is no way to properly separate =
parameters that go to the inner and to the outer AE. Well, you could introd=
uce a prefix and only parameters having that prefix are passed to the inner=
 AE, but what if your InnerAE has another InnerInnerAE...?=20

The ConceptMapperAnnotator in the UIMA sandbox accepts the path of an Analy=
sisEngineDescriptor for a tokenizer as a parameter and then instantiates th=
is, but it doesn't set any additional parameters. So when one sets up the p=
ipeline, one can create a AnalysisEngineDescription for the tokenizer, seri=
alize it as XML to a temporary file using the toXml() method and then pass =
that file to the ConceptMapperAnnotator. In that way, the ConceptMapperAnno=
tator does not have to know anything about how to pass on parameters to the=
 tokenizer and avoids any potential parameter name clashes.

At the moment, uimaFIT doesn't have explicit support for injecting Analysis=
EngineDescriptors directly as parameters. One could imagine something like =
this:

	createPrimitiveDescriptor(OuterAE.class,
                OuterAE.PARAM_NAME, "outer",
		OuterAE.PARAM_INNER_AE, createPrimitiveDescriptor(InnerAE.class,=20
			PARAM_NAME, "inner");

We do something like that already for external resources. I think it would =
make sense to add it for analysis engines as well. In that example above, y=
ou
can also see the that there could easily be a parameter name clash between =
the parameters of the inner and outer AE. Philip liked to work around that =
by prepending the full class name to each parameter name, but that approach=
 fails if OuterAE and InnerAE are actually two components of the same class=
 with different configurations, e.g. some generic filtering AE.

As long as uimaFIT doesn't support engine injection, I'd suggest you work w=
ith a temporary descriptor file that you generate with uimaFIT and pass to =
your OuterAE.=20

- use AnalysisEngineFactory.createPrimitiveDescription(...) to create the d=
escriptor for your inner AE
- call AnalysisEngineDescription.resolveImports(UIMAFramework.newDefaultRes=
ourceManager()) once on the descriptor to resolve it
- persist the generated descriptor to a temporary file using AnalysisEngine=
Description.toXML()
- pass the path to that file as InnerAEDescriptorPath to OuterAE

File.createTempFile() and File.deleteOnExit() are very helpful here.

-- Richard

--=20
-------------------------------------------------------------------=20
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD)=20
FB 20 Computer Science Department     =20
Technische Universit=E4t Darmstadt=20
Hochschulstr. 10, D-64289 Darmstadt, Germany=20
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckart@ukp.informatik.tu-darmstadt.de=20
www.ukp.tu-darmstadt.de=20
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------=20