On Mar 10, 2011, at 12:14 PM, Chris wrote: > Michael Tanenblatt <slothrop@...> writes: > >> >> I hope I get this right, as it's been a while since I've done this: >> >> Assume you have a token annotation that has a feature containing a POS tag >> as > a string value, and that feature >> is called "posTag". If you want to use that to limit your lookups, you would > set the parameter >> "TokenClassFeatureName" to "posTag" and then you would use the > "IncludedTokenClasses" parameter to >> list all of the values of that posTag feature that would indicate the token > should be included in the lookup >> (conversely, you could use the "ExcludedTokenClasses" to indicate those to > ignore during lookup). >> >> Specifying the POS tag in the dictionary is a way to override the tagger, > assuming your tagger doesn't >> overwrite existing tags, that's all. ConceptMapper does not handle POS tags >> in > any special way, they are >> just features, like any other feature. >> >> Does this make sense? >> >> On Mar 9, 2011, at 5:39 PM, Chris wrote: >> >>> The documentation for the ConceptMapper annotator discusses the possibility > of >>> limiting matches to specific parts of speech. If I understand correctly, >>> by >>> specifying a POS value in a ConceptMapper dictionary entry, I can filter >>> matches to just those tokens that have been tagged with the specified POS >>> value (as supplied, in my case, by running the OpenNLP POS Tagger before >>> ConceptMapper). In practice, however, specifying POS attribute values for > my >>> dictionary entries does not appear to have the desired effect. >>> >>> Am I misunderstanding what the POS attribute does in ConceptMapper? >>> Perhaps >>> it is meant only to use in the "write-back" capabilities of the annotator >>> to >>> populate/overwrite a POS attribute in a matched token instead of acting as >>> a >>> filter? >>> >>> Any help is appreciated in better understanding what role POS plays in the >>> execution of ConceptMapper. >>> >>> Thanks... >>> >> >> > That makes sense - thanks. I was hoping that it acted as an additional > matching > agent for variants - for example, being able to say that a match is only > valid > when the POS specified in the dictionary for a variant matched the > pre-populated > POS for the token annotation - but sounds like that was not how it was > intended > to be used. > > Thanks for the help. > > >
Well, it *is* open source--you could enhance it...
