gl_nlp() pukes w/ parameter nlp_type="analyzeSyntax" about googlelanguager HOT 10 CLOSED

Could you report the error message?

from googlelanguager.

Thanks for the quick work. Can I already github-install the new version?

Out of curiosity, w/ nlp_type="analyzeSyntax" I would only expect POS and lemmatization, and not expect sentiment to be returned, so it would seem the API is doing the right thing.

So my newbie question is: Is a fixed return format from a REST API a requirement in general? What am I missing?

from googlelanguager.

2018-02-16 17:21:50 -- analyzeSyntax: 23 characters
Error in data.frame(..., check.names = FALSE) :
arguments imply differing number of rows: 1, 0
Error: Result 1 is not a length 1 atomic vector
In addition: Warning message:
In call_api(the_body = body) :
API Data failed to parse. Returning parsed from JSON content.
Use this to test against your data_parse_function.

from googlelanguager.

Mark any luck with this issue?

from googlelanguager.

The problem was the API returned is inconsistent - when you request everything it includes the sentiment score, when you request just the analyzeSyntax part it omits it. This is a bug at the APIs end, which I will report, but I fixed the R error so that it won't stop if there isn't any content - it will return what it gets but it may not be what you needed in the first place :)

from googlelanguager.

Yes load the Github via remotes::install_github("ropensci/googleLanguageR")

They recently updated the API to include sentiment per entity, not just per document, which is what is (or isn't) being returned, so if you don't need it thats cool.

from googlelanguager.

I would argue that processing complexity is ordered as

nlp_type = c("analyzeSyntax", "analyzeSentiment", "analyzeEntities", "analyzeEntitySentiment", "annotateText")

i.e., if one explicitly requests syntax analysis ONLY he/she should not expect sentiment nor entities nor entity sentiment.

so maybe the API is doing the right thing already?

from googlelanguager.

I thought they were more independent than that but that does make sense.

from googlelanguager.

the reason NLP doesn't work in the real world (other than for fixed utterances) is because they proceed in this ordered fashion, which is also the reason most computer vision pipelines don't work well (edge detection, feature detection, object detection, etc.), from low to high level. indeed, true intelligence relies on a stack of modules with back-and-forth communication, where all are engaged simultaneously, perhaps seeking consistency maximization, impossible in the serial model.

crucially, that's why sentiment analysis fails to decode sarcasm. "congrats to XYZ customer service. after a quick 34 days in line, a brilliant representative happily deleted my purchase record".

from googlelanguager.

Interesting, I wonder if its easier to get these individual elements (e.g. per sentence sentiment) what people will build on top. For instance, your example relies on the context that 34 days in line isn't "quick", if that context can be added perhaps it can reverse the sentiment score and give it more a chance to detect humans being human :)

I missed your question:

So my newbie question is: Is a fixed return format from a REST API a requirement in general? What am I missing?

I read annotateText as a convenience function that is the combination of all the analysis in one big list, e.g analyzeSyntax plus the other 3 options. Its a bug in my mind if the analyzeSyntax part of the annotateText return is not the same as when you request analyzeSyntax on its own.

from googlelanguager.