Very possible that results specification doesn't work correctly
through the JNI. Nobody has ever used them in C++ since I've been
working with it.
Eddie
On Wed, Jan 23, 2008 at 4:02 PM, Marshall Schor [EMAIL PROTECTED] wrote:
Eddie - this is for you to check I think:
There is code in
, January 25, 2008 3:57 PM
To: uima-dev@incubator.apache.org
Subject: Re: capabilityLangugaeFlow - computeResultSpec
LeHouillier, Frank D. wrote:
We have an annotator that wraps a black box information extraction
component that can return objects of a variety of types. We check the
result
Marshall Schor wrote:
I think my change is ready for code review. I kept all the
idiosyncratic behavior of the old code, so users should not notice any
difference. All the tests run, and test case above runs at the 6000ms
range.
There are 3 areas changed:
1) ResultSpecification_impl is
Marshall Schor wrote:
The Capability Language Flow for an aggregate is computed in
CapabilityLanguageFlowController.computeFlowTable.
This starts with the aggregates output capabilities, and figures out a
flow for each language, that produces all the outputs.
Should this computation also
Marshall Schor wrote:
Can I replace the class CapabilityContainer with the much more
efficient (now) ResultSpecification class?
It seems to me they do the almost same thing, and the
ResultSpecification may be handling the corner cases better.
Is there some subtle difference I'm missing? It
I may have missed something - I don't see what would need to be added to
the ResultSpecification class. The method hasOutputTypeOrFeature(...)
is always called with doFuzzySearch== true, which is how the
containsType or containsFeature methods operate (always) in the Result
Specification
I went back and checked the Javadocs for the ResultSpecification, prior
to my reworking of it. I think I treated the x-unspecified slightly
wrong, and if I had done it right, then the anomaly noted in the
previous note (below) would not be there.
The previous Javadocs all say that the
Yes, that is correct!
- Michael
Marshall Schor wrote:
While experimenting with this approach, I found some tests wouldn't
run. (By the way, the test cases are great - they have been a great
help :-) ).
Here's a case I'm want to be sure I understand:
Let's suppose that the aggregate says
While experimenting with this approach, I found some tests wouldn't
run. (By the way, the test cases are great - they have been a great
help :-) ).
Here's a case I'm want to be sure I understand:
Let's suppose that the aggregate says it produces type Foo with language
x-unspecified.
Let's
Can I replace the class CapabilityContainer with the much more efficient
(now) ResultSpecification class?
It seems to me they do the almost same thing, and the
ResultSpecification may be handling the corner cases better.
Is there some subtle difference I'm missing? It would be nice to
The code which checks if a type or feature is in a result spec, for a
particular language, always includes generalizing the language specifier
by dropping the part beyond the first -. For example, en-us and
en-uk are simplified to en. Because of this, I'm thinking of
shrinking the result
engines too.
-Original Message-
From: Marshall Schor [mailto:[EMAIL PROTECTED]
Sent: Friday, January 25, 2008 5:06 AM
To: uima-dev@incubator.apache.org
Subject: Re: capabilityLangugaeFlow - computeResultSpec
The implementation for checking if a feature is in the result spec does
The implementation for checking if a feature is in the result spec does
the following:
If the result-spec is not compiled, it says the feature is present if
it specifically put in, or if its type has the allAnnotatorFeatures flag
set.
If the result-spec is compiled, it says the feature is
: Re: capabilityLangugaeFlow - computeResultSpec
The implementation for checking if a feature is in the result spec does
the following:
If the result-spec is not compiled, it says the feature is present if
it specifically put in, or if its type has the allAnnotatorFeatures flag
set
Michael Baessler wrote:
Michael Baessler wrote:
Adam Lally wrote:
On Jan 7, 2008 6:56 AM, Michael Baessler [EMAIL PROTECTED]
wrote:
I tried to figure out how the ResultSpecification handling in
uima-core
works with all side effects to check how it can be done
to detect when a ResultSpec
Adam Lally wrote:
On Jan 24, 2008 9:51 AM, Michael Baessler [EMAIL PROTECTED] wrote:
Without looking at the code, I didn't understand why this is a
consequence of the behavior you described above. I thought you said
and if the type has subtypes, it adds those too? Anyway, I
definitely
Without actually testing this (so this may be a wrong conclusion) - it
seems to me that the code in CapabilityLanguageFlowController that sets
up the result specs for components, by language, in the mFlowTable,
ignores the typesOrFeatures that the result spec adds when compile() is
called.
Marshall Schor wrote:
Without actually testing this (so this may be a wrong conclusion) - it
seems to me that the code in CapabilityLanguageFlowController that
sets up the result specs for components, by language, in the
mFlowTable, ignores the typesOrFeatures that the result spec adds when
What about allAnnotatorFeatures? Supposed the aggregate says it needs a
particular Feature of a particular type. Suppose a delegate is marked
as producing that type, and has allAnnotatorFeatures marked. This
wouldn't work.
You could say in this case that the output capability of the
From this point of view..
+1 to deprecate allAnnotatoreFeatures
-- Michael
Marshall Schor wrote:
What about allAnnotatorFeatures? Supposed the aggregate says it needs
a particular Feature of a particular type. Suppose a delegate is
marked as producing that type, and has
On Jan 24, 2008 7:54 AM, Marshall Schor [EMAIL PROTECTED] wrote:
If you recall, the compile method for results specifications augments
the set of types/features by doing 2 things: if the type has
allAnnotatorFeatures=true, it adds all the features of the type; and if
the type has subtypes, it
Adam Lally wrote:
On Jan 24, 2008 7:54 AM, Marshall Schor [EMAIL PROTECTED] wrote:
If you recall, the compile method for results specifications augments
the set of types/features by doing 2 things: if the type has
allAnnotatorFeatures=true, it adds all the features of the type; and if
the
The thing that adds allAnnotatorFeatures and subtypes is compiling the
result spec. The builder of the mFlowTable doesn't compile the
resultspec before using it - so it doesn't have these consequences.
-Marshall
Adam Lally wrote:
On Jan 24, 2008 7:54 AM, Marshall Schor [EMAIL PROTECTED]
On Jan 24, 2008 9:51 AM, Michael Baessler [EMAIL PROTECTED] wrote:
Without looking at the code, I didn't understand why this is a
consequence of the behavior you described above. I thought you said
and if the type has subtypes, it adds those too? Anyway, I
definitely think that this
In older UIMA versions the CapabilityLanguageFlowObject(List aNodeList,
ResultSpecification resultSpec) constructor was used when the result
was set by an application using the process method with the resultSpec
argument. In the current version it seems that only the version with the
Thanks. I'll see about comparing the older method with the current
method, to verify this. -Marshall
Michael Baessler wrote:
In older UIMA versions the CapabilityLanguageFlowObject(List
aNodeList, ResultSpecification resultSpec) constructor was used when
the result was set by an
Marshall Schor wrote:
In looking thru the code for ResultSpecification_Impl, it seems there
seems to be an inconsistency - unless I (quite possible :-) ) missed
something.
The calls to the containsType(...) method operate in one of 2 ways,
depending on whether or not the result
When looking at the tests for the capability language flow I see both
tests one with the result spec argument in the process() method and one
without.
In older UIMA versions, when using the debugger I see that both
constructors are used there.
-- Michael
Marshall Schor wrote:
Thanks. I'll
Marshall Schor wrote:
I'm thinking of simplifying the CapabilityContainer class. Right now
it has code to process input and well as output capabilities, but the
input ones appear never to be used. Can anyone confirm that? If
confirmed, I would propose to remove the part related to input
OK. This would confirm that the other constructor is no longer needed,
since the test that passes a result-spec arg in the process method no
longer calls that.
Thanks. -Marshall
Michael Baessler wrote:
When looking at the tests for the capability language flow I see both
tests one with the
Easy to see- just trace the test case... -Marshall
Michael Baessler wrote:
But it would still be interesting why this is never needed and how it
works now.
-- Michael
Marshall Schor wrote:
OK. This would confirm that the other constructor is no longer
needed, since the test that passes a
I did this trace. Here's how it works now, without calling this.
The process(cas, result-spec) call goes to AggregateAnalysisEngine_Impl
which calls setResultSpecification on the AEEngine_impl object, which
1) clones the result-spec object
2) adds capabilities to it from the *inputs* of all
OK, will do.
-- Michael
Marshall Schor wrote:
Easy to see- just trace the test case... -Marshall
Michael Baessler wrote:
But it would still be interesting why this is never needed and how it
works now.
-- Michael
Marshall Schor wrote:
OK. This would confirm that the other constructor is
Fine with me. Seems to be the way it works in the past, so we should not
change it!
-- Michael
Marshall Schor wrote:
Given that (as far as I can tell - let's see, that would be AFAICT),
the resultSpec is *always* used in compiled mode (because the wrapper
always compiles it), the current
Here's the trace of how this works, when run from a top level
process(cas) call:
1) the call goes to the AnalysisEngine_Impl process method, which calls
processAndOutputNewCASes in the same object. This calls the ASB_impl
process method, which creates a new AggregateCasIterator(aCAS). This
So in the older version of the capabilityLanguageFlow the inputs where
not recognized. But I think it is not bad that these are added
automatically since the flow can't work
if those are missing!
-- Michael
Marshall Schor wrote:
I did this trace. Here's how it works now, without calling
On Jan 23, 2008 8:06 AM, Michael Baessler [EMAIL PROTECTED] wrote:
In older UIMA versions the CapabilityLanguageFlowObject(List aNodeList,
ResultSpecification resultSpec) constructor was used when the result
was set by an application using the process method with the resultSpec
argument. In
Eddie - this is for you to check I think:
There is code in UimacppEngine in method serializeResultSpecification
which adds result spec types and features to 2 IntVector arrays (one for
Types, one for Features). As currently designed, these miss getting
the subtypes of types, and all the
I'll fix the Javadocs to correspond to what the code does. This will
have the result that
addResultFeature(1-feature, languages) will *add* to the existing
languages, while
addResultFeature(1-feature) will *replace* all existing languages
with x-unspecified.
-Marshall
Marshall Schor
Some corner cases.
Case 1: If using the method to alter an existing result spec by adding
a single type with an associated set of languages, the passed in
allAnnotatorFeatures boolean will now be unioned with any existing
setting of this. Javadocs updated to reflect this.
Case 2: If you
The class CapabilityLanguageFlowObject has 2 defined constructors, but
one is never used/referenced:
CapabilityLanguageFlowObject(List aNodeList, ResultSpecification resultSpec)
Can this be removed?
-Marshall
If this is removed or if it is never called, then there is a section of
the logic in CapabilityLanguageFlowObject which is never used, because
mNodeList == null:
if (mNodeList != null) {
// 80 or lines of code elided
}
Can this logic be removed?
-Marshall
Marshall Schor wrote:
The class
In looking thru the code for ResultSpecification_Impl, it seems there
seems to be an inconsistency - unless I (quite possible :-) ) missed
something.
The calls to the containsType(...) method operate in one of 2 ways,
depending on whether or not the result specification has been compiled
by
I'm thinking of simplifying the CapabilityContainer class. Right now it
has code to process input and well as output capabilities, but the input
ones appear never to be used. Can anyone confirm that? If confirmed, I
would propose to remove the part related to input capabilities.
There is a
Yes, I think so. This test dumps the result spec for each AE to a file
to check if it was computed correctly.
The computation of the result spec is done during the initialization of
the aggregate AE when the capability language flow is created.
The precomputed result spec can later be used in
I'm doing a redesign for the result spec area to improve performance.
The basic idea is to put a hasBeenChanged flag into the result spec
object, and use it being false to enable users to avoid recomputing
things.
Why not use equal ? because a single result spec object is shared
among
Michael -
I'm confused about how this test is setup. The test descriptor this
code uses loads an aggregate, and then runs a process method which ends
up calling some dummy process method called SequencerTestAnnotator.
This process method dumps (to a file) the result spec. Is that the case
Michael Baessler wrote:
Adam Lally wrote:
On Jan 7, 2008 6:56 AM, Michael Baessler [EMAIL PROTECTED]
wrote:
I tried to figure out how the ResultSpecification handling in uima-core
works with all side effects to check how it can be done
to detect when a ResultSpec has changed. Unfortunately I
Adam Lally wrote:
On Jan 7, 2008 6:56 AM, Michael Baessler [EMAIL PROTECTED] wrote:
I tried to figure out how the ResultSpecification handling in uima-core
works with all side effects to check how it can be done
to detect when a ResultSpec has changed. Unfortunately I was not able
to, there
Adam Lally wrote:
On Dec 18, 2007 8:55 AM, Michael Baessler [EMAIL PROTECTED] wrote:
Hi,
I got the request on my table that the computation of the result spec
for the capabilityLanguageFlow takes to much time.
I looked at the code and found something interesting... maybe I'm wrong,
I'm not
Hi,
I got the request on my table that the computation of the result spec
for the capabilityLanguageFlow takes to much time.
I looked at the code and found something interesting... maybe I'm wrong,
I'm not sure.
When looking at the ASB_impl.java at processUntilNextOutputCas() I found
the
On Dec 18, 2007 8:55 AM, Michael Baessler [EMAIL PROTECTED] wrote:
Hi,
I got the request on my table that the computation of the result spec
for the capabilityLanguageFlow takes to much time.
I looked at the code and found something interesting... maybe I'm wrong,
I'm not sure.
When looking
52 matches
Mail list logo
