headers
Duan, Nick | 1 Apr 04:19
Favicon

RE: User configuration params in CPE descriptor

In CPE component descriptors (AE, Collection Reader, and CASConsumer), one can specify user-defined
parameters in the <ConfigurationParameters/> and <ConfigurationParameterSettings/> elements.  Are
there similar tags in CPE descriptor?  What would be the API for retrieving the parameter values?  I am
trying to define some run-time parameters for the CPE.  It would be convenient to have the parameters in the
CPE descriptor.  Otherwise, I would have to define them in a property file, and that means more code to
maintain and more configurations for the end user...

Nick 

-----Original Message-----
From: Eddie Epstein [mailto:eaepstein@...] 
Sent: Tuesday, March 31, 2009 5:01 PM
To: uima-user@...
Subject: Re: User configuration params in CPE descriptor

I think this means having parameter overrides in a CPE descriptor,
and I'm pretty sure the answer is yes. Not supported by cpeGui.

Eddie

On Tue, Mar 31, 2009 at 3:13 PM, Jaroslaw Cwiklik <uimaee@...> wrote:
> Not sure I understand what it is you are trying to accomplish.
> Please provide more detail.
>
> JC
>
>
> Is there any way to specify a user-defined parameter in CPE descriptor
> (like what you can do in CPE components' descriptors)?
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jörn Kottmann | 1 Apr 10:17
Picon

Re: UIMA AS as OSGI bundle


On Mar 31, 2009, at 9:47 PM, Jaroslaw Cwiklik wrote:

> Jörn, not sure how I feel about this yet. What you are proposing is  
> to add a
> list of dependent jars into the
> manifest.mf files found in the Uima AS jars. There may be a problem  
> with
> this. ActiveMQ jars, for example,
> are named differently in each release.Some users (perhaps) may want to
> switch between say AMQ 5.2.2 and 4.1.1 and with a hard
> dependency in the manifest  there may be a runtime problem. How do you
> resolve such a problem?

In the OSGI manifest the Import-Package (or Required-Bundle) defines  
on what the bundle
depends, dependencies are then resolved by the OSGI runtime.
In our case it should be fine to define a dependency on
activemq 4.1.1 or higher, right ?

Jörn
Permalink | Reply | 1 comment |
headers
Adam Lally | 1 Apr 16:14
Picon
Gravatar

Re: User configuration params in CPE descriptor

On Tue, Mar 31, 2009 at 10:19 PM, Duan, Nick <Nick.Duan@...> wrote:
> In CPE component descriptors (AE, Collection Reader, and CASConsumer), one can specify user-defined
parameters in the <ConfigurationParameters/> and <ConfigurationParameterSettings/> elements.
 Are there similar tags in CPE descriptor?

Yes, there's a <configurationParameterSettings> tag that you can use
in the CPE descriptor to set parameter values for each of the CPE
components.  Documentation is here (see section 3.6.1.2):
http://incubator.apache.org/uima/downloads/releaseDocs/2.2.2-incubating/docs/html/references/references.html#ugr.ref.xml.cpe_descriptor.descriptor.cas_processors.individual

 >What would be the API for retrieving the parameter values?  I am
trying to define some run-time parameters for the CPE.  It would be
convenient to have the parameters in the CPE descriptor.  Otherwise, I
would have to define them in a property file, and that means more code
to maintain and more configurations for the end user...
>

I forget the exact API, but look at the Javadocs for CpeDescription.
The API structure should more or less be parallel with the XML format.

  -Adam
Permalink | Reply | 0 comments |
headers
Peter Klügl | 2 Apr 13:23
Picon

Problem accessing annotations in a window

Hello,

I have a problem accessing annotations, especially annotations of a 
given type in a window represented by another annotation. I am using 
type priorities but not in this concrete situation. Therefore i am not 
using the subiterator to access the contained annotations, but several 
other methods like this one:

public List<AnnotationFS> getAnnotationsInWindow(
        AnnotationFS windowAnnotation, Type type) {
    List<AnnotationFS> result = new ArrayList<AnnotationFS>();
    FSIterator completeIt = getCas().getAnnotationIndex().iterator();
    if (getDocumentAnnotation().getEnd() < windowAnnotation.getEnd()) {
        completeIt.moveToLast();
    } else {
        completeIt.moveTo(windowAnnotation);
    }
    while (completeIt.isValid()
        && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation
            .getBegin()) {
        completeIt.moveToPrevious();
    }

    if (completeIt.isValid()) {
        completeIt.moveToNext();
    } else {
        completeIt.moveToFirst();
    }

    while (completeIt.isValid()
(Continue reading)

Permalink | Reply | 4 comments |
headers
Thilo Goetz | 2 Apr 14:14
Picon
Picon

Re: Problem accessing annotations in a window

Hi Peter,

I see one issue with your code: you're using the windowAnnotation
to position the iterator.  Instead, you should be using an
annotation of the type you're searching for.  This is because
annotations are sorted by type as well.  If you don't specify
explicit type priorities, it doesn't mean that no type priority
will be used.  It just means that the type priority is arbitrary.
I think our documentation is misleading in this respect, I was
confused myself when I just read it.

The net effect of this is that you can't reliably position an
iterator where you're looking for annotations of type a with an
annotation of type b.  If you were just looking for annotations
of a specific type, you could change your code like this:

// Warning: untested
windowAnnotation = getCas().createAnnotation(type, windowAnnotation.getBegin(),
windowAnnotation.getEnd());

However, you also appear to be interested in annotations of subtypes
of your input type.  Those might be ordered differently again.

So what to do?

You can either use explicit type priorities (a PITA and not recommended),
or you use an annotation for iterator positioning that's guaranteed to
position the iterator in front of the first annotation you're interested
in.  For example, you could do this:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Klügl | 2 Apr 15:40
Picon

Re: Problem accessing annotations in a window

Hi Thilo,

first of all, thanks for the detailed answer.

I will try the approach with the increased end offset of the window, but 
I fear that this won't change the results (but should result in some 
speedup). I already added the additional code fragment in the methods in 
order to get the correct start position irrespective of the type order:

while (completeIt.isValid()
       && ((Annotation) completeIt.get()).getBegin() >= windowAnnotation
           .getBegin()) {
       completeIt.moveToPrevious();
   }

   if (completeIt.isValid()) {
       completeIt.moveToNext();
   } else {
       completeIt.moveToFirst();
   }

This should ignore all different orders of types in the index. Beside that, I also tried to use the same type
in the window annotation and even a new window with an explictly defined type priority resulting in a
(theoretically) correct starting position. But none of those methods returns always the correct list of
contained annotations. I must have made a mistake somewhere... for example see the example with the debug
information I added to my last mail. How can it be possible that an annotation is "disrespecting" the
begin/end indexing strategy? Is it possible that changing a feature value without
removeFromIndex/addToIndex can confuse the index in this way? I already started to make a guess.

I would love such an ignoreTypeOrder flag.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Klügl | 2 Apr 17:22
Picon

Re: Problem accessing annotations in a window

Hi Thilo,

>
> Hi Peter,
>
> yes, if you change the begin/end position of an annotation without
> removeFromIndex/addToIndex, that will invalidate the whole index.
> The index has no way of knowing that certain feature values changed,
> and so can't do automatic reordering of the index.  Indexes are
> kept sorted, so you can't modify members without telling the
> index about it.  This is a speed/convenience trade-off, and we
> opted for speed at the time...
>
> --Thilo
>
>   
I think I located my problem. I often programmatically change the features, but was extremely sure not to
touch the begin/end feature for the obvious indexing reasons you mentioned. After adding
removeFromIndex/addToIndex everywhere the results of the methods look correct and it should be quite
straight-forward to identify the real problem.

Thank you for your help!

Peter

>> I would love such an ignoreTypeOrder flag.
>>
>> I will try some things now and get back to you with the results.
>>
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Schor | 2 Apr 21:45

Re: UIMA AS as OSGI bundle


Jörn Kottmann wrote:
>
> On Mar 31, 2009, at 9:47 PM, Jaroslaw Cwiklik wrote:
>
>> Jörn, not sure how I feel about this yet. What you are proposing is
>> to add a
>> list of dependent jars into the
>> manifest.mf files found in the Uima AS jars. There may be a problem with
>> this. ActiveMQ jars, for example,
>> are named differently in each release.Some users (perhaps) may want to
>> switch between say AMQ 5.2.2 and 4.1.1 and with a hard
>> dependency in the manifest  there may be a runtime problem. How do you
>> resolve such a problem?
>
> In the OSGI manifest the Import-Package (or Required-Bundle) defines
> on what the bundle
> depends, dependencies are then resolved by the OSGI runtime.
> In our case it should be fine to define a dependency on
> activemq 4.1.1 or higher, right ?
In an ideal world, that would be true :-) .  In earlier testing, we had
discovered that higher level components sometimes did and sometimes did
not play nicely with other levels (when talking to each other over the
network, for instance).  

-Marshall
>
> Jörn
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane