Natural Language Processing for the Working Programmer
21–30 of 48 posts
Re: Natural Language Processing for the Working Programmer
#22I'm not that familiar with Haskell and the past week's HN frontpage articles on Monads was just confusing...but what is it about Haskell that makes it more useful for NLP than, say, Python?
Re: Natural Language Processing for the Working Programmer
#23I'm not that familiar with Haskell and the past week's HN frontpage articles on Monads was just confusing...but what is it about Haskell that makes it more useful for NLP than, say, Python?
Not much. It's a more expressive and cleaner language, but on the other hand python has NLTK + scipy community. Scala (or Java) is another great NLP language. It's got decent libraries (openNLP, mallet, mahout), hadoop, and Scala is almost as nice as Haskell.
Re: Natural Language Processing for the Working Programmer
#24I was working with NLP, and its various toolkits (python-nltk I'm looking at you). The thing about NLP is, there just isn't enough libraries (for humans) to simply plug NLP into use. Even nltk, the premier python library for NLP, seems to be an NLP core-library for building NLP solutions, rather than for building NLP-powered apps. It also seems to extremely unpythonic. Is there a missing link there? I don't know. So…
Re: Natural Language Processing for the Working Programmer
#25Earlier quoted context omitted.
I've used the Stanford NLP library extensively for NER. I made heavy use of it in my senior thesis project. It's pretty straightforward to use their library to read a document and output an XML file containing NER data (and lots of other fun stuff). For instance, from the sentence: > World War II, or the Second World War (often abbreviated as WWII or WW2), was a global military conflict lasting from 1939 to 1945, whi…
For those who want to play around with dynamic output: http://nlp.stanford.edu:8080/parser/ This is a bit more human friendly.
Re: Natural Language Processing for the Working Programmer
#26I was working with NLP, and its various toolkits (python-nltk I'm looking at you). The thing about NLP is, there just isn't enough libraries (for humans) to simply plug NLP into use. Even nltk, the premier python library for NLP, seems to be an NLP core-library for building NLP solutions, rather than for building NLP-powered apps. It also seems to extremely unpythonic. Is there a missing link there? I don't know. So…
NERILY appears to be closed source and only usable on a subscription pricing model. It appears to be similar to zemanta.com - unless I am mistaken and this is also available as a library?
Re: Natural Language Processing for the Working Programmer
#27Earlier quoted context omitted.
I've used the Stanford NLP library extensively for NER. I made heavy use of it in my senior thesis project. It's pretty straightforward to use their library to read a document and output an XML file containing NER data (and lots of other fun stuff). For instance, from the sentence: > World War II, or the Second World War (often abbreviated as WWII or WW2), was a global military conflict lasting from 1939 to 1945, whi…
I had experimented with NLTK, CoreNLP, OpenNLP etc and when it came it NEP extraction, I felt NLTK does the better job (none of them were anywhere close to perfect/dependable), but NLTK had a lot more dictionaries to choose from and overall better. We use a highly customized/overhauled NLTK for our apps Iris(siri for Android) and Friday for Android.
Re: Natural Language Processing for the Working Programmer
#28I'm not that familiar with Haskell and the past week's HN frontpage articles on Monads was just confusing...but what is it about Haskell that makes it more useful for NLP than, say, Python?
Not much. It's a more expressive and cleaner language, but on the other hand python has NLTK + scipy community. Scala (or Java) is another great NLP language. It's got decent libraries (openNLP, mallet, mahout), hadoop, and Scala is almost as nice as Haskell.
Haskell's mechanisms for defining parsers, lexers, and other pattern match tools is so good it probably passes over the line from "pretty" to "objectively better".
A lot of people who need to lex and parse data and then act on it turn to Haskell. It has some really remarkable and efficient libraries. And even for "common" target languages it's reasonable to write extremely fast parsers. With tuning, projects like Aeson are among some of the fastest JSON parsers and writers out there (only a few projects exceed its speed and resource efficiency in ANY runtime).
Re: Natural Language Processing for the Working Programmer
#29I was working with NLP, and its various toolkits (python-nltk I'm looking at you). The thing about NLP is, there just isn't enough libraries (for humans) to simply plug NLP into use. Even nltk, the premier python library for NLP, seems to be an NLP core-library for building NLP solutions, rather than for building NLP-powered apps. It also seems to extremely unpythonic. Is there a missing link there? I don't know. So…
While it's possible that some parts of NLTK may be unpythonic, I disagree that it's somehow inaccessible or hard to use. The NLTK project is fairly well-documented, and I've never had any difficulty using it. Also, all the NLTK code I've ever examined looks Pythonic to me, unlike the Java-style Python that I sometimes see coming out of academia; they follow PEP8 and have a developer style guide. There may be pockets…
Re: Natural Language Processing for the Working Programmer
#30So, the book is basically frozen. We hope to have more time in the future to continue the writing...