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 Uim
lto:[EMAIL PROTECTED]
Sent: Friday, 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 var
nks for your comments :-)
-Marshall
>
> -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 implementatio
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 restr
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 setters
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 it
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
Ok, I didn't follow that... so fine with me to do the change!
-- Michael
Marshall Schor wrote:
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 h
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 class
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
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 inc
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 include in the set of need
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
elimi
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 h
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 following:
If the result-spec is not
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 t
s analysis 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
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 i
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 resul
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 tha
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]> w
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
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 subtype
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 allAnnotatorFeatures
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 delegat
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
co
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.
If
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 y
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 wro
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 fea
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.
On Jan 23, 2008 10:07 AM, Marshall Schor <[EMAIL PROTECTED]> 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 implementation would have the effect that
>
> 1) th
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 this
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
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 impl
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
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 co
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 r
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 implementation would have the effect that
1) the allFeatures flag would work
2) subtypes of a type specified in the resul
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 result-spec arg in the process
method no longer calls that.
Thanks. -Marsha
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
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
cap
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 se
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 specification
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 application
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
precomput
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
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
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 C
The class CapabilityLanguageFlowObject has 2 defined constructors, but
one is never used/referenced:
CapabilityLanguageFlowObject(List aNodeList, ResultSpecification resultSpec)
Can this be removed?
-Marshall
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 mult
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 the
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
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
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 are to much ope
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
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
58 matches
Mail list logo