Most of the other methods in the language api, such as analyze_syntax, analyze_sentiment etc, have the ability to return the constituent elements like
sentiment.score
sentiment.magnitude
token.part_of_speech.tag
etc etc etc....
but I have not found a way to return name and confidence in isolation from classify_text. It doesn't look like it's possible but that seems weird. Am missing something? Thanks
The language.documents.classifyText method returns a ClassificationCategory object which contains name and confidence. If you only want one of the fields you can filter by categories/name or categories/confidence. As an example I executed:
POST https://language.googleapis.com/v1/documents:classifyText?fields=categories%2Fname&key={YOUR_API_KEY}
{
"document": {
"content": "this is a test for a StackOverflow question. I get an error because I need more words in the document and I don't know what else to say",
"type": "PLAIN_TEXT"
}
}
Which returns:
{
"categories": [
{
"name": "/Science/Computer Science"
},
{
"name": "/Computers & Electronics/Programming"
},
{
"name": "/Jobs & Education"
}
]
}
Direct link to API explorer for interactive testing of my example (change content, filters, etc.)
Related
I understand that GitHub's GraphQL-based v4 API is much more efficient than the v3 API.
I would like to use the GraphQL API to retrieve, for a given repo:
All of the open milestones.
For each milestone, its title, description, all of its issues (open and closed)
For each issue, its title, description, status, and all messages.
Is there a straightforward way to do this?
Yes. It is straightforward to do so . The query looks like :
{
repository(owner: "gatsbyjs", name: "gatsby") {
description
url
milestones(states: [OPEN],first:2) {
nodes{
title
description
url
issues(states:[OPEN,CLOSED], first:2){
nodes{
title
state
url
comments(first:2){
nodes{
url
body
createdAt
}
pageInfo{
hasNextPage
endCursor
}
}
}
pageInfo{
endCursor
hasNextPage
}
}
}
pageInfo{
endCursor
hasNextPage
}
}
}
}
Note:
For the repository which the url is https://github.com/gatsbyjs/gatsby , its owner is gatsbyjs and its name is gatsby
Go to its API Explorer to try and fine tune the query.Click Ctrl+Space will auto-suggest the available fields that can be retrieved.
Do the paginating by yourself to loop through all records by adjusting the starting cursor and the number of records to be returned in first , after.
It gives you the following :
{
"data": {
"repository": {
"description": "Build blazing fast, modern apps and websites with React",
"url": "https://github.com/gatsbyjs/gatsby",
"milestones": {
"nodes": [
{
"title": "Next Major",
"description": "Issues that will require a breaking change, and which would constitute being done in the next major version of Gatsby.",
"url": "https://github.com/gatsbyjs/gatsby/milestone/5",
"issues": {
"nodes": [
{
"title": "Make accessibility warnings errors",
"state": "OPEN",
"url": "https://github.com/gatsbyjs/gatsby/issues/19945",
"comments": {
"nodes": [
{
"url": "https://github.com/gatsbyjs/gatsby/issues/19945#issuecomment-568891716",
"body": "Hiya!\n\nThis issue has gone quiet. Spooky quiet. 👻\n\nWe get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.\nIf we missed this issue or if you want to keep it open, please reply here. You can also add the label \"not stale\" to keep this issue open!\nAs a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out [gatsby.dev/contribute](https://www.gatsbyjs.org/contributing/how-to-contribute/) for more information about opening PRs, triaging issues, and contributing!\n\nThanks for being a part of the Gatsby community! 💪💜",
"createdAt": "2019-12-25T12:02:26Z"
},
{
"url": "https://github.com/gatsbyjs/gatsby/issues/19945#issuecomment-570779866",
"body": "Hey again!\n\nIt’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.\nPlease keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m `HUMAN_EMOTION_SORRY`. Please feel free to reopen this issue or create a new one if you need anything else.\nAs a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out [gatsby.dev/contribute](https://www.gatsbyjs.org/contributing/how-to-contribute/) for more information about opening PRs, triaging issues, and contributing!\n\nThanks again for being part of the Gatsby community! 💪💜",
"createdAt": "2020-01-04T12:02:28Z"
}
],
"pageInfo": {
"hasNextPage": false,
"endCursor": "Y3Vyc29yOnYyOpHOIgVo2g=="
}
}
},
{
"title": "Configurable output folder",
"state": "OPEN",
"url": "https://github.com/gatsbyjs/gatsby/issues/1878",
"comments": {
"nodes": [
{
"url": "https://github.com/gatsbyjs/gatsby/issues/1878#issuecomment-324062470",
"body": "Do you have a specific use case in mind? This has been discussed before but no one has come up with a concrete use case that justified adding a new option.\r\n\r\nEvery option we add to Gatsby makes the project more complex which has all sorts of long-term costs so unless something is really valuable, I'd rather people handle this sort of thing themselves e.g. just copy the files to the output directory you want or create a symlink. This could easily be turned into a plugin that people could install, etc.",
"createdAt": "2017-08-22T15:27:41Z"
},
{
"url": "https://github.com/gatsbyjs/gatsby/issues/1878#issuecomment-324074853",
"body": "Yes, I have a use-case. I am going to use Gatsby for a documentation part as a part of complex project. All static files (Gatsby output, plus some others) should be placed into one folder `build`, that will be deployed somehow later. In other words, the Gatsby output is only one subfolder in my setup.\r\n\r\nSo far I have worked this around in `postbuild` step, but it looks hacky:\r\n\r\n```\r\n\"build\": \"gatsby build\",\r\n\"postbuild\": \"mv public build/gatsby-subsite\"\r\n```\r\nAdding configurable output folder will reduce this complexity and will help me not to move files around one more time.",
"createdAt": "2017-08-22T16:08:21Z"
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "Y3Vyc29yOnYyOpHOE1D9ZQ=="
}
}
}
],
"pageInfo": {
"endCursor": "Y3Vyc29yOnYyOpLPgAAAAAAAArvODwULXA==",
"hasNextPage": true
}
}
}
],
"pageInfo": {
"endCursor": "Y3Vyc29yOnYyOpHOAEEbsw==",
"hasNextPage": false
}
}
}
}
}
I am new to GraphQL and I wonder how I can explore an API without a possible wildcard (*) (https://github.com/graphql/graphql-spec/issues/127).
I am currently setting up a headless Craft CMS with GraphQL and I don't really know how my data is nested.
Event with the REST API I have no chance of just getting all the data, because I have to setup all the endpoints and therefore I have to know all field names as well.
So how could I easily explore my CraftCMS data structure?
Thanks for any hints on this.
Cheers
merc
------ Edit -------
If I use #simonpedro s suggestion:
{
__schema {
types {
name
kind
fields {
name
}
}
}
}
I can see a lot of types (?)/fields (?)...
For example I see:
{
"name": "FlexibleContentTeaser",
"kind": "OBJECT",
"fields": [
{
"name": "id"
},
{
"name": "enabled"
},
{
"name": "teaserTitle"
},
{
"name": "text"
},
{
"name": "teaserLink"
},
{
"name": "teaserLinkConnection"
}
]
But now I would like to know how a teaserLink ist structured.
I somehow found out that the teaserLink (it is a field with the type Entries, where I can link to another page) has the properties url & title.
But how would I set up query to explore the properties available within teaserLink?
I tried all sorts of queries, but I am always confrontend with messages like this:
I would be really glad if somebody could give me another pointer how I can find out which properties I can actually query...
Thank you
As far as I'm concerned currently there is no graphql implementation with that capability. However, if what you want to do is to explore the "data structure", i.e, the schema, you should use schema instrospection, which was thought for that (explore the graphql schema). For example, a simple graphql instrospection query would be like this:
{
__schema {
types {
name
kind
fields {
name
}
}
}
}
References:
- https://graphql.org/learn/introspection/
UPDATE for edit:
What you want to do I think is the following:
Make a query like this
{
__schema {
types {
name
kind
fields {
name
type {
fields {
name
}
}
}
}
}
}
And then find the wished type field to grab more information (the fields) from it. Something like this (I don't know if this works, just an idea):
const typeFlexibleContentTeaser = data.__schema.types.find(t => t === "FlexibleContentTeaser")
const teaserLinkField = typeFlexibleContentTeaser.fields.find(f => f.name === "teaserLink")
const teaserLinkField = teaserLinkField.type.fields;
i.e, you have to transverse recursively through the type field.
I would like to specify inner constraints in a GraphQL query that would limit the results of the outermost query as part of a query / predicate builder I'm working on. I'm not sure if this is considered to be within GraphQL's capabilities but it makes sense to me as something that people would want to do.
For example, I might want to show a list of blog posts that were recently commented on like this:
{
posts{
title
date
comments(since: $earliestDate){
body
date
author {
name
}
}
}
}
The normal behaviour of this would be to bring back all blog posts and only comments that met the criteria.
{
"posts": [
{
"title": "Post 1",
"date": "2017-07-31"
"comments": [
]
},
{
"title": "Post 2",
"date": "2017-06-10",
"comments": [
{
"body": "Comment text",
"date": "2017-08-09",
"author": {
"name": "Michael"
}
}
]
}
]
}
But I want my query to prevent the retrieval of "Post 1" because it has no comments in the last month, but I'm not sure that's something GraphQL will make easy to do.
Is there functionality within GraphQL to support returning this result?
{
"posts": [
{
"title": "Post 2",
"date": "2017-06-10",
"comments": [
{
"body": "Comment text",
"date": "2017-08-09",
"author": {
"name": "Michael"
}
}
]
}
]
}
TL;DR - In general, you want the behavior of a field to only be defined by:
The arguments passed to that field
The identity of the object that is being queried
The global context of the query (eg, the identity of the user executing the query)
I think that the behavior you're after is not really ideal for GraphQL. At least as I've seen, GraphQL tends to treat fields as relatively independent from each other (even though they're nested).
For example, you would not expect arguments passed to a child field to change the behavior of its parent. And similarly, I think you would not expect the presence or absence of a child field to change the behavior of its parent.
The best way to accomplish the behavior you're after would be to add an argument to the posts field, indicating that only posts with comments should be returned:
{
posts(withCommentsOnly: true) {
title
date
comments(since: $earliestDate) {
body
date
author {
name
}
}
}
}
To understand the reasons why, just think about these kinds of scenarios:
{
authors {
id
posts {
comments { body }
}
}
}
If this query has the behavior you describe, for each author, you would only get the posts which also have comments. But then imagine that you re-query one of those authors later:
{
node(id: "author_id") {
... on Author {
posts { title }
}
}
}
Now would you get a different set of posts? That kind of behavior would make it very difficult for people to query your GraphQL schema using standard GraphQL clients, because client-side caching mechanisms would probably not be able to correctly update their caches.
Firebase Data is structured as JSON. As per the best practice we should create denormalised form of Data. We should push same data in different nodes. As per their documentation it is okay to duplicate data in different branch.
How should I structure this data in Firebase?
I am writing a blogging application that was there in PARSE and wants to migrate to Firebase .
Each of my Blog is having different hashTags. These HashTags are clickable. So when we click a particular hashTag it will redirect to a page with common blogs having same hashTags .
How do we conceptualize above hash tag behaviour in Firebase.
How to structure the data so that i can query all blogs for a particular hashtag ?
like select * from [blogs] where tag = '#hashtag'
Try this
blogs
blog_01
hashtag:"#hashtag"
data: "some data"
blog_02
hashtag: "#anotherHashtag"
data: "more data"
blog_03
hashtag: "#superHashtag"
data: "another data"
and the code
ref = rootRef.childByAppendingPath("blogs")
ref.queryOrderedByChild("hashtag").queryEqualToValue("#anotherHashtag")
.observeEventType(.Value, withBlock: { snapshot in
//.Value can return multiple nodes within the snapshot so iterate over them
for child in snapshot.children {
let hash = child.value.objectForKey("data") as! String
print(hash) //prints 'more data'
}
})
Edit: This is OS X Swift code but you can get the general idea as it applies across platforms.
I think Firebase wants you to do something similar to this:
{
"blogs": {
"blog1": {
"name": "blogpost1",
"text": "blogpost1 text"
"tags": {
"tag1": true,
"tag2": true,
"tag3": true
}
},
"blog2": {
"name": "blogpost2",
"text": "blogpost2 text"
"tags": {
"tag1": true
}
},
"blog3": {
"name": "blogpost3",
"text": "blogpost3 text"
"tags": {
"tag1": true
}
}
}
{
"tags": {
"tag1": {
"blog1": true,
"blog2":true,
"blog3":true,
},
"tag2": {
"blog1":true
},
"tag3": {
"blog1":true
}
}
}
I hope this helps. Essentially you would query your tags json with the each tag containing the key for a respective blog post. A good next step would be to probably, as opposed to putting true as a value in the tags, put a date so that you can order the post in your search results sequentially.
Post what you came up with as a solution please.
I'm trying to decide upon the best format of response for my API. I need to return a reports response which provides information on the report itself and the fields contained on it. Fields can be of differing types, so there can be: SelectList; TextArea; Location etc..
They each use different properties, so "SelectList" might use "Value" to store its string value and "Location" might use "ChildItems" to hold "Longitude" "Latitude" etc.
Here's what I mean:
"ReportList": [
{
"Fields": [
{
"Id": {},
"Label": "",
"Value": "",
"FieldType": "",
"FieldBankFieldId": {},
"ChildItems": [
{
"Item": "",
"Value": ""
}
]
}
]
}
The problem with this is I'm expecting the users to know when a value is supposed to be null. So I'm expecting a person looking to extract the value from "Location" to extract it from "ChildItems" and not "Value". The benefit to this however, is it's much easier to query for things than the alternative which is the following:
"ReportList": [
{
"Fields": [
{
"SelectList": [
{
"Id": {},
"Label": "",
"Value": "",
}
]
"Location": [
{
"Id": {},
"Label": "",
"Latitude": "",
"Longitude": "",
"etc": "",
}
]
}
]
}
So this one is a reports list that contains a list of fields which on it contains a list of fieldtype for every fieldtype I have (15 or something like that). This is opposed to just having a list of reports which has a list of fields with a "fieldtype" enum which I think is fairly easy to manipulate.
So the Question: Which format is best for a response? Any alternatives and comments appreciated.
EDIT:
To query all fields by fieldtype in a report and get values with the first way it would go something like this:
foreach(field in fields)
{
switch(field.fieldType){
case FieldType.Location :
var locationValue = field.childitems;
break;
case FieldType.SelectList:
var valueselectlist = field.Value;
break;
}
The second one would be like:
foreach(field in fields)
{
foreach(location in field.Locations)
{
var latitude = location.Latitude;
}
foreach(selectList in field.SelectLists)
{
var value= selectList.Value;
}
}
I think the right answer is the first one. With the switch statement. It makes it easier to query on for things like: Get me the value of the field with the id of this guid. It just means putting it through a big switch statement.
I went with the first one because It's easier to query for the most common use case. I'll expect the client code to put it into their own schema if they want to change it.