Skip to content

language: allow raw request objects to annotate() #1998

Description

@jmuk

From internal feedback from the API team:

https://github.com/GoogleCloudPlatform/google-cloud-node/blob/master/packages/language/src/document.js#L235

annotate has options for features, named as entities, sentiment, and syntax. They are different from the terms in the API reference, thus, we should put the references in the comments of each features (entities -> extractEntities, syntax -> extractSyntax, sentiment -> extractDocumentSentiment). Also better to have a link to https://cloud.google.com/natural-language/docs/reference/rest/v1/documents/annotateText#features

cc: @monattar

Activity

  1. added
    api: languageIssues related to the Cloud Natural Language API API.
    on Feb 15, 2017
  2. stephenplusplus commented on Feb 15, 2017

    @stephenplusplus
    Contributor

    I think annotate was meant to accept a raw API request object in the form of https://cloud.google.com/natural-language/docs/reference/rest/v1/documents/annotateText#features, but it didn't end up that way. So instead of explaining the mapping of entities to extractEntities, we should allow this request to "just work":

    vision.annotate({
      extractEntities: true,
      extractSyntax: true
    }, function() {})

    So if they're using the upstream API docs as a reference, they won't need to use our aliases.

  3. jmuk commented on Feb 15, 2017

    @jmuk
    ContributorAuthor

    that should work. Thanks!

  4. changed the title [-][Language] features property name should refer to the actual vocabulary in the API references[/-] [+]language: allow raw request objects to `annotate()`[/+] on Feb 16, 2017
  5. added a commit that references this issue on Mar 1, 2017
    f733f33
  6. jmuk commented on Mar 1, 2017

    @jmuk
    ContributorAuthor

    Well, sorry for my misunderstanding, but I think the point of this feedback is the documentation and therefore simply allowing the those fields additionally isn't the solution (that would be a good thing to do though). The comments for those features fields should be updated in addition.

  7. stephenplusplus commented on Mar 1, 2017

    @stephenplusplus
    Contributor

    I think what we want is:

    Since we're in there, and since it's a pattern in other areas of the API, it would also be nice to allow the full name variants to work as well.

  8. jmuk commented on Mar 6, 2017

    @jmuk
    ContributorAuthor

    Current options vocabulary is good and we can keep it -- what API team cares is the relationship with the API documentations. Thus probably only the updating the link could be sufficient? @monattar for the confirmation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

api: languageIssues related to the Cloud Natural Language API API.priority: p0Highest priority. Critical issue. P0 implies highest priority.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions