Showing posts with label Literature Informatics. Show all posts
Showing posts with label Literature Informatics. Show all posts

Tuesday, July 17, 2012

String Similarity

This post is my attempt at recording a very nice thread of posts on BioNLP.org's mailing list on string similarity measures. Harsha G at Molecular Connections asked about string similarity measures which prompted 

Tools recommended:

Papers:

Responses:

From Tudor Groza:

Dear Harsha,

I would suggest you have a look at Simmetrics [1] - it is a comprehensive
package for string similarities ranging from basic ones, like Levenshtein
distance to more advanced one, like Smith-Waterman or Needleman-Wunch. You
can find the Java API at [2] - for some reasons the original page is
missing, hence the only way to get to it is via the Web archive.

Hope that this helps.

[1] http://sourceforge.net/projects/simmetrics/
[2]
http://web.archive.org/web/20081225104938/http://www.dcs.shef.ac.uk/~sam/simmetrics/index.html

Kind regards,
Tudor

 

From Sampo Pyysalo:

Dear Harsha, all,

Not sure what your exact needs are, but I've found that in
approximate-matching lookup against many larger biomedical resources it's
good to do a fast, comparatively simple first-pass lookup before running
more advanced string comparison algorithms to avoid the computational costs
of full comparison for a large number of string pairs. I've found Naoaki
Okazaki's simstring (http://www.chokkan.org/software/simstring/) to be
excellent for this first task. The way I'd recommend to use this is to
first filter a large string collection to a reasonably-sized set of best
matches (in terms of a comparatively coarse similarity function like char
n-gram cosine) with simstring and then run more advanced stuff like
custom-cost edit distance for this smaller set.

There are a number of studies by Okazaki as well as Yoshimasa Tsuruoka and
others on the topic of string similarity metrics for domain tasks that may
also be of interest to you, e.g.
http://dx.doi.org/10.1093/bioinformatics/btm393

Cheers,

Sampo

From Florian Leitner:

Dear Harsha,

A good overview is the 2003 W. Cohen paper "promoting" the SoftTFIDF measure and with a very good overview of available similarity measures:

http://dc-pubs.dbs.uni-leipzig.de/files/Cohen2003Acomparisonofstringdistance.pdf

As for libraries to do string similarity matching, there are many, many options available. As they have not been mentioned so far, most prominently, there are the Regular Expression libraries.

-- REGEX
In terms of pure speed, some of Google's own searches are powered by re2 (developed by a Google search engineer), a deterministic RegEx ("DFA")  engine that is significantly faster than the "default" engines available in most other programming languages (because they are all are at least in parts non-deterministic, i.e., "NFAs"). However, due to the pure deterministic nature there is quite some default functionality missing (e.g., lookaheads and -behinds, etc.), so you have to define all variants you wish to match in your patterns (no approximate matches!), while it is blazingly fast:

http://code.google.com/p/re2/

In terms of pure approximate matching speed, don't forget that *nix offers a pretty powerful approximate string matching implementation right at your "fingertips":

http://www.tgries.de/agrep/

Last, another C implementation of a POSIX compliant approximate (DFA-based) regex matcher is TRE, although this is library is therefore somewhat slower than the RE2 engine, too:

http://laurikari.net/tre/

These three regex libraries are probably the most noteworthy if you need raw speed. Then there are a few Java regex libraries that seem noteworthy, too:

First, there is a non-determinisitc RegEx engine (FREJ) to do approximate matching, also in Java:

http://frej.sourceforge.net/

And yet another Java regex implementation, partially DFA and partially NFA, is the Brics Automaton:

http://www.brics.dk/automaton/

(there are much more Java regex libraries, but let Google be your best friend if you need even more pointers...)

-- DISTANCE
Apart from the regex/D- or NFA based implementations, there are distance-based measures to do approx. string matching. A very fast similarity search tool is SimString, an approximate matcher based on distance measures, and already mentioned by Sampo in his post, in C++:

http://www.chokkan.org/software/simstring/

Probably the most well-known package in this domain is the SecondString package from the CMU (from W. Cohen, the author cited above) for approx. string matching in Java, also based on edit distance measures:

http://secondstring.sourceforge.net/

Last I'd mention there is a simple Python module to calculate n-gram-based similarities; while I do love Python very much, alone due to that fact that this is Python-based, it will most likely be the slowest option listed here:

http://packages.python.org/ngram/index.html

Hope this helps to get you up to [matching] speed!

Cheers,
Florian

 From Aurélie Névéol:

Harsha,

Another measure to look into is the "PubMed distance" described in this paper:

Lu Z, Wilbur WJ. Improving accuracy for identifying related PubMed queries by an integrated approach. J Biomed Inform. 2009 Oct;42(5):831-8.

An example of use and evaluation can be found in this other paper:

Névéol A, Islamaj-Doğan R, Lu Z. Author Keywords in Biomedical Journal Articles. Proc AMIA Annu Symp. 2010:537-41.

Best regards,

Aurelie

From Bob Carpenter:

I'd suggest looking further than Jaccard distance in
the LingPipe matchers.  We have TF/IDF matchers based
on character n-grams that are widely used in practice (not
just by us or with our implementation;  note
that this is NOT the same as Cohen et al.'s soft TF/IDF,
which I've never fully understood).

There's also the Jaro-Winkler matchers, which are
tuned for matching single-word names.

LingPipe also has a dictionary-based matcher that will
spot approximate matches (by weighted edit distance) in
text using the Aho-Corasick algorithm for deterministic
matching and suffix arrays for speeding approximate matching.

And you can also use something like an HMM- or CRF-based
chunker to find matches in texts.  It basically then looks
like a named-entity problem.

If you want something fancier that should outperform any of
these methods, check out this paper by McCallum, Bellare and Pereira:


http://lingpipe-blog.com/2010/04/27/mccallum-bellare-and-pereira-2005-a-conditional-random-field-for-discriminatively-traied-finite-state-string-edit-distance/

I'm also quite keen on this method for string comparison
by Dreyer, Eisner and Smith, though I haven't tried it, either:

  http://aclweb.org/anthology-new/D/D08/D08-1113.pdf

And in the end, you may be wanting to do something like cluster
similar terms rather than just provide pairwise similarities.
Andrew McCallum and crew have done some great work on this problem,
and there's a huge swath of "deduplication" and "record linkage"
literature that's related.

Wednesday, May 7, 2008

AIM for Sales

In talking to Sales staff about our Alert Information Management (AIM) project, I've learned that Sales people in bioPharma are either on the road, in doctor's offices/hospitals or at home. It is basically a given that they shouldn't be using Blackberries or other mobile clients for reading news and information updates while driving for everyone's safety. It is also a given that they shouldn't be using wireless gadgets in hospitals due to potential interference issues and therefore patient safety. Therefore, staying up to date on new research regarding their drugs and disease areas is something Sales staff have to do at home. Of course, their management wants them out talking to doctors - not sitting at home catching up on the latest research even though bioPharmas all have staff devoted to delivering research updates to Sales staff.

It is public knowledge that I'm involved in a project using Newsgator's Enterprise Server (NGES) for our AIM project. It has a very nice concept of 'locations' for different delivery mechanisms. For example, we can collect news and alert streams of information from a variety of sources: RSS feeds, emails, website monitors, search alerts that all get converted to RSS for management and re-distribution. Re-distribution can be in a variety of flavors: RSS streams, aggregated RSS streams, website insertion as a portlet for RSS, email alerts, screensavers, ...

I was thinking that I really enjoy listening to podcasts in my car and catching up on news and learning from them which led to me thinking why don't we add a new 'location' for NGES such that RSS streams are converted to podcasts. Locations are RSS feed specific so a Salesperson could set up the 'podcast location' to only include the RSS feeds they need to follow in this manner. There are already several websites that provide RSS to podcast conversion such as YAKITome or Odiogo. With this, a Salesperson could stay up to date using the down time while driving by listening to these podcasts. All of this would be automated and not require any additional manual effort to deliver (i.e. no empire building by adding a group dedicated to reading the news or research reports).

Using the iPhone as the platform for this would provide high-quality mobile web access, an RSS reader, a phone and a podcast tool wrapped up in one device. One particular feature that I would love (and which is not possible with the Blackberry device I have to use) is the easy switch between listening to a podcast, taking a call and then going back to the podcast. This is key - because fumbling with multiple devices in a car is not a great idea.

Of course, it's obviously easy enough using the available 'RSS to podcast' tools to bolt onto the back end of our RSS management system. Either way, it's just another example of the flexibility of RSS for AIM.

Monday, April 14, 2008

Citation Matching to Pubmed

Matching citations to Pubmed is a challenge when the citation information is partially incorrect or presented differently. Some examples of this that are hard to avoid are author names with international characters (diacritical marks, umlauts, tilde, etc) and gene names that include greek characters that are represented in some places as greek symbols and others are alpha-expansions (e.g. tgf-β or tgf-beta). Another source of error is from the manual entry of citations.
Here is an algorithm to match citations based on partially incorrect citation information:

Algorithm:

Parameters:
  • Titletokens = all space delimited title words over 4 chars
  • Authors = last name of author
  1. Run a search in Pubmed of: (<Titletokens> OR'd together) AND (Authors OR'd together) AND (year OR vol OR firstpage)
  2. Retrieve Pubmed records
  3. Compare citation fields: Titletokens, Authors, year, vol, firstpage, journal name and keep the best matching Pubmed record

There are two ways to improve this citation matching:
  • Use the journal search feature in Pubmed to return ISSN numbers for the Journal name part of the citation record to compare against the Pubmed record OR use a fuzzy match algorithm between the often abbreviated journal name in the citation and the full journal name provided by Pubmed.
  • Use a Lucene-based search (or a similar search tool) using standard relevancy ranking of the citation's Titletokens, Authors, year, vol, firstpage, journal name against an field-based index of Medline. The top hit should be the correct citation assuming the relevancy ranking is high enough. One could take the top citation and then run a citation match on it (e.g. Algorithm Step 3) but that might be overkill. Of course, this would require keeping a Lucene index of Medline available and up to date for a citation matching service.

Most of the citations are due to mis-spellings (author names or title words) or incorrect citation information, but this is usually due to a field in the citation being incorrect rather than all of the fields in the citation. Of course, some of the incorrect matches or in some cases no matches being found are due to the citation not being in Medline.

Chart* presenting the bi-modal distribution of %Match (number of tokens matching between citation and Pubmed) vs Number of citations correctly matched to Pubmed records. A score above 70% Token matching between a citation record and a Pubmed record results in very few False Negatives and no False Positives.

Shows the bi-modal distribution of correct and incorrect citations based on citation token matches.

For more information on the datapoints in the chart above:

Percent Token MatchCorrectIncorrect
0-5% 0 111
6-10% 0 7
11-15% 0 43
16-20% 0 57
21-25% 0 54
26-30% 0 28
31-35% 1 5
36-40% 0 9
41-45% 1 3
46-50% 1 5
51-55% 1 5
56-60% 6 3
61-65% 15 1
66-70% 33 0
71-75% 85 0
76-80% 188 0
81-85% 261 0
86-90% 324 0
91-95% 132 0
96-100% 25 0
Totals1073 331

* Chart and Table results thanks to my colleague Lulu Chen who curated approximately 1000 proposed citation matches for this project.