We are used to that any NLU service integration with Botkit should be implemented as middleware. This is a fairly obvious approach.
Botkit Studio has added LUIS support out of the box recently. And that approach confuses me.
Depending on the resolved intent, I want to make an API call, passing extracted entities to the endpoint. Thus, the call chain looks like this:
Botkit App [calls Studio API] → Botkit Studio [sends message to the NLU service] → LUIS [resolves intent and entities] → Botkit Studio [finds convo object based on intent trigger and returns convo to the bot] → Botkit App [makes an API call from skill] → API [returns response to the bot] → Botkit App [sends response text to the chat client]
It makes me feel that I'm using it wrong. How do you use the new NLU feature for cases like this?
Thank you.
You can use LUIS directly as a middleware INSTEAD of or IN ADDITION to using the cloud. This can be useful if you wanted to say, only process content that does not result in a hear match to the NLP provider. The inbuilt LUIS support is designed for people that do no want to or are unable to code this kind of logic, and allows you to just work with Studio's trigger and console to help train the NLP provider.
You might want to check this out if you have not seen it, it takes you through how responses are evaluated in your studio application, and where you can manipulate that processing:
https://botkit.ai/docs/readme-pipeline.html
Related
At my current company, we extensively use OpenAPI and Stoplight Studio to define API contracts.
We are now starting to use message bus concepts, and would like to keep using Stoplight Studio for message definitions too.
I can't see anywhere on the Stoplight Studio website that specifically mentions message bus, or messaging.
Is this scenario supported by OpenAPI?
Not sure about "Spotlight Studio" specifically, but Async API was designed to bring OpenAPI style contract definitions to Event Driven Architectures.
In order to build a Google Assistant app, Google provides two different APIs as part of their node.js actions-on-google library :
ActionsSdkApp
DialogflowApp
There have a common interface, but I don't understand what the difference is between the two and why I would use one or the other.
In short, these two objects provide similar (although not identical) methods to handle requests and provide results for two default ways Google allows you to build an Action for the Assistant.
The DialogflowApp object is the one you will likely use for most purposes. It is meant to work with the Dialogflow tool, letting it handle the Natural Language Processing (NLP) components and passing the results, where appropriate, to your webhook. It provides a few methods that are specific to Dialogflow features, such as Contexts, and maps other things to the response format that Dialogflow expects.
The ActionsSdkApp is meant to be used if you are using your own NLP and your webhook is getting things directly from Google (without using Dialogflow). If you need to build an actions.json file, you're using the Actions SDK.
Both have common methods and idioms, such as app.ask() and app.tell() and mapping app.data to session storage and so forth, even if the details of implementing these are different for each type.
You should be using the one that matches the tool that you're using. For most new users - that will likely be Dialogflow and the DialogflowApp object.
Update
Note that the API in the question, the specific objects asked about, and the specific methods talked about in my answer are for the previous version of the library.
The concept of when to use the ActionSDK vs Dialogflow objects in the current library still hold, so the concept behind this question and answer are still valid, but the technical details have changed.
Update - Jun 2020
The library in question is now deprecated, since it no longer works with the current version of Actions on Google (Actions Builder/SDK AoG v3). It still works with Dialogflow (which uses AoG v2) and if you're still using the AoG v2 Actions SDK.
IN SIMPLE TERMS
Use the Actions SDK for one-shot apps. These are apps that provide the required answer directly after being invoked and then stop. They give you just this one result. A typical example would be setting a timer to ten minutes.
Use the Dialogflow for all other apps, for those that are really conversational, where there are multiple paths to follow and where you want your user to provide more information during the conversation.
I am working on a project and I need to use this tow api; jtapi, gjtapi. The problem is
both gjtapi and jtapi project seem dead. Is there a new similar java api?
JTapi is a specification that is implemented by vendors, as CISCO or AVAYA. In my experience, there is no an generic API for JTapi, because each provider customizes their own implementation according at their telephony platform.
If you want a "generic" JTapi you should review this link, that refer to an Asterisk JTapi:
http://asterisk-jtapi.sourceforge.net/
What are some web apps that allow me to play with any REST APIs visually (by clicking) and also get some code generated (in any language) that captures what I have described visually?
Similar to Swagger or Google API Playground but allows me to talk to anything that speaks REST (assuming I have the proper auth credentials and I know what messages it understands).
Bonus points for something that can also "discover" what messages are understood, given a URL endpoint.
Microsoft has 2 that I know of
OData API explorer
The data market service explorer (requires signing in, and then you can access free data sets)
Considering that REST API's are going to follow their own conventions, terms, and have their own documentation (hopefully), this is an impossible problem. If you restrict your quest to visualizing API's that follow a "standard" form of self-documentation (see REST web service WSDL? for some hopeful scenarios) you might be able to accomplish this.
Or you can use something like http://www.programmableweb.com/ to discover tutorials, tools, examples, and mashups of various existing APIs.
You could mock an API at http://apiary.io/.
You could explore and existing one through tools (e.g. REST Console for Chrome)
What you can't have, is one-size-fits-all explorer for "every possible REST API." Some APIs follow conventions that others don't.
apigee and apihub (now part of mulesoft) are two that I frequently visit. Of the two, apigee is my preferred provider.
One of the reasons that you're not going to see a lot of websites like this is because of the same-origin policy. This means that you can't access a RESTful API located at api.google.com from a web app running at, say, www.restfiddle.com without sending all the API traffic through restfiddle.com's servers. Sites like JSFiddle can exist (and are used widely) because all the processing is done on the client side.
Browser plugins, however, are exempt from the same-origin policy. If you're using Chrome, try Postman. If your REST client doesn't need to be web-based, check out SoapUI. IntelliJ IDEA has a nice REST client as well.
Try Restlet Studio, it's the only visual API designer I've found, and seems pretty good, it imports and exports swagger & RAML.
http://studio.restlet.com/
I'm looking for a server side component, preferably java, that will allow me to subscribe to pubsubhubbub feeds through javascript. I understand that subscribers are server side applications in the standard rest/pubsubhubbub format, but Google seems to have created a ajax bridge that looks quite handy.
Unfortunately, I'm dealing with data that simply cannot leave our servers, let alone go through Google's.
Is anyone aware of a (preferably free) server side proxy for pseudo javascript pubsubhubbub subscribers?
Reference: http://code.google.com/apis/feed/push/docs/index.html#hiworld
I know for a fact that Kwwika and Pusherapp are working on this. I can intro you with these guys if you want.
If not, I believe this should be relatively easy to build with stuff like Node.JS for example. This code on Github should be a good first start. Things like this have been built with it.
We (superfeedr) are trying to get more people building similar things...
I'm looking for a server side
component, preferably java, that will
allow me to subscribe to pubsubhubbub
feeds through javascript
There is a java implementation]1 of the subscribe part available. But the hub-part hasn't yet been implemented in java which is needed to subscribe to the feed which should be private. For the javascript(jquery) part I would just use simple long-polling.
Is anyone aware of a (preferably free)
server side proxy for pseudo
javascript pubsubhubbub subscribers?
I don't think a free solution like that exists (yet). Even google's push API isn't open yet.
Unfortunately, I'm dealing with data
that simply cannot leave our servers,
let alone go through Google's.
There isn't yet an implementation of the HUB-part of the pubsubhubbub protoccol. But if it is internally I also don't think you need this kind of fan-out the hub(specification) is offering(broadcast to other servers).
I think you could just use A comet framework like Atmosphere to suspend connection and broadcast feed diff. I think this can be written quick with the Atmosphere framework(1 day you will have a working prototype).
You can see an example using a combination of Superfeedr and Kwwika within a web application that lets you subscribe to any RSS feed or track keywords within RSS feeds here:
http://superfeedr.kwwika.com
And you can get the source code in GitHub here:
http://github.com/kwwika/ASP.NET-MVC-PubSubHubbub-Subscriber/tree/Kwwika-Superfeedr-Demo