Live data from Hacker News

Natural Language Processing for the Working Programmer

nlpwp.org

21–30 of 48 posts

Re: Natural Language Processing for the Working Programmer

#22
post #11

I'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?

Parser Combinators are a great example of the advantages of functional programming for this sort of work.

Re: Natural Language Processing for the Working Programmer

#23
post #11

I'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.

By extension, Clojure can use those same java libraries

Re: Natural Language Processing for the Working Programmer

#24
post #2

I 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

#25
post #12

Earlier 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.

http://www.nerily.com/#demo -> Or this with a JSON API output.

Re: Natural Language Processing for the Working Programmer

#26
post #24
post #2

I 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?

It is indeed closed source and available as a NLP as a Service model, what we do have instead is a quick-to-deploy ReST API, with JSON output, and even a chrome extension to train your own dictionary.

Re: Natural Language Processing for the Working Programmer

#27
post #12

Earlier 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.

NLTK may very well be better. I only compared OpenNLP and Stanford because I was implementing my thesis in Scala and I wanted a library running on the JVM.

Re: Natural Language Processing for the Working Programmer

#28
post #11

I'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.

> Not much. It's a more expressive and cleaner language, but on the other hand python has NLTK + scipy community.

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

#29
post #2

I 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…

It isn't just extraction, but the entire process, from training a dictionary, to training it, etc. Have you tried training your own dictionary to extract custom entities? It is "non-trivial".

Re: Natural Language Processing for the Working Programmer

#30
One of the authors here: we wrote this during the Pragmatic Programmer's writing month in 2010 and some more in 2011. Then I got caught up writing my PhD thesis, and now a new job (as an NLP engineer, but in Java ;)).

So, the book is basically frozen. We hope to have more time in the future to continue the writing...

Post reply on HN