Re: capabilityLangugaeFlow - computeResultSpec
Marshall Schor <
msa@...>
2008-02-01 14:49:17 GMT
LeHouillier, Frank D. wrote:
> While making this change wouldn't affect us in any way as I can see now,
> it would still be possible to use the Features in the Result Spec in a
> similar way.
>
> Suppose you have an information extraction component that extracts
> entities with attributes and you want to control which attributes are
> actually being added to the CAS with the Result Spec. You might have
> type Person, with a range of features such as Address, Phone number,
> Age, etc. some of which you want to output in a given configuration and
> others not. Suppose the information extraction component also extracts
> attributes which are so useless that you don't include them as features
> in the type system at all such as an internal id number. Currently,
> with a compiled Result Spec you could have the annotator look up the
> feature on the basis of the name of the feature and then you could
> reliably instantiate the feature without further ado. After your
> change, the feature would have to be checked to see if it actually
> exists.
>
We added code in the actual change that now checks to see if the feature
actually exists (for a "compiled" Result Spec). I thought it was better
to preserve the status quo here, rather than remove this check (for
performance reasons). It didn't seem like it would have any measurable
performance impact - it's one hash table lookup, basically.
Cheers. -Marshall
> Again, this doesn't seem like it is that big a deal to me but I thought
> I might just point out that it might have a use case. In practice, it
> seems to me that most annotators figure out the features available
> either during compilation by using the JCas or during the initialization
(Continue reading)
RSS Feed