You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by "Osborne, John D" <jo...@uabmc.edu> on 2018/05/29 17:33:54 UTC

Runtime Parameters to Annotators Running as Services

What is the best practice for passing runtime meta-data about the analysis to individual annotators when running UIMA-AS or UIMA-DUCC services? An example would be  a database identifier for an analysis of many documents. I can't pass this in as parameters to the aggregate analysis engine running as a service, because I don't know what that identifier is until runtime (when the application calls the service).

I used to put such information in the JCas, having the CollectionReader implementation do all this work. But I am striving to have a more lightweight CollectionReader... The application can obviously write metadata to a database or other shared resource, but then it becomes incumbent on the AnalysisEngine to access that shared resources over the network (slow).

Any advice appreciated,

 -John

Re: [External Sender] Re: Runtime Parameters to Annotators Running as Services

Posted by Eddie Epstein <ea...@gmail.com>.
From the original description I understand the scenario to be that the
service needs to access a database that is unknown at service
initialization time. Then the CAS received by the service must include a
handle to the database. The CAS would be generated by the client, which
sounds like in your case to include a collection reader. If the client is a
UIMA aggregate and the remote service is one of the delegates then any
annotator between the CR and the remote delegate could add content to the
CAS.

Sorry if I am missing something here.
Eddie

On Fri, Jun 1, 2018 at 9:39 AM, Osborne, John D <jo...@uabmc.edu> wrote:

> Thanks - when you say having the client putting the data in the CAS do you
> mean:
>
> 1) Putting in the CollectionReader which the client is instantiating
> 2) Some other mechanism of putting data into the CAS I am not aware of
>
> I had been using 1), but in the processing of refactoring my
> CollectionReader I was trying to slim it down and just have it pass
> document identifiers to the aggregate analysis engine. I'm fuzzy on whether
> 2) is an option and if so how to implement.
>
>  -John
>
>
> ________________________________________
> From: Eddie Epstein [eaepstein@gmail.com]
> Sent: Thursday, May 31, 2018 4:25 PM
> To: user@uima.apache.org
> Subject: [External Sender] Re: Runtime Parameters to Annotators Running as
> Services
>
> I may not understand the scenario.
>
> For meta-data that would modify the behavior of the analysis, for example
> changing what analysis is run for a  CAS, putting it into the CAS itself is
> definitely recommended.
>
> The example above is for the UIMA service to access the artifact itself
> from a remote source (presumably because it is even less efficient for the
> remote client to put the data into the CAS). That is certainly recommended
> for high scale out of analysis services, assuming that the remote source
> can handle the load and not become a worse bottleneck than just having the
> client put the data into the CAS.
>
> Regards,
> Eddie
>
> On Tue, May 29, 2018 at 1:33 PM, Osborne, John D <jo...@uabmc.edu>
> wrote:
>
> > What is the best practice for passing runtime meta-data about the
> analysis
> > to individual annotators when running UIMA-AS or UIMA-DUCC services? An
> > example would be  a database identifier for an analysis of many
> documents.
> > I can't pass this in as parameters to the aggregate analysis engine
> running
> > as a service, because I don't know what that identifier is until runtime
> > (when the application calls the service).
> >
> > I used to put such information in the JCas, having the CollectionReader
> > implementation do all this work. But I am striving to have a more
> > lightweight CollectionReader... The application can obviously write
> > metadata to a database or other shared resource, but then it becomes
> > incumbent on the AnalysisEngine to access that shared resources over the
> > network (slow).
> >
> > Any advice appreciated,
> >
> >  -John
> >
>

RE: [External Sender] Re: Runtime Parameters to Annotators Running as Services

Posted by "Osborne, John D" <jo...@uabmc.edu>.
Thanks - when you say having the client putting the data in the CAS do you mean:

1) Putting in the CollectionReader which the client is instantiating
2) Some other mechanism of putting data into the CAS I am not aware of

I had been using 1), but in the processing of refactoring my CollectionReader I was trying to slim it down and just have it pass document identifiers to the aggregate analysis engine. I'm fuzzy on whether 2) is an option and if so how to implement.

 -John


________________________________________
From: Eddie Epstein [eaepstein@gmail.com]
Sent: Thursday, May 31, 2018 4:25 PM
To: user@uima.apache.org
Subject: [External Sender] Re: Runtime Parameters to Annotators Running as Services

I may not understand the scenario.

For meta-data that would modify the behavior of the analysis, for example
changing what analysis is run for a  CAS, putting it into the CAS itself is
definitely recommended.

The example above is for the UIMA service to access the artifact itself
from a remote source (presumably because it is even less efficient for the
remote client to put the data into the CAS). That is certainly recommended
for high scale out of analysis services, assuming that the remote source
can handle the load and not become a worse bottleneck than just having the
client put the data into the CAS.

Regards,
Eddie

On Tue, May 29, 2018 at 1:33 PM, Osborne, John D <jo...@uabmc.edu> wrote:

> What is the best practice for passing runtime meta-data about the analysis
> to individual annotators when running UIMA-AS or UIMA-DUCC services? An
> example would be  a database identifier for an analysis of many documents.
> I can't pass this in as parameters to the aggregate analysis engine running
> as a service, because I don't know what that identifier is until runtime
> (when the application calls the service).
>
> I used to put such information in the JCas, having the CollectionReader
> implementation do all this work. But I am striving to have a more
> lightweight CollectionReader... The application can obviously write
> metadata to a database or other shared resource, but then it becomes
> incumbent on the AnalysisEngine to access that shared resources over the
> network (slow).
>
> Any advice appreciated,
>
>  -John
>

Re: Runtime Parameters to Annotators Running as Services

Posted by Eddie Epstein <ea...@gmail.com>.
I may not understand the scenario.

For meta-data that would modify the behavior of the analysis, for example
changing what analysis is run for a  CAS, putting it into the CAS itself is
definitely recommended.

The example above is for the UIMA service to access the artifact itself
from a remote source (presumably because it is even less efficient for the
remote client to put the data into the CAS). That is certainly recommended
for high scale out of analysis services, assuming that the remote source
can handle the load and not become a worse bottleneck than just having the
client put the data into the CAS.

Regards,
Eddie

On Tue, May 29, 2018 at 1:33 PM, Osborne, John D <jo...@uabmc.edu> wrote:

> What is the best practice for passing runtime meta-data about the analysis
> to individual annotators when running UIMA-AS or UIMA-DUCC services? An
> example would be  a database identifier for an analysis of many documents.
> I can't pass this in as parameters to the aggregate analysis engine running
> as a service, because I don't know what that identifier is until runtime
> (when the application calls the service).
>
> I used to put such information in the JCas, having the CollectionReader
> implementation do all this work. But I am striving to have a more
> lightweight CollectionReader... The application can obviously write
> metadata to a database or other shared resource, but then it becomes
> incumbent on the AnalysisEngine to access that shared resources over the
> network (slow).
>
> Any advice appreciated,
>
>  -John
>