Re: [DISCUSS] Result Specs, cap. lang. flow, was: Re: Default Result Specifications too complicated?

2007-06-21 Thread Marshall Schor
+1 Backwards compatibility is something we take seriously, and when a change is needed, we should provide transition time for our existing users. Results specifications seem to be good concept - and this approach gives us time to thoughtfully evolve it. -Marshall Thilo Goetz wrote: As email

[DISCUSS] Result Specs, cap. lang. flow, was: Re: Default Result Specifications too complicated?

2007-06-20 Thread Thilo Goetz
As email discussion on this subject was dragging on, and the time for our planned next release is fast approaching, the UIMA committers had a phone call to resolve this issue. Present were: Adam, Eddie, Marshall, Thilo (Michael is currently unavailable, back next week) We had a lively discussion

Re: Default Result Specifications too complicated?

2007-06-19 Thread Adam Lally
On 6/18/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: Adam Lally wrote: > It seems like there is a tradeoff here between supporting users > migrating from 1.4 to 2.2, versus supporting users migrating from 2.0 > or 2.1 to 2.2, is there not? But for 2.1 users it's easy, they just need to rename the

Re: Default Result Specifications too complicated?

2007-06-18 Thread Thilo Goetz
Adam Lally wrote: > On 6/18/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: >> If we need to go this route, we'd rather implement a custom flow. That >> seems the lesser evil. >> > > Can you do what you need using a flow controller? The core of this > problem is the that the FlowController interface

Re: Default Result Specifications too complicated?

2007-06-18 Thread Adam Lally
On 6/18/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: If we need to go this route, we'd rather implement a custom flow. That seems the lesser evil. Can you do what you need using a flow controller? The core of this problem is the that the FlowController interface does not allow the custom flow

Re: Default Result Specifications too complicated?

2007-06-18 Thread Thilo Goetz
Adam Lally wrote: > To update this thread: We've determined that the particular use case > we know about that was relying on this feature of the > capabilityLanguageFlow could be addressed by changing the annotator > code if necessary, to check for existence of Tokens in the CAS before > creating

Re: Default Result Specifications too complicated?

2007-06-15 Thread Adam Lally
To update this thread: We've determined that the particular use case we know about that was relying on this feature of the capabilityLanguageFlow could be addressed by changing the annotator code if necessary, to check for existence of Tokens in the CAS before creating additional Tokens. Of cour

Re: Default Result Specifications too complicated?

2007-06-12 Thread Adam Lally
On 6/12/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: no, this is not an option. So you vote against the option... that is fine, it doesn't mean it isn't an option *to consider*. We have users who use the capabilityLanguageFlow in 1.4 in ways that will break in 2.x. I don't want them to migrate

Re: Default Result Specifications too complicated?

2007-06-12 Thread Thilo Goetz
Hi Adam, Adam Lally wrote: > On 6/11/07, Michael Baessler <[EMAIL PROTECTED]> wrote: >> OK, for the next release I think we have to possibilities... >> >> 1) we implement the SimpleStepWithResultSpec function to fix the >> capabilityLanguageFlow as it was in UIMA 1.4. This allows UIMA 1.4 users >>

Re: Default Result Specifications too complicated?

2007-06-12 Thread Adam Lally
On 6/11/07, Michael Baessler <[EMAIL PROTECTED]> wrote: OK, for the next release I think we have to possibilities... 1) we implement the SimpleStepWithResultSpec function to fix the capabilityLanguageFlow as it was in UIMA 1.4. This allows UIMA 1.4 users that use the capabilityLanguageFlow to mi

Re: Default Result Specifications too complicated?

2007-06-11 Thread Michael Baessler
Adam Lally wrote: On 6/8/07, Michael Baessler <[EMAIL PROTECTED]> wrote: the old code is still in place that tries to set the result spec for the next node, but I think it has no effect. It is in CapabilityLanguageFlowObject.next() // check if current engine should be called if

Re: Default Result Specifications too complicated?

2007-06-08 Thread Adam Lally
On 6/8/07, Michael Baessler <[EMAIL PROTECTED]> wrote: the old code is still in place that tries to set the result spec for the next node, but I think it has no effect. It is in CapabilityLanguageFlowObject.next() // check if current engine should be called if (shouldEngineBeCal

Re: Default Result Specifications too complicated?

2007-06-08 Thread Michael Baessler
Adam Lally wrote: On 6/6/07, Michael Baessler <[EMAIL PROTECTED]> wrote: Here is a short example. Annotator 1 can do Tokens and Lemmas Annotator 2 can do Tokens and Sentences Application is interested in Tokens, Lemmas and Sentences. I guess the default result spec for Annotator 1 is Tokens and

Re: Default Result Specifications too complicated?

2007-06-07 Thread Adam Lally
On 6/6/07, Michael Baessler <[EMAIL PROTECTED]> wrote: Here is a short example. Annotator 1 can do Tokens and Lemmas Annotator 2 can do Tokens and Sentences Application is interested in Tokens, Lemmas and Sentences. I guess the default result spec for Annotator 1 is Tokens and Lemmas. The defaul

Re: Default Result Specifications too complicated?

2007-06-06 Thread Michael Baessler
Adam Lally wrote: On 4/18/07, Michael Baessler <[EMAIL PROTECTED]> wrote: OK, but can the FlowController manipulate the ResultSpec for an annotator before it is called? Or can the FlowController just decide the flow of the engines (if they are called, which order ...) If the FlowController does

Re: Default Result Specifications too complicated?

2007-04-18 Thread Adam Lally
On 4/18/07, Michael Baessler <[EMAIL PROTECTED]> wrote: OK, but can the FlowController manipulate the ResultSpec for an annotator before it is called? Or can the FlowController just decide the flow of the engines (if they are called, which order ...) If the FlowController does not manipulate the

Re: Default Result Specifications too complicated?

2007-04-18 Thread Michael Baessler
Adam Lally wrote: This changed in 2.0 with the introduction of the flow controller. The ResultSpec no longer has any dependence on the flow. The framework assumes the most general case of the custom flow controller. The effect is that an annotator's ResultSpec will include all of the input typ

Re: Default Result Specifications too complicated?

2007-04-17 Thread Adam Lally
On 4/17/07, Michael Baessler <[EMAIL PROTECTED]> wrote: Sorry, I currently don't understand what is going on here... you mentioned above how the default Result Spec is computed. But I think the Result Spec depends on the used aggregate flow, isn't it? So what flow is used in the sample above, th

Re: Default Result Specifications too complicated?

2007-04-17 Thread Michael Baessler
Adam Lally wrote: P.S. Here are the specific rules for the Result Spec (this is documented in the manual more or less in this form): The default Result Spec is automatically computed from the capabilities in the component descriptors, as follows: 1) The outermost aggregate's result spec is set

Re: Default Result Specifications too complicated?

2007-04-16 Thread Marshall Schor
Adam Lally wrote: I'm interested in getting others' opinions on this. I was recently helping some users who were having a problem where a 3rd-party annotator they were using wasn't producing annotations that they expected it to. The annotator was embedded in a nested aggregate. It took me a co

Default Result Specifications too complicated?

2007-04-16 Thread Adam Lally
I'm interested in getting others' opinions on this. I was recently helping some users who were having a problem where a 3rd-party annotator they were using wasn't producing annotations that they expected it to. The annotator was embedded in a nested aggregate. It took me a couple of hours to fi