Currently, I am working in a FAQ bot, I have to include QnA pair each time when I get a new question related to the particular topic. Is it possible to revert to previous version if a particular QnA pair is not needed? This is the case, If I have added some hundred QnA pairs and I don't want it, Can I revert to previous version. From the QnA maker versioning its saying its not possible. As this is an earlier post, still that feature not present or in future there is a plan to include?
Also I know .tsv,.csv etc can be uploaded each time. Is there a provision to revert to previous version of QnA pair in QnA maker?
Short answer:
No, it has not changed since 2017. For plans to include it, I don't know, and there is no "iteration" or "version" in QnA Maker app.
Long answer:
But with some development, you can handle it.
You can see the list of API methods available for QnA Maker knowledge base management: https://westus.dev.cognitive.microsoft.com/docs/services/5a93fcf85b4ccd136866eb37/
In particular, you can focus on Update Knowledgebase method here: as you can see in its body sample, there is a delete block:
{
"add": {
"qnaList": [],
"urls": [],
"files": []
},
"delete": {
"ids": [
4,
13,
35
],
"sources": [
"Custom Editorial"
]
},
"update": { ... }
}
So you can use this method to "rollback" the entries that you added previously.
But be careful, because you have to use the id fields and they are not matching the id field used when you are using add.
Also I know .tsv,.csv etc can be uploaded each time. Is there a
provision to revert to previous version of QnA pair in QnA maker?
That may be a good option for quick rollback, if you save your KB every time before a modification, because you will not need to process the ID as mentioned above.
Related
I'm finding conflicting information on creating one time use deep links.
expire desktop_url generated through branch SDK after one time use
The documentation on "type" says "Must be an int. Set to 1 to limit deep link to a single use. Set to 2 to make the link show up under Quick Links while adding $marketing_title to data. Does not work with the Native SDKs." (https://docs.branch.io/links/integrate/)
I created a link using the included JSON with a POST to https://api2.branch.io/v1/url.
{
"branch_key": "*********************",
"data": {
"entityId": "282fd3da-5200-45f4-80a2-4f3a1c36bff6",
"$link_exp_date": 1567271700000
},
"type": 1,
"feature": "test_feature",
"tags": []
}
I expected the URL to be available for one time use. However I am able to successfully use the link multiple times until it expires. And retrieving the link using GET https://api.branch.io/v1/url doesn't return any properties that indicate the link was used.
Even before creating a deep link and testing, you need to integrate the Branch SDK in your respective app (Android, iOS etc).
The simple way to create a deep link is via dashboard and test this when the app is installed.
I have tried to check In and check Out a Bulk guest using /4.0/guestlists/{guestlist_id}/guests/_bulk API function. But it's not updating the status. Except for Status, it is updating everything. Can anyone help me out to solve this problem?
The Social Tables API doesn't currently support updating the checked_in_status using the /4.0/guestlists/{guestlist_id}/guests/_bulk route.
To achieve this functionality you will need to use:
/4.0/guestlists/{guestlist_id}/guests/checkin
body:
{
guests: ["guest_id_1", "guest_id_2"],
event_name: "Some Event Name" // optional. used by check-in notifictations
}
This currently does not support setting to checked-out or to reset the Guest to non checked-in state. If this is the desired functionality please let us know and we can add it to our external API.
Please feel free to ask if you have any other questions!
UPDATED
You can now provide a checked-in status to the bulk check-in route
{
"guests": [
"99b4ae20-2779-11e6-b0b7-13c2616041ae",
"99b4ae21-2779-11e6-b0b7-13c2616041ae"
],
"checked_in": 1,
"event_name": "Some Event Name" // optional. used by check-in notifictations
}
I have a handful of WordPress websites that use The Events Calendar for displaying events that are open to the public.
I notice if I type a cities name and then the word event, that our website is not being pulled in to the special section that appear. Google uses its Knowledge Graph. I was looking through the source code and noticed that our sites uses JSON-LD, generated from the information used for the event, one of the methods Google talks about using, but don’t understand why our site information isn’t being shown.
These sites have been up a year and get 3k visits a month so they're being indexed fairly regularly.
I was looking through the event properties JSON-LD, and I noticed the entire event address (street, city, state zip) gets put inside the name property of the Place or Postal array (Heres a screenshot of my sites schema). When I look up other events that are pulled into Google, they list the those attributes in the address properties (Screenshot of other site’s schema).
I think because the address is put into the name property instead of the address property, that Google might not be showing the events. Has anybody else seen this happen with their sites? Or is something else wrong with the sites we set up?
Right now your events are marked up using the Google example, but I believe this is wrong:
https://developers.google.com/structured-data/rich-snippets/events
"location" : {
"#type" : "Place",
"sameAs" : "http://www.hi-dive.com",
"name" : "The Hi-Dive",
"address" : "7 S. Broadway, Denver, CO 80209"
}
2019 edit: The markup and URL above have since changed and match what is expected from the testing tool.
In order for your sites structured data to match that other event you have a screen shot of, you will need to adjust your JSON-LD to the way it's presented on schema.org, which uses PostalAddress and narrows down a little bit more:
https://schema.org/location (and https://schema.org/PostalAddress) - Click the JSON-LD example tabs
"location": {
"#type": "Place",
"name": "Withworth Institute",
"address": {
"#type": "PostalAddress",
"addressLocality": "Seattle",
"addressRegion": "WA",
"postalCode": "98052",
"streetAddress": "20341 Whitworth Institute 405 N. Whitworth"
},
"url": "wells-fargo-center.html"
}
I can't say for certain if this is the primary reason for your issue but I do think you should follow the schema.org approach either way. Even the Structured Data Tool per your screenshots seems to indicate that it's looking for postalAddress even though Google doesn't use that in the example.. perhaps that article is outdated.
I can confirm that a migration to JSON-LD from inline RDFa style schema, which validates 100% using their new rich snippet validator tool no longer shows Review stars in search results. They've also taken away the ability to see stars validate using old style RDFa schema validation.
This could be an issue with the search team not talking to the developers responsible for the structured data and schema tools, rolling out disjointed feature upgrades. Their recommended use of JSON-LD will likely have a negative impact on display in search in the near term if you'd like to see additional meta data populate in search results pages.
If meta data in search results is a firm requirement you could roll off your JSON-LD module and use a module with the older RDFa or microdata implementation inline in your HTML. Hopefully this will be remedied soon.
Let's assume that I have a resource called group with the following representation:
{
"id": 1,
"name": "Superheroes"
"_links": {
"self": {
"href": "http://my.api.com/groups/1"
}
}
}
Now let's say I want to create a new person instance by POSTing to /persons/1. Which of the following should I use for the request body:
Using ID
{
"name": "Batman",
"groupId": 1
}
Using link
{
"name": "Batman",
"group": "http://my.api.com/groups/1"
}
With the first method I access the id directly either to look up the related resource or eventually store the id in the database, when I persist the person instance. But with the other method, I either have to extract the id from the URI or, follow the link to load the related resource, and then find out its id. I really don't want to store the URI in the database.
With the latter option, seeing that the server controls the structure of the URI, is it fine for me to parse the id out of the link? Following the link back to the server itself seems odd, seeing that at this point we already have access to the information directly (we just need the id).
So to sum up, which of these options is best?
Use the id directly.
Use the link, but parse out the id.
Use the link, but access the link to get the resource instance, and then get the id.
TL;DR: Use simple ids.
More detailed explanation:
A straightforward approach is to create a person by POSTing to /groups/1/persons with a payload {"name": "Batman"}.
However, while such approach works for simple cases, the situation gets complicated if there are 2 resources that need to be referenced. Let's assume that a person also needs to belong to exactly one company:
GET /persons/1
{
"name": "Batman",
"group": 1, // Superheros, available at /groups/1
"company": 5 // Wayne Enterprises, available at /companies/5
}
Since there is no relationship between companies and groups, it is not semantically correct to create a person via POSTing to /groups/1/companies/5/persons or to /companies/5/groups/1/persons.
So let's assume you want to create a person with a request looking like this:
POST /persons
{
"name": "Batman"
"group": ???, // <--- What to put here?
"company": ??? // <--- What to put here?
}
Which brings us to the answer to your question:
Ease of use. Your API should be primarily designed for the ease of use. This is especially true, if you design a public API. Therefore, Option 2 (Use the link, but parse out the id) is out, since it imposes additional work for clients of your API.
Constructing search queries. If you want to be able to query persons which belong to the company 10 and the group 42, simple ids lead to more readable and less error-prone urls. Which of the following do you consider more readable?
URL with a simple id:
GET /groups/42?company=10
or URL with a url-encoded link:
GET /groups/42?company=http%3A%2F%2Fmy.api.com%2Fcompanies%2F10
I wouldn't underestimate the point of readability. How many times do you need to debug your API in various curls, logs, postmans, etc.
Development Links need to be parsed in the backend, while simple ids can be used directly. It's not about performance, but rather about additional work/tests you have to put in.
Endpoint maintenance. Imagine that your API endpoint evolves. You decide one day to switch to https or to include versioning in the url. This might break API clients, if they for some reason rely on structure of the links. Also, you might want to checkout if link parsing on your backend is done properly.
Argumentum ab auctoritate I know this is not a proper argument, but if you checkout APIs of large players, e.g. Twitter, Github or Stripe, they all use simple ids.
HATEOAS. One common argument in favour of links is that it is aligned with HATEOAS. However, as far as I know, this relates to additional links in API responses rather than using links in payloads of POST requests.
All in all, I would go for simple ids, since I haven't yet heard a compelling argument favouring links, which would beat the aforementioned.
You are missing two important things here.
You need a standard way to describe forms in the response, in this case your POST form.
The information about the group ids / uris, or how to get them has to be described in the form in a standard way.
For example a HTML FORM with a SELECT INPUT would be RESTful. The closest thing we got in json to do the same is json-ld and hydra. But if you are obsessed with hal, then use hyperagent forms or something like that. It will never be a standard, but if compatibility is not an issue, then it is good enough.
To answer your question, you should use the id, because the server knows how to interpret it. The client needs the resource identifiers, the server needs it only in the uri part of the request, not in the body.
From my experience, it is always best to go with the simplest solution for making requests.
The process of generating a new url and parsing it seems excessive to get a resource, whereas sending the id of the item you want seems much simpler.
Thus, I would send a request in the form:
{
"name": "Batman",
"group": 1
}
I would like to do something like facepile using the graph api with open graph 2 actions : from a custom object and a custom object, give me the friends (using my facebook application) that did this action on this object.
The problem is that using FQL, I cannot query custom objects and actions. Using the graph API, I cannot find a way to intersect the list of my friends with the object I'm interested in.
The best I could do was the following using the batch mode of the graph API :
batch=[
// First we get the list of friends that are using my facebook application
{ "method": "GET", "relative_url": "fql?q=SELECT+uid+FROM+user+WHERE+uid+IN+(SELECT+uid1+FROM+friend+WHERE+uid2=me())+AND+is_app_user=1+LIMIT+0,49", "name": "friends"},
// Then query each friend to get the list of objects that went through my namespace:testaction
{ "method": "GET", "relative_url": "{result=friends:$.data.0.uid}/namespace:testaction" },
{ "method": "GET", "relative_url": "{result=friends:$.data.1.uid}/namespace:testaction" },
...
{ "method": "GET", "relative_url": "{result=friends:$.data.49.uid}/namespace:testaction" }
]
It's quite inefficient and does not fully resolve my issue since :
I still have to filter the results to get only the one that matches
the object I want
If there is a large number of objects in namespace:testaction, I have to go through paging, doing more queries (I try to minimize the number of queries)
Do you see a better way to do this ?
This probably isn't exactly what you're looking for, but given the fact that facebook (AFAIK) doesn't provide (and will probably never provide) the ability to do this. I think you should simply store the information yourself and then query the data from your own database. It would be like what you're doing in your question, but you can optimize it since it's your database.
I'm sure you thought about this already, but someone had to say it.
It's now possible to do this with one Graph API request:
GET https://graph.facebook.com/me/friends?limit=50&fields=name,namespace:testaction.limit(100)
see field expansion and updates to the graph API.
If the answer derickito gave is not enough, you should explore getting your app on the Facebook white-list (aka become a partner) to get at some the private Graph API where this functionality might exist, but is not available for "normal" application that are stuck using the public Graph API.