Altogether sounds good to me, I'm interessted :-)
-- Michael
Michael Tanenblatt wrote:
>
> On May 13, 2008, at 2:31 AM, Michael Baessler wrote:
>
>> Michael Tanenblatt wrote:
>>> My comments inline, below:
>>>
>>> On May 10, 2008, at 2:56 AM, Michael Baessler wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> thanks for the detailed comparison. ConceptMapper seems to be very
>>>> interesting
>>>> but I have some additional questions. Please see my comments below:
>>>>
>>>> Michael Tanenblatt wrote:
>>>>> OK, good question. I have never used the project that is in the
>>>>> sandbox
>>>>> as ConceptMapper has been in development and production for a long
>>>>> time,
>>>>> so my comparisons are based solely on what I gleaned from the
>>>>> documentation. From this cursory knowledge of the DictionaryAnnotator
>>>>> that is already in the sandbox, I think that ConceptMapper provides
>>>>> significantly more functionality and customizability, while seemingly
>>>>> providing all of the functionality of the current DictionaryAnnotator.
>>>>> Here is a comparison, with the caveats claimed earlier regarding my
>>>>> level of familiarity with the current DictionaryAnnotator:
>>>>>
>>>>> Both annotators allow for the use of the same tokenizer in dictionary
>>>>> tokenization as is used in the processing pipeline, though in slightly
>>>>> different ways (descriptor vs. Pear file). ConceptMapper has no
>>>>> default
>>>>> tokenizer, though there is a simple one included in the package.
>>>>
>>>> I think having a default tokenizer is important for the "ease of use"
>>>> of the
>>>> dictionary component. If users just want to use a simple list of
>>>> words(multi words) for processing,
>>>> they don't want to setup a separate tokenizer to create the
>>>> dictionary. Can explain
>>>> more detailed what a user have to do to tokenize the content.
>>>
>>> I am not sure I agree with you on this point. Since the default setup
>>> for ConceptMapper is to tokenize the dictionary at load time, which is
>>> when the processing pipeline is set up, and since there will need to be
>>> a tokenizer in the pipeline for processing the the input text, I think
>>> that it is perfectly reasonable to require the specification of a
>>> tokenizer in the ConceptMapper AE descriptor for use as the tokenizer
>>> for the dictionary. This enforces the point that the same tokenizer be
>>> used for tokenizing the dictionary as the input data, which is actually
>>> something that I believe to be more than reasonable. In fact, I think it
>>> *should* be a requirement, otherwise entries that are in the dictionary
>>> might not be found, due to a tokenization mismatch.
>>>
>>> To simplify setup for naïve users, as I said, there is a simple
>>> tokenizer annotator included in the ConceptMapper package, and that
>>> could be used for both the dictionary and text processing. It breaks on
>>> whitespace, plus any other character specified in a parameter.
>>
>> It was not my intention to say that I disagree with the way how
>> ConceptMapper
>> does the tokenization of the dictionary content. I was not aware that
>> you use one of the tokenizers
>> of the processing pipeline. May I missed that in one of your previous
>> mails.
>>
>> The way ConceptMapper does the tokenization is fine with me.
>> Are there any special requirements to the tokenizer (multi threading,
>> resources ...)? I think you
>> create your own instance of the tokenizer during initialization of
>> ConceptMapper.
>
> The tokenizer is created using UIMAFramework.produceAnalysisEngine().
> The subsequent analysis engine is run against a dictionary entry's text
> using its process() method and the tokens created in the CAS as a result
> of this process are then collected and then the CAS is reset for the
> next entry to be processed.
>
>>
>>
>> Some tokenizers produce different results based on the document
>> language. Is there a setting
>> to specify the language that should be used to tokenize the dictionary
>> content?
>
> There is a AE descriptor parameter that is passed to
> setDocumentLanguage() for the tokenizer processing of the dictionary
> entries.
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> One clear difference is that there is no dictionary creator for
>>>>> ConceptMapper; instead, you must build the XML file by hand. This is
>>>>> due, in part, to the fact that dictionary entries can have arbitrary
>>>>> attributes associated with them. This leads to what I think is a
>>>>> serious
>>>>> advantage of ConceptMapper: these attributes associated with
>>>>> dictionary
>>>>> entries can be copied to the annotations that are created in
>>>>> response to
>>>>> a successful lookup. This is very useful for attaching a code from
>>>>> some
>>>>> coding scheme (e.g., from a medical lexicon or ontology) or a
>>>>> reference
>>>>> to a document in which the term was originally extracted, or any
>>>>> number
>>>>> of other features. There is no limit to the number of attributes
>>>>> attached to the dictionary entries, and the mapping from them to the
>>>>> resultant annotations is configurable in the AE descriptor.
>>>>
>>>> So if I understand you correct, the dictionary XML format is not
>>>> predefined. The XML tags
>>>> used to specify the dictionary content are related to the used UIMA
>>>> type system. How do you
>>>> check for errors in the dictionary definition?
>>>
>>> The predefined portion of the XML is:
>>>
>>> <token>
>>> <variant base="text string" />
>>> <variant base="text string2" />
>>> ...
>>> </token>
>>>
>>> which defines an entry with two variants. It is any additional
>>> attributes that you might want to add (POS tag, code, etc.) that is not
>>> predefined, but also not required. The only error checking would be that
>>> the SAX parser would throw an exception if the above structure is not
>>> intact.
>>>
>>>>
>>>>
>>>> The resulting annotations are specified in the AE descriptor. So I
>>>> think you have a mapping from
>>>> dictionary XML elements/features to UIMA types/features? Is there a
>>>> default mapping?
>>>>
>>>
>>> There is no default mapping. Any identifying attributes that you might
>>> want transfered to the resultant annotations can be put into the token
>>> element or the individual variant elements, but as I said, that is
>>> optional.
>> OK so when adding a feature "email" to the token as shown in the
>> example below, there have to be an
>> "email" feature (String valued) in the type system for the created
>> result annotation.
>>
>> <token email="[EMAIL PROTECTED]>
>> <variant base="John Doe" />
>> </token>
>
> Let's say you specify that the resultant annotations are going to be of
> the type "DictTerm", and each had a feature "EMailAddress". You could
> then specify the mapping from "email" to "EMailAddress" in the
> descriptor, and then when "John Doe" was found in the text, it would be
> annotated with a DictTerm with an "EMailAddress" of
> "[EMAIL PROTECTED]".
>
>
>
>>
>>>
>>>
>>>> Can the dictionaries also be language specific?
>>>
>>> Well, I am not sure what this means. If you mean: will ConceptMapper
>>> load different dictionaries depending on the language setting, then the
>>> answer is no. It currently allows only one dictionary resource to be
>>> specified, and it will be loaded if necessary. I would agree that this
>>> would be a nice feature to incorporate, though.
>>
>> I just want to know if the dictionary can have a language setting. In
>> some cases the dictionary
>> content is language specific and so I want to add a setting to the
>> dictionary that the content
>> should be used for English only.
>>
>> So your reply answers my question :-)
>
> Right, whichever dictionary you set as the DictionaryFile resource is
> the one that is used.
>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> ConceptMapper only has provisions for using one dictionary per
>>>>> instance,
>>>>> though this is probably a relatively simple thing to augment.
>>>>>
>>>>> ConceptMapper dictionaries are implemented as shared resources. It is
>>>>> not clear if this is the case for the DictionaryAnnotator in the
>>>>> sandbox. One could also create a new implementation of the
>>>>> DictionaryResource interface. This was done in the case of the
>>>>> CompiledDictionaryResource_impl, which operates on a dictionary
>>>>> that has
>>>>> been parsed and then serialized, to allow for quick loading.
>>>>
>>>> The DictionaryAnnotator cannot share dictionaries, since the
>>>> dictionaries are compiled
>>>> to internal data structures during initialization of the annotator.
>>>
>>> The same is true of ConceptMapper, so I am not sure how useful it is
>>> that it is an UIMA resource. Nevertheless, it is one, and other
>>> instantiations of ConceptMapper could attach to that resource, if
>>> needed.
>>>
>>>>
>>>>
>>>>>
>>>>> In addition to the ability to do case-normalized matching, which both
>>>>> provide, ConceptMapper provides a mechanism to use a stemmer, which is
>>>>> applied to both the dictionary and the input documents.
>>>>
>>>> Is the stemmer provided with the ConceptMapper package?
>>>> If not, how is it integrated?
>>>
>>> None is provided. To adapt one for use, it needs to adhere to a simple
>>> interface:
>>>
>>> public interface Stemmer {
>>> public String stem(String token);
>>> public void initialize(String dictionary) throws
>>> FileNotFoundException, ParseException;
>>> }
>>>
>>> The only method that has to do anything is stem(), which takes a string
>>> in and returns a string. Using this, it was quite simple to integrate
>>> the open source Snowball stemmer.
>>>
>>>
>>>>
>>>>>
>>>>> Both systems provide the ability to specify the particular type of
>>>>> annotation to consider in lookups (e.g., uima.tt.TokenAnnotation), as
>>>>> well as an optional feature within that annotation, with both
>>>>> defaulting
>>>>> to the covered text. ConceptMapper also allows an annotation type
>>>>> to be
>>>>> used to bound lookups (e.g. a sentence at a time, or an NP at a time,
>>>>> etc.). Perhaps this was an oversight on my part, but I did not see
>>>>> this
>>>>> in the existing sandbox annotator.
>>>> Sorry, I don't understand what do you mean by "ConceptMapper also
>>>> allows an
>>>> annotation type to be used to bound lookups". Can you give an example?
>>>
>>> What I mean is that ConceptMapper works span by span, and that span is
>>> specified in the descriptor. Typically, that span is a sentence, but
>>> could be an NP or even the whole document. Dictionary lookups are
>>> limited to tokens that appear within a single span--no crossing of span
>>> boundaries are allowed. Does this make sense?
>>
>> Yes, thanks!
>>
>>>
>>>>
>>>>>
>>>>> Token skipping is an option in both systems, though it is implemented
>>>>> differently. ConceptMapper includes has two methods available: the
>>>>> ability to use a stop-word list to handle the simple case of omitting
>>>>> tokens based in lexical equality, and feature-based include/exclude
>>>>> lists. The latter is not as general as I'd like in its implementation.
>>>>> Perhaps the filter conditions of the current DictionaryAnnotator is
>>>>> better.
>>>>>
>>>>> Finally, and again this may be due an oversight on my part in reading
>>>>> the documentation, it is not clear what the search strategy is for the
>>>>> current DictionaryAnnotator, but I would assume it finds
>>>>> non-overlapping
>>>>> longest matches. While ConceptMapper supports this as a default, there
>>>>> are three parameters in the AE descriptor to control the way the
>>>>> search
>>>>> is done.
>>>>
>>>> Right, you cannot configure the matching strategy for the
>>>> DictionaryAnnotator.
>>>> Currently the matching strategy is "first longest match" and no
>>>> "overlapping"
>>>> annotations are created. So you are right non-overlapping longest
>>>> matches.
>>>>
>>>>
>>>> Altogether, I see advantages for both system. I'm not sure if there is
>>>> a way to
>>>> create one Dictionary component with the advantages of both since some
>>>> of the
>>>> base concepts are different e.g. dictionary content object. But maybe
>>>> we can try :-)
>>>>
>>>> -- Michael
>>>
>>
>> -- Michael
>
